RFC 3240

RFC 3240 💖 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration

okay bestie, RFC 3240 is an Informational doc (so it's not an Internet standard, just useful info 🧚) from the DICOM Committee, written by D. Clunie and E. Cordonnier, dated February 2002. It's Request for Comments number 3240 in the Network Working Group. The header doesn't have an Obsoletes or Updates line, so it doesn't replace or change anything else. 🎀

Status of This Memo ✨

This memo is information for the Internet community, not an Internet standard of any kind. Distribution is totally unlimited, so share it with everyone 💅

Copyright Notice 🌸

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🦋

This doc registers the MIME sub-type application/dicom, which stands for Digital Imaging and Communications in Medicine. The baseline encoding comes from the DICOM Standards Committee's "Digital Imaging and Communications in Medicine" 📖

1. DICOM Definition 🩺

DICOM is the protocol and format spec for swapping images, time-based waveforms, reports and related info in medical apps. It's giving organized medical data energy 🔥

Single DICOM objects (like images) can be packed into files and emailed using this media type. A whole set of DICOM files can also come with a DICOMDIR index file that points to them 🗂️

2. IANA Registration 📝

Media type name 💜

Application

Subtype name 💜

dicom

Required parameters ✨

The id parameter is built from a DICOM File ID (see DICOM PS3.11). The whole thing is capped at 71 characters, and each component is capped at 8 characters. The delimiter is a forward slash /. There's never a leading delimiter, so it's not a regular path from a root directory, no cap 🙈

If a DICOMDIR (the index of files) is included, it points at the other DICOM files in the set using this File ID. The File ID isn't stored inside each DICOM file itself. If there's no DICOMDIR, the id parameter can be left out. The DICOMDIR also has the media type application/dicom, and you can tell it apart from other files because its ID is DICOMDIR 🫶

Here's an example:

"ROOTDIR/SUBDIR1/MRSCAN/A789FD07/19991024/ST00234/S00003/I00023"

Each component has to be a character string using only characters from a subset of the G0 repertoire of ISO 8859. That subset is uppercase letters, digits and underscore. These characters are allowed:

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. Easy 💅

Encoding considerations 🍓

DICOM info is binary, so the encoding has to support lossless transfer of binary information. Usually the Content-Transfer-Encoding is set to Base64.

Multiple DICOM parts should be sent as a Multipart/related entity [2387]. Receiving agents shall also support multiple parts as a Multipart/mixed entity. If you include multiple DICOM parts, one of them can be a DICOMDIR. In that case, every file the DICOMDIR refers to shall also be present. The DICOMDIR doesn't have to be the first Application/dicom part in the message. If it isn't, the optional start parameter should point to the content-id of the part that holds the DICOMDIR 🧩

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

Security considerations 🔐

This part is SERIOUS, bestie 😭 Application/dicom parts hold medical information, including individual demographic info. So their exchange should be restricted to a secure network or wrapped in a secure wrapper that protects a patient's right to confidentiality, following local and national policy. The specific security mechanisms are outside the scope of this proposal. Mechanisms like Secured MIME (S/MIME) [2633] or similar might be appropriate.

Interoperability considerations 🤝

DICOM info is specific to the medical imaging domain, so generic email apps might not be able to interpret it.

The media type was designed to allow two things:

• (i) DICOM-aware applications to interoperate
• (ii) Generic applications to save the files in a form recognizable as DICOM files, which a DICOM application can then use later

Published specification 📚

The DICOM Standard is maintained by the DICOM Standards Committee and 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 a 128 byte preamble indicates a 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: The 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. It's for interchanging biomedical images.

Author/Change controller 👑

DICOM Standards Committee

3. References 📚

[DICOM] DICOM Standards Committee, "Digital Imaging and Communications in Medicine", 2001.

[2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.

[2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

4. Authors' Addresses 💌

David Clunie
RadPharm
943 Heiden Road
Bangor PA 18013
USA

Phone: +1-570-897-7123
Fax:   +1-425-930-0171
EMail: dclunie@dclunie.com


Emmanuel Cordonnier
Etiam
20 rue du Pr J. Pecker
35000 Rennes
France

Phone: +33(0)299 14 33 88
Fax:   +33(0)299 14 33 80
EMail: emmanuel.cordonnier@etiam.com

5. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society.