The most basic imaging use case includes scheduling, acquiring, managing, processing, displaying, reporting on, and distributing images. A patient is scheduled for a diagnostic exam (e.g., a chest radiograph). A radiography technician uses an imaging device (e.g., an X-ray unit) to acquire images and transmit them to an archive (e.g., a PACS). A radiologist accesses these images, interprets them, and creates a report that is sent to the Radiology Information System (RIS) for distribution to the referring physician, sometimes alongside the images. During interpretation, radiologists may need to see prior imaging studies. Increasingly, such studies are available from other institutions, from jurisdictional, regional or national archives, from cloud-based image sharing solutions, or brought by patients or their families on a CD or DVD. Today, one may choose to store imaging information to a long-term archive, burn the images to a CD or DVD for the patient, share it through an EHR, render them on mobile devices (like tablets or phones), digitally reconstruct the images to form 3D visualization, and share them to portals (for ordering physicians or to patients themselves).
DICOM is the standard for retrieving, storing, printing, and transmitting information in medical imaging, and includes both a file structure and communication protocol . It is an international standard (ISO 12052) for medical imaging and related information. DICOM defines formats for images, waveforms, and derived structured data to provide the entire dataset necessary for clinical use. It enables imaging department workflow management, media exchange and printing, and it achieves this using service-based network protocols over TCP/IP and HTTP. DICOM defines how to store acquired images from modalities such as CT, MRI, X-Ray, Ultrasound, Angiography, PET, microscopes, cameras and ophthalmological devices. These image instances may be formatted as single or multi-frame objects, multi-dimensional volumes, or cine loops. These may be original or derived images and may be associated with annotations and other presentation settings. These objects can refer to related documents, such as requisitions, consent forms, and reports. Other non-image medical data, like ECG waveforms, ultrasound measurements, or radiation dose information, can also be stored using DICOM. For all objects, DICOM defines significant meta-data, for example, for patient identification and demographics, ordering information, acquisition parameters, and workflow context. This metadata is used to query, sort, route, display, and manage the images.
In terms of an information model, DICOM defines a logical hierarchy, starting with the patient, as demonstrated in Fig. 1.
A patient represents the human or animal subject of medical imaging and has a collection of imaging studies.
Each study represents an organized set of images for a particular diagnostic purpose and contains a collection of series.
Each series represents a single acquisition event on a single machine and contains a collection of instances.
Each instance represents a single data object which may be an image frame, a set of images frames, or a document (measurements or a report).
Furthermore, even when distributed or accessed independently, each DICOM instance is fully usable since it is fully self-describing. Each instance contains a complete set of metadata, including:
Study-level attributes, such as the study unique identifier, the study description, and the patient demographics.
Series-level attributes, such as the series unique identifier, the modality, and the body part imaged.
Instance-level attributes, such as the instance unique identifier, the image resolution, and the table position where the image was acquired.
Each attribute of the metadata has a defined data type and cardinality and is identified by a 32-bit tag—usually shown as two sets of four hexadecimal digits. For example, the tag (0010, 0010) identifies the data attribute containing the patient’s name, which has the datatype of a person name, and can occur at least once. Each DICOM instance is identified by a globally unique identifier (meaning, no two instances ever use the same identifier, worldwide).
DICOM also defines non-image objects that are associated with images and studies—these include:
Key object selections (called KOS) identify one or more images intended for a specific purpose, such as representing something clinically significant.
Grayscale presentation states (called GSPS) describe how an individual image or a set of images can be annotated, rotated, cropped, and brightness and contrast adjusted, without modifying the underlying image instance.
Structured reports (called SR) encode measurement data in a machine-readable way (e.g., radiation dose SR for ionizing radiation exposures)
Encapsulation objects take non-DICOM files such as CDA  (clinical document architecture), PDFs, or textual reports and store them in the DICOM format so they can be stored and managed as part of an imaging study.
As new imaging-related technologies emerge, such as multi-energy CT, or clinical 3D printing, new object types are defined.
To understand how DICOMweb became part of the standard, it is important to understand the healthcare and technology ecosystems. Technology in general, and specifically in healthcare, had evolved and so the technologies used in medical imaging had to evolve as well to meet the needs of clinical systems utilizing imaging. Imaging is not the major focus for many healthcare systems, which thus may be reluctant to invest time and effort into understanding a “niche” protocol such as DICOM. There may be safety risks if systems are misconfigured or misused; for example, displaying an arm X-ray for an amputation surgery without the laterality markers specified in the DICOM metadata can lead to serious errors. There are many nuances associated with display of medical images, including tag morphing, lifecycle management, scaling, and dealing with huge data sets. In addition, given that Information Technology (IT) personnel are familiar with concepts such as image display and content upload over the web, and data parsing, historically, DICOM did not use the same technology commonly encountered for those applications. The DICOM file format is not an image format recognized by internet browsers (unlike JPEG, GIF, PNG, and others). Storing newly acquired images (such as, from a clinician’s smartphone for an ad-hoc acquisition) requires in-depth knowledge of both the acquisition parameters and DICOM rules to create the right tags and file format. Managing the image lifecycle (from acquisition, to ingestion, to storage) requires specialized software. Metadata extraction requires parsing binary data, as opposed to XML or JSON technologies. Scaling a system upward requires specialized knowledge of imaging systems, unlike growing a set of clustered nodes in a virtual cloud infrastructure. Storage and bandwidth/latency issues are magnified as image data sets grow into gigabytes and terabytes. There was a need to leverage new technologies in medical imaging, and the users and vendors in the medical imaging industry needed ways to take advantage of web technologies in ways that were compatible with their significant investments in existing infrastructure.
Aside from the technology, the needs of clinicians and healthcare institutions changed over time too. Patient-centered care continues to evolve and it demands consistent access to data wherever it is stored (including other institutions) from anywhere the clinician happens to be (in the hospital, at home, in an airport terminal) and on whatever device the clinician is using (a desktop computer, a tablet, a telemedicine cart, a patient bedside terminal, a hallway-mounted computer, or a mobile phone). Hospital IT departments have evolved from individual departmental specialists into enterprise teams, marked with some associated loss of specialist knowledge. Application development paradigms have shifted toward service-oriented architectures. Security and privacy concerns have become much more prevalent, especially with moves to cloud services that have begun to reflect patient confidentiality regulations and protections. The era of “pushing” healthcare data from system to system has started to come to an end, and the era of “pulling” data on demand has begun. Furthermore, the principles of traditional radiological imaging are being supplanted by a broader concept of enterprise imaging with governance of all clinical images regardless of their origin. Enterprise imaging is “a set of strategies, initiatives and workflows implemented across a healthcare enterprise to consistently and optimally capture, index, manage, store, distribute, view, exchange, and analyze all clinical imaging and multimedia content to enhance the electronic health record.”  So, for both technology and non-technology reasons, a different approach had to be taken to address the needs of users and systems across the spectrum.
Starting in 2003, a web-enabled DICOM extension began to take shape. Initially called WADO, or Web Access to DICOM Persistent Objects, it defined a method to retrieve DICOM objects using HTTP, the same technology used on the web. Over time, other services were added to DICOM to augment the retrieval use case—this included search via QIDO-RS (Query based on ID for DICOM Objects) and upload via STOW-RS (Store over the Web). WADO was upgraded to WADO-RS to more closely follow the emerging RESTful style of web interfaces. Collectively, these technologies became known as DICOMweb. DICOMweb adds HTTP powered services to DICOM, modeled after the style of Representational State Transfer (REST). REST has become the dominant API style used by companies and market verticals all around the world . REST enables systems that are scalable, fault-tolerant, recoverable, secure, and loosely-coupled . DICOMweb was designed to augment existing DICOM systems with web technologies. This is important because, given the penetration of DICOM-enabled systems all around the world by hundreds of companies producing trillions of DICOM images, it is not feasible to switch to a completely different standard without disruption. DICOMweb makes it possible to render DICOM instances into widely used consumer-friendly formats suitable for web browsers on both desktops and mobile devices, without requiring a mass conversion of the existing historic data or information model. DICOMweb preserves the historical DICOM information model and metadata rules while enabling access to this information in web formats.
Through embracing web technologies, DICOMweb helps to enable communication of imaging data not only to systems within an institution but also to those outside. Further, it supports the security necessary to make this safe natively using the same industry standards that secure commercial activities like banking. Industry-standard security and acceleration appliances can be used to achieve greater performance, since they are optimized for industry-standard HTTP traffic. And, through using RESTful principles, DICOMweb allows for rapid development by software developers. It is possible to access basic DICOMweb retrieval services directly in a browser with no special tools needed; to access traditional DICOM services, often specialized software libraries were needed.
Medical imaging over the web has undergone its own evolution, as well. This technology evolution is indicated by the suffix on the service names; “URI” representing a Uniform Reference Identifier method, “WS” representing a Web Service (or SOAP) method, and “RS” representing a RESTful method. The original WADO service, now known as WADO-URI, was developed to provide retrieval of DICOM instances using query parameters on a single resource. For example, a WADO-URI service resource URL may look like “https://myserver.com/wado?studyUID=2.16.8184.108.40.206.3&seriesUID=2.16.8220.127.116.11.6&objectUID=2.16.818.104.22.168.9” where the resource is named “wado” and the parameters passed include “studyUID”, “seriesUID”, and “instanceUID”. This has since evolved into what is known as WADO-RS, which uses multiple resource concepts to provide retrieval services. For example, “https://myserver.com/studies/2.16.822.214.171.124.3/series/2.16.8126.96.36.199.6/instances/2.16.8188.8.131.52.9” refers to a hierarchal relationship of resources—the 2.16.8184.108.40.206.9 instance resource in the “instances” resource in the “2.16.8220.127.116.11.6 series resource in the “series” resource in the 2.16.818.104.22.168.3 study resource in the “studies” resource. This more accurately reflects how the study contents are nested and provides the ability to request bundles of resources at the series or study level. DICOMweb also aligns with evolutions in other healthcare APIs; an example of this is HL7’s Fast Healthcare Interoperability Resources (FHIR) . Reflecting evolving approaches to network communications, for a period DICOM also defined a web API called WADO-WS using the SOAP (Simple Object Access Protocol) specification, but this API has since been retired from the DICOM Standard . During the same time period, an independent group began to work on a competing standards project, called MINT (Medical Imaging Network Transport) . Many of the concepts from MINT were later re-worked and adopted into the development of the DICOMweb *-RS services, with input from the user and vendor communities alike.