Summary
The Digital Imaging and Communications in Medicine (DICOM) standard is used for the exchange of images and related information. The DICOM standard can be thought of as having several levels of support, such as the support for image exchange for both senders and receivers, the underlying information model and information management services.
This whitepaper provides a high-level overview of the characteristic elements of the DICOM standard.
1. Introduction
What is DICOM? The Digital Imaging and Communications in Medicine (DICOM) standard has been around for more than a decade now. However, it was not until the mid-nineties that the DICOM standard really took off.
Today, virtually all imaging devices (aka Modality) that are used in radiology, such as CT, MRI, Ultrasound, RF, and other digital rooms, supports the DICOM standard for the exchange of images and related information.
Imaging devices for other "ologies", such as endoscopy, pathology, ophthalmology and dermatology, are also starting to implement the DICOM standard, because there is an increasing need to integrate all of these images into the patient master record (e.g. EHR).
Though it is not an official term, one can think of the DICOM standard as having several levels of support, or different dimensions. The most fundamental and primary level of support is the support for image exchange for both senders and receivers. Other levels include support for connecting to a database and retrieving image information or for enabling another device to find out which images have been locally stored so that it can retrieve them. Other dimensions deal with image management, patient scheduling information, image quality, media storage, security, etc. But before we delve into these detailed DICOM services, let's first discuss the DICOM fundamentals.
2. DICOM Fundamentals
2.1 Information Model
DICOM has an information model, which differentiates it from other standards, in particular the HL7 version 2.x standard, which is generally used elsewhere in the medical facility to exchange patient and related information. The DICOM information model includes relationships between the DICOM objects as well as a common terminology.
DICOM information objects are definitions of the information to be exchanged. One can think of them as templates that are re-used over and over again when a modality generates a new image or other DICOM object. Each image type, and therefore information object, has specific characteristics. For example, a CT image requires different descriptors in the image header than an ultrasound image or an ophthalmology image. These templates are identified by unique identifiers, which are registered by the National Electrical Manufacturers Association [NEMA], the DICOM standard facilitator.
Information objects are also known as part of the Service Object Pairs (SOP) Classes. An example of a SOP Class is the CT Storage SOP Class, which allows CT images to be exchanged. Even though most people associate DICOM objects with images, it is important to note that a patient schedule list and a queue to be sent to a printer are also DICOM objects with defined templates.
| |
The information model defines that a patient can have multiple studies resulting in multiple series that contain the individual images. This definition is necessary if a patient has a CT scan, which has two series of images, one with contrast and one without. One might think that this definition is obvious; however, it is critical to specify the terms and their meanings, otherwise devices will never be able to communicate.
An information model is especially critical when interfacing with information systems that have to deal with multiple scheduled procedure steps, all identified by their own identifiers, all relating to the procedures that were performed and all relating to the results (reports, measurements, 3-D reconstructions, etc.) in an unambiguous manner.
|
2.2 Transport
The DICOM protocol is rather robust. First, each DICOM command is acknowledged. Second, a device just does not send an object; it always negotiates whether the receiver indeed understands this type of service as well as the object type. This provides an implicit version control. When a receiver does not understand the latest Multiframe Ultrasound object, for example, it will inform the requester so that the sender can either fall back to a different object (e.g. a previous version) or send the information to a different destination.
This negotiation is referred to as Association establishment. In addition to the type of service, it also negotiates the Transfer syntax. The Transfer syntax is nothing more than the encoding that is used to exchange the information. A device might support the standard transfer syntax or a specific JPEG compression syntax that allows the information to be exchanged in a faster way. There are several different Transfer syntaxes and they can be expected to expand continuously as new image compression methods are developed.
There are very strict guidelines requiring each DICOM compatible device to describe its functionality, including the supported SOP Classes and Transfer syntaxes in a document called the DICOM Conformance Statement. This document allows a user to determine in advance whether or not a specific device is compatible with other devices.
Conformance statements contain details about exception and error handling and often contain the complete specifications for the information objects (e.g. images) that are exchanged.
Not only are these documents used by potential users and buyers, they are also key documents for the people who make these systems work, such as system integrators and testers.
| |
Imagine that you have just purchased a new device and installed it. When connecting, the new modality does not communicate with your other devices: the DICOM connection never makes it past the negotiation; it refuses to communicate with your installed base. There can be a very good reason for this lack of communication. The device might support a newer SOP Class, which your other devices do not (yet) support. To find this out during system installation is somewhat late, though.
The functionality of the device is described in the DICOM Conformance Statement. For example, if you require a radiology order number to be present with your images, you should look in the device's conformance statement for this feature. In addition, you can find details such as which compression technology is supported, what media is supported, etc.
|
3. Dimensions of DICOM
How can the DICOM standard be used? One can discuss this according to the levels or different dimensions of DICOM.
3.1 Exchanging Objects
The first level is the basic mechanism to exchange objects, such as images and diagnostic reports provided by the
Storage SOP Classes.
With regard to imaging, new acquisitions techniques are continuously being defined that require information objects to be modified, so that the appropriate information is exchanged.
The nice thing is that there is often already a DICOM infrastructure in place that allows the exchange, archival and retrieval of these new objects.
Radiology is becoming a provider of archiving and storage services for the other specialties.
This is confirmed by the ever increasing popularity of Picture Archiving and Communication Systems (PACS).
3.2 Information Management Services
The next dimension of DICOM deals with information management services. As soon as we exchanged images, users found that they had to have a PACS system administrator, who would pretty much spent all of his time dealing with 'orphan' images. Orphan images are images that have been lost or are being temporarily stored in the so-called penalty box at the archive or QA station.
The DICOM Modality Work List allows scheduling information to be retrieved by a modality.
It has been widely implemented and should be a requirement for all new modality purchases.
The companion service of the Modality Work List, the Modality Performed Procedure Step, is not yet as popular. Most vendors are now offering it in their newest modalities. This service allows a device to communicate what the actual performed exam was (versus what was scheduled) to allow changes in the procedure to be exchanged. In addition, it tells when a procedure has been started, potentially indicating this on the scheduling list and provides information about the number of images that were generated.
The other service in this category is the DICOM Storage Commitment, which transfers the responsibility for the images to the receiver, so they can be safely removed from the local disk.
Workflow management is one of the relatively recent additions to the standard. These services is basically a generalized version of the Modality Work List and Modality Performed Procedure Step services. It levels the playing field even more to allow best of breed systems to be implemented.
As of today, it is almost impossible to purchase an image archive from vendor A and to use workstations from vendor B. They are still tightly coupled. However, it is possible to retrieve a list of all images from the archive at the workstation, if you want to know which image is being read by which physician, to avoid duplicate reading. In order to implement this you have to understand the proprietary protocols that vendors exchange among themselves and update, for example, the status of an image. This is changing with the implementation of the DICOM General Purpose Work List mechanism.
The General Purpose Work List will provide a standard manner by which a reading list or a folder can be provided to a workstation, e.g. containing all chest images to be read. The workstation can then 'lock' this study to let others know that it is being read.
| |
Why would mismatches occur? There have been no scientific studies that we know of, but there are reports that state that in general 40% of the data entered has some type of spelling error. What is the solution? Central data entry and management.
The DICOM Modality Work List allows scheduling information to be retrieved by a modality and is therefore a must. Almost all vendors provide this service now. A technologist merely scans a barcode or selects the patient information from a menu and the information is copied on the screen. This is almost a no-brainer; people don't want to have to fix misspellings anymore.
IHE and Workflow
What is IHE ? The IHE [IHE] (Integrating the Health Enterprise) initiative offers a formalized description of workflow processes within the healthcare enterprise. These workflow processes are subsequently formalized in the form of implementation profiles for transactions used to communicate clinical data. These implementation profiles are created by a consensus process among professionals; the profiles are based on existing messaging standards such as HL7 and DICOM.
The IHE Radiology implementation profiles are widely supported by vendors.
|
3.3 Image Quality
Image quality is another major area in which a lot of improvements have been made due to DICOM standardization. The problem is how to achieve consistency in the image presentation on different monitors, as well as on film, independent of the make or type of characteristics of the media.
The first thing that had to be created was a 'gold standard' that every monitor and hardcopy device could adhere to. This gold standard is the DICOM Grayscale Standard Display Function.
It specifies exactly what luminance or density level should be produced for a certain input value, based on the Barten curve, which maps the values into a range that is perceptually linear. This means that input values are mapped into a space that is perceived as linear by a human observer.
Figure 1. Inconsistent image display.
The lump visible on the left is almost invisible on the right.
What is the impact of this standard? The result is that the images all look alike. When an image is sent from a radiologist to a physician, the physician sees the same grayscale presentation. The same applies for the technologist. She wants to make sure that what she sees on the monitor is what she will get on the film, even if the printer is in the basement or in the main radiology department, instead of in the outpatient clinic.
What do we have to do to achieve this consistency? Well, devices have to support the DICOM grayscale standard, potentially implementing a presentation look up table (a.k.a. presentation LUT) to map the values.
The other component of image quality is presentation consistency. When a physician zooms an image, ads annotation, changes the Window width and Level, etc., this information should also be preserved in a standard manner. Often today this information is stored in a proprietary way, so it is impossible to view it on a workstation from another vendor. This could be taken care of by the DICOM Presentation State Service.
3.4 Structured Reporting
DICOM Structured Reporting deserves a discussion by itself (see [StrucRep]). It is just an object that can be exchanged, very similar to an image, except that instead of pixel data, the message body is a Structured Report (SR). Why would we want to standardize a report in DICOM if HL7 has exchanged these for several years in a relatively robust manner? The answer is two-fold.
-
The HL7 version 2.x standard does not really allow for a rigorous structure. It is still more or less a blob of text without a lot of contextual information. Having a structure is sometimes even a legal requirement, such as in the case of mammography. In other cases, the information is always presented in a structural, similar way, such as specific measurements for Ultrasound. The advantage of a structure is that it lends itself very well to data mining and potentially can be used to do outcome measurements.
-
It allows very effective linking to other DICOM objects, such as images, parts of images, presentations of images, waveforms, etc. It integrates very well in the DICOM structure, which is why one might expect that when mages are closely linked, the SR will be used.
A critical part of the SR is the definition of templates that can easily be mapped, for example, in XML. These templates are still very much under development; however, there are activities that include the cardiology logs and the development of output for Computer Aided Diagnosis systems, such as used for mammography. There are other specific SR applications, such as the ability to contain information about key or significant images.
3.5 Security Mechanisms
Another dimension is related to the DICOM Security mechanisms.
First of all, one should note that the DICOM standard facilitates the exchange of information. It is only part of the overall information chain. Therefore, it is also only a relatively small part of everything an institution has to do to create a secure environment.
Before a person accesses an image, there are procedures and rules about the placement of the monitor. There are access control and authorization rules that are taken care of by the application level software using passwords or even biometric access controls. There is an audit and logging mechanism required that logs any data access and by whom.
When we finally have access to the information and want to retrieve it using a non-secure line, such as the Internet, is when DICOM has to worry about the security. This is a relatively easy extension; the data can just be encrypted using standard mechanisms and utilities. Electronic signatures are another aspect of DICOM security. The electronic signatures prevent someone from changing the information without the receiver noticing it.
Security is described in the DICOM standard as well as in the IHE Technical Framework [IHE]. Both encryption and digital signatures have been demonstrated at RSNA and the European Congress of Radiology (ECR). The demonstration software and public source code are available for implementers to try out and use.
3.6 Exchange Media
Media is a part of the DICOM standard that often creates confusion. Vendors who claim to offer a 'DICOM archive' mostly cause this misunderstanding. Since the DICOM standard is a communications standard, there is no such thing as a DICOM archive, though there can be a device that supports the DICOM way of exchanging information. DICOM does standardize exchange media, though.
The exchange media is intended to be used to store images or other DICOM objects in a standard format. These images or other DICOM objects can then be exchanged and potentially be read by another device that can read that format. The applications are typically for portable Ultrasound units that collect images on a CD. The CD is later used to download the images to a workstation. Another good application is the collection of a cardiology study on a CD so that the patient can take it with him to another hospital.
|
Because we don't have the luxury of negotiating what type of information is to be stored on those media, including the transfer syntax (e.g. what type of JPEG), there are very strict constraints defined in the Media Application Profiles. Some archives store the images in the format as described by these application profiles, and therefore claim to be a DICOM archive. Again, this is somewhat confusing.
4. Future Developments
What can be expected from DICOM in the near future? The DICOM standard is never more than 2 months old. Every two months a new addition to the standard is created and released.
Does this mean that you will have to upgrade your system every two months? Definitely not. A CT device that could send images in a DICOM format, supporting the DICOM Storage SOP Class in 1993 would still be able to do so in 2004. However, if you want to exchange MR spectroscopy data, your device would have to support the new MR SOP Class. So, when technology advances, you can expect the DICOM standard to follow it and accommodate it.
The latest additions to the DICOM standard, including a draft version of the complete standard can be found at the NEMA website [NEMA].
5. References
[IHE] "IHE Radiology Technical Framework", http://www.ihe.net
[NEMA] "Digital Imaging and Communications in Medicine", http://medical.nema.org
[OTech] http://www.OTechimg.com/
[StrucRep] "Structured Reporting, a powerful DICOM mechanism", http://www.ringholm.com/docs/02030_en.htm
| |
An example of a recent addition to the DICOM standard is Visible Light, which will accommodate endoscopy, pathology, ophthalmology and dermatology. Radiation Therapy (RT) is also feeling the pinch for increased integration. They require the import of regular images such as CT scans and radiographs and the creation of objects such as therapy plans, RT images, and treatment records. RT modalities are just starting to implement these services and to become integrated. They are where main radiology was 5 years ago with regard to connectivity; they are just starting to implement and offer the basic level of image communication.
Other new additions that are in the pipeline include a new MR object that can accommodate the new acquisition techniques and the exchange of spectroscopy data, new CT objects and also 3-D objects (for Ultrasound, for example). In general, acquisition is moving to multi-dimensional, 3-D or more, and DICOM is following that trend.
|
About Ringholm bv
Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT.
We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
|
