Journal:Thirty years of the DICOM standard

From LIMSWiki
Jump to navigationJump to search
Full article title Thirty years of the DICOM standard
Journal Tomography
Author(s) Larobina, Michele
Author affiliation(s) Consiglio Nazionale delle Ricerche
Primary contact Email: michele dot larobina at cnr dot it
Year published 2023
Volume and issue 9(5)
Page(s) 1829-1838
DOI 10.3390/tomography9050145
ISSN 2379-139X
Distribution license Creative Commons Attribution 4.0 International
Download (PDF)


Digital Imaging and Communications in Medicine (DICOM) is an international standard that defines a format for storing medical images and a protocol to enable and facilitate data communication among medical imaging systems. The DICOM standard has been instrumental in transforming the medical imaging world over the last three decades. Its adoption has been a significant experience for manufacturers, healthcare users, and research scientists. In this review, 30 years after introducing the standard, we discuss the innovation, advantages, and limitations of adopting DICOM and its possible future directions.

Keywords: DICOM, metadata, file formats, communication protocols, quantitative imaging


Standardization is a key concept in the digital imaging world. The absence of a standard limits the usability and sharing of medical images. It forces users to deal with a multitude of data formats and to convert data from one format to another. Moreover, any image file, in addition to pixel data, contains metadata. Metadata is data describing the image and plays a non-secondary role in digital imaging. While general-purpose image format metadata can be limited to the description of the pixel matrix, in formats for scientific applications metadata can describe the subject, the instrumentation set-up, the image acquisition parameters, and any other element of interest related to the imaging workflow. Despite this, the power of metadata is most often underestimated and consequently unexpressed. A standard helps in defining the metadata section for the correct use and interpretation of the image itself.

The field of medical imaging is exemplary in the context of standardization processes for pioneering vision and for having created a long-lived and appreciated standard. In the early 1980s, an association of users and professionals of the healthcare sector, the American College of Radiology (ACR), jointly with the National Association of Electronic Manufacturers (NEMA), started to define a new standard for the encoding and exchange of digital medical images. In 1993, the ACR-NEMA committee presented Digital Imaging and Communications in Medicine (DICOM) as a standard with more functionality and long-term vision than the previous standardization attempts known as ACR-NEMA 1.0 (1985) and 2.0 (1988).[1][2][3][4][5][6][7] For its time, DICOM represented an authentic novelty. Before the introduction of the DICOM standard, and therefore, until the first half of the 1990s, the medical imaging world saw diagnostic modalities, even within the same department, very confined to their rooms. The images were generally printed to film to be interpreted by the radiologist. In a native digital format, images were viewed and processed on the modality console and rarely exported to different workstations. Medical imaging systems were not connected to each other except for some dedicated point-to-point connections. Image transfer between modalities and image processing workstation, both inside and outside an imaging department, took place mainly through removable media with an important limitation: the absence of a common file format and the unknown of correctly reading the removable media storage (typically a magneto-optical disks or a tape). Therefore, the usability of the images remained linked to the availability of software for reading proprietary image formats and the media themselves. (A complete overview of the old proprietary file formats can be found on the David Clunie Medical Image Formats website.[8]) The DICOM international standard was conceived to overcome the limitations imposed by proprietary architectures and data formats and to allow and promote communication among medical imaging devices using the same network infrastructures of internet-enabled computer networks.

With its conception, the novelties of the DICOM standard were:

  • To state that in medicine the standardization of image format and image-related information, as well as their communication over a network, is essential;
  • To remark that, for medical images, metadata is as important as pixel data; and
  • To be general enough to cover almost every medical imaging modality and flexible enough to follow their evolution over time.

First developed for radiology and then cardiology departments, the DICOM standard has evolved over the years to support various other branches of medical imaging well beyond radiology, such as dermatology and ophthalmology, with the objective to encompass almost all modalities of imaging-based medicine. There are approximately 80 modalities defined by the standard today. DICOM is also the current standard for radiation therapy in the so-called second-generation radiotherapy after a complete revision in 2014. DICOM also supports data exchange of time-based signals or waveforms, such as those generated in clinical neurophysiology, which include, among others, electrocardiograms (ECGs) and electroencephalography (EEG). In more recent times, the DICOM standard has been proposed for digital pathology. The adoption of the standard in this area would favor the integration of clinical imaging and laboratory medicine.[9][10][11] DICOM does not limit its action to images and associated information originating directly from medical devices. It defines mechanisms for archiving and sharing quantitative derived images, image-derived data, annotations, and reports.

DICOM is a constantly evolving standard and is revised five times a year with contributions from the numerous DICOM working groups divided by fields of application and imaging modalities.[12] However, DICOM only provides recommendations and no accompanying software. Despite this, the availability of some high-quality open-source software libraries and utilities in several programming languages—such as DCMTK (C and C++), DCM4CHE (Java), and PyDICOM (Python)[13][14][15]—has helped in spreading and affirming the standard.

This article presents an overview of the DICOM standard, covering its fundamental principles and concepts. It also explores the advantages and limitations of the standard while outlining some potential future developments. Throughout this document, all references to the DICOM standard in sections, figures, and tables refer to the 2023b edition.

Not only pixels: The power of metadata in medical images

Medical images must be standardized in a format that can be stored, shared, and used effectively. Therefore, a standard must necessarily deal with metadata as well. The DICOM standard aims to establish a reliable format for medical images and associated information. One of the most significant advancements of the DICOM image format is its metadata formulation, which provides an accurate and detailed description of the subject and procedure used to generate the image. The standard emphasizes that metadata is essential for the full use of medical investigation for clinical, management, and research purposes, establishing the non-divisibility of the pixel data from the metadata. Each DICOM image consists of metadata and pixel data embedded in a single file so that, as the standard institutional website remarks, “the image can never be separated from this information by mistake.”

Knowing how a medical image has been generated from the diagnostic modalities is extremely helpful. For example, a nuclear medicine image will contain information about the injected radiopharmaceutical, injection time, acquisition start time, and end time. An X-ray computed tomography image will contain information about the X-ray tube voltage and current, exposure time, slice thickness, etc. This kind of data are consistently included in the metadata of every DICOM image. To understand the structure of a DICOM metadata section, remember that the standard describes real-world entities, such as patients, studies, diagnostic modalities, and images, in terms of objects and relationships that may occur between them (the so-called entity-relationship model). It is a high level of abstraction that has helped make the DICOM a complex format. Objects are defined in a standard way through groups of attributes describing them in detail. As a result, DICOM needs to store many attributes (Figure 1) to guarantee a comprehensive depiction of the imaging process.

Fig1 Larobina Tomography23 9-5.png

Fig. 1 DICOM image metadata contains detailed information to identify and describe the main entities of the imaging workflow: Patient, Study, Series, and Images. The Patient data section essentially includes a unique patient identifier, the patient’s name, date of birth, sex, and data such as the patient’s weight, which is required to normalize voxel values by body weight as in the case of standardized uptake value (SUV) in PET. The Study section includes a unique identifier, the study date and time, the study description, the Institution name, the referring physicians, etc. The Series section will contain a unique identifier, the body part examined, the field of view, and data related to the imaging modality, such as acquisition protocol and scanning parameters, as well as the manufacturer name, the model, and the software of the equipment used. Finally, the Image section will contain a description of the pixel data necessary for the correct loading and display of the image: rows, columns, samples per pixel, bit depth, photometric interpretation, pixel size, etc.

How is the metadata section populated? There are attributes set during the installation/configuration of the imaging modality (mainly related to the hardware and software of the system, the institution name, etc.), attributes automatically exchanged with the hospital information system (HIS)/radiology information system (RIS) of the department, attributes specified by the acquisition procedure selected for the examination, etc.

In a DICOM file, each attribute is identified by a unique tag consisting of two hexadecimal numbers. The first represents the group and the second represents the element. For example, the tag for the modality is (0008, 0060).

DICOM attributes are logically grouped into modules to identify and describe real-world objects. Modules are presented in standard documents in the form of tables. Modules store the name, tag, definition, and type of the attributes and can hold attributes from various groups. There are modules common to multiple imaging modalities and others specific to one modality, as outlined in Annex C.7 and C.8 of the PS 3.3 standard document (Table 1). Groups of attributes repeated across multiple modules are called "macros." The DICOM data dictionary (PS 3.6) contains all the attributes defined and described in the standard, known as public data elements. Metadata can also include manufacturer-specific attributes known as "private data elements" for which there is no description and are not part of the data dictionary. It is important to note that private data elements are assigned an odd group number, whereas public data elements always have an even group number. The number of data elements present in a DICOM file, both public and private, is generally variable. A specific tag indicates the start of the pixel data and hence the end of the metadata section.

Table 1. Summary of the modules defined in the DICOM standard document PS 3.3—Annex C7 and C8. The list of modality-specific modules has been truncated for brevity; there are approximately 80 modalities defined by the standard, each with its own separate module.
C.7. Common Composite Image Information Object Definition (IOD) Modules C.8. Modality-Specific Modules
C.7.1. Common Patient IE Modules
C.7.2. Common Study IE Modules
C.7.3. Common Series IE Modules
C.7.4. Common Frame of Reference IE Modules
C.7.5. Common Equipment IE Modules
C.7.6. Common Image IE Modules
C.7.7. (Retired) Patient Summary Module
C.7.8. (Retired) Study Content Module
C.7.9. Palette Color Lookup Table Module
C.7.10. Common Acquisition IE Modules
C.7.11. Common Multi-Resolution Pyramid IE Modules
C.8.1. Computed Radiography Modules
C.8.2. CT Modules
C.8.3. MR Modules
C.8.4. Nuclear Medicine Modules
C.8.5. Ultrasound Modules
C.8.6. Secondary Capture Modules
C.8.7. X-ray Modules
C.8.8. Radiotherapy Modules
C.8.9. PET Modules

C.8.32. Parametric Map
C.8.33. Tractography Results Modules

Regarding the DICOM pixel data section, the support for floating point values (single precision 32-bit and double precision 64-bit) is limited to radiation dose values in radiotherapy and, more recently, to parametric maps defined as images in which the pixel values have been derived from the value stored by the modality to be the expression of a physical quantity. In all the other cases, DICOM pixel values can only be integers. DICOM uses a scale factor whenever the values stored in each voxel need to be scaled to different units. This is achieved through two fields specified in the metadata defining the slope and the intercept of the linear transformation to be used to convert pixel values to real-world values.

Rules and tools for the exchange of medical images and related information

Beyond a standardized file format for medical images and associated information, the DICOM standard provides a communication protocol to easily share images in a vendor-independent manner. Protocols are defined by Tim Berners-Lee, one of the creators of the World Wide Web, as simple rules for global systems.[16] This definition is both brief and impactful.

The purpose of the DICOM protocol is to establish communication between diagnostic and sometimes therapy systems of different manufacturers and display, storage, and management devices on a network. The introduction of the DICOM standard marks the beginning of a revolution similar to the introduction of computer networks: no more separate diagnostic equipment, but diagnostic systems, and in some cases of therapy, processing/display and reporting stations that can be connected together and that can share images and related data, storage devices and printers. To realize this objective, the DICOM standard provides an upper-layer protocol that runs over the well-established internet standard protocol TCP/IP. Any DICOM-compliant device attached to the network is an Application Entity identified, in addition to the TCP/IP parameters (IP address, subnet mask, and port number) by a 16-character identification code called “Application Entity Title.” Application Entities can exchange services among themselves according to the client-server model that DICOM renames "Service/Provider"; the requestor of a service is called a "Service Class User," while the provider is called a "Service Class Provider." Depending on the service, a DICOM node can act as a user or provider. Establishing an association involves a negotiation phase during which the service to be exchanged and the role played by each node is established. Next, the transfer syntax for the data exchange is decided, the connection is established, and the data transfer takes place. The main services available on a DICOM network are:

  • Storage: This service is required to archive images across a network. Typically, it is used by an acquisition modality to send images to a picture archiving and communication system (PACS) or a storage server.
  • Storage Commitment: This is an enhanced version of the Storage service with in addition a message sent by the storage provider to the user to confirm that “archiving was successful,” so that the user can safely delete the images locally.
  • Print: This service prints images from an acquisition modality or a display station.
  • Query/Retrieve: This service enables nodes on the DICOM network to query a PACS or another storage unit in order to know the list of images available on it and then to retrieve them.
  • Modality Worklist: This service manages the list of exams to be acquired for each patient. Each examination of the list is scheduled and its completion is made known to the system that updates the data. It is only possible in departments equipped with a computerized reservation/acceptance system (HIS/RIS) integrated into the DICOM network.

Recently, DICOM has added a protocol called DICOMweb built on top of the HyperText Transfer Protocol (HTTP) for using services via the web.[17][18][19][20] DICOMweb enables query, retrieval, storage, and worklist services. DICOM images can be retrieved traditionally as binary objects containing metadata and pixel data or with metadata in JavaScript Object Notation (JSON) or Extensible Markup Language (XML) and pixel data as DICOM bulk data or, optionally, in a format suitable to be directly displayed in a web browser (JPEG).

In addition to the storage of images through a network, the DICOM standard specifies how to standardize image storage on removable physical media such as CD/DVD/Blue-ray discs, magneto-optical discs, USB-connected removable devices, and compact-flash removable devices (DICOM PS 3.12). In this way, the interoperability is extended and ensured even when the image exchange takes place through removable supports. To store DICOM images on physical supports, the standard prescribes a flat-file organization consisting of a folder that serves as a container for the patient’s images, along with a DICOMDIR file. DICOMDIR contains the association between image files and the patient study-series information for all the DICOM files on the media. DICOMDIR is not human-readable as it is a binary file in DICOM format, so a software utility is necessary to read it. Figure 2 shows the DICOMDIR concept schematically.

Fig2 Larobina Tomography23 9-5.png

Fig. 2 On the left, the DICOMDIR flat image files organization in the case of a patient who underwent a whole-body PET/CT diagnostic study. On the right, the corresponding image file organization using the hierarchical folder tree option (patient-study-series) in the OsiriX Viewer export utility. The PET study was reconstructed with and without attenuation correction (AC). According to the standard, DICOMDIR image filenames are no more than eight characters without any extension.

DICOM’s strengths and weaknesses

DICOM is a complex standard designed to offer maximum flexibility, with the ambition to virtually embrace almost all medical imaging modalities. The adoption of the DICOM standard has greatly improved the access, exchange, and usability of medical images. Today, PACS, RIS, and HIS are critical components of every imaging department, and their existence relies on DICOM. The power of metadata in medical imaging has been for a long time underestimated and consequently unexpressed. Thanks to DICOM, clinicians and researchers recognized, after an initial slow acknowledgment phase, that metadata are not only helpful but essential for a better understanding and management of the images. DICOM confirmed the assumption that metadata is as important as pixel data. The adoption of DICOM also encouraged and facilitated data exchange between researchers, creating added value for research. The DICOM standard also has a primary role in the emerging field of enterprise imaging, whose ultimate goal is to connect as many technologies as possible in a collaborative workflow in order to provide added value for the electronic health record (EHR).[21][22]

Conformance (the DICOM philosophy)

It is essential to understand that compliance with the DICOM standard is voluntary. The standards body publishes the recommendations, leaving the manufacturers free to implement or not some aspect of the standard, with the only duty being to the user to declare it in a conformance statement. There is no certification or validation mechanism to verify compliance. This extreme flexibility ended up creating problems due to a consequent variability between the implementations of the various vendors, which led to a decrement in the level of interoperability between imaging systems and between imaging systems and PACS, especially in the earlier implementation of the standard.

Standards prescribe rules, but it is important to acknowledge that not all vendors, programmers, and researchers may consistently follow all suggested rules. Additionally, errors may occur due to the intricate nature of the standard.

It is clear that having a software tool to easily verify compliance with a standard is a helpful way to support and speed up the assertion of the standard itself. Such a test and validation tool becomes even more necessary as the complexity of the standard increases.

Private tags

The presence in the metadata of private tags identifying private data elements is another peculiar aspect of the standard. As reported in Clunie et al.[23], “private data are data elements that the DICOM standard allows to be included, but whose meaning and encoding are not defined by the standard itself.” It is not difficult to understand that the use of proprietary data can create troubles besides appearing contradictory for an open standard. The DICOM standard considers private data necessary because manufacturers may need to codify and include in the imaging process description parameters or information not yet contemplated by the standard (PS 3.5—Section 7.8), as can be, for example, those related to innovative technological solutions adopted by instruments they produce. It is, therefore, a guarantee of maximum flexibility that the standard offers to the manufacturers and belongs to the long-term vision of the standard. This is the theory because, in practice, there are manufacturers who make excessive use of private tags, using them despite the existence of public tags intended to hold the same information.[24][25][26][27] Indeed, the use of private data could be better regulated and documented. Their overuse could have been classified as violating the standard without harming the trade-secret protection or affecting the generality of the standard. Unfortunately, the DICOM standard has not foreseen limitations for private tags, leaving the matter to be regulated based on the relationship between customers and device vendors.

Data protection (privacy)

Another issue connected to the adoption of the DICOM standard is that a metadata section rich in information with explicit reference to patients’ personal data poses a privacy problem every time the images are viewed or exported outside of the structure where they were acquired and reported. It is recommended to anonymize DICOM images before transmitting them externally. However, it is common experience, especially in the post-processing field, that sometimes anonymized images do not work while native ones do. This may be because certain processing software uses private information for measurements and calculations. Tools for de-identification/anonymization are numerous, but it is always necessary to carefully select the options that the de-identification software provides, limiting the fields that are overwritten (cleaned) and retaining whenever possible private tags even in the anonymized version as they could contain essential information for image analysis. The DICOM standard recently published a list of “known to be safe” private tags (PS 3.15 Annex E), which is a good practice to keep in the de-identification process.[23]

Nevertheless, the goal of de-identification is not straightforward due to the need to satisfy privacy regulations on the one hand and the capability to have a fully functional anonymized DICOM on the other. These difficulties have complicated data sharing between working and research groups and limited the creation of public databases containing DICOM images.[28][29]

Quantitative image analysis

The primary focus of the DICOM standard is within the clinical domain. The DICOM file format was not designed with image post-processing as an application. As an image format, DICOM is used by vendor-supplied quantitative processing tools, by groups that have developed their own software and are familiar with the standard, and whenever the processing relies entirely on a single software application that is compatible with DICOM. In other cases, researchers and programmers prefer to work with alternative formats, starting the post-processing pipeline by converting DICOM images into the format of choice for their research project[30]; then, they do not consider the DICOM format for encoding their analysis results, though, in recent years, software tools have been made available to the research community to facilitate the translation of the results of their analysis back into the DICOM format.[31][32] DICOM remains the reference for the information reported in the metadata section. Cases in which metadata does not completely match researchers’ expectations are still encountered. Critical issues have been highlighted in magnetic resonance imaging (MRI), particularly for perfusion and diffusion studies. Commonly reported issues about metadata are, among others, an insufficient detail of information, not mandatory public attributes of interest, and the use of private tags to contain parameters essential for quantitation.[24][26][33] The lack of response to these needs has encouraged the development of alternative standards, such as the Brain Imaging Data Structure (BIDS)[34], that may not have been born if DICOM had shown greater openness towards the research world.

Computerized image analyses and processing may have even more relevance in the coming years due to the contribution that artificial intelligence (AI) techniques are expected to have. From a predominantly research-based activity separated from the clinical domain, image processing will be in the future increasingly integrated into clinical practice.

The DICOM standard has already developed tools to support quantitative imaging. Among these are Parametric Maps for storing images quantitatively derived from acquired images, DICOM Segmentation for the saving of segmentation results in terms of images, Structured Reports and Annotations for the encoding of image-derived associated data as volumes of segmented regions, measurements for cancer lesions characterization, etc. These DICOM tools still have limited support and adoption and might form the basis for future expansions of the standard. Undoubtedly, the support for image processing and the integration of image analysis results into PACS systems or enterprise image archives is a major challenge for the DICOM standard in the next decade.

Conclusions and future directions

DICOM demonstrates the positive influence and added value that a standard can have in a specific field. However, there is no standard for all areas of scientific imaging. For example, there is no single standard for biological image data despite numerous attempts to develop and adopt a standard. One of the first microscopy data formats, the Image Cytometry Standard (ICS), released in 1990[35], was inspired by the work of the ACR-NEMA consortium and shows similarity to the Interfile format developed in the same years for nuclear medicine diagnostic images.[36] More recently, the Open Microscopy Environment Consortium (OME) first proposed a modified version of the well-known Tagged Image File Format (TIFF) with an enriched metadata section encoded in XML (OME-TIFF)[37], and then, in an attempt to have a more complete and powerful format, proposed its successor, the OME-Zarr.[38] The DICOM standard has also focused on the histopathology whole slide imaging application. It was chosen as the format for the Imaging Data Common project, a cloud-based imaging data science platform for cancer studies started by the U.S. National Cancer Institute (NCI).[39] Other formats have been developed and successfully established in specific fields, such as the MRC format for cryo-electron microscopy[40] and the imzML format for mass spectroscopy images.[41] Unfortunately, none of the proposed standards have been affirmed except for some specific fields, and vendor proprietary formats are still in use.

The possibilities for the affirmation of a standard lie in the convergence between industry and the scientific community. Sometimes, standards have been proposed by the scientific community but then have failed to establish themselves, probably because the industries of the sector have not recognized the advantages of a single standard to justify an investment or a change in the company policy on the subject.

The field of medical imaging is exemplary in the standardization processes for the pioneering vision and longevity of its standard promoted at the end of 1980. This experience highlights that the opportunity to have a standard should not be underestimated. Beyond revolutionizing the clinical practice, the DICOM standard has encouraged and facilitated data exchange between researchers, creating added value for research. We think adopting a standard in other imaging-based contexts could also have a similar positive impact.

Today, it is impossible to imagine an imaging department without DICOM. However, after 30 years, the time is ripe to review some of the initial directives. A modern standard should anticipate innovation, not just follow it. Overall, DICOM should recover the initial long-term vision that allowed it to propose solutions ahead of time. Through experience, it has become clear that there are areas in which the DICOM standard could be further improved, including simplifying and clarifying the documentation, limiting and regulating private tags, increasing the support for research and quantitative image processing, and strengthening privacy protection procedures. Additionally, the development and use of validation tools should be encouraged to minimize non-standard implementations.

Abbreviations, acronyms, and initialisms

  • ACR: American College of Radiology
  • AI: artificial intelligence
  • BIDs: Brain Imaging Data Structure
  • CT: computed tomography
  • DICOM: Digital Imaging and Communications in Medicine
  • ECG: electrocardiogram
  • EEG: electroencephalography
  • HIS: hospital information system
  • HTTP: HyperText Transfer Protocol
  • ICS: Image Cytometry Standard
  • IE: information entity
  • IOD: Information Object Definition
  • JSON: JavaScript Object Notation
  • MRI: magnetic resonance imaging
  • NCI: National Cancer Institute
  • NEMA: National Electrical Manufacturers Association
  • OME: Open Microscopy Environment
  • PACS: picture archiving and communication system
  • PET: positron emission tomography
  • RIS: radiology information system
  • SUV: standardized uptake value
  • TIFF: Tagged Image File Format
  • TCP/IP: Transmission Control Protocol/Internet Protocol
  • XML: eXtensible Markup Language



This research received no external funding.

Conflicts of interest

The author declares no conflict of interest.


  1. Medical Imaging Technology Association. "DICOM". Retrieved 08 May 2023. 
  2. Bidgood, W D; Horii, S C (1 March 1992). "Introduction to the ACR-NEMA DICOM standard." (in en). RadioGraphics 12 (2): 345–355. doi:10.1148/radiographics.12.2.1561424. ISSN 0271-5333. 
  3. Horii, S C (1 September 1997). "Primer on computers and information technology. Part four: A nontechnical introduction to DICOM." (in en). RadioGraphics 17 (5): 1297–1309. doi:10.1148/radiographics.17.5.9308117. ISSN 0271-5333. 
  4. Bidgood, W. D.; Horii, S. C.; Prior, F. W.; Van Syckle, D. E. (1 May 1997). "Understanding and Using DICOM, the Data Interchange Standard for Biomedical Imaging" (in en). Journal of the American Medical Informatics Association 4 (3): 199–212. doi:10.1136/jamia.1997.0040199. ISSN 1067-5027. PMC PMC61235. PMID 9147339. 
  5. Clunie, David A.; Carrino, John A. (2002), Dreyer, Keith J.; Mehta, Amit; Thrall, James H., eds., "DICOM" (in en), PACS (New York, NY: Springer New York): 73–119, doi:10.1007/978-1-4757-3651-9_5, ISBN 978-1-4757-3653-3, Retrieved 2023-10-09 
  6. Mildenberger, Peter; Eichelberg, Marco; Martin, Eric (1 April 2002). "Introduction to the DICOM standard" (in en). European Radiology 12 (4): 920–927. doi:10.1007/s003300101100. ISSN 0938-7994. 
  7. Graham, R.N.J.; Perriss, R.W.; Scarsbrook, A.F. (1 November 2005). "DICOM demystified: A review of digital file formats and their use in radiological practice" (in en). Clinical Radiology 60 (11): 1133–1140. doi:10.1016/j.crad.2005.07.003. 
  8. Clunie, D.. "Contents". Medical Image Format FAQ. Retrieved 08 May 2023. 
  9. Clunie, David A. (1 June 2021). "DICOM Format and Protocol Standardization—A Core Requirement for Digital Pathology Success" (in en). Toxicologic Pathology 49 (4): 738–749. doi:10.1177/0192623320965893. ISSN 0192-6233. 
  10. DICOM Standards Committee, Working Group 26 (Pathology) (12 July 2021). "Digital Imaging and Communications in Medicine (DICOM) - Supplement 222: Microscopy Bulk Simple Annotations Storage SOP Class" (PDF). NEMA. Retrieved 20 September 2022. 
  11. Herrmann, Markus D.; Clunie, David A.; Fedorov, Andriy; Doyle, Sean W.; Pieper, Steven; Klepeis, Veronica; Le, Long P; Mutter, George L. et al. (1 January 2018). "Implementing the DICOM Standard for Digital Pathology" (in en). Journal of Pathology Informatics 9 (1): 37. doi:10.4103/jpi.jpi_42_18. PMC PMC6236926. PMID 30533276. 
  12. Medical Imaging Technology Association. "Working Groups & Minutes". DICOM. Retrieved 08 May 2023. 
  13. Eichelberg, Marco; Riesmeier, Joerg; Wilkens, Thomas; Hewett, Andrew J.; Barth, Andreas; Jensch, Peter (19 April 2004). Ratib, Osman M.; Huang, H. K.. eds. Ten years of medical imaging standardization and prototypical implementation: the DICOM standard and the OFFIS DICOM toolkit (DCMTK). San Diego, CA. pp. 57. doi:10.1117/12.534853. 
  14. " - Open Source Clinical Image and Object Management". dcm4che development team. Retrieved 31 August 2023. 
  15. "Welcome to Pydicom". Pydicom development team. Retrieved 31 August 2023. 
  16. Berners-Lee, Tim; Fischetti, Mark (1999). Weaving the Web: the original design and ultimate destiny of the World Wide Web by its inventor (1st ed ed.). San Francisco: HarperSanFrancisco. ISBN 978-0-06-251586-5. 
  17. Drnasin, Ivan; Grgić, Mislav; Gogić, Goran (1 October 2017). "JavaScript Access to DICOM Network and Objects in Web Browser" (in en). Journal of Digital Imaging 30 (5): 537–546. doi:10.1007/s10278-017-9956-7. ISSN 0897-1889. PMC PMC5603437. PMID 28138796. 
  18. Genereaux, Brad W.; Dennison, Donald K.; Ho, Kinson; Horn, Robert; Silver, Elliot Lewis; O’Donnell, Kevin; Kahn, Charles E. (1 June 2018). "DICOMweb™: Background and Application of the Web Standard for Medical Imaging" (in en). Journal of Digital Imaging 31 (3): 321–326. doi:10.1007/s10278-018-0073-z. ISSN 0897-1889. PMC PMC5959831. PMID 29748852. 
  19. Ziegler, Erik; Urban, Trinity; Brown, Danny; Petts, James; Pieper, Steve D.; Lewis, Rob; Hafey, Chris; Harris, Gordon J. (1 November 2020). "Open Health Imaging Foundation Viewer: An Extensible Open-Source Framework for Building Web-Based Imaging Applications to Support Cancer Research" (in en). JCO Clinical Cancer Informatics (4): 336–345. doi:10.1200/CCI.19.00131. ISSN 2473-4276. PMC PMC7259879. PMID 32324447. 
  20. Gorman, Chris; Punzo, Davide; Octaviano, Igor; Pieper, Steven; Longabaugh, William J. R.; Clunie, David A.; Kikinis, Ron; Fedorov, Andrey Y. et al. (22 March 2023). "Interoperable slide microscopy viewer and annotation tool for imaging data science and computational pathology" (in en). Nature Communications 14 (1): 1572. doi:10.1038/s41467-023-37224-2. ISSN 2041-1723. PMC PMC10033920. PMID 36949078. 
  21. Clunie, David A.; Dennison, Don K.; Cram, Dawn; Persons, Kenneth R.; Bronkalla, Mark D.; Primo, Henri “Rik” (1 October 2016). "Technical Challenges of Enterprise Imaging: HIMSS-SIIM Collaborative White Paper" (in en). Journal of Digital Imaging 29 (5): 583–614. doi:10.1007/s10278-016-9899-4. ISSN 0897-1889. PMC PMC5023533. PMID 27576909. 
  22. Roth, Christopher J.; Lannum, Louis M.; Persons, Kenneth R. (1 October 2016). "A Foundation for Enterprise Imaging: HIMSS-SIIM Collaborative White Paper" (in en). Journal of Digital Imaging 29 (5): 530–538. doi:10.1007/s10278-016-9882-0. ISSN 0897-1889. PMC PMC5023525. PMID 27245774. 
  23. 23.0 23.1 Clunie, David A.; Flanders, Adam; Taylor, Adam; Erickson, Brad; Bialecki, Brian; Brundage, David; Gutman, David; Prior, Fred et al. (2023). "Report of the Medical Image De-Identification (MIDI) Task Group -- Best Practices and Recommendations". arXiv. doi:10.48550/ARXIV.2303.10473. 
  24. 24.0 24.1 Neu, Scott C.; Crawford, Karen L.; Toga, Arthur W. (2012). "Practical management of heterogeneous neuroimaging metadata by global neuroimaging data repositories". Frontiers in Neuroinformatics 6. doi:10.3389/fninf.2012.00008. ISSN 1662-5196. PMC PMC3311229. PMID 22470336. 
  25. Li, Xiangrui; Morgan, Paul S.; Ashburner, John; Smith, Jolinda; Rorden, Christopher (1 May 2016). "The first step for neuroimaging data analysis: DICOM to NIfTI conversion" (in en). Journal of Neuroscience Methods 264: 47–56. doi:10.1016/j.jneumeth.2016.03.001. 
  26. 26.0 26.1 Kompan, I. (2021). "Implementation of DICOM Parametric Maps for Perfusion MRI". Proceedings of the MRI Together 2021–Session A1, Online Presentation. 
  27. Shin, Han-Back; Sheen, Heesoon; Lee, Ho-Young; Kang, Jihoon; Yoon, Do-Kun; Suh, Tae Suk (1 December 2017). "Digital Imaging and Communications in Medicine (DICOM) information conversion procedure for SUV calculation of PET scanners with different DICOM header information" (in en). Physica Medica 44: 243–248. doi:10.1016/j.ejmp.2017.05.063. 
  28. Freymann, John B.; Kirby, Justin S.; Perry, John H.; Clunie, David A.; Jaffe, C. Carl (1 February 2012). "Image Data Sharing for Biomedical Research—Meeting HIPAA Requirements for De-identification" (in en). Journal of Digital Imaging 25 (1): 14–24. doi:10.1007/s10278-011-9422-x. ISSN 0897-1889. PMC PMC3264712. PMID 22038512. 
  29. Moore, Stephen M.; Maffitt, David R.; Smith, Kirk E.; Kirby, Justin S.; Clark, Kenneth W.; Freymann, John B.; Vendt, Bruce A.; Tarbox, Lawrence R. et al. (1 May 2015). "De-identification of Medical Images with Retention of Scientific Research Value" (in en). RadioGraphics 35 (3): 727–735. doi:10.1148/rg.2015140244. ISSN 0271-5333. PMC PMC4450976. PMID 25969931. 
  30. Larobina, Michele; Murino, Loredana (1 April 2014). "Medical Image File Formats" (in en). Journal of Digital Imaging 27 (2): 200–206. doi:10.1007/s10278-013-9657-9. ISSN 0897-1889. PMC PMC3948928. PMID 24338090. 
  31. Fedorov, Andriy; Clunie, David; Ulrich, Ethan; Bauer, Christian; Wahle, Andreas; Brown, Bartley; Onken, Michael; Riesmeier, Jörg et al. (24 May 2016). "DICOM for quantitative imaging biomarker development: a standards based approach to sharing clinical data and structured PET/CT analysis results in head and neck cancer research" (in en). PeerJ 4: e2057. doi:10.7717/peerj.2057. ISSN 2167-8359. PMC PMC4888317. PMID 27257542. 
  32. Bridge, Christopher P.; Gorman, Chris; Pieper, Steven; Doyle, Sean W.; Lennerz, Jochen K.; Kalpathy-Cramer, Jayashree; Clunie, David A.; Fedorov, Andriy Y. et al. (1 December 2022). "Highdicom: a Python Library for Standardized Encoding of Image Annotations and Machine Learning Model Outputs in Pathology and Radiology" (in en). Journal of Digital Imaging 35 (6): 1719–1737. doi:10.1007/s10278-022-00683-y. ISSN 0897-1889. PMC PMC9712874. PMID 35995898. 
  33. Larobina, M. (2003). "The DICOM File Format : Postprocessing Features in MRI". Physica medica : European Journal of Medical Physics (4). doi:10.1400/19277. 
  34. Gorgolewski, Krzysztof J.; Auer, Tibor; Calhoun, Vince D.; Craddock, R. Cameron; Das, Samir; Duff, Eugene P.; Flandin, Guillaume; Ghosh, Satrajit S. et al. (21 June 2016). "The brain imaging data structure, a format for organizing and describing outputs of neuroimaging experiments" (in en). Scientific Data 3 (1): 160044. doi:10.1038/sdata.2016.44. ISSN 2052-4463. PMC PMC4978148. PMID 27326542. 
  35. Dean, Phillip; Mascio, Laura; Ow, David; Sudar, Damir; Mullikin, James (1990). "Proposed standard for image cytometry data files" (in en). Cytometry 11 (5): 561–569. doi:10.1002/cyto.990110502. ISSN 0196-4763. 
  36. Cradduck, T. D.; Bailey, D. L.; Hutton, B. F.; Conninck, F. De; Busemann-Sokole, E.; Bergmann, H.; Noelpp, U. (1 October 1989). "A standard protocol for the exchange of nuclear medicine image files:" (in en). Nuclear Medicine Communications 10 (10): 703–714. doi:10.1097/00006231-198910000-00002. ISSN 0143-3636. 
  37. Goldberg, Ilya G; Allan, Chris; Burel, Jean-Marie; Creager, Doug; Falconi, Andrea; Hochheiser, Harry; Johnston, Josiah; Mellen, Jeff et al. (2005). "[No title found"]. Genome Biology 6 (5): R47. doi:10.1186/gb-2005-6-5-r47. PMC PMC1175959. PMID 15892875. 
  38. Moore, Josh; Basurto-Lozada, Daniela; Besson, Sébastien; Bogovic, John; Bragantini, Jordão; Brown, Eva M.; Burel, Jean-Marie; Casas Moreno, Xavier et al. (1 September 2023). "OME-Zarr: a cloud-optimized bioimaging file format with international community support" (in en). Histochemistry and Cell Biology 160 (3): 223–251. doi:10.1007/s00418-023-02209-1. ISSN 0948-6143. PMC PMC10492740. PMID 37428210. 
  39. Fedorov, Andrey; Longabaugh, William J.R.; Pot, David; Clunie, David A.; Pieper, Steve; Aerts, Hugo J.W.L.; Homeyer, André; Lewis, Rob et al. (15 August 2021). "NCI Imaging Data Commons" (in en). Cancer Research 81 (16): 4188–4193. doi:10.1158/0008-5472.CAN-21-0950. ISSN 0008-5472. PMC PMC8373794. PMID 34185678. 
  40. Cheng, Anchi; Henderson, Richard; Mastronarde, David; Ludtke, Steven J.; Schoenmakers, Remco H.M.; Short, Judith; Marabini, Roberto; Dallakyan, Sargis et al. (1 November 2015). "MRC2014: Extensions to the MRC format header for electron cryo-microscopy and tomography" (in en). Journal of Structural Biology 192 (2): 146–150. doi:10.1016/j.jsb.2015.04.002. PMC PMC4642651. PMID 25882513. 
  41. Schramm, Thorsten; Hester, Zoë; Klinkert, Ivo; Both, Jean-Pierre; Heeren, Ron M.A.; Brunelle, Alain; Laprévote, Olivier; Desbenoit, Nicolas et al. (1 August 2012). "imzML — A common data format for the flexible exchange and processing of mass spectrometry imaging data" (in en). Journal of Proteomics 75 (16): 5106–5110. doi:10.1016/j.jprot.2012.07.026. 


This presentation is faithful to the original, with only a few minor changes to presentation, spelling, and grammar. In some cases important information was missing from the references, and that information was added. The original put information into a Table 2 that didn't need to be in a table; it was made into a bulleted list for this version.