1339 Integrating the Healthcare Enterprise: A Primer

IHE PRIMER 1339

Integrating theHealthcare Enterprise:A PrimerPart 1. Introduction1

Eliot L. Siegel, MD ● David S. Channin, MD

Does the subject of this series of articles intrigue you but you’re not sure if thetopics covered really apply to you and your practice? Before you read anotherword, go to the end of this introduction and seriously try to answer the questionsposed there. If you answer “yes” to questions 1, 4, 5, 6, and 7, you need to readthese articles.

And they said, “Go to, let us build a city and a tower, whose top may reach unto heaven;and let us make us a name, lest we be scattered abroad upon the face of the whole earth.”And the Lord came down to see the city and the tower, which the children of men builded.And the Lord said, “Behold, the people is one, and they have all one language; and this theybegin to do: and now nothing will be restrained from them, which they have imagined to do.Go to, let us go down, and there confound their language, that they may not understand oneanother’s speech.” So the Lord scattered them abroad from thence upon the face of the earth:and they left off to build the city. Therefore is the name of it called Babel; because the Lorddid there confound the language of all the earth: and from thence did the Lord scatter themabroad upon the face of all the earth.—Genesis 11:4–9

IntroductionWith the arrival of the new millennium, we find ourselves well into the “informationage” with respect to healthcare delivery. Improving the delivery of healthcare both ina quantitative and qualitative sense will depend on improving management of digitalinformation within and among healthcare institutions. Currently, within a givenhealthcare setting, there are typically dozens of information systems that each per-form specific functions. There might be, for example, a billing system, an admission/discharge/transfer (ADT) system that registers patients, as well as numerous depart-mental systems (eg, radiology information system and picture archiving and commu-nication system [PACS]). To optimize “information efficiency,” these systems needto intercommunicate such that end-users of the system have the information theyneed to make their decisions and get their work done, when and where they need todo so. Historically, many of these information systems developed as monolithic,stand-alone systems without significant interfaces to other systems. Fortunately, theadvent of medical information systems standards such as HL7 (Health Level 7) (1)

Index terms: Information management ● Radiology and radiologists, departmental management

RadioGraphics 2001; 21:1339–1341

1From the Department of Diagnostic Imaging, University of Maryland School of Medicine, 10 N Greene St, Baltimore, MD 21201 (E.L.S.); and De-partment of Radiology, Northwestern University, 448 E Ontario St, Suite 300, Chicago, IL 60611 (D.S.C.). Received May 29, 2001; revision re-quested June 27 and received July 11; accepted July 11. Address correspondence to D.S.C. (e-mail: [email protected]).

©RSNA, 2001

and DICOM (Digital Imaging and Communica-tions in Medicine) (2) have created a mechanismto share patient data and optimize work flow.

These and other standards, however, are nec-essary but not sufficient for the successful integra-tion of heterogeneous information systems. Con-sider, for example, the case of the light bulb. Veryearly in the evolution of the light bulb, there werenumerous, vendor-specific types of bulb bases.This multiplicity of design caused great havocamong lamp manufacturers and consumers untila limited set of bulb base designs became industrystandards. Now consider the situation if a lampwere used for signaling. The sender and receivercan both choose from a number of different ven-dors of signaling lamps. Both sender and receiverunits can use any number of standard light bulbs,wiring systems, and sources of electricity. If, how-ever, the sender and receiver do not agree on theframework for how they are going to blink thelinks, then the standards they have implemented(bulbs, wiring, electricity) will not succeed in fos-tering the desired communication.

Similarly, the typical healthcare enterprise con-tinues to suffer with a situation analogous to thebiblical “tower of Babel,” whereby each hospitalinformation system utilizes HL7, DICOM, andother standards in a wide variety of ways as topractically preclude communication of informa-tion from one to another. Consequently, thesesystems often operate almost completely indepen-dently, with a paper printout typically serving asthe only means of communication. This lack ofconsensus by various hospital and radiology infor-mation systems, PACS, and modality vendors onhow to use existing standards has thwarted ourefforts to automate processes such as physicianorder entry, patient and examination registration(especially for the challenging “John Doe” pa-tient), and the creation and review of imagingreports. The failure to automate these processeshas resulted in a very inefficient work flow, de-spite the use of electronic information systems.

The Integrating the Healthcare Enterprise(IHE) initiative defines such a consensus effortand framework (3) for integrating informationsystems in a healthcare environment. A joint ef-fort of the Radiological Society of North America(RSNA) and the Healthcare Information andManagement Systems Society (HIMSS), the IHEinitiative began in 1998 as an effort to moreclearly define how existing standards, notably

DICOM and HL7, should be used to resolvecommon information system communicationtasks in radiology. The IHE technical frameworkdefines, precisely, a common information modeland a common vocabulary for systems to use incommunicating medical information. It thenspecifies, precisely, how DICOM and HL7 (sofar) are to be used by information systems tocomplete a set of well-defined transactions thataccomplish a particular task. At the same time,the framework provides a common human vo-cabulary that professionals and vendors can use todiscuss further problems of this nature.

Modality and medical information system ven-dors have rapidly become strong supporters andarchitects of the IHE effort. Vendors came to-gether to demonstrate the way in which actualproducts could support this next level of integra-tion. The first demonstration was held at theRSNA annual meeting in 1999 and again at the2000 annual meeting of HIMSS. The initiativewas expanded in its second year and shown atRSNA 2000 and HIMSS 2001. The Year 3 ef-forts will be on display at this year’s RSNA meet-ing and at next year’s HIMSS convention.

The following two articles are the first twoparts of a four-part primer designed to furtherexplain the IHE initiative. The first article willdetail the seven “integration profiles” that arecurrently defined in the IHE technical framework.This piece will define the common language ofthe framework that allows professionals and ven-dors to describe the problems and their solutions.More detailed descriptions of common problemsin radiology and how the specific integration pro-files address these specific scenarios are pre-sented. Again, non-radiology healthcare informa-tion system users and providers will be able toidentify analogous problems within their domainsand subsequently be equipped to formulate theirsolution in terms that the IHE community can acton.

The second article attempts to explain whatIHE does for each of the different users of medi-cal information systems, currently aimed at radi-ology processes and procedures. Other healthcareinformation system users and vendors will, webelieve, see in these descriptions analogous prob-lems and scenarios that arise in their domains.They will also discover that the IHE initiative isan extensible vehicle that can and will be ex-panded to meet the challenge of these needs inother medical domains besides radiology. Users(through their professional organizations), ven-dors, and standards organizations are invited to

1340 September-October 2001 RG f Volume 21 ● Number 5

participate fully in the IHE initiative and are en-couraged to contact the IHE project offices at theRSNA or HIMSS headquarters.

The third and fourth articles will be publishedin the November 2001 issue of RadioGraphics.The third piece will detail the role of existingstandards in the IHE initiative. IHE is not a stan-dard nor is the initiative a standards body. IHE isnot a certifying authority. The IHE community ofvendors and users makes use of existing stan-dards, notably DICOM and HL7, to achieve theintegration goals of IHE. This third article willdetail some of the newer components of DICOMand how they relate to IHE. It will also examinehow HL7 is evolving to meet the challenge ofmore complex information system integrationdemands.

The fourth and last article will explain the fu-ture of IHE. The Year 3 (2001/2002) demonstra-tion will be described in more detail. This articlewill include practical aspects of how to includeIHE requirements in contracts and requests forproposals. Future directions of the IHE initiativeand mechanisms by which other users, vendors,and organizations can participate will be de-scribed. It is only through this further participa-tion by users and vendors that the IHE initiativecan grow and flourish. The plans for expansion ofthe initiative outside radiology will be presented.

In addition to this primer series, more informa-tion about the initiative, including the latest ver-sion of the IHE Technical Framework, can befound at the IHE web site: www.rsna.org/IHE.

Questions for Consideration1. Do you have communication problems in

your work flow and between your informationsystems that you think IHE could help you re-solve?

2. Does the Scheduled Work Flow integrationprofile adequately represent or codify the way youperform radiologic procedures? If no, how is itlacking?

3. Are the distinctions between Order, Re-quested Procedure, Scheduled Procedure Step,and Performed Procedure Step clear to you? Does

this hierarchy adequately capture the complexityof performing radiologic procedures?

4. Is the performance of grouped procedures asignificant problem for you? Does the Presenta-tion of Grouped Procedures integration profileaddress this scenario adequately? If no, how is itlacking?

5. Do you have significant clinical or opera-tional problems related to making images appearsimilar on film and on workstations? If yes, doyou use the DICOM (part 14) gray-scale displayfunction standard to calibrate your equipment?Does the Consistent Presentation of Images inte-gration profile adequately address this issue? Ifno, how is it lacking?

6. Do you have significant problems managingpaperwork (requisitions, notes, patient history,etc) in addition to films and images? If yes, doesthe Key Image Note integration profile addressthese needs? If no, how is it lacking?

7. Do you have significant management prob-lems in reconciling unknown patients, performingprocedures on trauma patients, or performingprocedures when one or more information sys-tems are unavailable? If yes, does the Patient In-formation Reconciliation integration profile ad-dress these scenarios adequately? If no, how is itlacking?

8. What other aspects of radiology work flowcould benefit from IHE type integration profiles?

9. Are there any related topics that you wouldlike to see discussed or clarified in future articlesor presentations?

References1. Health Level Seven. Application protocol of elec-

tronic data exchange in healthcare environments,version 2.4. Ann Arbor, Mich: HL7, October 2000.

2. National Electrical Manufacturers’ Association.Digital Imaging and Communications in Medicine(DICOM). Rosslyn, Va: NEMA, 1996; PS 3.1-1996–3.13-1996.

3. Radiological Society of North America/HealthcareInformation and Management Systems Society.IHE technical framework, year 3, version 4.6. OakBrook, Ill: RSNA March 2001.

Editor’s note.—Please visit the online version of this article in the Education Resources pages of RSNA Link(www.rsna.org) and answer the questions posed above. We are very interested in your opinions on these articles.

RG f Volume 21 ● Number 5 Siegel and Channin 1341

IHE PRIMER 1343

Integrating theHealthcare Enterprise:A PrimerPart 2. Seven Brides for Seven Brothers:The IHE Integration Profiles1

ONLINE-ONLYCME

See www.rsna.org/education/rg_cme.html.

LEARNINGOBJECTIVESAfter reading thisarticle and takingthe test, the reader

will be able to:

� Understand com-mon work flow andinformation systemproblems that occurin radiology depart-ments.

� Understand whatthe IHE initiativefrom RSNA andHIMSS is.

� Understand theIHE informationmodel.

� Understand theseven integrationprofiles of the IHEand the specific prob-lems they address.

David S. Channin, MD

IntroductionThis article describes at a high level the IHE information model and the seven inte-gration profiles that make use of this model to accomplish a number of important,common, core processes in radiology. Although the technical details of IHE can beleft to the boffins and experts, radiologists will need to understand, at a high level, theinformation model and work flow derived from this model. This will allow them tounderstand why the information systems to which they are increasingly exposed donot currently perform as they would desire or expect. More important, they will thenunderstand the importance of the IHE initiative in offering the hope that future infor-mation systems, which will adhere to the IHE framework, will be able to function in amore integrated fashion, thereby solving some common problems of today’s medicalinformation systems. It is hoped that nonradiologist readers will see similarities withproblems in their information model and work flow and will be encouraged to partici-pate in the expansion of the IHE initiative into other subspecialty areas.

IHE is not a standard nor a certifying authority. IHE is more than a standard. IHEdefines a common language to assist humans in unambiguously discussing how tointegrate heterogeneous information systems. IHE has defined, in a technical frame-work document (1), a view of the radiology world. This is not to say that there is onlyone possible view of radiology, nor does this imply that it is the best view of radiology.It is merely one view of radiology, about which a large group of IHE participantscould come to consensus. As the IHE initiative expands, so too will its view of theworld.

Abbreviations: ADT admission/discharge/transfer, DICOM � Digital Imaging and Communications in Medicine, HL7 � Health Level 7, PACS �picture archiving and communication systems, RIS � radiology information systems, DICOM S/R � DICOM Structured Reporting

Index terms: Information management ● Picture archiving and communication system ● Radiology and radiologists, departmental management ● Ra-diology reporting systems


1From the Department of Radiology, Northwestern University, 448 E Ontario St, Suite 300, Chicago, IL 60611. Received May 29, 2001; revision re-quested June 27 and received July 11; accepted July 11. Address correspondence to the author (e-mail: [email protected]).

©RSNA, 2001

Within this world, there are a number of tasksthat must be accomplished to deliver radiologyservices to patients. Again, these are not all thetasks that must be accomplished to provide com-plete radiology services, but they are a fundamen-tal subset of the necessary core processes. TheIHE precisely defines these tasks. More tasks willbe defined for more processes in future years aspart of the expansion of IHE both within radiol-ogy and in other subspecialty healthcare areas.

Lastly, IHE defines the information model thatspecifies the bits and pieces of data that must becreated, managed, manipulated, and exchangedto accomplish these tasks successfully. This infor-mation model is an integration of subsets of HL7(Health Level 7) (2) and the DICOM (DigitalImaging and Communications in Medicine)model of the real world (3). Most important, allthe pieces of information and their meanings re-quired for the IHE defined processes are fullyspecified in the IHE technical framework. Thus,vendors and their information systems, who agreeto abide by and implement the IHE framework,now have a common, fully defined, mutuallyagreed-on context in which to interact to performradiology processes successfully.

The IHE technical framework is process ori-ented. It defines a set of actors that must interactwith each other to complete a given process suc-cessfully. The actors interact by means of well-defined transactions that are based (currently) onDICOM and HL7 messages. The framework in-tentionally avoids assigning roles to specific prod-ucts (eg, hospital information systems, radiologyinformation systems [RIS], picture archiving andcommunication systems [PACS], or imaging mo-dalities), even though specific products have tra-ditionally performed some of the transactions.The goal is to define the interactions among func-tional components of the healthcare informationsystem environment. Vendors and users of thevarious information systems that make up thisenvironment can then decide which productsimplement which roles in a specific department.

IHE has defined seven integration profiles,each of which groups a set of actors and transac-tions together with a common vocabulary to ac-complish a specific, typical work flow task. Theseintegration profiles—(a) Scheduled Work Flow,(b) Patient Information Reconciliation, (c) Con-sistent Presentation of Images, (d) Presentation ofGrouped Procedures, (e) Access to RadiologyInformation, (f) Key Image Note, and (g) SimpleImage and Numeric Reports—are the core pro-cesses addressed by the IHE technical frameworkat this time.

Before we discuss the seven integration pro-files, let us examine in more detail the model ofthe real world used by the IHE framework. It isimportant to define clearly the terms used in thismodel because some of the terms have been usedambiguously in the past. By precisely defining theterms of the model, we will be better able to un-derstand the integration profiles and the problemsthey address.

In the IHE model, a patient is the subject of anorder for radiology service placed on behalf of anordering physician by an Order Placer actor. Onecan imagine that the Order Placer actor is oftenpart of a hospital information system or a clinicalinformation system, but the framework does notforce this decision.

This order is fulfilled by an imaging servicerequest that will be managed by the DepartmentSystem Scheduler or Order Filler actor (for sim-plicity, hereinafter referred to as the Order Filler).Again, traditionally, the Order Filler in radiologywould be the RIS, although this is not specified inthe framework. What is required is that some in-formation system must take responsibility formanaging the imaging service request by imple-menting the Order Filler actor. It is at this pointthat the Order Filler assigns the accession numberto the imaging service request.

A single imaging service request is satisfied byengendering one or more requested procedures.Requested procedures are the unit of work for theradiologist. A requested procedure is the smallestunit of work that can be codified and billed andwhich causes a radiology report to be generated.Requested procedure identifiers identify requestedprocedures. It is important to note that requestedprocedure identifiers are not the same as acces-sion numbers. Recall that the accession number isassigned by the Order Filler at the level of the im-aging service request. An imaging service requestcan lead to one or more requested procedures,and each requested procedure is a unit of codi-fied, billable, reportable work. Thus, two re-quested procedures created in response to thesame imaging service request could share thesame accession number. Outside the IHE world,the term accession number is used by some ven-dors to represent imaging service requests and byother vendors to mean requested procedures.IHE removes this ambiguity by clearly specifyingthat accession numbers shall be defined at the levelof the imaging service request (created by the Or-der Filler) to satisfy the Order Placer. For similarreasons, we avoid the terms “study” and “exami-nation” because these terms are also used am-biguously.

The requested procedures are in turn com-posed of scheduled procedure steps. Scheduled


procedure steps drive work flow. Scheduled pro-cedure steps are work that is anticipated to beperformed by technologists (and radiologists) atthe modality. Thus, scheduled procedure steps arethe fundamental unit of work for a modality andthus are the elements that should appear in mo-dality work lists. It is important to recognize thatduring a particular procedure a scheduled proce-dure step may not be performed, since not allscheduled work is necessarily appropriate in allsituations. Scheduled procedure steps becomeperformed procedure steps as the technologist atthe modality workstation completes the work.

Let us consider a series of examples. In asimple case, a referring physician orders “radio-graphic evaluation of the right hand.” This ordercauses the creation of a single imaging service re-quest that is assigned an accession number. Thisparticular imaging service request generates asingle requested procedure, “computed radiogra-phy, right hand, two views,” which is associatedwith a single CPT code (73130). This requestedprocedure could, depending on the particularvendor’s implementation, be accomplished as oneor more scheduled procedure steps. In otherwords, each view could be a separate scheduledstep or both views could be incorporated into thesame scheduled procedure step. At this point, thetechnologist images the patient and the scheduledprocedure step becomes a performed procedurestep. The radiologist generates a report for therequested procedure, and the Order Filler actornotifies the Order Placer that the imaging servicerequest has been satisfied.

In a more complex example, a referring physi-cian orders a “ventilation perfusion scan for pul-monary embolus.” Again, this order would causethe creation of a single imaging service requestthat is assigned an accession number by the OrderFiller. This imaging service request, however,generates two requested procedures—“lung scanventilation” (CPT 78593) and “lung scan perfu-sion” (CPT 78580)—but they share the sameaccession number. Each requested procedure inthis case consists of a single scheduled procedurestep, which becomes a performed procedure stepas the work is completed. The radiologist cannow dictate separate reports for each requestedprocedure or, as is done at some institutions, dic-tate a single report that applies to both requestedprocedures. In either case, the two requested pro-cedures are fulfilled, and the Order Placer is noti-fied that the imaging service request has been ful-filled.

Keeping this information model in mind, wewill now examine the seven integration profilesand the problems that they address.

Scheduled Work FlowThe Scheduled Work Flow integration profile fillsin all the necessary details to perform the typicalwork flow previously described. The significanceof this profile should not be underestimated. Thisintegration profile was the first to be developed inyear 1 of the IHE initiative (1998) and remainsthe underpinning of the information model. Moreimportant, the lack of tight integration of sched-uled work flow between heterogeneous hospitaland departmental information systems can have asignificant deleterious effect on hospital and de-partmental operations. In the worst scenario,there may be no transfer of information from onesystem to another other than through a paper re-port and repeat, manual data entry. Every timethere is a manual handoff of information there isrisk of error and introduction of inefficiency.

Even in the presence of simple (non-IHE) inte-gration between systems, there is often just aminimum set of messages exchanged and integra-tion is said to be “loose.” Typically, these inter-faces are point-to-point between two informationsystems. When extended to a large institution,“loose” integration entails management of manyof these point-to-point interfaces. This manage-ment rapidly becomes a complex, expensive task.Overall, the effect is that while routine operationsproceed, there are few mechanisms for proactivelypreventing and managing error or exceptioncases, and significant manual intervention is re-quired to keep the systems coordinated. For ex-ample, with loose integration, the status of proce-dures in one system may not exactly match thestatus in another system because one system maynot signal every state transition. Occasionally, oneinformation system may attempt to cancel a pro-cedure that has already occurred or one or moreinformation systems are temporarily unavailableand manual reconciliation must occur. From avendor viewpoint, without the IHE ScheduledWork Flow integration profile, each system instal-lation becomes a custom integration project withthe associated cost and complexity that customwork entails.

The Scheduled Work Flow profile makes useof nine actors and over 40 transactions to ensure arich collaboration between the components of theinformation system environment. In addition toOrder Placer, Order Filler, and Acquisition Mo-dality introduced above, this profile introducesthe ADT (admission/discharge/transfer) PatientRegistration, the Image Manager, Image Archive,Performed Procedure Step Manager, Image Display,and Image Creator actors. Recall that the one

RG f Volume 21 ● Number 5 Channin 1345

information system can implement many morethan one actor. In fact, the framework requiresthe grouping of the Image Manager, Image Ar-chive, and Performed Procedure Step Manager aswell as other actor groupings (troupes), whichsignificantly reduces the potential number of in-volved information systems in any one implemen-tation.

In introducing the Performed Procedure StepManager and defining the usage of DICOM Mo-dality Performed Procedure Step, the ScheduledWork Flow profile ensures that all the informa-tion systems can be appropriately notified as (im-age-based) work is performed and completed.The performed procedure step–in progress trans-action occurs as the work is started on the modal-ity workstation. The performed procedure step–complete message is important because it ensuresthe link between the scheduled procedure step(and the requested procedure it is part of) and theexact list of images constituting the performedprocedure step. This message provides the ImageManager with two critical pieces of information:(a) the precise list of images to expect and (b) thesignal that the acquisition step is completed. Themessage avoids errors in reporting incompletestudies and simplifies the technologist task thatwould otherwise have to be performed through aRIS and a PACS terminal. The Image Manageror Order Filler actors can also use this knowledgeto perform related tasks (eg, long-term archive,prepare the study for review). The Order Filleralso sends an order status update message to in-form the Order Placer that the imaging servicerequest has been satisfied. If an Image Displayactor is then available, the images may then bedisplayed, presumably to the ordering physician.

Patient Infor-mation Reconciliation

The Patient Information Reconciliation integra-tion profile is used to support the clinical situa-tion when the patient is unknown to the enter-prise and yet imaging must proceed. This situa-tion most frequently occurs in the setting oftrauma, but the IHE framework also identifiesseveral other scenarios in which this can occur.For example, the ADT Patient Registration actormay register an unidentified patient (John Doe)and the Order Placer actor may place an order.Subsequently, the patient is identified and theADT Patient Registration actor sends update/merge messages to both the Order Placer and Or-der Filler. The Order Filler then notifies the Im-age Manager.

In a similar scenario, an unidentified patientmay be registered (John Doe) at the ADT Patient

Registration actor but in this case the order isgenerated at the Order Filler in the eventualitythat the Order Placer is unavailable. Again, rec-onciliation occurs as the update messages flowthrough the profile. The same logic applies in thecase of an unidentified patient who is registeredand imaged at a modality before an order is en-tered. This integration profile also supports situa-tions in which information is incompletely propa-gated; for example, the wrong patient record isused in ordering/scheduling due to communica-tions failures or information is mistyped at a mo-dality workstation in the absence of a modalitywork list.

These are all common scenarios. In a looselyintegrated world, in the absence of IHE, thesecases engender angst that errors will not becaught, and significant manual effort must be ex-pended to detect and correct these events.

Consistent Pre-sentation of Images

The Consistent Presentation of Images profile isat the core of the service provided by the radiol-ogy department. In defining precisely how tomake use of the DICOM Gray-scale StandardDisplay Function (also known as DICOM part 14or GSDF) and the relatively new DICOM Gray-scale Soft-copy Presentation State, this profileensures that images are displayed as similarly as isphysically possible on different display devices,including both soft-copy display and film. Thus,images viewed on film on a viewbox, on a diag-nostic quality workstation, or on a personal com-puter should be perceived similarly, given thephysical limitations of the display device hardwareand the ergonomics of the viewing environment.

Consistent presentation of images has greatclinical significance when healthcare providersmay be discussing electronically rendered imagesat a distance. It is crucial for image features to berendered as equally perceptible as possible be-tween what may be very different devices andconditions. Similarly, it is important to be able tospecify precisely how an image was displayed andto be able to reproduce a specific presentation ofan image. One can imagine numerous medico-legal scenarios in which it may be critical to re-produce these image presentations.

The importance of accomplishing this particu-lar integration profile cannot be understated.First, as evidenced by DICOM part 14 itself, thisis an immensely complicated task that is the resultof years of collaborative scientific research be-tween industry and academia. In addition to itsclinical and medicolegal implications, this profilehas a significant impact on work flow operationsin the department. This profile plays a key role inthe Presentation of Grouped Procedures profile


described below. More important, it can be usedto introduce a number of efficiencies in the de-partment. Consider the example of routine mag-netic resonance imaging. The technologist, infinishing a study, typically zooms, pans, and setswindows or levels for each of the images in a se-ries to make the images suitable for filming orviewing. Zooming and panning the image canusually be performed once for the first image in aseries and then propagated to the remainder ofthe images in the series because the field-of-viewand other image parameters typically do notchange between images in a given series. Settingwindows or levels, on the other hand, is typi-cally performed image by image because signalstrength typically varies across images in a series.Until the advent of the DICOM Gray-scale Soft-copy Presentation State and this integration pro-file, there was no way to capture and transmit thisinformation from one device to another. Typi-cally, there is no way to capture this informationeven on a given device. Postprocessing would,thus, traditionally, have to be repeated by the ra-diologist viewing the study on a workstation andeven by the technologist when a subsequent printrequest appears. This repetition can be very costlyin terms of both radiologist and technologistthroughput.

There are more nefarious scenarios in whichthis profile can be critical to good patient care.Consider the case of direct coronal computedtomography (CT) of the sinuses. For this exami-nation, the patient is placed prone on the CTtable and the neck is hyperextended. The CTgantry is then tilted such that the angle of the gan-try matches that of the hyperextended neck. Thispositioning allows for axial imaging (with maxi-mum spatial resolution) of what is an anatomi-cally coronal plane. The CT scanner, however,still believes that it is performing axial imaging.Thus, although the DICOM orientation vectorsand the image labeling are correct, the images aretypically displayed upside down and flipped left toright compared with the traditional presentationof a coronal image. Again, the images are cor-rectly labeled, but they are not displayed in a tra-ditional format (eg, patient’s right to image left).Physicians, thinking the images are displayed“traditionally” could make drastically wrongtreatment decisions unless they take the time tocarefully check the DICOM orientation labeling.Many scanners can “automatically” flip these im-ages before filming so this has not typically been aproblem in the film-based world. In a soft-copyenvironment, however, there has been no way tocommunicate the correct presentation of the im-ages to a remote image display (such as a PACS)until the advent of DICOM Gray-scale Soft-copyPresentation State and this integration profile.

This scenario is a good example of a bad thing: aninformation system introducing a new opportu-nity for human error. The Consistent Presenta-tion of Images integration profile closes the doorto this opportunity.

The phenomenon of filmless imaging in radiol-ogy also removes a critical quality assurance stepwhen hard copy is generated. Specifically, in atraditional film environment, radiologists performimportant quality assurance steps in that they de-termine which images are of sufficient quality torelease from the department. In a filmless envi-ronment, in which the radiologists themselves donot see the actual film, poor quality images maybe printed and distributed outside the depart-ment. The Consistent Presentation of Imagesprofile ensures that images appear as closely aspossible to those viewed in the soft-copy environ-ment.

The Consistent Presentation of Images profileaccomplishes its goal by specifying that all ImageDisplay and Print Composer actors must be cali-brated to the DICOM part 14 Gray-scale Stan-dard Display Function. They, along with theircolleagues Acquisition Modality, Image Manager,Image Archive, Image Creator and Print Server,must support the creation, storage, and transmis-sion of the appropriate DICOM Gray-scale Soft-copy Presentation States. Print Composer andPrint Server support this integration profile bymeans of the “print request with presentationlook-up table” transaction.

Presentation ofGrouped Procedures

This integration profile solves the very difficultproblem of “linked procedures.” This refers toprocedures that are related to each other by thefact that they are derivatives of the same physicalacquisition of data. The role of the Presentationof Grouped Procedures integration profile in solv-ing this very difficult problem has been previouslydetailed (3). In this article, we merely summarizethe importance of this problem and highlight therole of this integration profile in resolving this is-sue.

In a grouped procedure, we receive an orderfrom a physician for, for example, “CT of thechest, abdomen, and pelvis for abscess.” Thisimage service request would (depending on asite’s protocol) first expand the order into threerequested procedures; “CT chest, enhanced,”“CT abdomen, no additional contrast,” and “CTpelvis, no additional contrast.” Note that the firstrequested procedure would engender two sched-uled procedure steps; “contrast injection, CT,”followed by “CT chest.” The second and third


requested procedures each engender a singlescheduled procedure step, “CT abdomen,” and“CT pelvis,” respectively. Each requested proce-dure would be reported separately, resulting inthree reports each corresponding to separatelybillable, CPT codes. In addition, many institu-tions interpret these steps independently for anumber of reasons. First, some institutions mayhave the chest images interpreted by a thoracicradiologist, whereas the abdominal and pelvicimages may go to other radiologists. Second,some institutions generate separate physical re-ports for each requested procedure billed. In anyevent, however, the protocol on a typical, multi-detector, helical CT scanner calls for performinga single helical data acquisition from the thoracicinlet through to the inferior pubic rami. Theproblem here is that we want to reprocess thechest images with the lung reconstruction kernel,set the lung window levels, and then split thesingle physical data set between the requestedprocedures. This causes two new problems. Thefirst is how to group the lung window images andthe mediastinum window images of the chest withthe requested procedure, “CT chest, enhanced.”The second problem is how to indicate that otherportions of the same helical acquisition are to beassociated with other requested procedures with-out transmitting or storing the data set more thanonce.

In a film-based environment, this “split” of thedata is handled by the same work flow, specifi-cally generating multiple sets of films postpro-cessed at different window values. In an elec-tronic environment, however, the same work flowdoes not work successfully. We do not want tosend the data set to the PACS multiple times,once for each requested procedure. We also donot want to send a portion of the data set to onestudy and a second portion to the second study,since there are situations in which a single viewermight want to view the entire data acquisition atone time without jumping from study to study.There may also be overlap between points in thedata set, and a given image would need to appearin two or more requested procedures. It shouldbe noted that this scenario is quite common inCT, where it might occur up to 30% of the time(Channin, unpublished data, 2000), dependingon the service population of the institution. Thereare numerous other imaging situations where thisoccurs.

The Presentation of Grouped Procedures pro-file solves this problem. The Acquisition Modalityactor allows the technologist to perform the pro-

cedure step and acquire a data set. These imagesare stored to the Image Archive as is commonlydone today with DICOM storage. The technolo-gist then creates one or more Gray-scale Soft-copy Presentation States that associate subsets ofthe images (and the image manipulations that areappropriate for those images as described above)with the appropriate requested procedure. Thisensures that the value added by the technologistin establishing the structure and presentation ofthe combined image sets can be fully used by theImage Manager to automate the reading of thesame image set, which has been properly split andpresented depending on the requested procedure.

Access to Radiology InformationThe Access to Radiology Information integrationprofile provides a well-defined means for deliver-ing radiologic information to non–RIS and theusers of those systems. This profile and theSimple Image and Numeric Reports integrationprofile begin to make use of DICOM StructuredReporting (DICOM S/R) (4). DICOM S/R is acomplex, sophisticated part of the DICOM stan-dard designed to address most, if not all, of radio-logic and other medical reporting requirements.IHE, in accordance with its strategy of makinguse of existing standards (notably DICOM andHL7), defined these integration profiles to solvereal-world work flow process problems with well-defined subsets of DICOM S/R. A textbook de-scribing DICOM S/R in detail is now available(5).

The Access to Radiology Information profileintroduces the Report Reader, Report Repository,and External Report Repository Access actors. Inthe IHE model, a Report Creator actor sends aradiologic interpretation as a DICOM S/R objectto a Report Manager. The Report Manager isresponsible for maintaining versions of the reportand the state of the report (eg, is it authenti-cated?). At any time, the Report Manager cansend a report to the Report Repository, and theReport Manager can make this report (eg, a pre-liminary report) available for query and retrievalaccording to the definitions in the Access to Radi-ology Information integration profile. At a mini-mum, the Report Manager must send a final re-port to the Report Repository. The Report Re-pository provides permanent storage of theDICOM S/R reports and responds to reportquery and retrieve messages from any ReportReader in the institution. The External ReportRepository Access provides a similar query andretrieve functionality but acts as a gateway thattranslates external reports from other informationsystems into the IHE model by using DICOMS/R.


The Access to Radiology Information integra-tion profile also precisely specifies the details tobe used by Image Display actors to query andretrieve images and presentation states. Thus, thisprofile provides the critical link between RIS,which may be in the process of conversion to anIHE model architecture, and legacy systems,which would like to provide their users access toradiologic information, notably reports, images,and presentation states.

Key Image NotesThe Key Image Note integration profile describesa mechanism by which technologists, radiologists,and others involved in the performance of radio-logic procedures can flag images as significant andattach a comment to those images. The analogyin the real world is to all the scraps of paper, espe-cially yellow Post-it� notes, that tend to get asso-ciated with a radiologic procedure yet are not in-tegrated into the formal, final report nor evercompletely managed as part of the patient’s medi-cal record. This integration profile makes use of anew DICOM object, the Key Object SelectionDocument (DICOM supplement 59). Users ofthe Image Creator or Acquisition Modality actorscan create these objects and send them to the Im-age Manager and Image Archive for storage aspart of the procedure. Image Display actors canthen retrieve these objects from there for eventualdisplay to the user. Important points in the defini-tion of this profile include (a) one key image notecan be associated with many images, (b) multiplekey image notes can be associated with a singleimage, and (c) key image notes can reference spe-cific presentation states thus ensuring that a com-ment addressed to a visible feature will likely beperceivable when the note is read.

This key image note mechanism can be usedfor many purposes. Technologists, nurses, andothers can use key image notes to document inci-dents that occur during the procedure. These in-cidents can be clinical (eg, the patient had a reac-tion), technical (eg, “at this point in the proce-dure the power failed”), or quality control related(eg, “these images have artifact due to patientmotion and respiration”). Radiologists can usethe key image note mechanism to indicate rapidlyto clinicians which images contain the most sig-nificant findings. Similarly, radiologists can tagimages that contain teaching findings or othertechnical issues that need to be documented.

Simple Imageand Numeric Reports

This last integration profile begins to address thediagnostic reporting work flow that occurs in allradiology departments. Acknowledging the com-plexity of diagnostic reporting in general, the re-

lated complexity of the DICOM Structured Re-porting standard, as well as a host of reportingissues that are currently outside the scope of theIHE initiative, IHE defined a modest integrationprofile to allow the creation, transmission, stor-age, and display of reports based on a subset ofDICOM S/R. The simple image and numericreports profile can meet many, but not all, routinereporting needs. Enhancement of reporting pro-files will surely follow in the future of IHE.

The IHE model for simple image and numericreports is based on DICOM templates defined asDICOM content mapping resources (DICOMsupplement 53). These templates specify thestructure of the document to be used for a specificpurpose, in this case, this IHE integration profile.This does not mean that other templates cannotand will not be used in reporting, but merely thata specific template, namely the “basic image diag-nostic report template” (TID 2000) is to be usedat this time in IHE transactions. This templateand therefore the IHE model states that a simpleimage and numeric report shall have a title andcontains one or more sections. Each section has atitle and can contain report text, measurements,image references, and coded entries (eg, diagnosisor pathology codes). Report text and coded en-tries can also document further image referencesand measurements from which they are inferred.One can easily see that “simple” is in the eye ofthe beholder and that the IHE model and integra-tion profile can manage reports that can be quitesophisticated.

The previously introduced Report Creator,Report Reader, Report Manager, Report Reposi-tory and External Report Repository Access ac-tors submit, query, and retrieve these DICOMS/R reports. In IHE year 3, a new actor, the En-terprise Report Repository, is identified as therecipient of a new structured report export trans-action, such that legacy hospital information sys-tems can receive straight text (ASCII) versions ofthese simple image and numeric reports via anHL7 message. Again, this allows a mechanism bywhich an institution can slowly transition to anIHE architecture while maintaining functionalityin existing information systems.

ConclusionsWe have described the IHE model of radiologywork flow and seven integration profiles that usethis model to successfully perform complex pro-cesses in the radiology department. Radiologistscannot ignore the information model and workflow that surrounds them as they do their work.In a film-based world, radiologists by virtue of


their training and experience have a very goodunderstanding of the physical processes requiredto provide accurate, high-quality, radiologic im-ages and interpretations. In shifting to an elec-tronic paradigm of radiology, radiologists mustnow understand, at least at a high level, the newinformation model and work flows that surroundthem, occasionally without a physical presence.For better or worse, as information systems be-come integrated, whether to reduce the oppor-tunity for error or to introduce efficiencies, wemust all realize that we are now smaller parts of alarger machine, and we must keep in the back ofour minds a picture, painted with broad brushstrokes, of the model that binds us together andto the information systems that support us.

Acknowledgments: The author thanks Charles Pari-sot and Christopher Lindop of GE Medical Systemsand Dr David Avrin of the University of California at

San Francisco for their contributions to the section re-lated to the Presentation of Grouped Procedures inte-gration profile. This work was presented at the 2001SPIE Medical Imaging Conference in San Diego, Cali-fornia.

References1. Radiological Society of North America/Healthcare

Information and Management Systems Society.IHE technical framework, year 3, version 4.6. OakBrook, Ill: RSNA March 2001.

2. Health Level Seven. Application protocol of elec-tronic data exchange in healthcare environments,version 2.4. Ann Arbor, Mich: HL7, October 2000.

3. National Electrical Manufacturers’ Association.Digital Imaging and Communication in Medicine(DICOM). Rosslyn, Va: NEMA, 1996; PS 3.1-1996–3.13-1996.

4. National Electrical Manufacturers’ Association.Digital Imaging and Communication in Medicine(DICOM), supplement 23. Rosslyn, Va: NEMA,2000.

5. Clunie DA. DICOM structured reporting. Bangor,PA: PixelMed, 2000.

This article meets the criteria for 1.0 credit hour in category 1 of the AMA Physician’s Recognition Award. To obtaincredit, see www.rsna.org/education/rg_cme.html.


IHE PRIMER 1351

Integrating theHealthcare Enterprise:A PrimerPart 3. What Does IHE Do for ME?1

David S. Channin, MD ● Charles Parisot ● Vishal Wanchoo ● AndreiLeontiev ● Eliot L. Siegel, MD

IntroductionThe Integrating the Healthcare Enterprise (IHE) initiative brings together users anddevelopers of medical information systems to advance data integration. Each of thesestakeholders in the healthcare delivery process is vital to successfully caring for pa-tients in an expert, efficient, and cost-effective manner. Each of the different mem-bers of this community has a slightly different perspective on why IHE is importantand how IHE can (positively) affect their role in delivering healthcare.

In this article, we present eight differing perspectives. Readers are referred to thesecond article in this primer series (1) for a more detailed explanation of these inte-gration profiles. Readers from other (nonradiology) segments of the healthcare enter-prise and industry should see in this collection of user perspectives kindred spiritswith vested interests in addressing analogous problems from their domains.

The Departmental Chief or ChairmanAs a radiology departmental chief, I have the ultimate responsibility to provide thehighest possible quality of care for our patients in addition to prompt, reliable, andresponsive consultation for our clinical colleagues in as cost-effective a manner as ispractical. I am accountable for analyzing and optimizing departmental work flow andproductivity and for creating a vision and road map for the future direction of the de-partment. Selection, procurement, and integration of imaging equipment and infor-mation systems are integral parts of my job.

Abbreviations: DICOM � Digital Imaging and Communications in Medicine, HL7 � Health Level 7, PACS � picture archiving and communica-tion system, RIS � radiology information system



1From the Department of Radiology, Northwestern University, 448 E Ontario St, Suite 300, Chicago, IL 60611 (D.S.C.); Global Connectivity Cen-ter, GE Medical Systems Information Technologies, Buc, France (C.P.); Department of Radiology Systems, GE Medical Systems Information Tech-nologies, Mt Prospect, Ill (V.W.); Radiology and Imaging Solutions Division, IDX Systems, Burlington, Vt (A.L.); and Department of Diagnostic Im-aging, University of Maryland School of Medicine, Baltimore (E.L.S.). Received May 29, 2001; revision requested June 27 and received July 11; ac-cepted July 11. Address correspondence to D.S.C. (e-mail: [email protected]).

©RSNA, 2001

In 1989, a work flow analysis of our radiologydepartment was performed, which, to our sur-prise, demonstrated that 59 steps and a dozenpeople were required to produce a routine chestradiograph of an inpatient. With the transition tothe use of computers alone, there would havebeen very little reduction in the number of stepsor the time required for them without integrationof the various information systems and modalitieswithin the entire healthcare enterprise. Duringthe past 10 years, we have subsequently rede-signed our work flow and have been forced to cre-ate custom interfaces with our vendors by usingDICOM (Digital Imaging and Communicationsin Medicine) (2) and HL7 (Health Level 7) (3)interfaces. These efforts have drastically de-creased the number of work flow steps to lessthan 10 and have similarly reduced our depart-mental turnaround times. Unfortunately, thesecustom interfaces were often slow and unreliable(especially the initial ones) and, in many cases,quite expensive. Today, fortunately, most of thesework flow enhancements can be obtained by us-ing the IHE integration profiles.

During the past several years, I have often feltlike Charlie Brown from the comic strip Peanuts,after he has once again charged down the field atthe football held enticingly in place by Lucy onlyto have it snatched away at the last possible mo-ment. In one of the comic strips that has beenarchived in the American History Museum, Lucyeven gives Charlie Brown a signed document“proving” she won’t pull away the football andshe still manages to yank it away just before he’sable to kick it. This scenario has been repeated inour department for the past 10 years, as we’vebeen promised by earnest and presumably well-meaning vendors that our brand new modality orinformation system will “plug and play” virtuallyseamlessly with our existing systems by usingDICOM and HL7, without any need for any sig-nificant customization. The consistent need formajor “customization” of our new modality orinformation system after delivery has typicallyresulted in problems. These difficulties haveranged from the need to perform additionalmanual work flow steps to “temporarily workaround” the problems to major delays in our abil-ity to use the equipment and major additionalunbudgeted expenses to attempt to provide thepromised full functionality of the system. Theseidiosyncratic interfaces also add to the complexityof the system, which has resulted in increasedequipment down time especially when softwareupgrades are installed on our modalities or infor-

mation systems, which need to be further modi-fied to continue to function properly.

As departmental chief, it is important for me tohave the flexibility to purchase equipment that is“best of breed” rather than staying with a singlevendor or a short list of vendors that happen tohave a custom or “approved” interface to my ex-isting systems. Universal adoption of the IHE in-tegration profiles will make it much easier for meto have the flexibility to purchase what I wantrather than settle for second best. Similarly, I donot want to feel constrained to utilize my infor-mation technology staff’s choice of a hospital in-formation system provider for my radiology infor-mation system (RIS) or radiology picture archiv-ing and communication system (PACS) butwould rather know that by conforming to IHEintegration profiles, my own choices will be likelyto integrate seamlessly with the hospital systems.

In today’s job market in which there are severeshortages of qualified radiology personnel, I needto make sure that I provide an optimized workflow process and adequate tools for my depart-mental administrator, technologists, and radiolo-gists to get their jobs done as effectively as pos-sible with a minimum of frustrations. I also needto ensure that the unique requirements of ourclinicians, information technology staff, and ven-dors are addressed as well. I have been impressedwith the IHE progress thus far and remain opti-mistic that it will continue to evolve to serve theneeds of my department, staff, and associates.

The DepartmentManager or Administrator

As the department of radiology administrator, Iam focused on providing superlative service toour patients and our referring physicians in ascost-effective a fashion as possible. I am strug-gling against tighter budgets, rising costs, increas-ing procedure volumes, and an extremely tighttechnical labor pool.

As I walk through my department, I want tosee patients moving through the system comfort-ably and efficiently. I do not want to see idle, ex-pensive modality devices when I know that wehave backlogs of outpatients waiting for proce-dures. I do not want to see technologists jumpingfrom one information system to another to com-plete routine tasks. I want to see more proceduresdone per technologist per modality device. I wantmy electronic environment to reduce the numberof steps we take in any given process. I do notwant to add work flow steps because of informa-tion systems. I do not want to see technologists“sneaker-netting” paper around the departmentwhere once we ran films.

Since we are now in a filmless environment, Iwant to be confident that studies are performed


according to protocol, manipulated by the tech-nologists appropriately, stored correctly and per-manently into the PACS, and ready for viewingon both workstations and, as necessary, film.

I want to make sure that our referring physi-cians can access radiology information—imagesand reports—from the information systems theyuse. When they access this information, I want tobe confident that they are getting the images theyexpect in a format that is displayed correctly. Al-though I understand that the return on invest-ment from information systems comes from morethan film cost reductions, I still want to minimizenot only my film costs, but also the costs associ-ated with managing these requests for radiologyinformation. Authorized users of radiology infor-mation should be able to query and retrieve theinformation they need for patient care from mysystems so that I do not have to manage pushingthis information to them.

I want to reduce the opportunity for errors bythe technologists, because these errors are notonly dangerous to the patient but very labor in-tensive and therefore expensive to correct. In thedays of film, when modalities were islands offunctionality, a stick-on label and a pen couldcorrect an error. Now, modalities are intertwinedwith the RIS, PACS, and other information sys-tems, and errors on one device have significantupstream and downstream repercussions on otherinformation systems.

I understand fully that the return on invest-ment from my information systems comes fromincreasing these efficiencies and reducing tangibleand intangible costs, not from reducing film costs.I believe that the IHE initiative will foster theseefficiencies.

The TechnologistAs a technologist, I am focused on performing thehighest quality possible radiologic procedures onmy patients. I want my patients to be as comfort-able as possible, wait the least amount of time,and move through our department as quickly aspossible.

I know how to perform a procedure on my mo-dality. I know how to problem solve to get theprocedure done, and I know when to get help inproblem solving. Yet, as the department hasadded more and more information systems, Ihave had to learn how to use all these differentsystems. I have no clear mental picture of howthese systems interact. Each information systemrefers to parts of the radiologic procedure and thesteps involved in the radiologic process differ-ently, and each system has different means formodifying information and correcting mistakes.Figuring out what to do next in any given sce-

nario or in the case of an exception is gettingmore and more complicated not simpler.

I often find myself repeating steps in my workflow unnecessarily. For example, if I zoom, pan,and select window levels once to film a study or tosend it to PACS, I may have to repeat these stepsover and over for a given procedure. Worse yet, ifI do some image manipulations, another user of adifferent information system may have to repeatthe work I have already done. Either I should beable to do the work once or they should be able todo this step once, but both of us should not haveto reproduce each other’s work.

Although we are now in a mostly filmless envi-ronment, we are still generating and manipulatingtoo much paper. We get orders on paper, elec-tronic orders printed on paper, requisitions, pro-tocol sheets, flow sheets, quality assurance sheets,and patient history sheets. We have manual log-books and protocol notebooks. I have no choicebut to put my comments and questions on allthese sheets of paper. I am constantly on thephone clarifying orders, rendering generic ordersmore specific, and manually scheduling inpatientsand outpatients into the system. Even so, I muststill spend time interrupting the radiologists formore clarifications. This reduces my efficiencyand their efficiency.

When I complete a procedure on my modalityworkstation, I want to be assured that the imagesare permanently stored and that they will be pre-sented for viewing as I have manipulated them. Itake responsibility for the appearance of my im-ages, and I want to know that my time and effortis not being wasted.

I want to receive fewer requests for radiologyimages and reports from outside sources. Once Ihand off the images to PACS, I want users toquery and retrieve the images from the PACS. Ido not want to spend my time pushing images tovarious three-dimensional postprocessing, surgi-cal, or research workstations.

My job is to perform high-quality radiologicprocedures on sick patients. I hope that the IHEinitiative can foster information systems that helpme and my equipment do just that.

The RadiologistAs a radiologist, I am focused on providing thehighest possible quality of care for my patientsand the highest level of service to the referringphysicians who entrust me with the care of theirpatients. I am struggling to do this in the face ofincreasing bureaucracy, increasing regulation ofmy practice, and decreasing reimbursements, all

RG f Volume 21 ● Number 5 Channin et al 1353

within the context of a very competitive marketthat includes a very tight technical and profes-sional labor pool. I must continually work harderand smarter to keep up.

I routinely use a number of departmental in-formation systems, including RIS and PACS. Atmy institution, 95% of the 250,000 procedureswe perform per year are acquired, stored, trans-mitted, and interpreted from a PACS. I nowspend the majority of my clinical time in front ofone or more workstations. On occasion, I use asmall number of other terminals and personalcomputers to access other hospital informationsystems located outside my department. In be-tween clinical responsibilities, I use the RIS toedit and sign reports. I then coordinate with ourpractice manager to make sure that the profes-sional billing information gets entered correctlyinto our practice’s billing system. Although theseinformation systems are adequate for getting mywork done, my frustration lies in the fact that theydo not work better together to facilitate my workflow and make me more efficient.

Consider the routine scheduled work flow.When a technologist finishes a study, he or sheplaces the requisition, which is stapled to numer-ous associated pieces of paper, in a pile in a lettertray. Although we are filmless in our department,we are far from being paperless. Currently, thereis no way to electronically annotate the study. Iwant to capture electronically what are nowscribbles in the margins of the various papers. Ialso want my residents to be able to annotate im-ages.

Every few minutes, I retrieve a stack of requisi-tions and return to my PACS workstation. Byvirtue of the accession number printed on the req-uisition, I can usually identify the study thatneeds to be interpreted. On occasion, a study islisted as “unspecified” because the image infor-mation received by the PACS from the modalityworkstation does not match the order informationreceived by the PACS from the RIS. This hap-pens frequently for trauma patients and other“John Does,” but also when the hospital’s admis-sion/discharge/transfer system is down. For eitherof these scenarios, I must wait for the RIS admin-istrator to manually enter the order and the PACSadministrator to manually merge the image infor-mation with the order information once it arrivesin the PACS. This not only delays me in inter-preting the study, but I worry that the referringphysician will not be able to find the imagingstudy in a timely fashion when clinically needed.

Because of our reliance on paper requisitions,it is also very difficult for us to distribute work

efficiently among the available radiologists. Weare bound to the paper requisition. We must alsobe in proximity to the technologists so that we canconfirm exactly what was done, when, and why.The scheduling and specification of imaging pro-tocols for work to be done is very inefficient. Myresidents and I are constantly being interrupted toschedule and specify protocols for studies.

On occasion, the image folder on my PACSworkstation is empty because, for example, im-ages from a computed tomographic (CT) exami-nation of the abdomen are stored with CT imagesof the chest, since the images were all acquired inone data acquisition. I can almost always find thecorrect images, but it does slow me down. Again,I worry if my clinical colleagues will find the im-ages in a timely fashion.

More important, images are often not pre-sented to me as I wish to see them. In the goodold days, the technologists would adjust the im-ages on the modality workstation before filmingthem. Now, even when they do make adjustmentsto the images for an occasional hard copy, thosechanges don’t show up on my PACS workstationand I must redo the manipulations. This dupli-cated effort, again, slows down the technologistsand slows me down.

Since I no longer interpret studies from filmand therefore do not see filmed images beforethey are released from the department, I am con-cerned that the quality of filmed images sent fromthe department may be suboptimal.

Worse still, there are scenarios in which ourclinical colleagues must manipulate images toensure that they are viewed correctly. Images maybe technically labeled correctly, but they are notdisplayed conventionally. For example, we findthat they often must be flipped manually horizon-tally or vertically. Because these manipulationsare not sent from the modality workstation to thePACS, they must be performed again on thePACS. This needs to be done very quickly, as Iworry that clinicians may not notice that the im-ages, although labeled correctly, are not displayedas expected. This could lead to disastrous patientoutcomes.

I need to be able to quickly identify and markimages that are important to the clinicians. I needbetter reporting tools. I need to record measure-ments and comments and to have them inte-grated into a consistent model for reporting radio-logic findings.

IHE has addressed a number of common,problematic scenarios that crop up in my elec-tronic world. For me, the solutions embodied inthe IHE technical framework cannot be imple-mented fast enough. Waiting for them to becomerealized in the products and systems I use daily


makes me feel like a chained dog faced with asteak just out of reach.

The Nonradiologist ClinicianAs a clinician, I am focused on providing the besthealthcare possible to my patients. I must providethis superlative care to more and more patients,and I must juggle more and more patient needs. Ido so in the context of an ever-changing health-care environment with rising bureaucracy, in-creasing administrative chores, decreasing reim-bursement, and more and more information sys-tems. These information systems are supposed tomake my life easier and more efficient. Instead,they add steps to my work flow and reduce myefficiency, exactly the opposite of what they aresupposed to do. I must have all the information Ineed to support my decision-making processwhen and where I need it. I spend too much ofmy time hunting and gathering information, andthis strains the time I have available to digest theinformation and see my patients.

When I place a request for a procedure, I wantto know when the procedure has or is going to bestarted, and I want to know when the study iscompleted. I want to see my patient’s imageswhen I need to see them. This might be 2 minutesafter they leave the procedure room or 2 yearsafter they leave the institution. I want to see theimages and reports in my office, at home, in theclinic, and in the operating room.

When I access the images, I do not want tomanipulate the images to highlight image featuresand findings. The technologists should have donethis, and this is part of the value added by the ra-diologist. I rely on the radiologists more than Iam willing to admit. I need their report, but itmust be available in a timely fashion. I can’t siftthrough 100 or 1,000 CT or magnetic resonanceimages looking for key findings. I need and trustthe radiologists to filter and consolidate this vastamount of information for me. I need them tomake annotations and comments that I can seewhen I am looking at the images.

My institution is now filmless, which has prosand cons. I greatly appreciate the positive impactof PACS on our institution. I especially appreci-ate no longer having to wait for films in the filmfile room. I appreciate that studies are almostnever lost now. However, I still need film on oc-casion, and although I understand that the radi-ologists no longer check each film, I need to havegood-quality hard copies available when I call forthem.

When I access the images on a workstation, Idon’t want to spend time looking for images infolders. I don’t care if the chest, abdominal, andpelvic CT images are acquired in one spiral, one

helix, or one “double helix”: I want look at thechest when I need to see the chest and I want tolook at the abdomen when I need to see the ab-domen. When I need to look at today’s abdomi-nal CT images, I don’t want to wade through abunch of neck and chest images from the previousexamination before I get to the abdominal im-ages. I can’t afford to waste precious time surf-ing the PACS looking for the images. Similarly,when my patients come in as John or Jane Doe orchange their names or need to have their identityprotected, I don’t want to waste time looking fortheir images.

I am looking for the IHE initiative to make theinformation systems with which I interact per-form more cohesively such that I can work moreefficiently, not less efficiently, in an electronicenvironment.

The Chief Information OfficerAs the chief information officer, I am responsiblefor protecting and serving the data of the patientsof our institution. As the steward of this informa-tion, I am responsible for the oversight and man-agement of dozens if not a hundred or more infor-mation systems. I face this responsibility in thecontext of increasing internal policies and proce-dures for information management that are them-selves a reflection of growing local, state, and fed-eral regulations. I am also facing this informationmanagement challenge in the context of tighterbudgets, rapid technology growth and the associ-ated rapid obsolescence curve, increasing person-nel costs, and a very tight technical labor market.

In the good old days, I was less concerned withinformation system purchases in departmentssuch as radiology. We understood that there wereinformation systems buried in the modalities, butat the time they didn’t communicate with otherinformation systems. Now, as the modalities anddepartmental information systems become moresophisticated and need to interact with other de-partmental and hospital information systems, thelevel of complexity has gone through the roof. Inow have to understand how work flow is pro-cessed in each department, and I need to definethe points of contact between these informationsystems.

I want to deploy best-of-breed computer sys-tems to best support my clinical, research, educa-tional, and management user communities. I loveinformation systems standards. When standardswork as intended, I can buy best-of-breed systems.Standards also encourage a healthy competitionbetween my vendors to improve performance and


service. Unfortunately, standards don’t com-pletely address all of my needs. Until they do, Ican no longer afford to develop, test, and managemore point-to-point interfaces between systems. Imust, therefore, consolidate to fewer informationsystems, even though this means occasionally giv-ing up best-of-breed end user functionality. Iknow that I will never be able to consolidate toone system from one vendor, and so I look to theIHE initiative to define a framework that I can askmy vendors to implement to help me consolidateto a handful of systems that act in concert to pro-cess work flow in my institution.

The ImagingInformation System Vendor

“Connectivity” of imaging acquisition systems isa nonnegotiable customer expectation. Providerstransmit images from their modality workstationsto a variety of imaging information systems,which include stand-alone analysis or reviewworkstations, cluster archiving systems, hard-copy film and paper output devices, and an in-creasing number of PACS. The level of connec-tivity expected by our customers now reaches wellbeyond point-to-point image transfer, taking intoaccount increasingly sophisticated work flow pro-cesses.

Many customers wonder why radiology re-quires more than what DICOM delivers for imag-ing. It is widely known that DICOM develop-ment has been a challenge; however, over the last8 years, we in industry have optimized DICOMto provide good interoperability between radiol-ogy systems.

Now the “bar of clinical information integra-tion” has been raised. New demands, such aslinking images to radiology documents, accessingRIS and other clinical information systems, andcommunicating these data beyond the walls of theradiology department, require a broader level ofconnectivity. And this leads to the challenge ofthe new decade: increase efficiency and comfortof patient care and decrease the risk of medicalerrors. To achieve these goals, the imaging indus-try needs to reach out to healthcare informationvendors to develop a complementary range ofconnectivity standards, among which HL7 plays acentral role.

Through the IHE initiative, industry reachespractical agreements on the best use of informa-tion technologies and standards to solve real-

world clinical problems. This is good for custom-ers who desire flexibility to select best-of-breedimaging systems. In addition, for vendors itgreatly simplifies the design and installation ofnew equipment and the process of upgrading pre-viously installed equipment.

IHE is about teamwork, and not only team-work between vendors, but also that between us-ers and vendors. This is a novel approach to thecomplex problems of healthcare information sys-tems integration that now has reached maturity inits definition. The capabilities of IHE have beenproved through several multivendor demonstra-tions at RSNA 1999 and 2000 and at HIMSS2000 and 2001. In addition, since any integrationeffort is difficult to test in the field, the IHE “con-nect-a-thon” which precedes these demonstra-tions is an extremely beneficial forum in which totest integration in a neutral environment.

To exploit the benefits of the IHE efforts todate, two specific actions need to be taken. First,vendors need to enhance and align DICOM andHL7 capabilities of their imaging and nonimagingproducts with the IHE initiative. Second, custom-ers who plan to leverage the benefits of IHE bypurchasing new products or upgrading existingscanners need to demand IHE participation fromtheir vendors.

Although IHE takes a rather extensive perspec-tive at specifying how each of the seven integratedwork flow processes (or integration profiles) canbe implemented in the institution, it does not re-quire that the user upgrade all information sys-tems at once. Each work flow process can beimplemented in incremental steps, preferablystarting with the Scheduled Work Flow integra-tion profile. For example, users may elect to inte-grate one or two modalities with the RIS or PACS(or both) to support the Scheduled Work Flowintegration profile. Overall, IHE is a key elementin reducing the risk of encountering integrationroadblocks. IHE significantly increases the levelof the confidence in planning and executing theseprojects in a successful manner. This benefitsboth the customer and the vendor.

IHE also is an opportunity for vendors tomaintain a simpler dialogue with customers inunderstanding their integration requirements. Inaddition, it provides a common framework forvendors to reach agreement on solving providerproblems. For example, the IHE Consistent Pre-sentation of Images integration profile ensuresthat images are consistently displayed on any dis-play system within the institution (film or softcopy). This benefits both the user and the vendor


in that images will appear consistent across allcalibrated display systems. Users no longer willhave to call their local service person to “tweak”the image to make it look like their films. Vendorsbenefit from reduced service calls.

The NonimagingInformation System Vendor

The mission of many imaging and nonimagingmedical information systems vendors is to trans-form healthcare delivery by helping customersimprove efficiency and provide consistent qualitycare to patients. In making this transformation, itis challenging to overcome the barriers to accessinformation across system boundaries. Yet, thereis a better approach than the “interface engine”method of data integration, which adds unduecomplexity, poor maintainability, and highercosts to the institution.

Each individual information system is highlydependent on work flow information from othersystems in keeping the provision of radiology ser-vices responsive to the entire healthcare institu-tion. In the past, custom ad-hoc integration solu-tions were viewed as insurance policies againstlosing customers. In reality, they have resulted inlimited market growth while stifling technologicevolution. IHE provides a better solution.

In the radiology department, for example,three major forces are converging, which makesIHE a timely initiative. First, the “image factory”is becoming completely digital, which opens thedoor to higher efficiencies and quality of care.

The second force emerged from the dawn ofthe schizophrenic period when image informationhad to be separated strictly from the clinical andadministrative information. Now the rapid adop-tion of PACS, its linkage to the RIS, as well as theInternet distribution of images and reports, arereinforcing the need for nonimaging and imagingproduct vendors to work together. With strongerlinkages, the lines of RIS and PACS are beingblurred, evolving into a new generation of infor-mation systems. These new systems are compel-ling radiology leadership to team up with the chiefinformation officer.

Finally, the third force is the need to improveefficiency, cost effectiveness, and quality of carewhile concomitantly reducing medical errors.With this force, the “bar of patient informationintegration” has been raised. In the paper andfilm era, links between patient information andthe acquired images were a manual process,which was both error-prone and time consuming.In this new era, patient information managementbecomes an integrated capability of the prescrip-tion, acquisition, review and diagnosis of a study.

Vendors view IHE as a mechanism to enableconsistent exchange of clinical information and toallow healthcare providers to select best-of-breedinformation systems.

There is no question among vendors that theIHE initiative will lead to improved patient careand improved information accessibility for thehealthcare provider. Yet vendors also look forgrowth, profit, customer satisfaction, and em-ployee opportunity to fulfill their mission. Meet-ing the goals of IHE helps us make good on ourcorporate missions.

As an information system vendor, we needto ensure the future viability of our products.Through our involvement with IHE, we havegained insight and knowledge in enterprise infor-mation distribution. This insight has facilitatedour ability to turn our vision of enterprise radiol-ogy into reality. IHE is helping to drive the futurefunctionality of our products, and we believe thishelps to secure our position in the future.

IHE gives us a forum to address our initiativesand priorities. Those initiatives are evaluated ob-jectively along with the initiatives of other ven-dors. The end result is a solution that meets ev-erybody’s needs, thus reducing turf battles be-tween vendors. Healthcare providers are thedriving force behind IHE. Our involvement hasallowed us to create and maintain a close relation-ship with these users. Not only do we gain under-standing of our users’ issues, but users also gain abetter understanding of issues within the indus-try. This mutual understanding lends itself to acloser relationship.

In addition, our involvement has given us ex-posure to new users who share their ideas andexperiences and may also become potential newcustomers. To move forward, we need the sup-port of not only users but that of other vendors aswell. Our involvement with IHE has advanced thequality of our relationships with other vendors,which has improved our ability to better serve theneeds of our joint customers. Our involvementwith IHE has given us insight into the various is-sues and challenges in the imaging world. Thisknowledge has been invaluable as we expand ourproduct line.

Because of our IHE involvement, integrationefforts with other vendors can be completed inless time. Even integration efforts with non-IHEcompliant vendors are easier because we have aframework on which to build. With standard inte-gration models, our customers are easier to support.


Our involvement in IHE has allowed our em-ployees to expand their knowledge outside theradiology arena. This exposure to the healthcareindustry makes our employees more valuable.

The bottom line is that IHE is good for busi-ness. Our involvement is helping us meet our ob-jectives to deliver on our vision of the future. Thetruly remarkable thing about IHE is the fact that it’sgood for the patient, it’s good for the healthcareprovider, and it’s good for all information systemsvendors. IHE has created an environment whereeverybody wins.

ConclusionsNumerous stakeholders in the healthcare deliveryprocess share common problems, at least some ofwhich are addressed by the IHE initiative. Most

important, the IHE initiative provides a forumand a framework in which all these stakeholderscan come together and work to resolve theseproblems. The model established by this initiativecan and will be extended vertically within radiol-ogy, to other departmental areas, and horizontallyacross the healthcare enterprise.

References1. Channin DS. Integrating the Healthcare Enterprise:

a primer. II. Seven brides for seven brothers: theIHE integration profiles. RadioGraphics 2001; 21:1343–1350.


3. Health Level Seven. Application protocol of elec-tronic data exchange in healthcare environments,version 2.4. Ann Arbor, Mich: HL7, October 2000.


IHE PRIMER 1597

Integrating theHealthcare Enterprise:A PrimerPart 4. The Role of Existing Standards inIHE1

Michael Henderson ● Fred M. Behlen, PhD ● Charles Parisot ● Eliot L.Siegel, MD ● David S. Channin, MD

IntroductionIntegrating the Healthcare Enterprise (IHE) is not a standard. IHE is an initiativeand a movement that has produced numerous deliverables. First and foremost, IHEhas produced a milieu for open discussion among medical information system ven-dors, users, and other interested parties (eg, standards bodies, professional societies)on how to better integrate heterogeneous computer information systems with the goalof improving patient care. The initiative also provides vendors with a “connect-a-thon,” which allows them to confirm that their systems can successfully connect toand communicate with each other. From the perspective of practical value to theuser, the most important output of the IHE initiative is the technical framework (1).This document describes, as unambiguously as possible, the transactions that mustoccur to solve seven real-world problems, or integration profiles in IHE terms.

If the IHE and its technical framework are not standards, what are they? The tech-nical framework serves as a consensus document of how to think about, discuss, andsuccessfully overcome medical information system integration problems by using ex-isting standards and tools.

The following analogy may clarify further that one conforms to standards, whereasone complies with consensus documents such as the IHE technical framework. Con-sider hammers, nails, screwdrivers, and screws. There are many different hammers—cheap ones, expensive ones, manual, air-driven, and so on-but most hammers consistof a handle on one end and a shaped piece of hard material on the other. The sameapplies to screwdrivers. There are standards for hammers and standards for nails.There are even more technical standards for screws, since they are a more moderndevice. The standards for hammers might stipulate, for example, that the hammerhead cannot fragment into dangerous shrapnel when a force of less than n newtons isapplied to it. A standard, however, would probably not prohibit you from driving a

Abbreviations: ADT � admission/discharge/transfer, CDA � clinical document architecture, DICOM � Digital Imaging and Communications inMedicine, HL7 � Health Level Seven, IHE � Integrating the Healthcare Enterprise, PACS � picture archiving and communication system, RIM �reference information model, XML � extended markup language



1From 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 Radiol-ogy, Northwestern University Medical Center, 448 E Ontario St, Suite 300, Chicago, IL 60611 (D.S.C.). Received August 24, 2001; revision re-quested August 29 and received August 31; accepted August 31. Address correspondence to D.S.C. (e-mail: [email protected]).

©RSNA, 2001

screw with a hammer, and, in fact, numerouspeople probably do drive screws with hammers.One could imagine a group of prospective home-owners and a group of builders getting togetherand coming to a consensus that if a builder wantsto participate in a project that he or she will agreeto drive nails with only hammers and to drivescrews with only screwdrivers since those meth-ods yield the best result, that is, a safe, strongstructure with a good look and feel. The consen-sus could also state that a certain kind of nailshould be used in one situation and that anotherkind of nail should be used in another situation,without specifying a standard for how those nailsshould be manufactured.

To extend the analogy further, the homeowner(or even appropriate governing authorities) mightrequire the builder to conform to certain stan-dards, such as local electrical codes. The home-owner, however, could also require the builder toadhere to other consensus documents that mightotherwise be optional for the builder. The buildercomplies to meet a customer requirement, and bydoing so, the builder’s construction company canparticipate in a larger arena where cooperationamong builders is required. It might also lowertheir construction costs due to a reduction in thenumber of different kinds of nails and screws re-quired.

The Digital Imaging and Communications inMedicine (DICOM) (2) standard from theAmerican College of Radiology (ACR) and theNational Electrical Manufacturers’ Association(NEMA) and the Health Level Seven (HL7)standard (3) from same organizations are thetools—the hammer and screwdriver—currentlyused in the IHE technical framework. The dataelements used by these standards and preciselydefined by the IHE framework are the nails andscrews.

As the IHE initiative expands into other medi-cal arenas outside radiology and as it addressesother healthcare enterprise–wide processes, othertools (standards) will be added, as appropriate, tothe IHE toolbox. For now, however, understand-ing the role of HL7 and DICOM in IHE is suffi-cient, and this article is intended to clarify howthe IHE community of vendors and users employthe existing standards of HL7 and DICOM toachieve the integration goals of IHE. The articlealso examines how HL7 is evolving to meet thechallenge of more complex information systemintegration demands and details some of thenewer components of DICOM and how they re-late to IHE.

Health Level SevenHL7 is a standard for electronic data interchangein healthcare environments. Originally developedin 1987 by a group of large healthcare providerswho met at the University of Pennsylvania, thestandard at first emphasized point-to-point trans-mission of patient-oriented admission/discharge/transfer (ADT), order, and results information ininpatient environments. Today, HL7 prescribesformats for the interchange of information con-cerning all aspects of the healthcare enterprise,including billing, clinical pathways, care guide-lines, referrals, and information about practitio-ners and support staff.

The “seven” in HL7 is a reference to the posi-tion of the standard atop the seventh layer of theOpen System Interconnection (OSI) series ofprotocols from the International Organization forStandardization (ISO) (4). From its inception,HL7 has emphasized the data to be carried,rather than the formatting of messages or the con-figuration of endpoint systems. By its own de-scription, HL7 “does not try to assume a particu-lar architecture with respect to the placement ofdata within applications but is designed to sup-port a central patient care system as well as amore distributed environment where data residesin departmental systems. Instead, HL7 serves as away for inherently disparate applications and dataarchitectures operating in a heterogeneous systemenvironment to communicate with each other” (3).

Data in an HL7 message are transmitted infields of well-defined data types. Fields aregrouped into segments of related information.Messages may be formatted by using EncodingRules/7, which treat segments of a message asrecordlike entities and set off fields and subfieldelements by using common delimiters such as avertical bar (|) and caret (�). Alternatively, HL7messages may be transmitted by using externalprotocols such as the extended markup language(XML) (5).

HL7 provides widely adaptable specificationsfor the transmission of such data as patient identi-fiers and addresses, as well as the encoding ofclinical information, by using well-known systemssuch as the Common Procedure Terminology(CPT) from the American Medical Association(6), the International Classification of Diseases(ICD) (7), and Logical Observation IdentifierNames and Codes (LOINC) (8).

This “widely adaptable” capacity of HL7 is agreat weakness as well as a strength. “Widelyadaptable” means that different vendors canimplement the HL7 standard in a variety of ways.

1598 November-December 2001 RG f Volume 21 ● Number 6

This lack of uniformity makes HL7 interfaces ex-pensive and complicated for both vendors andcustomers because each of the many different sys-tems from many different vendors may have useda different interpretation of HL7. The IHE tech-nical framework comes to the rescue by specifyinghow to use HL7, which reduces the variability inimplementation. This consensus makes it easierfor users and vendors to interface their systems,which creates a potential for substantially reduc-ing costs.

Utility of HL7 in theClinical Service EnvironmentThe HL7 standard prescribes messages for thetransmission of patient demographic and registra-tion information, as well as for the communica-tion of clinical orders, observations, and resultsdata. The standard is thus well suited for trans-mitting data between integrated clinical informa-tion systems and systems dedicated to the supportof specific clinical services, such as laboratory andradiology.

Messages in HL7 are initiated through the oc-currence of trigger events, such as “patient is ad-mitted” or “new order is placed.” The event-driven nature of the HL7 environment makes it arelatively simple matter to produce case illustra-tions and interaction diagrams that precisely de-fine the participants in a dialogue, their roles andresponsibilities, and the nature of the communi-cations between them. A sample interaction dia-gram from section 6.1.4 of the IHE technicalframework document (1) illustrates how the abil-ity of HL7 to model real-world events fits intoIHE (Fig).

HL7 Use in IHEIn the IHE technical framework, several sets ofHL7 transactions are defined for communicatingthree broad categories of information: patient,order, and results information. These transac-tions operate between the ADT and order entrysystems on the requesting side and between theDepartment System Scheduler and Image Man-ager systems on the performing side.

Patient Information.—HL7 ADT messagesprovide for the communication of demographicand registration information in response to over60 discrete trigger events. The IHE technicalframework specifies Patient Registration and Pa-tient Update transactions in which this informa-tion will be communicated, and cites 13 triggerevents from the HL7 standard that will cause thegeneration of messages within the IHE model.

Order Information.—Within HL7, a general-purpose order management (ORM) message al-lows communication of order and status data be-tween Order Placer and Order Filler systems. TheIHE technical framework specifies Placer OrderManagement, Filler Order Management, Proce-dure Scheduled, and Procedure Update transac-tions that use HL7 ORM messages and order re-sponses (ORR) to coordinate the transmission ofthis information.

Results Information.—Although most IHEtransactions dealing with reports use the DICOMstandard, IHE uses the HL7 observation resultsunsolicited (ORU) message to transmit ASCIItext report information between a report managerand a repository.

Patient Information MessagesAs shown in the Figure, patient information origi-nates in all cases from the ADT system and flowsto the systems that need patient data to correctlyattach orders and results to the correct patient.HL7 messages are used to transmit demographicinformation, visit data, and such vital statistics asheight and weight.

The IHE technical framework documentspecifies a Patient Registration transaction by us-ing the trigger events shown in the interactiondiagram. In addition, a Patient Update transac-tion is defined by transfer, discharge, and classupdate events (and their cancellations, where ap-plicable); demographic data updates; and dupli-cate patient record merges.

Figure. Interaction diagram shows how patient in-formation flows from the registration system to inter-ested endpoint systems by means of ADT messages.A01, A04, A05, A11, and A38 represent the specifictrigger events that cause the transmission of messages:admission, registration, preadmission, admission orregistration cancellation, and preadmission cancella-tion. Each of these events triggers the generation of anevent-specific message to the Order Placer, depart-ment, and master patient index (MPI) systems.

RG f Volume 21 ● Number 6 Henderson et al 1599

IHE also provides for the entry of order infor-mation for unidentified patients directly into theOrder Placer or Order Filler systems. In this way,the provision of care is not impeded by the lack ofavailable demographic information or by the un-availability of system resources. Reconciliation ofpatient data among systems is accomplished sub-sequent to the placement or execution of the order.

Order Information MessagesIHE uses the HL7 general-purpose order man-agement message to communicate informationabout the patient for whom the order is beingplaced, the time for which the procedure is sched-uled, and the specific activities to be performed.In contrast to ADT messages, which are distin-guished by their trigger events, order messagesuse an order control code to communicate statetransitions (eg, new order, number assigned, or-der discontinued).

In the IHE model, orders may be initiated oneither a placer (order entry) or filler (DepartmentSystem Scheduler) system. The filler system isresponsible for determining the specific proce-dures and steps required to fill the order and fortransmitting all order information, including pa-tient demographics, to the Image Manager.

Four HL7 order transactions are specified inIHE: (a) placer order management, in which neworders and cancellations are transmitted from anorder entry system; (b) filler order management,which provides for communication of new orders,order updates, and cancellations from the De-partment System Scheduler or Order Filler;(c) procedure scheduled, in which order informa-tion is transmitted from the Order Filler system tothe Image Manager; and (d) procedure update, inwhich the Order Filler communicates changes toprocedure and schedule information to the ImageManager.

Results Information MessagesThe IHE technical framework facilitates thetransmission of DICOM structured reports to anenterprise report repository. To accommodate thewidest number of possible endpoints, reports arespecified as simple ASCII text; the use of specialformatting characters within the report is discour-aged.

Results received through DICOM structuredreports must be mapped to the HL7 standard. Ina number of cases, the data types and field widthsvary between the DICOM and HL7 standards.IHE provides a complete mapping of the fieldscommon to both formats.

Future Developments in HL7Although HL7 has been a successful standard byany measure, the implementation of each HL7interface involves substantial customization atconsiderable cost. In large measure, this customi-zation is the price for the flexibility that HL7 pro-vides. HL7 has evolved to meet the need for themany point-to-point connections present in thehealthcare enterprise. Like DICOM, HL7 doesnot dictate the internal organization of applica-tions, but only the meaning and format of com-munications between those systems. But unlikeDICOM, which operates in a much more limiteddomain, HL7 has no explicit information modelthat defines the relationships between the con-cepts in the various types of messages. There is aninformation model that is implied by the mes-sages, just as there is in natural language, but as innatural language there is considerable latitude forinterpretation. The Version 3 project, which be-gan in 1996, has undertaken to develop an ex-plicit information model common to all HL7messages: the reference information model(RIM). It is important to understand that theRIM does not model all of healthcare, but onlythe aspects that are common to the various appli-cation domains and need to be communicated.But even so, the scope of this modeling effort isimmense.

The lack of a common information model in-vites questions such as, “If I can fax a result to areferring physician, why can’t I fax a result to apatient?” (Answer: Because a fax number is anattribute of a physician, not of a patient.) TheRIM recognizes that physicians and patients areboth people, albeit in different roles, and thatboth may possess a fax number. Because they arederived from a common information model, thevarious Version 3 messages will have a greaterdegree of consistency. This greater consistencywill serve the aim of reducing the variability thatnecessitates extensive customization of presentHL7 interfaces. Further standardized compatibil-ity will ensue as internal data models of systemsevolve to become more compatible with the RIMand with Version 3 messaging (a natural result asdesigners adopt standard data models to simplifyinterfacing). This process will take many years,but its fruits will justify the years of developmentof Version 3.

In addition, Version 3 defines a developmentframework that specifies how messages are devel-oped from the RIM. Automated tools are beingdevised to make this process less arduous and er-ror prone.

The adoption of XML as the encoding syntaxfor HL7 Version 3 has attracted much attention.


It is important to understand that XML is a toolfor tagging text information and for working withtagged data, but it does not define the tags northeir meaning. HL7 provides these definitionsand uses XML as a tool for encoding them. XMLencoding will facilitate the communication andprocessing of HL7 messages with widely availablesoftware tools. A fair share of the HL7 develop-ment effort has gone into the adoption of XML,but that effort is dwarfed by the collective effort ofreconciling all messages to a common informa-tion model, the RIM.

Clinical Document ArchitectureAnother major development in HL7 is the clinicaldocument architecture (CDA). The CDA pro-vides an exchange model for clinical documents,which may include narratives, such as dischargesummaries, and structured consultation reports.The CDA employs the HL7 RIM, coded vocabu-laries, and XML to make documents that are leg-ible to both humans and machines. These docu-ments can be parsed and processed electronicallyand can still be retrieved and displayed by usingXML-capable Web browsers.

The CDA is called an architecture because itspecifies common characteristics of families ofdocuments rather than a specification based on asingle document schema. Implementation ofCDA occurs at three “levels.”

Level 1 of the CDA defines a document headerthat identifies the document, its version, its au-thor, whom it is about, and the clinical context(eg, encounter, location). Everything in the CDAheader is derived from the RIM. The body of thedocument contains basic text structures such assections, paragraphs, lists, and tables, but noRIM-derived content is specified (ie, the bodycontent is not standardized).

Level 2 assigns codes to document types and tostructures within the document body, enabling,for example, an insurance claim processor to ex-tract the diagnosis section from a report.

Level 3, which is expected to be completed in2002, will define the encoding of any RIM con-tent in a CDA document. Level 3 will specify themarkup of clinical content to the extent that it canbe expressed in the RIM. Thus, anything that canbe expressed in Version 3 messages can be en-coded in Level 3 CDA documents, althoughCDA documents may still contain text contentthat is not modeled in the RIM.

A key distinction of the CDA, as opposed toHL7 messaging, is its treatment of persistenceand paradigms for data management. Messagesare used to update databases, and of course data-bases can be designed and operated so as to pro-

vide persistent long-term storage, but the founda-tion on which databases operate is the mainte-nance of up-to-date information. Documentmanagement encapsulates information into per-sistent objects, which are archived until they arediscarded. A document may be superseded by alater version, but it cannot be changed. As such,document management is more focused on main-taining a collection of permanent records.

Clearly, both approaches have a role in healthinformation management. Persistent objects fa-cilitate the management of permanent records,whereas messages are better for updating dy-namic variables. The addition of the CDA to thetraditional HL7 messaging standards allows HL7to serve both needs.

Digital Imaging andCommunications in Medicine

There is probably not a radiologist in the worldwho does not know of DICOM. Many would saythat DICOM is a standard to communicate radio-logic images from acquisition devices to worksta-tions or a picture archiving and communicationsystem (PACS). This purpose was indeed theprime objective of DICOM in the late 20th cen-tury, but this is no longer the case.

DICOM at theClose of the 20th CenturyDICOM image transfer from a computed tomog-raphy, magnetic resonance imaging, computedradiography, radiofluoroscopy, angiography, ul-trasonography, nuclear medicine imaging, orpositron emission tomography device was a realityby the mid-1990s. This image transfer was thefirst dimension of DICOM. It made the DICOMstandard universally accepted in the radiologiccommunity and allowed the standard to extendrapidly to include cardiology and radiationtherapy. It is now poised to address the needs ofother medical imaging arenas such as microscopy,pathology, and ophthalmology. DICOM shouldno longer be viewed as a radiology-specific stan-dard. DICOM now includes, for example, specifi-cations for a variety of commonly used one-di-mensional waveforms, such as those used in car-diology or electrophysiology.

The second dimension of DICOM, which isalso widely accepted, addresses the network con-nection of print devices that produce film andother print media. Commonly called DICOM


Print, it is an important productivity tool that al-lows film and paper printers and other hard-copyimaging to be connected to a hospital network,not only within the radiology department but alsoin remote clinical areas.

The third dimension of DICOM concerns theinterchange of images on storage media such asmagneto-optical and CD-ROM disks. TheDICOM CD-R was particularly successful. Firstintroduced in angiography and cardiology as acost-effective and full-fidelity recording media toreplace traditional cine films, it is now increas-ingly used as an effective way to give patients theirimages for transfer between healthcare providers.With a simple DICOM viewer on the CD, anyreferring physician or even the patient can viewthe images on any personal computer. (Many freepublic domain DICOM image viewers exist; forexample, see www.psychology.nottingham.ac.uk/staff/cr1/dicom.html.)

The fourth dimension of DICOM arose fromthe recognition that the network integration needsof the imaging department required more thanthe electronic exchange of medical images. Imag-ing and work-flow management require that non-image information be exchanged between the im-aging devices and the information systems in thedepartment, notably the radiology informationsystem (ie, Department System Scheduler or Or-der Filler in IHE terminology) and increasinglythe PACS (the IHE Image Manager or ImageArchive). The first of these functionalities to bestandardized was the Modality Worklist serviceclass. This transaction transmits to the image ac-quisition device a variety of information such aspatient demographics, requested procedure, andscheduling information. This transfer of data al-lows a technologist at a modality to select the pa-tient or study information from a list of choicesand therefore reduces the chance of making a ty-pographic error in manually entering the sameinformation (however, errors in patient or studyselection can still occur). The Modality Worklistis now in broad use, and no enterprise of signifi-cant size can afford to operate in a digital environ-ment without it.

The DICOM Storage Commitment service classfollowed the DICOM Modality Worklist closely.Storage Commitment can be used to guaranteethat images will not be deleted from an acquisi-tion device unless another device (typically anarchive) takes ownership and responsibility forthe long-time care of the images.

DICOM in the 21st CenturyMore recently, DICOM introduced the PerformedProcedure Step service class that signals to the De-partment System Scheduler, Image Manager, andImage Archive that a scheduled step in the workflow has been completed. The signal includes keytracking information for the Image Manager orImage Archive and Department System Sched-uler, such as the list of images concerned anddose information. IHE has been instrumental inensuring that these three image management ser-vices (Modality Worklist, Storage Commitment,and Performed Procedure Step) become broadlysupported on modality workstations, PACS, andradiology information systems via the ScheduleWork Flow integration profile (9).

The fifth dimension of DICOM brings us backto images and their consistent display. In an envi-ronment of local, physical image production (ei-ther film-screen radiography or film printing), theimaging department can control image quality. Inan electronic environment in which images areprinted remotely or reviewed on far-flung work-stations, the consistency of gray-scale renderingbecomes an important issue. The techniques pre-viously used by the imaging department, notablythe cross-calibration of every image-renderingdevice against every image-generating source,cannot be extended to any significant size becauseof the cost and complexity of such a task.

DICOM provides a solution with the standard-ization of a gray-scale display function based onthe physiologic perception of luminance by thehuman eye (10). As a consequence of this stan-dardization, as soon as each sending or receivingdevice is independently calibrated against thisDICOM Gray-scale Display Function, pixel val-ues representing the actual gray-scale levels canbe perceived in a consistent manner independentof the luminance characteristics of the renderingdevice.

DICOM has extended the notion of gray-scalecalibration to include other manipulations, suchas flip, rotate, or zoom transformations and tex-tual or graphic annotations, such that a completedocumentation of how the image was presentedmay be made. DICOM (and therefore IHE)terms this a Gray-scale Presentation State, andthese states have been adopted as formal DICOMobjects.

There are a number of important scenarios forwhich precisely defined presentation states mightbe useful; for example, to make a record of theviewing conditions of an image at a specific pointin time, to transfer manipulations made on one


device to another device, and to ensure displayconsistency between a print composer and printer(although the latter uses an extension to DICOMPrint called Print Presentation Look-up Table). Inaddition, the Gray-scale Presentation State pro-vides a mechanism for optimizing the use of newDICOM objects for direct radiography and digitalmammography, both of which require that allsending and receiving systems to be calibrated.IHE has adopted these presentation services inthe IHE Consistent Presentation of Images inte-gration profile.

The sixth dimension of DICOM addressesreporting and measurement collection, includinglinks to the DICOM images from which thesereports and measurements are made. Called theDICOM Structured Reporting service class, thisDICOM component introduces a pragmatic andprogressive approach to coding and structure inreports. DICOM Structured Reporting objects,like the DICOM image objects, have the possibil-ity of being extremely complex. This potential forcomplexity is necessary to cover the wide range ofreporting applications. Just as the use of DICOMformatted images has taken a few years to addressall types of images, we expect DICOM Struc-tured Reporting to be adopted in stages.

DICOM Structured Reporting addresses theneed to electronically record measurements eitherdirectly at modality workstations or when themeasurements are integrated with viewing, analy-sis, and even computer-assisted diagnosis applica-tions. These DICOM reporting objects can alsobe used to capture informal notes that today arescribbled on tiny scraps of paper or image jackets.As tools to manage reporting codes and automaticreporting techniques, such as text templates, be-come more prevalent, DICOM Structured Re-porting should become a valuable format to sup-port more general radiology reporting, especiallyas it becomes more common to maintain linkswith key images and data mining applications.IHE begins the process of exploiting DICOMStructured Reporting in the IHE Simple Imageand Numeric Report integration profile.

The HL7-DICOMCommon Working GroupDICOM and HL7 are working together througha common working group, recognized by HL7 asthe Imaging Integration Special Interest Groupand by DICOM as Working Group 20. Thegroup monitors the IHE initiative and can supply

recommendations for changes in standards to theappropriate body, when changes are found neces-sary. The memberships of the Imaging Integra-tion Special Interest Group and Working Group20 also overlap with the membership of the IHETechnical Committee.

SummaryIHE is not a standard. It is an initiative that hasproduced a consensus document that serves as atechnical framework within which medical infor-mation systems can be designed to interact suc-cessfully to accomplish real-world tasks. IHE usesexisting standards as tools to achieve integration.Today, these tools are DICOM and HL7, whichare sufficient for the tasks described in the currentIHE integration profiles. As more integration pro-files and tasks are defined in other areas, otherstandards will be added as necessary.

References1. Radiological Society of North America Healthcare

Information and Management Systems Society.IHE technical framework, year 3, version 4.6. OakBrook, Ill: RSNA, March 2001.


3. Health Level Seven. Application protocol of elec-tronic data exchange in healthcare environments,version 2.4. Ann Arbor, Mich: HL7, October2000.

4. Channin DS, Chang PJ. Primer on computers andinformation technology. II. An introduction tocomputer networking. RadioGraphics 1997; 17:988–992.

5. Bosak J, Bray T. XML and the second-generationweb: the combination of hypertext and a globalInternet started a revolution. Sci Am 1999; 280:89–93.

6. American Medical Association. Current proce-dural terminology 2001. Chicago, Ill: AMA, 2001.

7. International Classification of Diseases, 9th revi-sion. Washington, DC: U.S. Department ofHealth and Human Services, 2001. Publication91-1260.

8. Huff SM, Rocha RA, McDonald CJ, et al. Devel-opment of the logical observation identifier namesand codes (LOINC) vocabulary. J Am Med In-form Assoc 1998; 5:276–292.

9. Channin DS. Integrating the healthcare enterprise:a primer. II. Seven brides for seven brothers: theIHE integration profiles. RadioGraphics 2001;21:1343–1350.

10. Barten PGJ. Contrast sensitivity of the human eyeand its effect on image quality. Bellingham, Wash:SPIE, 1999.


IHE PRIMER 1605

Integrating theHealthcare Enterprise:A PrimerPart 5. The Future of IHE1

David S. Channin, MD ● Eliot L. Siegel, MD ● Christopher Carr, MAJoyce Sensmeier, MS, RN, BC

IntroductionThe future of Integrating the Healthcare Enterprise (IHE) is you. All who are inter-ested in advancing integration of healthcare information to improve patient care arewelcome to participate in the IHE initiative. In particular, the stakeholders identifiedin a previous primer article (1)—the department chief or chairman, department man-ager or administrator, technologist, radiologist, nonradiologist clinician, chief infor-mation officer, imaging information system vendor, and nonimaging information sys-tem vendor—should actively participate in IHE efforts. In this article, we review thestructure of the IHE initiative, educational opportunities, the Year 3 demonstration,and how to specify and purchase IHE functionality. We also suggest other ways forthe stakeholders in medical informatics to participate.

Structure of the IHE InitiativeThe IHE initiative is organized into a set of committees, each of which has been givena specific role to play in making the initiative a success. The initiative is directed byan executive committee made up of senior members and senior staff members of thetwo (to date) sponsoring professional societies of the IHE, namely the RadiologicalSociety of North America (RSNA) and the Healthcare Information and ManagementSystems Society (HIMSS).

If you are a member or senior staff member of a professional healthcare-relatedsociety, you should be lobbying your society to become a sponsoring society of theIHE. Although there is a small financial burden to becoming a sponsoring society,there is a potential for a tremendous return on investment as the IHE expands tomeet the particular needs of your society and its membership. Studying the lessonslearned from the radiology examples and experience documented in these primer ar-ticles (1), as well as other reports, should help you identify analogous problem areasin your domain that could be addressed by expansion of the IHE initiative.

The IHE Executive Committee directs the Strategic Development Committee.This recently constituted committee consists of clinical and clinical informatics ex-perts from radiology, pathology, nursing, and internal medicine. There are also tech-

Abbreviations: DICOM � Digital Imaging and Communications in Medicine, HIMSS � Healthcare Information and Management Systems Soci-ety, HL7 � Health Level Seven, IHE � Integrating the Healthcare Enterprise

Index terms: Information management ● Radiology and radiologists, departmental management


1From the Department of Radiology, Northwestern University Medical Center, 448 E Ontario St, Suite 300, Chicago, IL 60611 (D.S.C.); Depart-ment of Diagnostic Imaging, University of Maryland School of Medicine, Baltimore (E.L.S.); Department of Informatics, Radiological Society ofNorth America, Oak Brook, Ill (C.C.); and Department of Professional Services, Healthcare Information and Management Systems Society, Chicago,Ill (J.S.). Received August 24, 2001; accepted August 29. Address correspondence to D.S.C. (e-mail: [email protected]).

©RSNA, 2001

nical representatives from the Electronic Com-munications Committee of the RSNA and theIHE Special Interest Group. The latter representschief information officers of major healthcare in-stitutions. The emeritus chairs of the IHE plan-ning committee are also included. Staff from theRSNA and HIMSS round out the committee.The committee is charged with identifying stepsin patient care work flow, recommending priori-ties of clinical and operational domains for IHEconsideration, identifying integration needs andbarriers (problems and solutions) within andacross domains, and lastly, helping to populatethe domain planning committees.

The domain planning committees (of whichthere is currently one [radiology] with others information) are responsible for filtering the prob-lem and solution sets from the Strategic Develop-ment Committee down to those sets that can real-istically be addressed by IHE. These committeesconsist of vendors and domain experts (eg, systemusers, administrators, hospital information systemexperts), and they direct parallel technical com-mittees to develop the solutions identified.

The technical committees are typically, al-though not exclusively, made up of vendor ex-perts. These experts are the unsung heroes of theIHE effort. These individuals spend (and theircompanies generously sponsor) an inordinateamount of time delving into the nitty-gritty detailof the integration to ensure that it works.

Last, and certainly not least, the IHE initia-tive has a technical project manager, Dr StevenMoore of the Mallinckrodt Institute of Radiologyat Washington University in St Louis, Missouri.Dr Moore and his team, working under subcon-tract from the RSNA and HIMSS, develop thetest software used by participants in the IHE con-nect-a-thon and demonstrations and managethese events. The software for the current year isavailable to only current participants in the con-nect-a-thon and demonstration. The small chargeto participate is typically trivial in comparison tothe value of the knowledge gained by the vendor,the value of participation in the connect-a-thon,and the value to the vendor’s products in comply-ing with the IHE technical framework. The soft-ware used in previous years’ demonstrations isavailable at no charge to the general public fromthe IHE Web site, www.rsna.org/IHE.

Educational ResourcesThere are numerous IHE educational resources.In addition to the demonstrations and work-shops at the annual meetings of both RSNA and

HIMSS, there are presentations and sessions onIHE-related topics at many medical and medicalinformatics meetings held throughout the year.

In addition to the current RadioGraphics seriesof primer articles (in the September-October2001 and November-December 2001 issues), theIHE Web site (www.rsna.org/IHE) has numerousother documents and PowerPoint presentationsthat can be used as educational materials. ThisWeb site is also home to the latest revision of theIHE technical framework (2), although somemight consider the framework to be graduate-level educational material. An IHE presentation isavailable through the HIMSS Web University atwww.himss.org. In addition, an IHE monographof relevant articles describing IHE functionality,solutions, and future directions will be publishedby HIMSS in early 2002.

Year 3 Demonstration:RSNA 2001 and HIMSS 2002

After participating in the connect-a-thon in earlyfall 2001, vendors will gather for public demon-strations of IHE integration at both the annualmeeting of the RSNA (November 25–30, 2001)and the annual meeting of HIMSS (January 27–31, 2002). After 2 years of rapidly expanding in-tegration capabilities, the IHE committees desig-nated Year 3 as a consolidation period: a time toeducate users about the solutions that IHE hasmade available to improve patient care, whilethese enhancements simultaneously becomebroadly available in commercial products. ForYear 3, the vendor demonstrations were rede-signed to communicate the clinical benefits avail-able through IHE and how to obtain them. Thedemonstration groupings will be organized by theseven IHE integration profiles (3): ScheduledWork Flow, Patient Information Reconciliation,Consistent Presentation of Images, Presentationof Grouped Procedures, Access to Radiology In-formation, Key Image Note, and Simple Imageand Numeric Reports. These integration profilesare discrete blocks of integration capability thatprovide specific enhancements to clinical prac-tice. Attendees at the demonstrations will beguided through the full sequence of integrationprofiles.

The demonstrations will be supplemented witheducational workshops targeted to the specificneed of clinicians, information technology andradiology administrators, systems implementers,and technical support staff. Of particular interestwill be sessions on clinical problems and solu-tions, with use of IHE to acquire integrated sys-tems, and on user perspectives from cliniciansand administrators whose institutions have imple-


mented IHE functionality. A kiosk that featuresan interactive video highlighting the IHE initiativewill also be available.

A full schedule of the demonstrations and edu-cational workshops at the RSNA annual meetingcan be found at www.rsna.org/IHE/ihedemo2001/.A similar schedule for the IHE demonstrationand related events at the HIMSS annual meetingcan be found at www.himss.org.

Professional societies and other organizationsinterested in incorporating components of thedemonstrations, workshops, and other presenta-tions into their societal events should contact rep-resentatives of the IHE initiative (see below). Aminiature speaker’s bureau is available, and thereare numerous IHE experts available to speak atother meetings.

How to Specify andPurchase IHE Functionality

Anyone involved in making information systempurchasing decisions at healthcare institutionsshould be well aware of the IHE initiative, theIHE information model, and the integration pro-files. A specific document, “IHE Profiles: Guide-lines for Buyers,” is available from the RSNAWeb site.

The IHE technical framework is a revision-controlled document that can be incorporated byreference into legal contracts. Although typically apurchase contract requires that equipment or ser-vices conform to standards, the contract can alsospecify compliance with the IHE technical frame-work. Thus, one can specify conformance to theHL7 and DICOM standards and additionallyrequire compliance with the IHE technical frame-work.

The role of radiology executives, radiology de-partment administrators, and senior managementin advancing the efforts of IHE by specifying IHEcompliance (and DICOM and HL7 conform-ance) in purchase contracts cannot be under-estimated. Although altruistic to a point, mosthealthcare information system vendors are drivenby marketing and sales organizations. Vendor en-gineering groups typically receive significant di-rection and guidance from these groups. If IHEcompliance and adherence to standards is notloudly and clearly communicated as being ofgreat importance to the user community, futureIHE engineering efforts may be diluted by per-ceived need to develop other functionality.

Vendors, on the other hand, will be thrilled toreceive uniform, loud and clear feedback fromtheir customers, especially when it leads to signifi-cant overall improvement in their products; low-ers the complexity (and therefore cost) of theirinterface development, deployment, and support;

and allows them to operate in a larger arena ofintegrated heterogeneous systems.

An important note to buyers: Beware the no-tion of purchasing a system that conforms to stan-dards (notably DICOM) and complies with IHE,yet in which these functionalities are not “turnedon” or in which “turning on” these functionalitiesrequires an additional cost. IHE, DICOM, andHL7 functionality should be on and runningwhen the system is installed and should be in-cluded in the base price of the system.

Future DirectionsThe IHE Strategic Development Committee is,as charged, expanding the model of integrated,scheduled work flow to include more patient carework flow processes. As new areas of integrationproblems between information systems are identi-fied, the committee will use the concept of inte-gration profiles to address them. The committeeis currently looking at pathology work flow, and atsuch enterprise-wide integration frustrations asdesktop integration, security (in light of forth-coming HIPAA [Health Insurance Portability andAccountability Act] requirements), and electronicmaster patient index issues. Other suggestions forfuture directions of IHE efforts are welcome.

How to Contact the IHETo learn more about IHE, please visit the IHEWeb site at www.rsna.org/IHE or search for theterm IHE at www.himss.org. To participate inIHE at any level, you should contact either JoyceSensmeier, Director of Professional Services, IHECoordinator, Healthcare Information and Man-agement Systems Society (HIMSS), 230 E OhioSt, Suite 500, Chicago, IL 60611-3269, or Chris-topher Carr, Director of Informatics, IHE Coor-dinator, Radiological Society of North America(RSNA), 820 Jorie Blvd, Oak Brook, IL 60523.

Comments, questions, concerns, and ideas canbe sent to the addresses above or electronically [email protected].

Call to ActionAnyone interested in realizing the dream of hav-ing all relevant patient information available to allcare providers on demand at the point of carewhile concomitantly reducing errors, reducingcosts, and increasing efficiency should be inter-ested in the IHE initiative and its future.

Chairmen should be studying the work flow intheir departments and identifying new ways thatIHE can assist them in improving these workflows by better integration of information. They


should identify clinicians in their departmentswith technical backgrounds or interests and en-courage and support them in participating in IHEcommittees. They should encourage studentsand residents in their departments to recognizehealthcare informatics as a legitimate area of re-search so as to foster the next generation of clini-cians capable of further advancing medical infor-matics technology. Together with departmentadministrators and senior institution managementincluding chief information officers, they shouldrequire standards conformance and IHE compli-ance in all relevant purchases.

Similarly, department administrators shouldconstantly look for work-flow problems in theirdepartments that IHE efforts could possibly rem-edy. These suggestions should be forwarded tothe IHE committees. As stated, administratorsshould demand IHE compliance and standardsconformance in all purchases. When purchasingnew equipment, they should consider not only thechemistry or physics and functionality of the de-vice but make a special effort to consider its infor-matics and how it fits into the work flow of andcommunicates with other systems in the depart-ment or institution.

In the trenches, technologists, radiologists, andclinicians should be documenting informationand work-flow problems they encounter in dailypractice. These problems should be forwarded tothe IHE committees. These individuals shouldnot be intimidated by a lack of technical expertise(remember, you don’t need to know how to forgeiron to use a hammer): The IHE initiative needsto identify clinically relevant problems to solve,and you can help. You should become active in

your professional societies, and if they are notparticipants in the IHE initiative, lobby them tojoin. You can also participate directly in the IHEcommittees. It is extremely interesting, educa-tional, rewarding, and even fun to participate inthese efforts. It is especially rewarding to see therapid incorporation of IHE efforts into real-worldproducts and the immediate benefit of IHE tech-nology in the clinical workplace.

Chief information officers and others in seniormanagement should lobby their professional soci-eties to join the IHE initiative. They should insistthat all their information system vendors partici-pate in the IHE effort, not just those involved indepartmental or specialty systems. There can nolonger be islands of information in a healthcareenterprise. All information systems must worksynergistically to get the job of delivering optimalhealthcare done.

Any vendor of a device that contains a com-puter of any sort should become involved in stan-dards bodies related to their domain. In addition,they should participate in the IHE initiative andencourage the inclusion of the appropriate stan-dards from their domain in the IHE toolbox.

There is a role for everyone in integrating thehealthcare enterprise. Got IHE?

References1. Channin DS, Parisot C, Wanchoo V, Leontiev A,

Siegel EL. Integrating the healthcare enterprise: aprimer. III. What does IHE do for me? Radio-Graphics 2001; 21:1351–1358.

2. Radiological Society of North America/HealthcareInformation and Management Systems Society.IHE technical framework, year 3, version 4.6. OakBrook, Ill: RSNA, March 2001.

3. Channin DS. Integrating the healthcare enterprise:a primer. II. Seven brides for seven brothers: theIHE integration profiles. RadioGraphics 2001; 21:1343–1350.


Documents

1339 Integrating the Healthcare Enterprise: A Primer