DICOM

Digital Imaging and COmmunications in Medicine 

Steven C. Horiil, Fred W. Prior(2), W. Dean Bidgood, Jr.(3),  Charles Parisot(4), Geert Claeys(5)

1. : Department of Radiology, Hospital of the University of Pennsylvania
2. : Department of Radiology, Pennsylvania State College of Medicine
3. : Department of Radiology, University of North Carolina, Chapel Hill
4. : General Electric Medical Systems
5. : Agfa Gevaert

The ACR-NEMA Digital Imaging and Communications in Medicine (DICOM) Standard has been developed to meet the needs of manufacturers and users of medical imaging equipment for interconnection of devices on standard networks. Its multiple parts provide a means for expansion and updating, and the design of the standard was aimed at allowing simplified development for all types of medical imaging. DICOM also provides a means by which users of imaging equipment may assess whether two devices claiming conformance will be able to exchange meaningful information. The future additions to DICOM include support for creation of files on removable media (such as optical disks or high-capacity magnetic tape), new data structures for x-ray angiography, and extended hard copy print management. The 1993 demonstration at infoRAD is expanded over that of 1992 and shows different manufacturer implementations and communications using both the DICOM information objects and the services that support them.

At the 1992 annual meeting of the Radiological Society of North America (RSNA), parts 1 (Introduction and Overview) and 8 (Network Communications Support for Message Exchange) of the ACR-NEMA DICOM (Digital Imaging and Communications in Medicine) Standard had been balloted and approved, and the final drafts were circulated. The remaining parts 2 through 7 and 9 were made available for comment. At infoRAD, a demonstration of DICOM Version 3.0, part 8 using previous ACR-NEMA Version 2.0 messages was shown. While these were not implementations that included all of the DICOM data structure, they did show that the network support was operational and could be implemented successfully.

During the year since the 1992 meeting, the ACR-NEMA Working Groups (WGs) responsible for the remaining parts of DICOM met monthly to complete the standard. This was accomplished in September 1993, after near-final versions of many of the parts had undergone the test of actual implementation throughout 1993 to ensure that a quality standard would be demonstrated by actual products at the 1993 RSNA meeting.

Now that DICOM Version 3.0 is finalized, users and manufacturers may get some idea of the scope of work involved. Because its multiple parts and arcane-appearing diagrams and terminology, understanding the use and value of these documents is a daunting task. This brochure will serve as an introduction to what DICOM is, what its component parts are, what major concepts form its foundation, and how it is bound to extend the electronic revolution in medical imaging.

In an effort to develop a standard means by which users of digital medical imaging equipment (such as computed tomography, magnetic resonance imaging, nuclear medicine, and ultrasound) could interface display or other devices to these machines, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee early in 1983. The mission of this group, the ACR-NEMA Digital Imaging and Communications Standards Committee, was to find or develop an interface between imaging equipment and whatever the user wanted to connect. In addition to specifications for the hardware connection, the standard to be developed was to include a dictionary of the data elements needed for proper image display and interpretation.

The committee surveyed many existing interface standards, but none was found that was entirely satisfactory. Some, however, were found to contain useful ideas. The American Association of Physicists in Medicine (AAPM) had, about a year before, developed a standard format for recording images on magnetic tape (1). The header portion would contain a description of the image along with the data elements (such as patient name) identifying it. A concept of using data elements of variable length identified with a tag or key (the name of the element) was thought to be particularly important and was adopted by the committee.

After 2 years of work, the first version of the standard, ACR-NEMA 300-1985 (also called ACR-NEMA Version 1.0) was distributed at the 1985 RSNA annual meeting and published by NEMA. As with many first versions, errors were found and improvements were suggested. The committee had empowered Working Group (WG) VI to follow up on the standard after it was published. This WG answered many questions from potential developers and began working on changes to improve the standard. In 1988, ACR-NEMA 300-1988 (or ACR-NEMA Version 2.0) was published. It used substantially the same hardware specification as Version 1.0, but it added new data elements and fixed a number of errors and inconsistencies.

The problem was that by 1988 many users wanted an interface between imaging devices and a network. While this could be accomplished with Version 2.0, the standard lacked the parts necessary for robust network communication. For example, one could send a device a message that contained header information and an image, but one would not necessarily know what the device would do with the data. Since ACR-NEMA Version 2.0 was not designed to connect equipment directly to a network, solving these problems meant major changes to the standard. The committee had very early adopted the idea that future versions of the ACR-NEMA Standard would retain compatibility with the earlier versions, and this placed some constraints on WG VI.

In a decision of major importance for the standard, it was decided that developing an interface for network support would require more than just adding patches to Version 2.0. The entire design process had to be re-engineered, and the method adopted was that of object-oriented design. Later sections will describe this process briefly.

In addition, a thorough examination of the types of services needed to communicate over different networks showed that defining a basic service would allow the top layer of the communications process (the application layer) to talk to a number of different network protocols. These protocols are modeled as a series of layers, often referred to as "stacks." The existing Version 2.0 stack that defined a point-to-point connection was one. Two others were chosen based on popularity and future expansion: the Transmission Control Protocol/Internet Protocol (TCP/IP) and the International Standards Organization Open Systems Interconnection (ISO-OSI). Figure 1 shows a diagram of the communication model developed. The basic design philosophy was that a given medical imaging application (which is outside of the scope of the standard) could communicate over any of the stacks to another device that used the same stack. With adherence to the standard, it would be possible to switch the communications stacks without having to rewrite the computer programs of the application.

Figure 1: The DICOM communications protocol model (see text for description; click above for figure).

After three years of work, WG VI, with many valuable suggestions from industry and academia, completed ACR-NEMA DICOM (also called DICOM 3.0). It is a much larger standard than Versions 1.0 or 2.0, but it also supports many more features than either of the prior versions.

Figure 2: The DICOM application model (click link above for figure). The rectangular boxes represent the entities which singly, or in combination, form the information objects. The diamond-shaped boxes are the relationships. The arrows represent the connections between entities and relationships and are shown with arrows to give some idea of the hierarchy not necessarily the movement of information. The "ls" and "Ns" indicate whether the relationship involves one entity to one entity, one to N, N to one, or N to N entities. IOD - information object definition, VOI - value of interest, LUT - look-up table, Mod - modality.

Simply stated, DICOM is a standard for the communication of medical images and associated information. It differs from ACR-NEMA Versions 1.0 and 2.0 in several major respects. Most important is that the basic design of the standard was changed. Versions 1.0 and 2.0 relied on an implicit model of the information that is used in radiology departments. The data elements were grouped based on the experience of the designers, and though the mapping was imperfect, the message structure did allow the necessary information to be transmitted. In contrast, DICOM relies on explicit and detailed models of how the "things" (patients, images, reports, etc.) involved in radiology operations are described and how they are related. These models are called entity-relationship (or E-R) models and are a way to be sure that manufacturers and users understand the basis for developing the data structures used in DICOM. Figure 2 shows an example of an E-R diagram, the overall application model defend for DICOM. This modeling process was begun in one of the working groups created as DICOM was being developed (WG VIII). This group began with the task of defining the interface requirements between a picture archiving and communications system (PACS) network and a hospital or radiology information system (HIS or RIS). This definition process required that the operations in radiology be properly modeled so that what was needed from an HIS or RIS could be determined along with what would be done with that information in the PACS. The basic E-R diagram for radiology department function served as the basis for most of the additional modeling done by WG VI in developing DICOM. The advantage of these models is that they clearly show both the data items required in a given scenario being modeled and how these items interact and are related. In looking at an E-R diagram it is important to note that it is not a flowchart that describes the steps of information movement; rather, it shows the relationships and hierarchies of information elements. Arrows are added to diagrams so that the direction of relationships is not misinterpreted. These diagrams are widely used throughout the DICOM standard as they clearly show the assumptions made in developing the components of the standard.

The importance of modeling arises from the need to know the context of the information when considering network communications. In a point-to-point environment, the user will know exactly what devices are connected and what their capabilities are. Hundreds of devices may be attached to networks and some devices may be reconfigured dynamically to handle different data loads or tasks. This means that it may not always be possible to know what the devices communicating can do. The devices may have to negotiate to establish a common ground on which to build the communications necessary to perform the task the user has requested.

As an example, consider one person making a telephone call to a stranger to ask about fixing an automobile engine. At a low level, communication involves dialing the correct phone number. This will establish a link between the two people. But, if the two people do not speak the same language, they will not be able to communicate. Even if both speak the same language, if their understanding of car engines is vastly different, they will not be able to communicate about the task at hand (fixing the engine). Successful communication requires not only that the individuals have the correct telephone number (network address) and establish a telephone connection, but that they agree on the language to speak and that they negotiate the level at which they have a common understanding (the presentation context).

This approach to developing data structures based on models and analysis of abstracted versions of real entities used in the models is obiect-oriented design. The objects are the entities (or collection of entities) defined by the model. Describing the characteristics of each of the entities are attributes. For example, the "patient" entity in Figure 2 has attributes that include "patient name" and "patient ID number" (to simplify the diagram, the attributes for the entities are not shown, but the standard includes tables that define these). DICOM calls the objects based on its models "information objects" and the models and tables of attributes that define them "information object definitions" (IODs). The entities shown in the model are abstractions. If real values are substituted for the attributes, the entity is called an " instance. "

Object-oriented design also provides a way to describe not only the information but what to do with the information, or how computer programs would access the information about a collection of objects. In object-oriented design, methods are associated with the defined objects. DICOM makes use of this concept by defining services such as "store image," or "get patient information." These services are implemented in DICOM using constructs known as operations or notifications. DICOM defines a set of generic operations and notifications and calls them the DICOM message service elements (DIMSE). The combination of an information object and such services is called a senice-object pair, or SOP. An information object may be used with a set of services, the result being a SOP class. Figure 3 shows an analogy between constructing a sentence and the corresponding items in DICOM.

The SOP class represents the elemental unit of functionality defined by DICOM. By specifying a SOP class to which an implementation must conform and the role a conforming device must support, it is possible to define unambiguously a precise subset of DICOM functionality including the types of messages to be exchanged, the data transferred in those messages, and the semantic context within which that data is to be understood. A device may, for a particular SOP class, serve one of two roles: in the service class provider (SCP) role, the device provides the services of the SOP class, or in the service class user (SCU) role, uses the services. Moreover, for each combination of SOP class and role, the standard defines a basic set of default behaviors governing communication, such as which device may initiate a conversation (2).

The Parts of DICOM - FIGURE 3   FIGURE 4

Figure 3: An analogy between building a sentence and DICOM concepts see p 8 for figure. The items to the left of the arrows represent parts of a sentence. To the right of the arrows are the analogous DICOM concepts. The verb "store" defines an action to be taken, equivalent to the DICOM Service carried in the DICOM Message Service Element. The noun "CT Image" defines a subject upon which the action will be taken; this corresponds to the DICOM Information Object Definition. The sentence constructed: "Store a CT Image" corresponds to the DICOM Service Object Pair Class, and if a specific CT image is referred to, the correspondence is to a Service Object Pair Instance.

Figure 4: The present parts and proposed extension of DICOM (see below for figure). This figure is not a layered model. The left hand portion represents the parts that define network and point-to-point DICOM communications. The right hand portion shows the parts that support communication using removable storage media. Note that some parts (parts 1, 2, 3, 5, and 6) are used in both environments while others are particular to the specific communications domain.

Unlike ACR-NEMA Versions 1.0 and 2.0, DICOM divides much of the specification into parts. This was done so that parts could be expanded (e.g., new information object definitions added) without having to republish the whole standard. Within the parts, those sections subject to addition or modification are in annexes, further reducing the editing required when updating parts. The current version of DICOM consists of nine parts. The interrelationships of the DICOM parts are not always readily apparent. Figure 4 is a diagram showing how the parts are related. This figure also shows parts 10 and 11, which address the way DICOM can use files on removable media (e.g., disk and tape) for exchange of information. These parts are described later in this brochure.

Part l of DICOM is the document that provides an overview of the rest of the standard. It provides a description of the design principles, defines many of the terms used, and gives a brief description of all the other part.

Part 2 is the definition of conformance to DICOM, and what conformance means. Rather than provide a specific list of items that every type of implementation has to follow to be conferment, DICOM offers a number of building blocks (e.g., SOP classes) and requires manufacturers to describe unambiguously how their products conform to DICOM. This process is constructing a conformance statement, and users will have access to these from the manufacturers. ACR-NEMA Versions 1.0 and 2.0 lacked such a mechanism, so it was possible for two devices claiming to be conformant to have different enough implementations that they would not communicate. The number of possible choices for information objects, service classes, roles, and data encoding in DICOM means that this problem would be far worse if there were not some way to describe exactly what choices were made in implementations and what basic requirements must be met by all implementations claiming conformance. This will guide users in selecting products that should work together and may also form the basis for a user to develop a conformance requirement as a part of a purchasing agreement.

Part 3 describes how information objects are defined. It then goes on to define the information object classes used in DICOM. In developing the information object definitions (IODs), it was found that many would contain groups of similar attributes. These were then collected together as a series of common modules that can be used by more than one IOD. The IODs themselves are in annexes to the part, ensuring that additions can be made without having to rewrite the unchanging section of the part. Table 1 lists the IODs defined in the annexes to part 3.

Table 1: DICOM Information Objects

Composite IODs Normalized IODs Computed Radiography Image Patient Information Computed Tomography Image Visit Information Magnetic Resonance Image Study Information Nuclear Medicine Image Study Component Information Ultrasound Image Results Information Ultrasound Multi-Frame Image Interpretation Information Secondary Capture Image Basic Film Session Stand alone Overlay Basic Film Box Stand alone Curve Basic Annotation Presentation Basic Study Description Basic Print Job Information Stand alone Modality Lookup Table (LUT) Basic Printer Information Stand alone Value of Interest (VOI) LUT VOI LUT Image Overlay Box

The two columns of the table are important. The left column lists IODs that are composite objects. These objects contain attributes that are related, but not inherent to, the real-world entity, plus those that are inherent. For example, the Computed Tomography IOD contains the attribute "image date" which is inherent to a CT image. However, it also contains the attribute "patient name" which is related to the CT image, but not inherent to it (it is an attribute inherent to the Patient Information IOD). The right column lists IODs that are normalized objects. The latter example, Patient Information, is normalized. It contains attributes that arc only inherent to the patient. There has been some debate about the composite objects since they were defined to retain some compatibility with Versions 1.0 and 2.0, but do not adhere to strict object-oriented design guidelines. However, recent computer science literature notes advantages of a composite object. Using composite objects means that related and inherent attributes can be retrieved (say, reading from disk) with fewer accesses (3).

Part 4 of DICOM contains the service class specifications. Service classes are built up from a set of operation primitives operating on IODs. The services can be thought of as the operations performed on the information objects. The roles of SCU and SCP are also defined in this part, and the expected behavior for each role in each service class is specified. This allows implements and users to understand what is expected of a device that supports a particular service class. Table 2 is a listing of the DICOM service classes of Version 3.0.

Table 2: DICOM Version 3.0 Service Classes

Part 4 Annex Service Class Name Annex A Certification Service Class Annex B Storage Service Class Annex C Query/Retrieve Service Class Annex D Study Content Notification Service Class Annex E Patient Management Service Class Annex F Study Management Service Class Annex G Results Management Service Class Annex H Print Management Service Class

The left column of the table is the annex of part 4 that specifies the service class named in the right column. Verification is intended to be used for checking and troubleshooting implementation service protocols. The storage service class provides the basic support for transfer of images between DICOM applications. To retrieve images from DICOM applications, the query/retrieve service class supports basic operations to access and move images based on simple search criteria (e.g., get all of the images of a particular patient). Study content notification allows one DICOM application to notify another about the existence, contents, and source location of the images in a study ("study" here has a specific DICOM definition, but in general is the collection of images and associated information that results in a single report being generated). The patient, study, and results management service classes were designed to support communication between DICOM-using PACS and a separate radiology or hospital information system (RIS or HIS). Patient Management handles admission, discharge, and transfer information along with the other demographic and visit information. Study management supports the creation, scheduling, performance, and tracking of studies. Results management has a similar role for the results of studies. Unlike the storage and query/retrieve service classes that also use patient information, these service classes are not image oriented. In addition to the information modeling used in DICOM, these service classes make use of functional modeling as well. This was done so that the role of the particular DICOM management service class relative to other information system functions would be well defined. The DICOM print management service class supports

DICOM device communication with networked hardcopy image printers (such as laser or color paper printers).

Once a DICOM application assembles a data set (a collection of information assembled from DICOM information objects and service classes), it must be encoded so that it can be put into message form for communication. This encoding process is specified in part 5. The main function of this part can be thought of as defining the "language" that two devices will use to "speak" with each other. The mechanics of the speaking are defined by the message exchange protocol (part 7), and the subject matter and what is to be done are defined by the information objects and service classes (parts 3 and 4). Such things as what character set (for text) is used, how a JPEG (Joint Photographic Experts Group) compressed image is encoded, how the data elements are structured, and what transfer syntax is used are also defined by part S. The transfer syntax is a set of encoding rules that is negotiated by two communicating applications so that they may unambiguously understand each other. To ensure the broadest interoperability between DICOM conformant devices, or communication with limited-capability devices, DICOM provides a default transfer syntax. All applications claiming to conform to DICOM must support at least this default syntax.

At the most basic level, all information objects are composed of data elements. These elements encode the values of the attributes described earlier (e.g., patient name, number of bits per pixel). To turn an information object from an abstract entity to an instance that represents something in the real world, values are supplied for the data elements. Part 6 of DICOM is the complete listing of all data elements along with their numeric names (or tags), their text names, what their representation is (text, floating-point number, etc.), whether they contain one or more items (the value multiplicity), and what the allowed values are for those elements that can only take on certain values. To maintain compatibility at this level of the DICOM data structure with earlier ACR-NEMA standards, no elements were re-defined unless they had errors in them. Elements no longer used are given the status of "retired," indicating to users and manufacturers that they may include the element in a DICOM data set, but it may be ignored unless the particular application being communicated still uses the element.

The user of a piece of medical imaging equipment interacts with software that translates his or her input into the data and commands used by the equipment. This software is often referred to as the application. In communications, this software would (in following the common layered model of communications) interact with the application layer of the communications protocol. DICOM follows this model, and part 7 defines what is needed by application software to interact with DICOM communications. In DICOM, a typical message consists of a command stream (the items needed to support the services defined in part 4) and a data stream (the information objects, encoded according to part 5). In some cases (such as during negotiation of capabilities), the data stream may be small or may not need to be present. Part 7 defines building of the command stream much as part 5 defines building of the data stream.

The message constructed in part 7 needs to be passed on to lower layers of the communications model for communication to take place. Part 8 defines the network support for exchanging the DICOM messages. Currently, TCP/IP and the ISO-OSI protocols are supported, but the nature of the upper layer service defined in this part is such that it should be possible to expand to other protocols with relative ease. Once out of the DICOM upper layer, the remainder of the communications protocol (either TCP/IP or OSI) follows the existing standards. DICOM does not, and does not need to, modify or customize anything in either of these standards.

The first versions of the ACR-NEMA standard defined a high-speed parallel data interface. There are some applications, particularly connecting to older equipment, that do use this version. For this reason, this older point-to-point protocol was remains usable with DICOM. In a manner transparent to the applications above, Dart 9 of the standard describes

this updated version of the 50-pin interface. In effect, a manufacturer could choose one of the network protocols of part 8, or the point-to-point protocol of part 9, and run the same application software in either situation. Contrary to common belief, it is possible to connect to networks using DICOM Versions 1.0 and 2.0, but such a connection requires a network interface unit (NIU) that talks to the point-to-point protocol on one side, and a network protocol on the other.

What Does DICOM Do for Radiology?

Though the major impact of DICOM is expected to be on PACS, the current trend towards "miniPACS" and "partial PACS" (4) makes DICOM applicable for many equipment interfacing tasks. For example, the shared printer system for a cluster of CT or MR imaging units could use DICOM as the interface specification for the network interconnecting the imaging equipment and printers. In an environment of imaging equipment from multiple manufacturers, this means avoiding custom or proprietary interfaces for the different machines. The effect of this is to reduce the difficulty and cost of connecting the equipment, and to simplify servicing.

The utility of connecting a PACS to other information systems, particularly an RIS or HIS, has been described (5-8), but this task often requires much work on the part of systems analysts and programmers, both on the PACS side and the RIS/HIS side. The DICOM standard, through its various management service classes, provides a way to simplify at least the PACS side of the problem. As RIS and HIS vendors move toward their own standards (such as HL-7), the task will be further simplified, though any connection between two different information systems is never a trivial one. The DICOM WGs have liaisons to the groups writing RIS and HIS interface standards and expect to work at harmonization with these efforts (there is more on this in a subsequent section of this brochure).

It is important to understand that one of the major goals of DICOM is to enable interoperability. Interfacing, in the sense of the mechanical and electronic connection of equipment, is difficult, but even this is not sufficient for operation to be transparent to the user. In the telephone example described previously, the task of interfacing could be thought of as the making of the telephone connection and establishing that the connection is to the right destination. For interoperation to occur, that is, for the two telephone parties to communicate and comprehend their tasks, an understanding of the data and its context is necessary. DICOM provides the tools for this in the form of the negotiation capability and the object-oriented design. The former allows understanding of capabilities, and the latter of context. Using DICOM does not guarantee interoperability, but it does make it easier for users and manufacturers to achieve.

As DICOM has been approved by its sponsoring organizations, the ACR and NEMA, implementations by manufacturers has started. The question facing users is how to go about adding DICOM to equipment requirements and understanding what the vendors mean when they say they are "DICOM conformant." The manufacturer conformance statements will clearly identify how they are conformant, and the structure of part 2 ensures that these claims will have the same overall structure. This will make it simpler for users to compare them and determine if they are compatible. It would also be reasonable for a user to require that perspective vendors meet with the user and explain how their implementations of DICOM would work together. This could, for example, be part of a request for proposal (RFP) or request for quotation (RFQ) when preparing to purchase new equipment.

The U. S. Army, in its large Medical Diagnostic Imaging and Support (MDIS) System purchases, has faced this problem, and the DICOM standard was not available for much of it. However, the Army has contracted with one of the authors of this brochure (Fred Prior) to develop a User Conformance Profile (UCP). This UCP would be issued by a buyer of imaging equipment to potential vendors. The vendors would then have to do the work of determining if and how their equipment conforms to the user's requirements. This UCP follows the conformance claim structure of DICOM part 2, which should reduce the burden on the vendor in responding to it. Though the description of the UCP was developed under Army contract, it will be placed in the public domain following Army acceptance.

The Future of DICOM

to ask, What else needs to be done? The scope of the problem of communication of medical images is so large, however, that there is much yet to be done. Perhaps first is the demonstration that DICOM works as a specification and standard. For the past 2 years, the RSNA has helped serve this role. With a contract to Mallinckrodt Institute of Radiology to develop the software, the RSNA, NEMA members, and ACR members have worked on the DICOM demonstrations at infoRAD. In conjunction with the RSNA Scientific Assembly and Annual Meeting, a sizable portion of the infoRAD exhibit space has been devoted to an area in which multiple manufacturers have shown that they can implement DICOM and that it does work at communicating images and associated information over a network. Mallinckrodt provides the central test nodes (CTNs) that work as servers to hold images and manage the network. Manufacturers then connect to these CTNs using their implementation of the DICOM standard, and using the service classes, either send, receive, query, or "print" images (printing on film that requires wet processing is not feasible in the exhibit area because of the plumbing requirements). This year, the support of all the parts of DICOM is new, as is the inclusion of a CTN developed in Europe by the University of Oldenburg and Rennes University under the guidance of the Comite Europeen de Normalisation (CEN). Manufacturers may also choose to send images to, or receive images from, a different manufacturer, a procedure that was not done in the past demonstration. Some manufacturers may also implement a connection to equipment in the Technical Exhibits area, and some may show implementation of the HIS/RIS interface support service classes (the management service classes). Though on the surface, the demonstration will not appear dramatically different from the prior one, in fact, it is very different and much more ambitious. Through a significant number of independent implementation efforts, the quality of the standard in supporting effective interoperability has already been demonstrated

To help expedite the implementation of DICOM, it is the intent of the RSNA, Mallinckrodt, and NEMA to make the software available early in 1994.

The scope of medical imaging extends well beyond radiological images. Endoscopists, pathologists, dentists, and dermatologists (to name just four specialty areas) all produce images as part of their practice. Recently, representatives of the professional societies of these groups have met with a special Working Group of ACR-NEMA to begin planning how they could take advantage of the DICOM work. The DICOM approach of an object-oriented design is making this process relatively straightforward. The professional society members can provide the expertise about constructing appropriate information objects, and the ACRNEMA DICOM groups can then help translate that into DICOM standard. The first task undertaken will be the definition of information objects for color imaging in endoscopy (including pulmonary, gastrointestinal, genitourinary, and orthopedic applications).

This model has resulted in the first non-radiology collaborative effort in the form of a new information object and three new parts of the Standard. About a year prior to the writing of this brochure, the American College of Cardiology (ACC) approached ACRNEMA with their problem of archiving and exchanging digital coronary angiography and ventriculography between digital cardiac catheterization laboratories. Most of the new cardiac laboratory equipment produces digital images, but as with CT or MR, the manufacturers use proprietary storage media and formats. The conventional 35 mm film avoids this problem but is not a cost-effective solution when the images are in digital form to begin with. The cardiologists, joined by angiographers and interventional radiologists from the Society of Cardiovascular and Interventional, organized two ad hoc working groups and defined an "X-ray angiographic information object." This will be added to part 3 as a new annex.

These groups also had the problem of recording the information on some form of removable medium. This is necessary because of the non-networked nature of most cardiac and angiographic laboratories, and because of the necessity of providing the cine images to other specialists who may have stand alone equipment. To meet this requirement, the ACRNEMA WG V, whose mission is to develop exchange media standards, was reactivated. This WG has produced a part 10 of DICOM that describes Media Storage and File Formats. This part is a media-independent set of definitions. It describes both a generic file and directory structure, and in analogy with the Upper Layer Senice of part 8, specifies a basic DICOM file senice. This file senice provides the connection to actual file systems. The file format describes how to put a DICOM data set into a file along with a directory to point to the contents of such files. The file format includes an area called a File Preamble that is seen first by a device reading the file. This area is provided for potential compatibility with non-DICOM file senices. In effect, a DICOM file may have "dual personalities." If read by a DICOM file reader, the File Preamble would be ignored, and the remainder of the file read as a DICOM file. If read by a non-DICOM reader, that reader could look at the preamble for a pointer to information on how to read the DICOM file into its own file structure.

Each application that needs to record files onto a medium may require different media. For example, the cardiologists need a high-capacity medium with fast access as a replacement for 35 mm cine film. Non-cardiac ultrasound specialists, however, would probably not need as high a capacity, though they night need cine loop capability. For this reason, parts 11 and 12 of DICOM will soon to define the Media Exchange Standard all the way to the media level. Each application will have an application profile that will be a vertical "slice" through all the layers of DICOM. In effect, it will specify for a given application, the SOP classes, transfer syntax, directory structure, basic file senice, media format, and physical medium needed. These profiles are necessary in part because, unlike communication over network connections, off-line communication by media inhibits the negotiation process.

Part 10 of DICOM was developed with extensive cooperation with the University of Geneva Papyrus group. Papyrus is a file format standard that has been in use for several years and uses ACR-NEMA data sets (9). The new version of Papyrus is expected to conform to DICOM.

The tremendous interest in imaging both within and outside of radiology, and the general interest in electronic medical records has fostered the development of a group that has representation from all of the medical informatics standards bodies and professional groups. This group is the Healthcare Informatics Standards Planning Panel (HISPP) -- sponsored by the American National Standards Institute (ANSI). ANSI is the U.S. representative to the International Standards Organization (ISO) and is the formal conduit for information exchange with CEN, the body that has responsibility for all medical informatics standards in Europe. The ISO also provides official communication with the Japanese standards organizations. As standards develop, coordination through ANSI HISPP and its international counterparts is vital if the end products are to be compatible. A look at the international nature of the imaging equipment business should serve to illustrate the importance of standards considerations that go beyond national boundaries.

Conclusion

Without a doubt, DICOM is the most ambitious medical imaging standards project undertaken by industry and professional societies. It is a complex standard because of the size of its content, but it is implementable and useful. The standard offers the right balance between the pragmatic objective of rapidly implementing support in current products and a solid modular foundation that ensures an ability to evolve with and respond to future needs. The amount of work done on DICOM is a part of the reason for the interest from other specialties that use images. Through the use of the expertise available in professional societies, information objects and services can be defined. These can than make use of the structure of DICOM for implementation.

DICOM was developed with the idea of extension and expansion, and that is already happening. Despite this, it is not the intent of the DICOM developers to address all of medical informatics. The emphasis, noted in the name, is on medical imaging. It is one of the goals of the DICOM developers that others should be able to take advantage of the work already done and the concepts proved.

Acknowledgement

The authors wish to acknowledge support from the ACR, NEMA, and the RSNA. They also wish to thank those who have participated in DICOM development and continue to do so. Comments and suggestions from colleagues in the United States, Europe, and Japan were also very useful and helped strengthen the standard.

References

The National Electrical Manufacturers Association 2101 L Street, NW, Suite 300 Washington, DC 20037

1. Baxter BS, Hitchner LE, Maguire Jr, GQ. A standard format for digital image exchange. American Institute of Physicists in Medicine (AAPM) Report Number 10. New York: AAPM, 1982.

2. Prior, FW. Specifying DICOM compliance for modality interfaces. Report prepared under contract DAMD17-93-M-4464, U.S. Army Medical Research and Development Command.

3. Hurson AR, Pakzad SH, Cheng J.-b. Object-oriented database management systems: Evolution and performance issues. IEEE Computer 1993; 26(2): 48-60. Horii SC, Seshadri SB. PACS clinical applications. Diagnostic Imaging 1993; 15(9): PACS Supplement.

4. Levine BA, Mun SK, Benson HR, Horii SC. Assessment of the integration of a HIS/RIS with a PACS. Proc SPIE 1990; 1234:391-397.

5. Feingold E, Seshadri SB, Arenson RL. Folder management on a multimodality PACS display station. Proc SPIE 1991; 1446:211-216.

6. Bakker AR, Lodder H, Kouwenberg, JML. Traffic between PACS and HIS/RIS; data or information? Proc SPIE 1990; 1234:495-500.

7. Bakker AR. Communication between hospital and radiology information systems and picture archiving and communication systems. In Osteaux M (ed). Hospital integrated picture archiving and communication systems - a second generation PACS concept. Berlin: Springer, 1992; 55-97.

8. Hoehn H, Ratib O. Papyrus 3.0: the DICOM compatible file format. Geneva, Switzerland: Digital Imaging Unit, Center of Medical Informatics, University Hospital of Geneva, 1993.