Digital Imaging and Communications in Medicine, otherwise known as DICOM is a common industry standard used by the radiology community worldwide to transfer medical imaging files. Established first in 1983, by a joint collaboration between the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), this standard was developed owing to one important problem: it was difficult for medical images generated on one vendor’s device to be transferred or displayed on another vendor’s hardware. More about the history of radiology before DICOM and the inception of its integration into PACS has been covered in another blog article here
In this article, we will deep-dive into the DICOM file type (without getting too technical) and explore another development that originated simultaneously with the standard- the concept of a DICOM viewer. We will also briefly cover the various features typically available in a DICOM viewer and how they have eradicated physical films from the field of radiology.
The anatomy of a DICOM file
Every DICOM file consists of a header that exhaustively mentions the hospital, patient, scanner, and image information. Every DICOM file is designed to be independent and standalone, with its principal identification embedded in a specific hierarchy in its header as follows:
- Level 1, ‘patient’ or the person undergoing the study
- Level 2, ‘study’ or the imaging procedure being followed in a specific hospital at a specific date
- Level 3, ‘series’ which could imply multiple scans of the same patient in one study (eg MRI) or single scan with varied reconstructions of data (eg CT)
- Level 4, ‘instance’ where every slice of the 3D image is treated as a separate entity
DICOM typically saves one file per slice, so a 3D scan can have hundreds of DICOM files. An example storage hierarchy of a DICOM file is as follows:
- Patient: 12345 (unique ID)
- Study: 20230728_CT (YYYYMMDD_Modality)
- Series: 1.2.345.67890…
- Instance: ‘000000.dcm’, ‘000001.dcm’, ‘000002.dcm’ and so on
It is important to note that this is a possible image storing format. Actual DICOM standards require each level to be provided with a unique identification ID (UID). For example, the series UID may also carry information about the identity of the file and how it is compressed. Since every file comes with metadata that pinpoints the exact study, it is difficult to anonymise DICOM files.
What is a DICOM viewer?
A DICOM viewer is a software application, or an interface, allowing radiologists to view medical images generated from different imaging modalities (like X-ray/MRI/CT) and stored in the DICOM format. With the X-ray turning digital, it was imperative to develop a platform-independent standard which could be easily shared, as well as an associated viewer which could interpret and open the files with ease.
How does a DICOM viewer work?
A DICOM viewer works in three stages:
- Retrieval, where the DICOM viewer connects to PACS/other databases to retrieve patient studies and image data. The viewer queries the database using specific information such as patient ID/ study UID/series ID to locate the relevant files.
- Parsing, where the DICOM viewer parses the files and interprets the DICOM headers, which contain the metadata mentioned above.
- Display, where the DICOM viewer extracts the pixel data from the DICOM instances and displays the image on the viewer’s GUI. This viewer renders the images in high resolution, allowing radiologists to comprehensively study the scan and diagnose.
Most DICOM viewers provide an inbuilt export option to convert and share images from DICOM to other image file types like JPEG, PNG and TIFF. While this provides ease-of-access, one needs to be aware of various issues like:
- Loss of metadata, where non-DICOM file types lose their UID
- Loss of quality, where image compression can create pixelation
- Regulation, where it might be illegal in some areas to share private health information of patients in non-DICOM format, and might be a violation of HIPAA regulation.
Losses in DICOM
While significant progress in the field of digitising radiology has been achieved, the reliability of a DICOM image needs to be revalidated at regular intervals. This is because there have been multiple instances of hospitals reporting missing image files which were originally created by the modality. Image loss not only affects the faith in digital imaging but it also affects patient diagnosis and daily quality of clinical work.
Four major reasons of image losses are possible:
- Vendor incompatibility
- Unsupported options
- Overloading by compression
- Collateral loss
More information on the losses encountered can be found in this article by Oglevee C. and Pianykh O in the Journal of Digital Imaging.
Features of a DICOM viewer
Adjacent to image viewing, the most important (and unarguably, the most important) use-case of a DICOM viewer is its image post-processing and reconstruction capabilities. Ranging from simple draw/annotate/zoom to medium-computation capacities of levelling, 2DMPR to high-resource computational features like 3DMPR and Volume Rendering, commercial DICOM viewers have a portfolio of features they offer. Additionally, some viewers integrate reporting abilities on the viewer itself. More on the features of a DICOM viewer will be covered in an upcoming blog article.
How does Nandico's DICOM Viewer fit-in?
Nandico’s DICOM viewer is a cloud-based, remote-access DICOM viewer with the fastest loading speed in the current market. We guarantee no image losses and no quality deterioration across devices. It possesses a multitude of features with one high-resource capacity (stay tuned to know more!) in the pipeline. Additionally, we offer a clean and intuitive UI, and a transparent pricing plan. Head over to Contact – Nandico to get a free demo now!
The Bottomline
DICOM file formats and viewers have significantly evolved since their first stable release (called DICOM 3.0) in 1993. Today, there are even separate, trailblazing DICOM viewers for separate OS: Horos/OsiriX MD are exclusively for MacOS, RadiAnt is exclusively for Windows while an open-source viewer Weasis can work on both platforms. All these platforms are limited to a workstation PACS server and thus confine the radiologist’s mobility. We promise to continue our discussion of workstation-based vs cloud-based PACS and associated levers in our next blog posts as well. Till then, stay tuned!