(RFC 3240 published February 2002, subtype last updated February 2002)

MIME media type name: Application

MIME subtype name: dicom

Required parameters:

"id" is constructed from a DICOM File ID (see DICOM PS3.11). The
total length is limited to 71 characters. Each component is
limited to 8 characters. The delimiter is a forward slash "/".
There is never a leading delimiter (i.e., this is not a
traditional path from a root directory).

If a DICOMDIR (which provides an index of files) is included, then
it will refer to other DICOM files in the file set by use of this
File ID. The File ID is not encoded within each DICOM file. If a
DICOMDIR is not present, then the "id" parameter may be absent.
Note that the DICOMDIR will also have a Media Type of
application/dicom and is distinguished from other files by its ID
of "DICOMDIR".

For example:
"ROOTDIR/SUBDIR1/MRSCAN/A789FD07/19991024/ST00234/S00003/I00023"

Each component shall be character strings made of characters from
a subset of the G0 repertoire of ISO 8859. This subset consists
of uppercase alphabetic characters, numeric characters and
underscore. The following characters are permissable:

A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V,
W, X, Y, Z (uppercase)
1, 2, 3, 4, 5, 6, 7, 8, 9, 0 and _ (underscore)

Optional parameters:

none

Encoding considerations:

The DICOM information is binary, therefore the encoding used shall
support lossless transfer of binary information. Typically, the
Content-Transfer-Encoding would be set to "Base64".

Multiple DICOM parts should be included as a Multipart/related
entity [2387]. Receiving agents shall also support multiple parts
as a Multipart/mixed entity. When multiple DICOM parts are
included, one of the parts may be a DICOMDIR, in which case, all
the files referred to by the DICOMDIR shall also be present. The
DICOMDIR is not required to be the first Application/dicom part
encoded in the message, in which case the optional "start"
parameter should refer to the content-id of the part containing
the DICOMDIR.

Multiple DICOM Application/dicom parts may be included with other
types of parts as a Multipart/mixed entity.

Security considerations:

Application/dicom parts contain medical information, including
individual demographic information. Accordingly, their exchange
should be restricted to a secure network or within a secure
wrapper that protects a patient's right to confidentiality
according to local and national policy. The specific security
mechanisms are outside the scope of this proposal. Such
mechanisms as Secured MIME (S/MIME) [2633] or similar might be
appropriate.

Interoperability considerations:

Because DICOM information is specific to the medical (imaging)
domain, generic e-mail applications may not be able to interpret
the information.

The Media Type has been designed in order to allow for

(i) DICOM aware applications to interoperate,
(ii) generic applications to save the files in a form
recognizable as DICOM files, that a DICOM application may
subsequently use.

Published specification:

The Digital Imaging and Communications in Medicine (DICOM)
Standard is a standard of the DICOM Standards Committee, published
by the National Electrical Manufacturers Association (NEMA), 1300
N. 17th Street, Rosslyn, Virginia 22209 USA,
(http://medical.nema.org).

Applications which use this media:

Biomedical imaging applications.

Additional information:

1. Magic number(s): "DICM" after 128 byte preamble indicates DICOM
PS 3.10 file

2. File extension(s): ".dcm" is recommended for files saved to
disk (other than DICOMDIR)


3. Macintosh file type code: Macintosh File Type "DICM" is
recommended

4. Object Identifiers: none

Person to contact for further information:

1. Name: Howard Clark
2. E-mail: how_clark&nema.org

Intended usage:

Common

Interchange of biomedical images.

Author/Change controller:

DICOM Standards Committee