HOME HELP FEEDBACK SUBSCRIPTIONS ARCHIVE SEARCH TABLE OF CONTENTS		QUICK SEARCH:   [advanced] Author: Keyword(s): Year:  Vol:  Page:

This Article Abstract Figures Only Full Text (PDF) Submit a response Alert me when this article is cited Alert me when eLetters are posted Alert me if a correction is posted Services Email this article to a friend Similar articles in this journal Similar articles in PubMed Alert me to new issues of the journal Download to citation manager Citing Articles Citing Articles via HighWire Citing Articles via Google Scholar Google Scholar Articles by Channin, D. S. Search for Related Content PubMed PubMed Citation Articles by Channin, D. S. Related Collections Informatics

Integrating the Healthcare Enterprise: A Primer

Part 6: The Fellowship of IHE: Year 4 Additions and Extensions¹

¹ From the Department of Radiology, Feinberg School of Medicine, Northwestern University, 448 E Ontario St, Suite 300, Chicago, IL 60611. Received July 2, 2002; accepted July 8. Address correspondence to the author (e-mail: dsc@radiology.northwestern.edu).

	Abstract

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
Recently, one of my friends, a computer wizard, paid me a visit. As we were talking, I mentioned that I had recently installed a picture archiving and communication system and a radiology information system. I told him how happy I was with the system and showed him a compact disk (CD) from it. To my surprise, he threw it into my microwave oven and turned it on. Instantly I got very upset, because the System had become precious to me, but he said, "Do not worry, it is unharmed." After a few minutes, he took the CD out, gave it to me and said, "Take a close look at it." To my surprise, the CD was quite cold to hold and it seemed to be heavier than before. At first, I could not see anything, but on the inner edge of the central hole, I saw an inscription, an inscription finer than anything I had ever seen before. The inscription shone piercingly bright, and yet remote, as if out of a great depth:

12413AEB2ED4FA5E6F7D78E78BEDE8209450920F923A40Eel0E50CC98D444AA08E324

"I cannot understand the fiery letters," I said in a timid voice.

"No, but I can," he said. "The letters are Hex, of an ancient mode, but the language is that of DICOM, which I shall not utter here. But in common English, this is what it says:

Two integration profiles to schedule work flow

Five for radiology with room to grow

One for the bacon to bring it home

One for HIPAA all alone

And one for results for those who would know

One technical framework in which to find them

One technical framework to guide them

One technical framework to bring them all

And in the Connect-a-thon bind them

In the Land of Lincoln where no shadows are*

We continue the saga of the fellowship of the IHE: clinicians, radiologists, informaticians, administrators, technologists, imaging system vendors, and non–imaging system vendors, as they begin their year 4 transactions. ... [*With apologies to both Tolkien and the anonymous Internet folk from whom this is borrowed.]

© RSNA, 2002

Index Terms: Information management • Picture archiving and communication system • Radiology and radiologists, departmental management • Radiology reporting systems

	Introduction

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
The Integrating the Healthcare Enterprise (IHE) initiative is now in its fourth year. In accordance with the IHE process, two extensions were made to the Scheduled Work Flow integration profile and three new integration profiles were added to further improve integration of information systems in healthcare institutions.

The new profiles are Basic Security integration profile, Charge Posting integration profile, and Postprocessing Work Flow integration profile. The Basic Security integration profile provides a framework for beginning to provide information systems infrastructure that is suitable to start meeting security requirements of HIPAA (Healthcare Information Privacy and Accountability Act). This profile, therefore, addresses such issues as system authentication and audit trails. The Charge Posting integration profile allows for the departmental system to communicate directly and precisely with a billing system to improve the accuracy and timeliness of departmental charges while allowing the complexity of departmental activity to be hidden from the billing system. The Postprocessing Work Flow profile describes mechanisms to automate the distributed postprocessing of images, such as three-dimensional reconstruction and computer-aided detection.

The most recent public comment period on the expanded technical framework (three volumes, 450 pages and growing) ended in April 2002. A successful connect-a-thon was held in September 2002. These new and ongoing activities will be fully presented at the annual meeting of the Radiological Society of North America (RSNA) in December 2002 and at the annual meeting of Healthcare Information and Management Systems Society (HIMSS) in early 2003. Numerous other educational sessions will be held at other major medical conferences. Detailed descriptions of the seven integration profiles previously defined in the IHE technical framework have been published (1–6). This article reviews the fundamental concepts of the IHE effort and highlights the year 4 changes.

	What Is IHE?

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
IHE is an initiative designed to stimulate the integration of the information systems that support modern healthcare institutions. Its fundamental objective is to ensure that all required information for medical decisions regarding the care of patients is both correct and available to healthcare professionals, when and where necessary. To meet this objective, IHE provides:

1. Venues where users and vendors can meet to mutually agree on a common vocabulary by which humans and machines can unambiguously communicate integration information.
   
2. A technical framework that defines integration profiles (Figure). Each integration profile is a representation of a real-world capability supported by a set of actors that interact through transactions.
   
3. A "connect-a-thon" where vendors come together and test the compliance of their real-world systems to the IHE technical framework.
   
4. Public demonstrations and educational exhibits to explain IHE and its importance to healthcare enterprises. These demonstrations and exhibits take place at the annual meetings of the RSNA and HIMSS. Smaller educational sessions take place at numerous medical conferences throughout the year.
   

View larger version (38K): [in this window] [in a new window] [Download PPT slide]   Figure.  Diagram shows the 10 current IHE integration profiles.

	What Is IHE Not?

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
IHE is not a standard. Rather, IHE supports the use of existing standards in an integrated manner, defining configuration choices, and removing "wiggle room" when necessary. When clarifications or extensions to existing standards are necessary, IHE refers recommendations to the relevant standards bodies.

IHE is therefore an implementation framework, not a standard. Referencing IHE as a standard and claiming conformance to IHE are both inappropriate. Conformance claims must be made in direct reference to specific standards. Conformance statements may, however, state that the products they describe are "implemented in accordance with the IHE technical framework" or "in compliance with the IHE technical framework." Vendors should therefore make and customers should therefore expect statements such as "Product X supports the IHE XXX integration profile as the IHE a1, a2, and a3 actors."

	Year 4 Enhancements to Scheduled Work Flow

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
The Scheduled Work Flow integration profile is fundamental to the IHE model. This profile defines precisely the transactions necessary to accomplish basic operations in a patient-centric, service-oriented department such as radiology. It is useful to review the Scheduled Work Flow integration profile as it also provides a convenient context in which to understand the IHE information model and some of the IHE terminology.

The profile begins when an ADT (admission/discharge/transfer) Patient Registration actor registers a patient. This registration passes to the Order Placer actor and the Department System Scheduler or Order Filler (hereinafter, Order Filler) actor. An order for an imaging service is passed from the Order Placer to the Order Filler, and the Order Filler assigns an accession number to this order. The Order Filler maps the order to one or more requested procedures, and each requested procedure is mapped to a set of one or more scheduled procedure steps. Note that orders are related to the ordering healthcare provider. Requested procedures are the unit of work for the radiologist and represent a codifiable, billable set of acts that result in a report. The scheduled procedure steps are provided to the modalities as part of the DICOM Modality Work List. Scheduled procedure steps are, therefore, units of work for the technologist or radiologist at the modality workstation. The modalities send Performed Procedure Step messages back to the Image Manager and the Order Filler such that these actors know what is in progress, what has been done, and what has been canceled. The modalities store images and gray-scale presentation states, as necessary to the Image Archive actor, and they execute a storage commitment transaction with the Image Manager. The Order Filler can query the Image Manager to determine image availability, and the Order Filler can notify the Order Placer when the order has been completed.

The Patient Information Reconciliation integration profile complements the Scheduled Work Flow profile by handling scenarios in which patient information is unavailable when needed (eg, John Doe, Trauma) or when actors (information systems) in the scheduled work flow process are unavailable.

In year 4, IHE has introduced two important extensions to the Scheduled Work Flow integration profile. Although they are optional with respect to implementation in year 4, users should understand the importance of these new options and insist on their presence in information systems being purchased.

The first, Exception Management Work Flow handles variants of two scenarios: (a) selection of the incorrect scheduled procedure step from the modality work list and (b) management of the consequences of having performed a procedure step other than the one that was scheduled. The former scenario typically arises from human error, whereas the latter arises when a technologist tailors a study to a given patient. In an electronic, integrated world, there must be a mechanism to inform downstream information systems of what has occurred. The downstream information systems must then be given enough information to automatically reconcile the differences. In the absence of this automatic reconciliation, manual error management can itself be fraught with inefficiency and further errors.

The second work flow enhancement, also of great potential value, is the Acquisition Protocol Setting option. The Acquisition Protocol Setting option affects primarily the Acquisition Modality, Order Filler, Image Manager, and Performed Procedure Step Manager actors. By using this extension, modality work list provides the modality in each scheduled procedure step with one or more protocol codes that indicate the precise procedure plan to be executed. The modality workstation maps the protocol code(s) to machine protocols. The technologist operating the modality workstation then has the option of either accepting the automatic mapping, modifying the automatic mapping, or overriding the mapping and making a manual selection dependent on the capabilities of the device. The importance of this extension lies in the fact, that regardless of the choice made by the technologist, the Image Manager and Order Filler will be properly informed in the performed procedure step message as to what choice was made and precisely what work (codified) was performed.

The IHE technical framework specifies that "the involved actors, Department System Scheduler, Acquisition Modality, Image Manager/Archive shall be configurable in order to support the codification scheme selected or defined by the healthcare enterprise." The importance of this codification cannot be underestimated. By investing in the creation of a "playbook," an institution can use the transactions of the Scheduled Work Flow integration profile with the Acquisition Protocol Setting option to manage in an automated fashion how procedures are performed across differing models of a modality from possibly different vendors. In addition, sites can reduce the variance in how procedures are performed across the department and across staff.

Perhaps most important, the site can map from performed procedure steps (with their performed protocol information) to Common Procedure Terminology (CPT) codes to provide for very accurate billing. Rather than capture CPT information at the time of order entry or at the time of scheduled procedure step and then reconcile (perhaps manually) postprocedure billing and coding, one can use the performed procedure step information to directly code the CPT information. This directly derived CPT information can then be used in the Charge Posting integration profile, also a year 4 integration profile.

	Charge Posting Integration Profile

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
The Charge Posting integration profile details standardized messages sent from the Order Filler to describe charges for procedures. These messages are based on HL7, version 2.3 transactions. Specifically, a charge processor (not defined by IHE) will receive ADT information from the ADT Patient Registration actor. The charge processor will then receive an HL7 Detailed Financial Transaction message from the Order Filler. IHE adopts the HL7 model of the real world for these transactions, in that (a) financial data related to the patient are accumulated as properties of accounts, (b) patients may have more than one active (open) account at a time, and (c) one account may contain financial data pertaining to more than one visit but a visit cannot span multiple accounts. Note that each site and each vendor’s implementation may, in accordance with applicable regulations, decide when each type of charge gets posted. As noted, the requested procedure is the unit of work for the radiologist that is codifiable and billable. The technical component and professional component could, however, be posted at different times in the work flow process.

The Charge Posting integration profile allows for the hospital’s billing system to be oblivious to the details of the radiologic work flow processes, yet the billing system can be accurately advised of charges to be applied. The Order Filler system uses information from the order, the scheduled and performed procedure steps, and any manually or semiautomatically processed information within the Order Filler system to provide this precise information.

	Postprocessing Work Flow Integration Profile

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
The Postprocessing Work Flow integration profile describes mechanisms to automate the distributed postprocessing of images, such as three-dimensional reconstruction and computer-aided diagnosis or detection (CAD). Current three-dimensional reconstruction and CAD systems typically integrate poorly into the work flow of radiology departments. Such systems are often implemented as stand-alone workstations, and the data sets must be manually stored to the workstations or DICOM Query/Retrieved from the Image Manager/Image Archive (PACS). The technologist then performs his or her portion of the postprocessing work at the stand-alone workstation, followed by the radiologist, and perhaps followed by a referring physician. In addition to this poor human work flow and the inefficient use of a stand-alone workstation, the work flow is hampered since it is often poorly coordinated as to when the postprocessing must be completed and what type of postprocessing (ie, three-dimensional reconstruction or CAD) was actually performed.

In creating the Postprocessing Manager actor, IHE creates the possibility of providing postprocessing work lists to Image Creator actors. The Image Creator actors, such as three-dimensional reconstruction workstations or CAD processors, now "know," much as Acquisition Modalities "know" via modality work lists that there is work for them to do.

Consider the following hypothetical scenario for CAD with mammography. When the Performed Procedure Step Manager receives a performed procedure step complete message from a digital mammography workstation for a screening mammography examination, it could notify the Postprocessing Manager to create a postprocessing work list for the CAD Image Creator actor. The CAD Image Creator queries the work list from the Postprocessing Manager, "claims" work list items, and retrieves the appropriate identified images from the Image Manager. The CAD Image Creator processes the images and sends updates on postprocessing status to the Postprocessing Manager. When finished, the CAD Image Creator can send its results, either images or "evidentiary documents" to the Image Manager for storage. The term evidentiary document is used to denote non-image DICOM objects (eg, DICOM Structured Reporting objects) that can be stored as part of a study. Note that the Postprocessing Manager must be grouped with either the Image Manager or the Order Filler and that there are provisions for notifying (via an IHE performed work status update transaction) either actor of precisely what has been performed. The Order Filler can then use this information to post charges as appropriate and as previously described. Again, the billing is precise in that it is based on performed work.

	Basic Security Integration Profile

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
The security measures defined in the Basic Security integration profile include user and node authentication as well as generation of audit transactions. To support these transactions, the IHE framework defines a new actor, the Secure Node. A Secure Node actor is grouped with other actors wishing to participate in transactions under the auspices of Basic Security. These actor/Secure Node pairs are further grouped into secure domains.

The Secure Node actor is responsible for managing the authentication process between itself and its partner and another IHE actor/Secure Node pair. A user, for example, might log in to a review workstation that implements the Image Display actor combined with a Secure Node actor. How the user is authenticated to the workstation is left to the site and the vendor to decide. Once identified to the Image Display/Secure Node pair, the user could, for example, request images from an Image Manager/Secure Node pair. The two Secure Node actors in this example would then perform an IHE-specified transaction to authenticate that these two systems are indeed permitted to interact.

At each step in the authentication process, audit record transactions are being generated to another new actor, the Audit Record Repository. In addition to providing for audit transactions for these authentication procedures, IHE defines 39 transaction and nontransaction events that trigger audit record transactions by various actor/Secure Node pairs.

For the audit transactions from heterogeneous information systems to have a consistent date and time stamp, IHE has also chosen to adopt the well-known and widely implemented Network Time Protocol as a transaction with which to synchronize the clocks on the various information systems.

	Conclusions

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 
In year 4, IHE has expanded both horizontally and vertically. Horizontally, IHE has added to the infrastructure that will facilitate the extension of IHE to areas outside radiology. The integration profiles of Scheduled Work Flow and Patient Information Reconciliation are more robust. The Basic Security, Charge Posting, and Access to Radiology Information profiles not only apply themselves across the institution but also serve as models for how to further develop horizontal infrastructure in the future.

Vertically, within radiology, there is near complete encircling of the radiologic work flow process. Next year’s additions and enhancements, already under discussion, should come close to bringing the entire radiologic work flow process within the bounds of the IHE initiative.

IHE functionality is becoming available in products now coming into clinical use. As the implications of these "IHE successes" become better understood, there is the potential to see a return on investment based on improved service to patients and referring physicians. In examining the year 4 additions in the context of the previous IHE work, the potential for marked improvements in work flow efficiency and therefore further return on investment in information systems is beginning to become apparent.

In year 4, the continued success of IHE depends on users demanding this functionality from imaging and nonimaging information system vendors. The vendors understand the theoretic advantages of providing this functionality but need persistent and consistent user feedback to encourage further development of IHE functionality.

Lastly, the IHE needs user participation in the strategic, technical, and planning committees, both within radiology and in other areas under development. As always, further information may be obtained online at www.rsna.org/IHE. Got IHE?

	Acknowledgments

 
The author thanks the members of the IHE strategic development, technical, and planning committees and the numerous coauthors of the IHE technical framework from which significant content is adapted.

	Footnotes

 
Abbreviations: ADT = admission/discharge/transfer, CAD = computer-aided diagnosis or detection, DICOM = Digital Imaging and Communications in Medicine, HIMSS = Healthcare Information and Management Systems Society, HL7 = Health Level 7, IHE = Integrating the Healthcare Enterprise

	References

Top Abstract Introduction What Is IHE? What Is IHE Not? Year 4 Enhancements to... Charge Posting Integration... Postprocessing Work Flow... Basic Security Integration... Conclusions References

 

1. Siegel EL, Channin DS. Integrating the Healthcare Enterprise: a primer. 1. Introduction. RadioGraphics 2001; 21:1339-1341.
2. Channin DS. Integrating the Healthcare Enterprise: a primer. 2. Seven brides for seven brothers: the IHE integration profiles. RadioGraphics 2001; 21:1343-1350.
3. Channin DS, Parisot C, Wanchoo V, Leontiev A, Siegel EL. Integrating the Healthcare Enterprise: a primer. 3. What does IHE do for ME? RadioGraphics 2001; 21:1351-1358.
4. Henderson M, Behlen FM, Parisot C, Siegel EL, Channin DS. Integrating the Healthcare Enterprise: a primer. 4. The role of existing standards in IHE. RadioGraphics 2001; 21:1597-1603.
5. Channin DS, Siegel EL, Carr C, Sensmeier J. Integrating the Healthcare Enterprise: a primer. 5. The future of IHE. RadioGraphics 2001; 21:1605- 1608.
6. Vegoda PR, ed. HIMSS target issues: Integrating the Healthcare Enterprise Chicago, Ill: HIMSS, 2001.
7. Internet Engineering Task Force web site. BSD Syslog Protocol, RFC 3164. Available at http://www.rfc-editor.org. 2002; Accessed July 23.
8. Internet Engineering Task Force web site. Network time protocol (NTP) version 3. RFC 1305. Available at http://www.rfc-editor.org. 2002; Accessed July 23.
9. Internet Engineering Task Force web site. Transport layer security (TLS) version 1.0 (RFC 2246). Available at http://www.rfc-editor.org. 2002; Accessed July 23.
10. International Telecommunication Union web site. ITU recommendation x.509: public-key and attribute certificate frameworks. Available at http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/. 2002; Accessed July 23.

This article has been cited by other articles:

				N. Hara, M. Onoguchi, T. Nishida, M. Honda, O. Houjou, M. Yuhi, T. Takayama, and J. Ueda Considerations for Setting Up an Order Entry System for Nuclear Medicine Tests J. Nucl. Med. Technol., December 1, 2007; 35(4): 259 - 271. [Abstract] [Full Text] [PDF]

This Article Abstract Figures Only Full Text (PDF) Submit a response Alert me when this article is cited Alert me when eLetters are posted Alert me if a correction is posted Services Email this article to a friend Similar articles in this journal Similar articles in PubMed Alert me to new issues of the journal Download to citation manager Citing Articles Citing Articles via HighWire Citing Articles via Google Scholar Google Scholar Articles by Channin, D. S. Search for Related Content PubMed PubMed Citation Articles by Channin, D. S. Related Collections Informatics