| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
|
|
|
|||||||
|
|||||||||
IHE Primer |
1 From Eastern Informatics, Silver Spring, Md (M.H.); LAI Technology, Homewood, Ill (F.M.B.); GE Medical Systems Information Technologies, Buc, France (C.P.); Department of Diagnostic Imaging, University of Maryland School of Medicine, Baltimore (E.L.S.); and Department of Radiology, Northwestern University Medical Center, 448 E Ontario St, Suite 300, Chicago, IL 60611 (D.S.C.). Received August 24, 2001; revision requested August 29 and received August 31; accepted August 31. Address correspondence to D.S.C. (e-mail: dsc@radiology.northwestern.edu).
Index Terms: Information management • Picture archiving and communication system • Radiology and radiologists, departmental management • Radiology reporting systems
 |
Introduction |
|---|
 Top Introduction Health Level SevenDigital Imaging and...SummaryReferences |
|---|
If the IHE and its technical framework are not standards, what are they? The technical framework serves as a consensus document of how to think about, discuss, and successfully overcome medical information system integration problems by using existing standards and tools.
The following analogy may clarify further that one conforms to standards, whereas one complies with consensus documents such as the IHE technical framework. Consider hammers, nails, screwdrivers, and screws. There are many different hammers—cheap ones, expensive ones, manual, air-driven, and so on-but most hammers consist of a handle on one end and a shaped piece of hard material on the other. The same applies to screwdrivers. There are standards for hammers and standards for nails. There are even more technical standards for screws, since they are a more modern device. The standards for hammers might stipulate, for example, that the hammer head cannot fragment into dangerous shrapnel when a force of less than n newtons is applied to it. A standard, however, would probably not prohibit you from driving a screw with a hammer, and, in fact, numerous people probably do drive screws with hammers. One could imagine a group of prospective homeowners and a group of builders getting together and coming to a consensus that if a builder wants to participate in a project that he or she will agree to drive nails with only hammers and to drive screws with only screwdrivers since those methods yield the best result, that is, a safe, strong structure with a good look and feel. The consensus could also state that a certain kind of nail should be used in one situation and that another kind of nail should be used in another situation, without specifying a standard for how those nails should be manufactured.
To extend the analogy further, the homeowner (or even appropriate governing authorities) might require the builder to conform to certain standards, such as local electrical codes. The homeowner, however, could also require the builder to adhere to other consensus documents that might otherwise be optional for the builder. The builder complies to meet a customer requirement, and by doing so, the builder’s construction company can participate in a larger arena where cooperation among builders is required. It might also lower their construction costs due to a reduction in the number of different kinds of nails and screws required.
The Digital Imaging and Communications in Medicine (DICOM) (2) standard from the American College of Radiology (ACR) and the National Electrical Manufacturers’ Association (NEMA) and the Health Level Seven (HL7) standard (3) from same organizations are the tools—the hammer and screwdriver—currently used in the IHE technical framework. The data elements used by these standards and precisely defined by the IHE framework are the nails and screws.
As the IHE initiative expands into other medical arenas outside radiology and as it addresses other healthcare enterprise–wide processes, other tools (standards) will be added, as appropriate, to the IHE toolbox. For now, however, understanding the role of HL7 and DICOM in IHE is sufficient, and this article is intended to clarify how the IHE community of vendors and users employ the existing standards of HL7 and DICOM to achieve the integration goals of IHE. The article also examines how HL7 is evolving to meet the challenge of more complex information system integration demands and details some of the newer components of DICOM and how they relate to IHE.
|
Health Level Seven |
|---|
|
TopIntroductionHealth Level SevenDigital Imaging and...SummaryReferences |
|---|
The "seven" in HL7 is a reference to the position of the standard atop the seventh layer of the Open System Interconnection (OSI) series of protocols from the International Organization for Standardization (ISO) (4). From its inception, HL7 has emphasized the data to be carried, rather than the formatting of messages or the configuration of endpoint systems. By its own description, HL7 "does not try to assume a particular architecture with respect to the placement of data within applications but is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Instead, HL7 serves as a way for inherently disparate applications and data architectures operating in a heterogeneous system environment to communicate with each other" (3).
Data in an HL7 message are transmitted in fields of well-defined data types. Fields are grouped into segments of related information. Messages may be formatted by using Encoding Rules/7, which treat segments of a message as recordlike entities and set off fields and subfield elements by using common delimiters such as a vertical bar (|) and caret (
). Alternatively, HL7 messages may be transmitted by using external protocols such as the extended markup language (XML) (5).
HL7 provides widely adaptable specifications for the transmission of such data as patient identifiers and addresses, as well as the encoding of clinical information, by using well-known systems such as the Common Procedure Terminology (CPT) from the American Medical Association (6), the International Classification of Diseases (ICD) (7), and Logical Observation Identifier Names and Codes (LOINC) (8).
This "widely adaptable" capacity of HL7 is a great weakness as well as a strength. "Widely adaptable" means that different vendors can implement the HL7 standard in a variety of ways. This lack of uniformity makes HL7 interfaces expensive and complicated for both vendors and customers because each of the many different systems from many different vendors may have used a different interpretation of HL7. The IHE technical framework comes to the rescue by specifying how to use HL7, which reduces the variability in implementation. This consensus makes it easier for users and vendors to interface their systems, which creates a potential for substantially reducing costs.
Utility of HL7 in the Clinical Service Environment
The HL7 standard prescribes messages for the transmission of patient demographic and registration information, as well as for the communication of clinical orders, observations, and results data. The standard is thus well suited for transmitting data between integrated clinical information systems and systems dedicated to the support of specific clinical services, such as laboratory and radiology.
Messages in HL7 are initiated through the occurrence of trigger events, such as "patient is admitted" or "new order is placed." The event-driven nature of the HL7 environment makes it a relatively simple matter to produce case illustrations and interaction diagrams that precisely define the participants in a dialogue, their roles and responsibilities, and the nature of the communications between them. A sample interaction diagram from section 6.1.4 of the IHE technical framework document (1) illustrates how the ability of HL7 to model real-world events fits into IHE (Fig).
|
Patient Information.— HL7 ADT messages provide for the communication of demographic and registration information in response to over 60 discrete trigger events. The IHE technical framework specifies Patient Registration and Patient Update transactions in which this information will be communicated, and cites 13 trigger events from the HL7 standard that will cause the generation of messages within the IHE model.
Order Information.— Within HL7, a general-purpose order management (ORM) message allows communication of order and status data between Order Placer and Order Filler systems. The IHE technical framework specifies Placer Order Management, Filler Order Management, Procedure Scheduled, and Procedure Update transactions that use HL7 ORM messages and order responses (ORR) to coordinate the transmission of this information.
Results Information.— Although most IHE transactions dealing with reports use the DICOM standard, IHE uses the HL7 observation results unsolicited (ORU) message to transmit ASCII text report information between a report manager and a repository.
Patient Information Messages
As shown in the Figure, patient information originates in all cases from the ADT system and flows to the systems that need patient data to correctly attach orders and results to the correct patient. HL7 messages are used to transmit demographic information, visit data, and such vital statistics as height and weight.
The IHE technical framework document specifies a Patient Registration transaction by using the trigger events shown in the interaction diagram. In addition, a Patient Update transaction is defined by transfer, discharge, and class update events (and their cancellations, where applicable); demographic data updates; and duplicate patient record merges.
IHE also provides for the entry of order information for unidentified patients directly into the Order Placer or Order Filler systems. In this way, the provision of care is not impeded by the lack of available demographic information or by the unavailability of system resources. Reconciliation of patient data among systems is accomplished subsequent to the placement or execution of the order.
Order Information Messages
IHE uses the HL7 general-purpose order management message to communicate information about the patient for whom the order is being placed, the time for which the procedure is scheduled, and the specific activities to be performed. In contrast to ADT messages, which are distinguished by their trigger events, order messages use an order control code to communicate state transitions (eg, new order, number assigned, order discontinued).
In the IHE model, orders may be initiated on either a placer (order entry) or filler (Department System Scheduler) system. The filler system is responsible for determining the specific procedures and steps required to fill the order and for transmitting all order information, including patient demographics, to the Image Manager.
Four HL7 order transactions are specified in IHE: (a) placer order management, in which new orders and cancellations are transmitted from an order entry system; (b) filler order management, which provides for communication of new orders, order updates, and cancellations from the Department System Scheduler or Order Filler; (c) procedure scheduled, in which order information is transmitted from the Order Filler system to the Image Manager; and (d) procedure update, in which the Order Filler communicates changes to procedure and schedule information to the Image Manager.
Results Information Messages
The IHE technical framework facilitates the transmission of DICOM structured reports to an enterprise report repository. To accommodate the widest number of possible endpoints, reports are specified as simple ASCII text; the use of special formatting characters within the report is discouraged.
Results received through DICOM structured reports must be mapped to the HL7 standard. In a number of cases, the data types and field widths vary between the DICOM and HL7 standards. IHE provides a complete mapping of the fields common to both formats.
Future Developments in HL7
Although HL7 has been a successful standard by any measure, the implementation of each HL7 interface involves substantial customization at considerable cost. In large measure, this customization is the price for the flexibility that HL7 provides. HL7 has evolved to meet the need for the many point-to-point connections present in the healthcare enterprise. Like DICOM, HL7 does not dictate the internal organization of applications, but only the meaning and format of communications between those systems. But unlike DICOM, which operates in a much more limited domain, HL7 has no explicit information model that defines the relationships between the concepts in the various types of messages. There is an information model that is implied by the messages, just as there is in natural language, but as in natural language there is considerable latitude for interpretation. The Version 3 project, which began in 1996, has undertaken to develop an explicit information model common to all HL7 messages: the reference information model (RIM). It is important to understand that the RIM does not model all of healthcare, but only the aspects that are common to the various application domains and need to be communicated. But even so, the scope of this modeling effort is immense.
The lack of a common information model invites questions such as, "If I can fax a result to a referring physician, why can’t I fax a result to a patient?" (Answer: Because a fax number is an attribute of a physician, not of a patient.) The RIM recognizes that physicians and patients are both people, albeit in different roles, and that both may possess a fax number. Because they are derived from a common information model, the various Version 3 messages will have a greater degree of consistency. This greater consistency will serve the aim of reducing the variability that necessitates extensive customization of present HL7 interfaces. Further standardized compatibility will ensue as internal data models of systems evolve to become more compatible with the RIM and with Version 3 messaging (a natural result as designers adopt standard data models to simplify interfacing). This process will take many years, but its fruits will justify the years of development of Version 3.
In addition, Version 3 defines a development framework that specifies how messages are developed from the RIM. Automated tools are being devised to make this process less arduous and error prone.
The adoption of XML as the encoding syntax for HL7 Version 3 has attracted much attention. It is important to understand that XML is a tool for tagging text information and for working with tagged data, but it does not define the tags nor their meaning. HL7 provides these definitions and uses XML as a tool for encoding them. XML encoding will facilitate the communication and processing of HL7 messages with widely available software tools. A fair share of the HL7 development effort has gone into the adoption of XML, but that effort is dwarfed by the collective effort of reconciling all messages to a common information model, the RIM.
Clinical Document Architecture
Another major development in HL7 is the clinical document architecture (CDA). The CDA provides an exchange model for clinical documents, which may include narratives, such as discharge summaries, and structured consultation reports. The CDA employs the HL7 RIM, coded vocabularies, and XML to make documents that are legible to both humans and machines. These documents can be parsed and processed electronically and can still be retrieved and displayed by using XML-capable Web browsers.
The CDA is called an architecture because it specifies common characteristics of families of documents rather than a specification based on a single document schema. Implementation of CDA occurs at three "levels."
Level 1 of the CDA defines a document header that identifies the document, its version, its author, whom it is about, and the clinical context (eg, encounter, location). Everything in the CDA header is derived from the RIM. The body of the document contains basic text structures such as sections, paragraphs, lists, and tables, but no RIM-derived content is specified (ie, the body content is not standardized).
Level 2 assigns codes to document types and to structures within the document body, enabling, for example, an insurance claim processor to extract the diagnosis section from a report.
Level 3, which is expected to be completed in 2002, will define the encoding of any RIM content in a CDA document. Level 3 will specify the markup of clinical content to the extent that it can be expressed in the RIM. Thus, anything that can be expressed in Version 3 messages can be encoded in Level 3 CDA documents, although CDA documents may still contain text content that is not modeled in the RIM.
A key distinction of the CDA, as opposed to HL7 messaging, is its treatment of persistence and paradigms for data management. Messages are used to update databases, and of course databases can be designed and operated so as to provide persistent long-term storage, but the foundation on which databases operate is the maintenance of up-to-date information. Document management encapsulates information into persistent objects, which are archived until they are discarded. A document may be superseded by a later version, but it cannot be changed. As such, document management is more focused on maintaining a collection of permanent records.
Clearly, both approaches have a role in health information management. Persistent objects facilitate the management of permanent records, whereas messages are better for updating dynamic variables. The addition of the CDA to the traditional HL7 messaging standards allows HL7 to serve both needs.
|
Digital Imaging and Communications in Medicine |
|---|
|
TopIntroductionHealth Level SevenDigital Imaging and...SummaryReferences |
|---|
DICOM at the Close of the 20th Century
DICOM image transfer from a computed tomography, magnetic resonance imaging, computed radiography, radiofluoroscopy, angiography, ultrasonography, nuclear medicine imaging, or positron emission tomography device was a reality by the mid-1990s. This image transfer was the first dimension of DICOM. It made the DICOM standard universally accepted in the radiologic community and allowed the standard to extend rapidly to include cardiology and radiation therapy. It is now poised to address the needs of other medical imaging arenas such as microscopy, pathology, and ophthalmology. DICOM should no longer be viewed as a radiology-specific standard. DICOM now includes, for example, specifications for a variety of commonly used one-dimensional waveforms, such as those used in cardiology or electrophysiology.
The second dimension of DICOM, which is also widely accepted, addresses the network connection of print devices that produce film and other print media. Commonly called DICOM Print, it is an important productivity tool that allows film and paper printers and other hard-copy imaging to be connected to a hospital network, not only within the radiology department but also in remote clinical areas.
The third dimension of DICOM concerns the interchange of images on storage media such as magneto-optical and CD-ROM disks. The DICOM CD-R was particularly successful. First introduced in angiography and cardiology as a cost-effective and full-fidelity recording media to replace traditional cine films, it is now increasingly used as an effective way to give patients their images for transfer between healthcare providers. With a simple DICOM viewer on the CD, any referring physician or even the patient can view the images on any personal computer. (Many free public domain DICOM image viewers exist; for example, see www.psychology.nottingham.ac.uk /staff/cr1/dicom.html.)
The fourth dimension of DICOM arose from the recognition that the network integration needs of the imaging department required more than the electronic exchange of medical images. Imaging and work-flow management require that nonimage information be exchanged between the imaging devices and the information systems in the department, notably the radiology information system (ie, Department System Scheduler or Order Filler in IHE terminology) and increasingly the PACS (the IHE Image Manager or Image Archive). The first of these functionalities to be standardized was the Modality Worklist service class. This transaction transmits to the image acquisition device a variety of information such as patient demographics, requested procedure, and scheduling information. This transfer of data allows a technologist at a modality to select the patient or study information from a list of choices and therefore reduces the chance of making a typographic error in manually entering the same information (however, errors in patient or study selection can still occur). The Modality Worklist is now in broad use, and no enterprise of significant size can afford to operate in a digital environment without it.
The DICOM Storage Commitment service class followed the DICOM Modality Worklist closely. Storage Commitment can be used to guarantee that images will not be deleted from an acquisition device unless another device (typically an archive) takes ownership and responsibility for the long-time care of the images.
DICOM in the 21st Century
More recently, DICOM introduced the Performed Procedure Step service class that signals to the Department System Scheduler, Image Manager, and Image Archive that a scheduled step in the work flow has been completed. The signal includes key tracking information for the Image Manager or Image Archive and Department System Scheduler, such as the list of images concerned and dose information. IHE has been instrumental in ensuring that these three image management services (Modality Worklist, Storage Commitment, and Performed Procedure Step) become broadly supported on modality workstations, PACS, and radiology information systems via the Schedule Work Flow integration profile (9).
The fifth dimension of DICOM brings us back to images and their consistent display. In an environment of local, physical image production (either film-screen radiography or film printing), the imaging department can control image quality. In an electronic environment in which images are printed remotely or reviewed on far-flung workstations, the consistency of gray-scale rendering becomes an important issue. The techniques previously used by the imaging department, notably the cross-calibration of every image-rendering device against every image-generating source, cannot be extended to any significant size because of the cost and complexity of such a task.
DICOM provides a solution with the standardization of a gray-scale display function based on the physiologic perception of luminance by the human eye (10). As a consequence of this standardization, as soon as each sending or receiving device is independently calibrated against this DICOM Gray-scale Display Function, pixel values representing the actual gray-scale levels can be perceived in a consistent manner independent of the luminance characteristics of the rendering device.
DICOM has extended the notion of gray-scale calibration to include other manipulations, such as flip, rotate, or zoom transformations and textual or graphic annotations, such that a complete documentation of how the image was presented may be made. DICOM (and therefore IHE) terms this a Gray-scale Presentation State, and these states have been adopted as formal DICOM objects.
There are a number of important scenarios for which precisely defined presentation states might be useful; for example, to make a record of the viewing conditions of an image at a specific point in time, to transfer manipulations made on one device to another device, and to ensure display consistency between a print composer and printer (although the latter uses an extension to DICOM Print called Print Presentation Look-up Table). In addition, the Gray-scale Presentation State provides a mechanism for optimizing the use of new DICOM objects for direct radiography and digital mammography, both of which require that all sending and receiving systems to be calibrated. IHE has adopted these presentation services in the IHE Consistent Presentation of Images integration profile.
The sixth dimension of DICOM addresses reporting and measurement collection, including links to the DICOM images from which these reports and measurements are made. Called the DICOM Structured Reporting service class, this DICOM component introduces a pragmatic and progressive approach to coding and structure in reports. DICOM Structured Reporting objects, like the DICOM image objects, have the possibility of being extremely complex. This potential for complexity is necessary to cover the wide range of reporting applications. Just as the use of DICOM formatted images has taken a few years to address all types of images, we expect DICOM Structured Reporting to be adopted in stages.
DICOM Structured Reporting addresses the need to electronically record measurements either directly at modality workstations or when the measurements are integrated with viewing, analysis, and even computer-assisted diagnosis applications. These DICOM reporting objects can also be used to capture informal notes that today are scribbled on tiny scraps of paper or image jackets. As tools to manage reporting codes and automatic reporting techniques, such as text templates, become more prevalent, DICOM Structured Reporting should become a valuable format to support more general radiology reporting, especially as it becomes more common to maintain links with key images and data mining applications. IHE begins the process of exploiting DICOM Structured Reporting in the IHE Simple Image and Numeric Report integration profile.
The HL7-DICOM Common Working Group
DICOM and HL7 are working together through a common working group, recognized by HL7 as the Imaging Integration Special Interest Group and by DICOM as Working Group 20. The group monitors the IHE initiative and can supply recommendations for changes in standards to the appropriate body, when changes are found necessary. The memberships of the Imaging Integration Special Interest Group and Working Group 20 also overlap with the membership of the IHE Technical Committee.
|
Summary |
|---|
|
TopIntroductionHealth Level SevenDigital Imaging and...SummaryReferences |
|---|
|
Footnotes |
|---|
|
References |
|---|
|
TopIntroductionHealth Level SevenDigital Imaging and...SummaryReferences |
|---|
This article has been cited by other articles:
|
|
 |
|
  N. Hara, M. Onoguchi, T. Nishida, M. Honda, O. Houjou, M. Yuhi, T. Takayama, and J. Ueda Considerations for Setting Up an Order Entry System for Nuclear Medicine Tests J. Nucl. Med. Technol., December 1, 2007; 35(4): 259 - 271. [Abstract] [Full Text] [PDF]
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
| RADIOGRAPHICS | RADIOLOGY | RSNA JOURNALS ONLINE |
