The opinions expressed herein are those of the author, and not necessarily those of the DICOM Standards Committee, the American College of Radiology, Health Level Seven or The University of Chicago.
I am here this morning representing the DICOM Standards Committee. I participate in DICOM as a representative of the American College of Radiology. I also Co-Chair DICOM Working Group 20 and the HL7 Imaging Integration SIG: this is really the same group recognized by both organizations and functioning as a joint working group. I represent the University of Chicago Hospitals to HL7, and serve as a member of the Radiology basic science faculty at The University of Chicago.
I am pleased to offer my testimony based on this experience, but given the short timelines, it was not possible to develop comments through official channels, and thus it should be stresssed that everything these comments represent my own opinion, and not necessarily that of any of these organizations.
This morning we will begin with some background facts about DICOM, what it is and how it works, and then develop a few points about the permanence of patient records, and finally in that context address the four question areas for which this testimony was solicited.
DICOM is a standard for Digital Image COmmunications in Medicine, whence comes its name, that is deployed in billions of dollars’ worth of equipment, and available from every major medical imaging equipment manufacturer. DICOM began as a joint effort by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), and in its first two versions was called the ACR-NEMA standard. DICOM is now (since the early 1990’s) an independent international organization called the DICOM Standards Committee, which still enjoys a high level of support from the ACR and from NEMA, but also includes other commercial and professional organizations in its membership.
DICOM is an international standard, representative of the global market for medical imaging equipment. DICOM has Type 1 Liaison status with the International Standards Organization (ISO), but the DICOM standard itself has not been submitted as an ISO standard.
The scope of DICOM is Diagnostic Imaging, as shown in Figure 1, which is extracted from Part 1 of the DICOM Standard. DICOM defines image objects from ophthalmology, dermatology, pathology, endoscopy and dentistry, as well as cardiology and radiology. DICOM also defines waveforms including electrocardiograms and electroencephalograms as well as audio. While there are other standards for waveforms, DICOM is unique in its ability to unambiguously synchronize waveforms with medical images, as is needed in cardiology.
But, Diagnostic Imaging is not all images and waveforms. We get patient identifying information and orders from outside the imaging department, and must return reports to the referring physicians. Thus, DICOM also includes facilities for reporting and for workflow management. The workflow management functions enable the automated handling of scheduled examinations and process steps, and tracking their completion status. The reporting features enable the generation of plain text or structured reports that can also reference images or waveforms with pointers, arrows or freehand annotation.
It has been well recognized that integration of imaging workflow with enterprise-wide patient care processes is essential to the efficiencies that digital image management promises. Thus, a large multi-year demonstration project has been jointly undertaken by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS), which brings together vendors to connect, test and demonstrate the interconnected systems under a number of use case scenarios. The project, called Integrating the Healthcare Enterprise (IHE), has completed Year two of its five-year plan. Their implementation guide, called the IHE Technical Framework, is not really a standard but a recipe for a tested configuration, which reduces the optionality in interfaces and provides for a smoother implementation. I like to think that someday, IHE or someone like them will go on to develop implementation recipes for other areas like laboratory, bedside monitoring and other interfaces.
Like other standards, DICOM defines both messaging services and information objects. Information objects may be either Composite or Normalized, and there are separate message services for each type, as shown in Figure 2. Composite information objects are more or less tangible things like images or waveforms or reports, that is, persistent bundles of information that one is not supposed to lose. They are called composite because they contain information about more than one object in the DICOM information model. For example, an image object has not only information about the image, but also about the patient, the equipment and the examination, all bundled together. They can be replaced by later versions, but they should not be modified. DICOM composite services store, move and query for composite information objects.
| DICOM SERVICES | |
|---|---|
| Composite | Normalized |
| C-STORE | N-EVENT-REPORT |
| C-GET | N-GET |
| C-MOVE | N-SET |
| C-FIND | N-ACTION |
| C-ECHO | N-CREATE |
| N-DELETE | |
| Figure 2 | |
Normalized information objects, on the other hand, are virtual things that exist inside of databases, and can be created, deleted and selectively modified using the message services. But there’s not the kind of persistence you see with composite objects.
Over the years of DICOM implementation experience, we have found the widest vendor and market support for the basic composite objects and services that support the acquisition, storage and transfer of medical images and waveforms. Today’s growing interest in workflow management, together with the IHE demonstration program, has increased the use of normalized services. What we have found is that there is a fairly clean separation between the persistent data which must be archived, and the dynamic data which must be managed in the patient care process but is of lesser importance to the medical record, and that these two categories are for the most part manipulated by the Composite and Normalized services, respectively.
With respect to interoperability, DICOM composite services are quite robust. While there have been some glitches with early DICOM implementations, most recent DICOM storage implementations work with just an hour or two of “fiddling” to set configuration parameters. More options present themselves in implementing workflow functions, but DICOM interfaces are still more rigidly constrained than some other standards. There is some loss of flexibility that attends this rigidity, but it is necessary in light of the fact that digital imaging systems are subject to regulatory constraints which limit vendors’ ability to customize their software.
DICOM also defines the storage of composite information objects in files and off-line media such as optical disks. Defining such storage formats is quite significant because it decouples DICOM information objects from DICOM transport services. DICOM information objects can be sent using other methods, such as FTP or e-mail attachments, in cases where DICOM messaging services are unavailable or impractical. (A DICOM supplement defining a MIME type for DICOM images has recently been approved, and is pending before the Internet Corporation for Assigned Names and Numbers (ICANN).) And, as we discuss below, standardized file and media storage formats have a favorable effect on data permanence.
Patient medical information ranges from the transient to the permanent: from information only important in the present context, to information that must be retained many years into the future. When computers were first applied to hospital information, they were used for the transient information where their capabilities could be applied despite limitations of storage space, while long-term patient records were printed on paper and stored in the medical records department. As we move into long-term storage of electronic patient records, it would be natural to continue using the tools and approaches employed for the transient data, but these assumptions must be examined.
Medical records must persist for a long time, much longer than the lifetime of any computer storing them. Thus, any system storing medical records must provide for migration of data to a successor system, and to the successor system’s successor. But how will this migration be accomplished?
The systems we have today are connected by messaging standards, and the actual media formats are not necessarily available to the user. This is true for DICOM archives, and in Relational Databases this arrangement is even enshrined as the Foundation Principle in E.F. Codd’s rules defining a Relational Database[1]. The Foundation Principle, or Zeroth Rule, requires that information be accessed only through the relational model, that is, through the query interface. How it’s stored internally is supposed to be of no concern to the user. This is not a bad thing, because it frees the designer of the database engine to optimize the storage format for high performance.
To migrate the data, one hooks up the two systems and transfers it, one to the other, through the messaging interface. Those who have attempted this with any two databases know that this is not a simple plug-it-together-and-throw-the-switch operation. Both systems must be housed, staffed and maintained while the transfer goes on. Even if everything goes well, it can take a long time [2,3]. It is really not like preserving written records so much as it is like oral tradition. Sage and youth sit down and accomplish the intergenerational transfer of information, and both must be supported while the transfer takes place.
By the time Hippocrates came on the scene in the late 5th century B.C.E., the Greeks were already writing things down, and some of the detailed case histories he recorded have survived, through transcription, to the present day.
The great advantage of written records is that you can transfer them to the next generation even when after the sage is dead. Is there a way we can bring this kind of progress to electronic medical records? If the information is stored in discrete information objects, and if the format of those objects is standardized and contains the information needed to relate them to each other, then the entire database can be reconstructed from the storage media. One could transfer the media, or more likely the data files, to the new system and let the new system assemble them into a new database.
This is happily the case for DICOM archives if the information objects are stored in so-called “Part 10” files on non-proprietary media. We have and we’ve demonstrated it in a real-life PACS migration at The University of Chicago[3]. To accomplish the same thing for computer-based patient records will require standards for stored patient records. There is encouraging progress in this direction at HL7, where the first level of the Clinical Document Architecture (CDA) has recently become an ANSI Standard. Through the joint working group, we have been working with HL7 to maintain compatibility between the CDA documents and DICOM information objects.
The conclusion from my experience in using DICOM is that it a worthwhile investment up front to separate transient data from the data we need to keep. It serves not only the longevity of the data, but also the integrity: if the patient’s record comprises N data objects, and you have transferred all N of them, then you can say that you have transferred the complete patient record. Such a test is more complex to define for a patient record consisting of database entries.
In this context, the following comments are offered in response to the “Draft Framework for Testifier Comments on the Draft Criteria for Selection of PMRI Standards” issued by the Committee. The first three questions solicited comments on:
The criteria, questionnaire and transaction set are reasonable and well thought-out, but I do have some concerns about the scope and degree of specificity of this selection process. I will return to general remarks later, but first I will offer some specific comments on the first three questions.
The criteria listed in Question 1, namely
are certainly valid, although it is difficult to say how one would measure and weigh these criteria to “choose” a standard to recommend under HIPAA. If this is intended to be a prioritized list, then data quality should, in my opinion, be at the top. If different medical records use different vocabularies and measurement units, and those vocabularies and units are clearly identified, it is possible, at least in principle, to build a translator, but if data are collected inconsistently or if records are missing or corrupted, there is little that can be done to rescue them.
The questionnaire covers a good set of quality measures for a standard, but is missing questions about data permanence and data migration. The questionnaire should ask how systems implementing the standard can migrate data to future systems, and how loss of information content in multiple migrations over many years can be avoided. And, the standard should have a way of defining completeness in transfer of a patient’s record. Also included should be whether the standard specifies a storage format for archival data. If the standard includes a storage format specification, is it based on a general-use file system or standard-specific media? In other words, if stored data is to be transferred from one media form to another, can this be accomplished via generic file-copying operations or must it include custom applications programs specific to the standard?
This is a good questionnaire, and I believe the results of the survey would make an interesting journal article. The government has some unique advantages that will help it obtain a high response rate to the survey. I believe the survey and the analysis of the results may help the DHHS to plan an approach to promoting standards for PMRI. But I doubt that it will directly lead to a selection of a winning standard for PMRI.
The proposed transaction set is reasonably complete. One change I would propose is that “radiological images” should be expanded to “medical images and waveforms”, as images are also produced in endoscopy, pathology, dermatology, cardiology and a host of other disciplines. Images and waveforms produced in diagnostic procedures are part of the evidence on which diagnostic results are based. The results are part of the medical record and must be retained for very long times, whereas required retention periods for evidence data are generally significantly shorter. We will have to be aware that as images find their way into reports, depending how they are referenced in the text portion, they may become part of the medical record and subject to longer retention requirements.
The stated topic, “… Selection of PMRI Standards” needs to be clarified with respect to the specificity of the planned selection. Is the goal to specify a fixed set of transactions and select a single “winner” for each transaction? Or is the goal to select a number of Standards Development Organizations to work with in converging on a set of interoperable standards? I would hope and recommend that the latter approach be followed. The process is not as simple as defining the transactions and selecting the best standard for each. I think the actual terrain of healthcare standards does have some areas of contested turf, but for the most part the various standards occupy different application domains. Thus, the hard work before us is one of bridging between these standards, and interfacing between real systems serving these application domains.
In other words, it is not that there are a lot of viable, acceptable and tested standards available, and that the DHHS just needs to choose the best ones. There is in fact much that remains to be done. In most of those areas where the standards are mature and well matched to application needs, there are already standards in almost universal use, as is DICOM for interfacing to imaging devices. In areas where obvious standard solutions are absent, there are more gaps than overlaps between standards.
The Federal Government can help in PMRI standardization efforts in a number of important and productive ways. Standards have immense impact, and yet standards organizations are limited by resources, most particularly by the number of qualified participants. The need for more representation from healthcare provider organizations is particularly acute. There are a number of disincentives to their participation:
A possible approach would be some fellowships to participate in standards work, perhaps awarded through the NLM by peer review, at a variety of levels. Representatives from provider organizations might just need travel fellowships; support for standards-related grants could encourage participation by academic informaticians. Similar considerations were used in designing the IAIMS program of the NLM.
And of course, some sort of public licensing or support of free vocabularies would save us all a huge amount of trouble, and would remove an annoying impediment to their use.
The standards development efforts can certainly use some help, enabling some acceleration of the process, but the vine can be killed by too much watering. The key reason is that pressure to achieve rapid consensus yields too much optionality, which is the enemy of interoperability. Let’s look how that works: three vendors come together to define a standard. Their data elements overlap as in the Venn diagram in Figure 3. They can agree on the things in the intersection, but the only way to get consensus immediately is to make the standard encompass the union of the three sets, and the only to do that is to make everything outside of the intersection optional. If you rush the process, that’s what you get. High interoperability requires little optionality, and that often takes many rounds of negotiation and use case review.
[Figure 3. Rapid consensus breeds optionality. not available]
My recommendation would be that the NCVHS narrow the scope of PRMI standards selection at this point, focusing on transactions sending results to the permanent patient record, and administrative functions managing results within the permanent record (merge, etc). Once standards have been selected, profiles or templates need to be defined to improve interoperability within each standard implementation. This in itself is quite an ambitious project, and is the one that has the greatest long-term impact.
In the meantime, implementation HIPAA claims requirements will have effects on implementation practice that will ripple through the healthcare system, in ways that I believe will be hard to predict, and it would be beneficial to wait for these results before attempting to standardize the many transactions handling transient data in the healthcare process.
In evaluating standards for transactions involving electronic health records, note should be taken of overseas efforts in CEN TC251 (Europe) and GEHR (Australia). These groups have made significant progress, and their experience bears attention.
And finally, coming back to the point stressed earlier, standardization of storage formats as well as message services is a powerful asset in the maintenance of long-term records.
1.Codd EF. A Relational Model for Large Shared Data Banks. Communications of the ACM. 1970;13.
2.Behlen FM, A DICOM document-oriented approach to PACS infrastructure, J. Digital Imaging, 11:3 Suppl. 1, 35-38, 1998.
3.Behlen FM, Sayre RE, Weldy JB, Michael JS, “Permanent” records: Experience with data migration in radiology information system and Picture archiving and communication system replacement, J. Digital Imaging, 13:2 Suppl. 1, 171-4, 2000.