ihe: a model for driving adoption of standards

IHE: a model for driving adoption of standards

Christopher D. Carra,*, Stephen M. Mooreb

aRadiological Society of North America, Oak Brook, IL, USAbMallinckrodt Institute of Radiology, St Louis, MO, USA

Received 15 July 2002; accepted 25 August 2002

Abstract

The development of communication standards in healthcare is a major ongoing engineering effort. While there is little doubt that this effort

has made possible significant advances in the performance of healthcare information and imaging systems, overall levels of systems

interoperability have not improved as dramatically as one might reasonably expect and the cost of implementing effectively integrated

systems remains high. The lag between the development of information standards and their implementation in real systems and institutions is

a genuine problem in healthcare. This paper describes an ongoing initiative that attempts to bring together healthcare professionals and

industry experts to coordinate the implementation of standards in ways that enhance operational efficiency and the quality of patient care.

q 2002 Elsevier Science Ltd. All rights reserved.

Keywords: Radiology; Informatics; Integration; Systems; Standards; Industry; Medical associations; Picture archiving and communication system; Modalities;

Workflow; Presentation consistency; Structured reporting; Charge posting; Security; Post-processing

1. Introduction

Despite the fact that great progress has been made in

developing data communication standards in healthcare—

notably, DICOM and HL7—the level of interoperability

among systems in most healthcare institutions remains

frustratingly low.

By intention and by consequence of the process through

which they are created, these standards often describe an

information architecture somewhat more general and

abstract than that required by engineers designing and

implementing systems. They may leave issues open to

interpretation or provide a range of choices to the

implementer.

Consequently, it frequently requires a major effort to

achieve significant integration of multiple systems—even

when all the systems involved comply with established

standards. Moreover, there is not a reliable way for

professionals seeking to acquire or upgrade systems to

specify a level of adherence to communication standards

sufficient to achieve truly efficient interoperability. There is

not a clear road map from the vast body of technical

information assembled by standards groups to its

application in solving specific clinical problems. A gap

persists between the establishment of standards to make

interoperability possible and the actual implementation of

integrated systems [1].

The integrating the healthcare enterprise (IHE) initiative

was established to help bridge that gap [2]. The IHE process

provides an organized way for healthcare professionals to

communicate to industry the integration capabilities they

need in order to work efficiently in providing optimal patient

care. Representatives of imaging and information systems

companies develop and document a consensus implemen-

tation of established communication standards to provide

those capabilities.

Their selections are recorded in the IHE Technical

Framework, a detailed and freely available implementation

resource. A testing process enables refinement of both the

documented information model and each participating

vendor’s implementation of the relevant pieces of it.

Demonstrations and educational sessions disseminate infor-

mation about the process and provide tools for purchasers to

use in acquiring systems with specific integration

capabilities.

Overall, the process helps to build a market for

standards-based integration by supplying incentives, edu-

cation and tools for both providers and purchasers. It defines

an iterative cycle of activity leading to a significant result

0895-6111/03/$ - see front matter q 2002 Elsevier Science Ltd. All rights reserved.

doi:10.1016/S0895-6111(02)00087-3

Computerized Medical Imaging and Graphics 27 (2003) 137–146

www.elsevier.com/locate/compmedimag

* Corresponding author. Tel.: þ1-630-368-3739; fax: þ1-630-571-7837.

E-mail address: [email protected] (C.D. Carr).

http://www.elsevier.com/locate/compmedimag

point (testing and public demonstration) and creates a

feedback loop for the design, testing and implementation of

standards-based integration solutions (Fig. 1).

1.1. Goals of systems integration

The healthcare enterprise is understood to consist of a

complex of facilities and care providers necessary to

perform diagnosis and treatment across the spectrum of

patient care. An increasingly vital element of this complex

is an interconnected array of information systems that

acquire, process, store and distribute data required for

diagnosis and care, as well as the associated administrative

and financial processes.

For practical and historical reasons these information

functions have evolved as discrete units, each addressing

particular aspects of the overall data architecture. Connec-

tions among these systems have developed less rapidly,

leading to a situation that can be described as ‘islands of

data’, wherein much information acquired in the process of

care is accessible only within a department or subunit of a

department and no comprehensive view of all the infor-

mation relevant to a given patient’s care is possible.

IHE is organized to identify barriers to information

sharing that can be removed through the coordinated

application of established standards. Priority is given to

improvements that will provide the greatest benefit for

clinical care. It is anticipated that the work done under IHE

will enable institutions to acquire integrated systems less

expensively and more conveniently. One desired outcome

of the activity is to contribute to the development of an

overall information and communications infrastructure

sufficient to give real substance to the concept of an

electronic patient record. The broader goal is to make all

relevant patient information available to care providers as

needed to support optimal patient care.

1.2. History

The Radiological Society of North America (RSNA)

held initial meetings with interested parties in the summer of

1997 to collect ideas about the process of a more unified

approach to an integrated healthcare information infrastruc-

ture. Further discussion between the RSNA and the

Healthcare Information and Management Systems Society

(HIMSS) led to a joint project initially sponsored by the two

organizations. This 5-year program would involve collab-

oration between the professional societies and equipment

vendors with the end goal of producing commercial

solutions that offer significantly enhanced information

sharing capabilities.

The RSNA and HIMSS convened a group of imaging and

information systems vendors in the fall of 1998. Organiz-

ational meetings held to design a process for collaboration

produced two clear results. The organizational structure was

defined (and will be discussed in Section 1.3). The second

result was a policy decision that this group would not

become a standards organization, but rather would commit

itself to clarifying how existing standards can be used to

promote systems integration. Rather than competing with

the already well-established standards efforts in healthcare,

IHE would work in ways complementary to them, driving

their adoption in commercial products and providing a

feedback loop for their further development and refinement.

1.3. Organization

Four separate committees were organized to guide this

process. The Strategic Committee consists of a small

number of vendor representatives (past chairs from other

IHE committees) and RSNA and HIMSS staff and board

members. This committee provides oversight to the other

committees and provides longer-range advice on the

direction of IHE (such as new technologies to pursue).

The Review Committee consists of HIMSS and RSNA

staff and board members. This group defines the rules of

participation for vendors and intervenes in issues and

conflicts involving the competitive interests of participating

vendors.

The Planning Committee consists of vendor representa-

tives, with oversight from HIMSS and RSNA membership

and logistical and secretarial support by HIMSS and RSNA

staff. The Planning Committee determines the general scope

of technical tasks to be completed each year, prioritizing

them based on input from RSNA and HIMSS membership.

It also outlines IHE demonstration and educational

programs.

The Technical Committee consists of technical repre-

sentatives from the vendor community, again with oversight

from the HIMSS and RSNA membership and support by

staff. This group takes the integration goals defined by the

Planning Committee and produces the detailed documen-

tation—the IHE Technical Framework—that specifies the

standards-based transactions required to achieve these

goals.

A final element in the structure has been the retention of a

technical project management team to oversee the testing

and demonstration process. The responsibilities of this team

Fig. 1. Overview of IHE process.

C.D. Carr, S.M. Moore / Computerized Medical Imaging and Graphics 27 (2003) 137–146138

have included development of software testing tools,

organization and supervision of face-to-face testing events,

and management of the vendor demonstrations. For the first

3 years of the initiative, the Electronic Radiology Labora-

tory at the Mallinckrodt Institute of Radiology, Washington

University, St Louis has played this role, under contract to

RSNA and HIMSS.

1.4. IHE technical framework

The IHE Technical Framework is a description of how to

apply existing standards to solve system integration

problems. Version 5.0 of the framework is available on

the RSNA web site at http://www.rsna.org/IHE. The two

volumes of the framework use the HL7 and DICOM

standards to describe solutions for specific integration issues

(Fig. 2).

The Technical Framework defines and makes use of

several key concepts.

† A data model, adapted from HL7 and DICOM, which

shows the relationships between the key frames of

reference (e.g. Patient, Visit, Order, Study) defined in the

framework.

† The concept of IHE Actors, which allows systems in the

enterprise to be described in generic, product-neutral

terms. Actors exchange messages to achieve specific

tasks. A commercial system may incorporate one or more

IHE Actors.

† The organization of the functionality described into

discrete units, known as Integration Profile. These

higher-level views of IHE functionality consist of a set

of Actors and transactions required to address a

particular clinical need. For example, the Scheduled

Workflow Integration Profiles incorporates all of the

process steps involved in performing a radiological

procedure in a typical scheduled patient encounter,

starting with patient registration and continuing through

ordering, image acquisition and image viewing. As of the

2002–2003 cycle of implementation and testing, IHE has

defined ten Integration Profiles. Their number will grow

over time.

The Technical Framework documents in detail the

transactions between Actors. For example in Figs. 3 and 4,

Transaction 1, Patient Registration, describes the HL7 ADT

messages sent for particular registration or admission

processes. Transaction 2, Placer Order Management

(ORM), describes the HL7 ORM messages that are sent

from an Order Placer (Hospital Information System) to an

Order Filler (Radiology Information System). For each

transaction, the Technical Framework defines the scope of

the transaction, presents its use-case, enumerates the Actors

involved in the transactions and their respective roles,

diagrams the interactions of the Actors, lists each event

involved and provides detailed message semantics.

In defining individual transactions, the Technical Frame-

work often strengthens the requirements defined in a

standard for the attributes in a message, usually by

mandating the presence of, or a specific values for, attributes

that might be optional or unspecified in the referenced

standard. By mandating the values of certain attributes, the

Technical Framework allows peer applications to commu-

nicate more dependably and perform at a higher level of

Fig. 2. Organization of Information in the IHE Technical Framework.

C.D. Carr, S.M. Moore / Computerized Medical Imaging and Graphics 27 (2003) 137–146 139

http://www.rsna.org/IHE

interoperability without custom, on-site interface

development.

The Technical Framework also provides important

mappings from the messages in one domain to another.

For example, HL7 describes order messages via ORM

messages. DICOM describes a worklist procedure that

allows a modality to query an information system for

procedure information. The Technical Framework defines

an explicit mapping from the data in the HL7 ORM message

to the data supplied in the DICOM query response by the

information system. This consistent mapping should

provide for smoother systems integration between commer-

cial Radiology Information System and Modalities.

1.5. IHE Integration Profiles

IHE Integration Profiles provide a common language for

purchasers and vendors to discuss integration needs of

healthcare enterprises and the integration capabilities of

products. They are particularly useful for writing the

integration portions of purchasing specifications. The goal

for most healthcare organizations is to implement practical

capabilities such as distributed access to diagnostic images

or smooth departmental workflow. Integration Profiles

allow communication about those high-level capabilities

while referencing the underlying technical precision

necessary to make them work. They give purchasers a tool

that reduces the difficulty, cost and anxiety associated with

implementing integrated systems.

IHE Integration Profiles organize and leverage the

integration capabilities that can be achieved by coordinated

implementation of communication standards. They do not

replace conformance to standards, and users are encouraged

to continue to request that vendors provide statements of

their conformance to relevant standards, such as DICOM

and HL7. Integration Profiles rather provide a more precise

definition of how standards are implemented. This

implementation of standards is supported by the industry

partners involved in the initiative, carefully documented,

reviewed and tested in circumstances where multi-vendor

integration must be achieved in a tightly compressed time

frame.

Each of the ten Integration Profiles defined by IHE thus

far addresses a specific information management problem to

answer a specific clinical need.

1.6. Scheduled workflow

The scheduled workflow (Fig. 5) Integration Profiles

establishes a seamless flow of information that supports

efficient patient care workflow in a typical imaging

encounter. It specifies transactions that maintain the

consistency of patient information from registration through

ordering, scheduling, imaging acquisition, storage and

viewing. This consistency is also the foundation for

subsequent workflow steps, such as reporting. Systems

involved in this profile are

† Enterprise-wide information systems that manage patient

registration and services ordering (i.e. admit–discharge–

transfer (ADT)/registration system and HIS.

† Radiology departmental information systems that man-

age department scheduling (i.e. radiology information

system (RIS))and image management/archiving (i.e.

picture archiving and communication system (PACS)).

† Acquisition modalities.

1.7. Patient information reconciliation (Fig. 6)

This Integration Profiles extends Scheduled Workflow by

providing the means to match images acquired for an

unidentified patient (for example, during a trauma case)

with the patient’s registration and order history. In the

example of the trauma case, this allows subsequent

reconciliation of the patient record with images acquired

Fig. 3. Sample IHE use-case diagram.

Fig. 4. Sample IHE interaction diagram.


(either without a prior registration or under a generic

registration) before the patient’s identity could be deter-

mined. Enabling this after-the-fact matching greatly sim-

plifies these exception-handling situations. Systems

involved in this Integration Profiles are

† Enterprise-wide information systems that manage patient

registration and services ordering (ADT/registration

system, HIS).


age department scheduling (RIS) and image manage-

ment/archiving (PACS).


1.8. Consistent presentation of images (CPI)

The CPI Integration Profiles (Fig. 7) specifies a number

of transactions that maintain the consistency of presentation

for grayscale images and their presentation state infor-

mation (including user annotations, shutters, flip/rotate,

display area, and zoom). It also defines a standard contrast

curve, the Grayscale Standard Display Function, against

which different types of display and hardcopy output

devices can be calibrated. Thus it supports hardcopy,

softcopy and mixed environments.

The systems included in this profile are hospital-wide

and radiology-department image rendering systems such as

Fig. 5. Scheduled workflow.

Fig. 6. Patient information reconciliation.


† Review or diagnostic image softcopy display stations

(stand-alone or integrated with a HIS, RIS or PACS).

† Image management and archiving systems (PACS).

† Hardcopy image producing systems on various media

such as film or paper.


1.9. Presentation of grouped procedures (PGP)

The PGP Integration Profiles (Fig. 8) addresses the

complex information management problems entailed when

information for multiple procedures is obtained in a single

acquisition step (for example CT of the chest, abdomen and

pelvis). PGP provides the ability to view image subsets

resulting from a single acquisition and relate each image

subset to a different requested procedure. A single acquired

image sets produced, but the combined use of scheduled

workflow and consistent presentation of images transactions

allows separate viewing and interpretation of the subset of

images related to each requested procedure. Among other

benefits, this allows generating reports that match local

billing policies without additional intervention.

The PGP Integration Profiles extends the Scheduled

Workflow Integration Profiles and the Consistent Presen-

tation of Images Integration Profiles. Systems involved

include




age department scheduling (RIS).

† Diagnostic image softcopy display stations (integrated

with a RIS or a PACS).

1.10. Access to radiology information

The access to Radiology Information Integration Profile

(Fig. 9) specifies support of a number of query transactions

providing access to radiology information, including images

and related reports. Such access is useful both to the

radiology department and to other departments such as

pathology, surgery and oncology. Non-radiology infor-

mation (such as lab reports) may also be accessed if made

available in DICOM format.

This profile includes both enterprise-wide and radiology-

department imaging and reporting systems such as

† Review or diagnostics image softcopy display stations

(stand-alone or integrated with a HIS, RIS, PACS or

Modality).

† Reporting stations (stand-alone or integrated with a HIS,

RIS, PACS or Modality).


† Report repositories (stand-alone or integrated with a HIS,

RIS or PACS).

1.11. Key image note

The Key Image Note Integration Profile (Fig. 10)

specifies a transaction that enables a user to flag as

Fig. 7. Consistent presentation of images.

Fig. 8. Presentation of grouped procedures.


significant one or more images in a study by referencing

them in a note linked with the study. This note includes a

title stating the purpose of the flagged images and a user

comment field. These notes will be properly stored, archived

and displayed as the images move among systems that

support the profile. Physicians may attach key image notes

to images for a variety of purposes: referring physician

access, teaching files selection, consultation with other

departments, and image quality issues, to name a few.

This Integration Profiles includes both the department

imaging systems and the hospital-wide image distribution

such as



modality).



1.12. Simple image and numeric report

The simple Image And Numeric Report Integration

Profiles (Fig. 11) facilitates the growing use of digital

dictation, voice recognition, and specialized reporting

packages, by separating the functions of reporting into

discrete actors for creation, management, storage and

viewing. Separating these functions while defining trans-

actions to exchange the reports between them enables a

vendor to include one or more of these functions in an actual

system.

The reports exchanged have a simple structure: a title; an

observation context; and one or more sections each with

Fig. 9. Access to Radiology Information.

Fig. 10. Key image note.


a heading, text, image references, and, optionally, coded

measurements. Some elements can also be coded to

facilitate computer searches. Such reports can be input to

the formal radiology report, thus avoiding reentry of

information.

This Integration Profile involves both the department

imaging and reporting systems and the hospital-wide

information systems such as



Modality).

† Reporting stations (stand-alone or integrated with a HIS,

RIS, PACS or Modality).

† Report management systems (standalone or integrated

with a HIS, RIS, PACS or Modality).

† Report repositories (stand-alone or integrated with a HIS,

RIS or PACS).

1.13. Basic security (SEC)

The Basic Security Integration Profiles establishes

security measures which, together with the Security

Policy and Procedures of the enterprise, provide patient

information confidentiality, data integrity and user

accountability. The goals of the Basic Security Inte-

gration Profile are

1. User accountability. To allow security officer in an

institution to audit activities, to detect non-compliant

behavior in the enterprise, and to facilitate detection of

improper creation, access, modification and deletion of

protected health information (PHI). PHI is considered to be

the information records (Registration, Order, Study/Proce-

dure, Reports and to a lesser degree Images/Presentation

States), not the flow of information (IHE transactions)

between the systems. This includes information exported to

and imported from every secured node in the ‘secured

domain’.

The audit trail contains information so that questions can

be answered such as

† For some user: which patients’ PHI was accessed.

† For some patient PHI: which users accessed it.

† What failed user authentication.

† What failed node authentication.

2. Access control. To limit access to all ‘secured nodes’

in a ‘secured domain’ (defined as a set of cross-connected

secured nodes) to ‘authorized users’.

3. Centralized audit record repository. To provide

central Audit Record repository as the simplest means to

implement security requirements. An immediate transfer

of Audit Records from all the IHE Actors to the Audit

Record repository is required, reducing the opportunities

for tampering and making it easier to audit the

department.

4. PHI data integrity. To allow tracking of the life of PHI

information (creation, modification, deletion and location).

The key features of the Basic Security Integration Profile

are the following

† Authentication of the user.

† Authentication of the node.

† Audit record generation.

1.14. Charge posting (CHG)

The Charge Posting Integration Profile specifies infor-

mation exchange from the Department System Scheduler/

Order Filler to the Charge Processor about charges

associated with particular procedures, as well as communi-

cation about patient demographics, accounts, insurance, and

guarantors between ADT Patient Registration and Charge

Processor. The Charge Posted Transaction contains some

information to generate a claim. Currently, these interfaces

contain fixed field formatted or HL7-like data. The goal of

including this in the IHE Technical Framework is to

standardize interface between clinical systems and the

Charge Processors. Additionally, the Charge Posted Trans-

action reduces the need of the billing system to have

knowledge of the radiology internals. The result is that the

Charge Processor will receive more complete, timely and

accurate data.

Fig. 11. Sample simple image and numeric report.


The Department System Scheduler/Order Filler indicates

to the Charge Processor that procedures are available for

TECHNical and/or Professional Billing. The Charge Posted

transaction may occur at various times in the workflow.

Regulations and site operating procedures determine when a

procedure is eligible for Charge Posting. Often, the events

are different for technical and professional charges. Techni-

cal charges are typically eligible at procedure completion.

Professional charges are typically eligible at result

verification.

1.15. Post-processing workflow (PWF)

The PFW Integration Profile addresses the need to

schedule and track the status of the typical PFW steps, such

as Computer Aided Detection or Image Processing. Work-

lists for each of these tasks are generated and can be queried,

work items can be selected and the resulting status returned

from the system performing the work to the system

managing the work. Typically the workitems will involve

the creation of objects such as images and evidence

documents. The created images and evidence documents

contain the necessary references for maintaining continuity

of order information.

The PFW Integration Profiles is a continuation of the

Scheduled Workflow Integration Profiles.

1.16. Implementation testing

The testing phase of the IHE demonstration process takes

place in two stages. The first round is performed with a set

of software tools called medical enterprise simulators and

analyzers (MESA), developed by the Technical Project

Management team with funding from HIMSS and RSNA.

Participating vendors use the tools to test their implemen-

tation of IHE Actors. The tools simulate the exchange of

messages with complementary Actors and analyze discre-

pancies between the vendor’s implementation and the

transactions defined in the Technical Framework. Success-

ful completion of these tests is a mandatory part of the IHE

process. While not exhaustive, the MESA tests indicate a

substantial baseline of success in implementing IHE

transactions.

The second round is a face-to-face testing event dubbed

the ‘Connectathon’, which takes place several weeks before

the actual demonstration. The event allows for broad

interoperability testing among all participating vendors

and systems. Vendors are given the opportunity to test with

all participating complementary Actors. Successful results

are recorded and documented. This information becomes

one of the most publicized aspects of the IHE process,

providing a significant incentive for vendors to work out any

remaining incompatibilities and successfully complete

interoperability testing.

As a practical matter, the vendors who attend the

Connectathon find the scheduled and unscheduled cross

vendor testing of great importance. The engineers who staff

the equipment have the opportunity to test with a large

number of other systems in a short time. In this environment

controlled by the HIMSS and RSNA professional organiz-

ations, the vendors have a chance to test with potential

partners in a non-competitive setting. Time is spent solving

issues rather than trying to convince a customer that one

product is correct while another product is not.

Each Connectathon event has included between 24 and

35 vendors testing a total of between 40 and 75 systems. In

the 5 days of the Connectathon, using the transactions

defined in the IHE Technical Framework, the participating

vendors set up, configure, integrate, and test their systems.

In all, hundreds of vendor-to-vendor connections are tested

and thousands of transactions passed among the systems

present.

The Connectathon offers vendors a unique opportunity

for connectivity testing—removing barriers to integration

that would otherwise have to be dealt with on site, at the

client’s expense. Companies taking part have responded

overwhelmingly that the IHE process addresses important

issues in their product development plans.

1.17. Public exhibitions and education

The effort to increase market awareness of the integration

capabilities available under IHE (and thereby stimulate

demand for this functionality) has involved a series of

public demonstrations at the annual HIMSS and RSNA

conferences [3]. For the first 3 years of the initiative, these

public forums have featured actual systems from a broad

array of vendors performing all of the IHE transactions,

Actors and Integration Profiles. No simulators were used in

these demonstrations. This combination has been highly

successful in establishing recognition of IHE in the

healthcare community, and providing evidence of its

accomplishments, as evidenced both by the broad and

continuing support of industry and by the high level of

recognition of the IHE project in the medical imaging and

informatics community.

Having achieved this initial progress as a demonstration

project, IHE has now shifted its focus to driving the

implementation of IHE functionality in commercial pro-

ducts and healthcare institutions. This involves implement-

ing an enhanced testing process and developing better tools

for purchasers and vendors to use in communicating about

the integration capabilities of commercial products.

Educational sessions about IHE at the HIMSS and RSNA

annual meetings will target specific groups of interested

parties (e.g. clinicians, administrators, information technol-

ogists, developers and consultants) and provide detailed

information about the clinical and operational benefits of

systems integration and instructions on how to acquire

integrated systems.


1.18. Expansion and evolution

IHE was started—and continues to be sponsored—by

two professional societies whose membership is in the

imaging and IT domains. The professional and industry

experts have been able to attract into the process have

proven successful in addressing systems integration issues

within the radiology department.

The procedural model they have developed for solving

system integration issues would seem equally applicable to

other domains. Certain of the functions they have worked to

implement using established standards, such as patient

registration and ordering, also could address problems

encountered in other domains. These functions could

potentially provide building blocks for an enterprise-wide

information technology infrastructure, if sufficient represen-

tation of all the stakeholders involved could be brought

together. HIMSS and RSNA have been in communication

with professional societies in other domains to encourage

them to join in broadening the initiative.

An important step towards the expansion of IHE into a

truly multi-disciplinary effort began with the formation of the

IHE Strategic Development Committee in September 2001.

This committee consists of representatives from multiple

clinical and operational domains. Its task is to begin defining

the key integration issues within and among these domains

and populating additional committees of professionals and

industry experts to explore solutions. The domains initially

targeted by the committee are: Cardiology, Laboratory,

Pharmacy/Medication Administration, and Interdepartmen-

tal Information Sharing. Work to identify key problems and

expertise in these domains has progressed significantly.

Meanwhile, IHE has expanded internationally, as well.

IHE demonstrations have taken place or are scheduled in

several European countries and Japan. A process has been

put in place to enable all of the nationally based IHE

initiatives to contribute to a global Technical Framework.

Provision has been made to document nationally based

differences stemming from healthcare policies and typical

practices, while at the same time seeking the highest

possible level of uniformity in the recording and exchange

of medical information.

Achieving successful integration within other units of the

enterprise, and establishing a broader set of information

links between departments, will depend on the willingness

of professionals and industry sectors representing these

domains to become engaged in the IHE process. The evident

success of this process in the radiology domain should

provide persuasive evidence that they have much to gain in

doing so.

2. Summary

While the development of messaging standards for

sharing patient information in healthcare is now well

advanced, the implementation of closely integrated systems

using these standards lags far behind. IHE initiative is a

combined effort of the medical professions and healthcare

information and imaging technology industry to coordinate

the implementation of standards for systems integration.

The authors discuss the process used by IHE to gain

consensus among professionals and industry on integration

priorities and solutions; the way information is structured in

the guide for implementing standards developed by the IHE

committees, the IHE Technical Framework; the tools IHE

has made available to help administrators implement

integrated systems, including the ten IHE Integration

Profiles; and the possible future expansion of IHE across

the many domains and departments comprising the

healthcare enterprise.

References

[1] Crossing the Quality Chasm. A New Health System for the 21st

Century, The National Academy of Sciences, 2000.

[2] Eliot L, Siegel MD, David S, Channin MD, et al. IHE primer.

Radiographics 2001;21:1339–41. see also pages1343–1350, 1351–

1358, 1597–1603.

[3] Integrating the Healthcare Enterprise (HIMSS Target Issues Mono-

graph), edited by by Paul R. Vegoda, FHIMSS, HIMSS 2001.

Christopher D. Carr is Director of Informatics for the Radiological

Society of North America (RSNA). While in graduate school in the

humanities, he became involved in projects creating electronically

enhanced texts. He came to RSNA in 1997 as a manager in the

publications department, responsible for launching the electronic

versions of RSNA’s journals, RadioGraphics and Radiology. In his

current position at RSNA, he is responsible for the Society’s Web

initiatives and several special informatics projects, including serving as

staff liaison to the Integrating the Healthcare Enterprise (IHE)

initiative.

Stephen M. Moore, MS, is Assistant Professor of Radiology at the

Mallinckrodt Institute of Radiology, St Louis, MO. His main interests

are in imaging informatics and system integration of radiology

operation.


ihe: a model for driving adoption of standards

Documents