DICOM Viewer and the DICOM Standard: Header Tags, PACS Integration, and DICOMweb

A DICOM viewer is specialized medical imaging software that parses, renders, measures, and annotates diagnostic and research image datasets formatted under the Digital Imaging and Communications in Medicine (DICOM) standard (NEMA PS3 / ISO 12052). Unlike consumer image viewers that display flat 8-bit RGB files, a DICOM viewer reconstructs high-bit-depth 2D slices, 3D multiplanar reconstructions (MPR), and 4D time-series volumes while simultaneously reading hundreds of structured clinical metadata attributes embedded in the DICOM header. In hospitals and clinical imaging core laboratories, DICOM viewers act as the visual workstation interface to a PACS system or Vendor Neutral Archive (VNA).

What Is DICOM? (The NEMA PS3 / ISO 12052 Standard)

DICOM (Digital Imaging and Communications in Medicine) is the global standard for the storage, printing, query, and network transmission of medical images and related clinical waveforms. Maintained by the DICOM Standards Committee in partnership with the Medical Imaging & Technology Alliance (MITA, a division of the National Electrical Manufacturers Association, NEMA) and published as NEMA PS3 (and internationally as ISO 12052), the standard consists of 22 interconnected parts.

DICOM solves a fundamental clinical informatics problem: a diagnostic CT, MRI, PET, ultrasound, or digital pathology scan is clinically meaningless—and potentially dangerous—if its pixel matrix is separated from patient identity, anatomical orientation, slice thickness, pixel spacing, or acquisition parameters. A DICOM object therefore binds raw pixel arrays and structured clinical metadata into a single unified Information Object Definition (IOD), organized hierarchically across four levels:

1. Patient: The individual subject undergoing imaging.
2. Study (StudyInstanceUID): A single imaging order or visit (which may contain multiple series across one or more modalities, such as a combined PET/CT study).
3. Series (SeriesInstanceUID): A specific acquisition sequence, protocol, or spatial reconstruction (for example, an axial T1-weighted post-contrast brain MRI series).
4. Instance / SOP Instance (SOPInstanceUID): An individual 2D image slice, multi-frame volume, waveform, segmentation object (SEG), or DICOM Structured Report (SR).

Inside the DICOM Header: Tags, Value Representations, and De-Identification

Under DICOM Part 10 (PS3.10, Media Storage and File Format for Media Interchange), a standard .dcm file begins with a 128-byte file preamble, followed by the 4-byte ASCII prefix "DICM", a File Meta Information header (Group 0002), and an ordered dataset of Data Elements. Each Data Element in the DICOM header is addressed by a hexadecimal tag pair (GGGG,EEEE)—where GGGG is the 16-bit Group Number and EEEE is the 16-bit Element Number—paired with an explicit or implicit 2-character Value Representation (VR) that defines its data type:

DICOM Tag (GGGG,EEEE)	Attribute Name	VR	Clinical Viewer & Research Function
(0010,0010) / (0010,0020)	PatientName / PatientID	PN / LO	Verifies patient identity in clinical PACS; stripped or pseudonymized under DICOM PS3.15 for clinical trials
(0008,0060)	Modality	CS	Identifies acquisition type (CT, MR, PT, US, CR, DX, MG, SM for slide microscopy)
(0020,0032) & (0020,0037)	ImagePositionPatient & ImageOrientationPatient	DS	3D patient coordinate origin $(x, y, z)$ in millimeters and direction cosines required for 3D MPR and cross-referencing
(0028,0030) & (0018,0050)	PixelSpacing & SliceThickness	DS	Calibrates physical millimeter measurements (RECIST tumor diameters, ROI areas, and voxel volumes)
(0028,1050) & (0028,1051)	WindowCenter & WindowWidth	DS	Maps 12-bit or 16-bit sensor intensities (such as CT Hounsfield Units) to 8-bit display grayscale levels
(0028,1052) & (0028,1053)	RescaleIntercept & RescaleSlope	DS	Converts stored pixel values $SV$ into physical units $U = m cdot SV + b$ (e.g., Hounsfield Units or PET SUV)
(7FE0,0010)	PixelData	OB / OW	Contains the raw uncompressed or compressed (JPEG Lossless, JPEG 2000, HTJ2K) image pixel matrix

In multi-site clinical trials and public repositories such as MIDRC, imaging pipelines must scrub protected health information (PHI) from standard and private (odd-numbered group) DICOM header tags in accordance with DICOM PS3.15 Annex E (Attribute Confidentiality Profiles)—as well as burned-in pixel text—before exporting files or converting them into neuroimaging research formats via dcm2niix.

PACS DICOM Architecture: DIMSE vs. DICOMweb Viewers

A DICOM viewer communicates with a hospital PACS system or Vendor Neutral Archive using one of two networking stacks specified in the vendor’s DICOM Conformance Statement:

• Classical DIMSE (DICOM Message Service Element, PS3.7 & PS3.8): Thick-client radiologist workstations communicate over raw TCP/IP sockets using Application Entity (AE) Titles, IP addresses, and port numbers. The viewer queries the PACS worklist via C-FIND, requests study transfer via C-MOVE or C-GET, and saves annotations or secondary captures via C-STORE.
• Modern DICOMweb RESTful APIs (DICOM PS3.18): Cloud and enterprise zero-footprint browser viewers (such as the Open Health Imaging Foundation / OHIF Viewer) operate over standard HTTPS using three RESTful services:
  • QIDO-RS (Query based on ID for DICOM Objects): Sends HTTP GET requests to search studies, series, or instances and returns lightweight JSON metadata.
  • WADO-RS (Web Access to DICOM Objects — RESTful): Streams study metadata, individual uncompressed/HTJ2K pixel frames, or server-rendered viewports on demand as the clinician scrolls through a study.
  • STOW-RS (Store Over the Web): Uploads newly generated DICOM Segmentation (SEG), Structured Report (SR), or Grayscale Softcopy Presentation State (GSPS) objects via HTTP POST.

DICOM vs. HL7: How Both Standards Work Together

Healthcare informatics architectures rely on both DICOM and HL7 (Health Level Seven / FHIR) as complementary protocols rather than competing alternatives:

• HL7 v2 / HL7 FHIR: Manages textual and event-driven clinical workflows—such as patient registration (ADT), radiology order placement (ORM / FHIR ServiceRequest), and finalized diagnostic radiology report distribution (ORU / FHIR DiagnosticReport and ImagingStudy).
• DICOM: Manages the modality worklist (`MWL`), high-volume binary image acquisition, spatial coordinate metadata, display calibration (DICOM PS3.14 Grayscale Standard Display Function), and pixel-level storage/retrieval. An EHR launch typically passes an accession number or FHIR ImagingStudy reference to the DICOM viewer to open the corresponding pixel dataset.

Diagnostic Clinical Viewers vs. Research DICOM Viewers

Under US Food and Drug Administration regulations (21 CFR § 892.2050, Medical Image Management and Processing System, product code LLZ), software intended for primary diagnostic interpretation by radiologists is regulated as a Class II medical device requiring FDA 510(k) clearance, verified spatial measurement accuracy, and DICOM PS3.14 GSDF monitor calibration.

By contrast, translational imaging researchers and biomedical engineers frequently use open-source scientific DICOM visualization and computing platforms—including 3D Slicer for volumetric segmentation and radiomics, MRIcroGL for GPU-accelerated neuroimaging volume rendering, and Horos or Weasis for desktop inspection—which carry explicit “Not for Diagnostic Clinical Use” labeling and are optimized for quantitative analysis and research pipeline integration.