HIE via IHE whitepaper

Note: This is a draft.

1 Introduction

1.1 Purpose

Throughout the world, healthcare providers face a difficult challenge: incomplete access to a patient's historical health information. Thus, one of the most significant applications of healthcare information technology is the exchange of health information among disparate clinical information systems. The core goal of the IHE (Integrating the Healthcare Enterprise) initiative is to facility health information exchange. IHE describes methods for a coordinated approach to integrating information systems. While its methods assume various abstract constructs that tie systems together into organized structures (e.g., XDS.b affinity domains), IHE does not make any recommendations about the actual human/business organizations that should exist to achieve effective health information exchange.

That said, it is a fact that across the world various organizations have developed or are developing to facilitate health information exchange. The purpose of this white paper is to describe how exchange communities, both existing and nascent ones, may use IHE Infrastructure profiles to achieve common health information exchange use cases.

1.2 Intended Audience

The assumed audience for this white paper includes anyone involved in a current or planning HIE community. Furthermore, the paper makes no assumptions about the reader's knowledge level. Topics covered should be of interest to both the naive and expert HIE community participants.

1.3 Overview of HIEs

The HIE concept is not a new one. For many years, there have been ebbs and flows of HIE-like activities across the world. The nature and scope of these HIE activities vary widely. HIE communities can be characterized by a number of different aspects. First, the geography of the community may vary from one community to another. What often comes to mind when speaking of an HIE community is a regional organization that facilitates information exchange across multiple organization that are relatively close geographically. Major metropolitan areas tend to be the locus of these regional exchanges, but sometimes a regional community may encompass several rural locals. On the opposite extreme of the geographic aspect of HIE communities would be the network of United States Veterans Hospitals. The VA (Veterans Administration) hospitals dot the entire map of the US, yet significant efforts have been spent on being able to exchange data among these geographically separated care centers.

A second characteristic by which to categorize HIE communities would be the organizational structure of the community. In some cases, the community consists of a single hospital and several out-patient clinics that have a referral relationship with the hospital. In other cases, a network of competing hospitals, laboratories and private clinics may gather to form an exchange community. Lately, there have been significant initiatives to create state-level exchange communities, which typically take the form of a network of individual HIE communities that already exist in the state.

A third means by which to describe HIE communities is the scope of the information exchange. Some communities have very limited exchange functionality. For instance, a community may focus entirely on electronic lab result delivery or e-prescribing. Most communities achieve a moderate scope to their exchange activities that might include results delivery, electronic referrals, and perhaps some sharing of encounter-based information (e.g., dictations). More advanced communities leverage their network to include even larger scopes (perhaps including the sharing of patients' consent preferences, exchange of clinical summaries, etc.). No two communities are alike in terms of the set of HIE activities that they facilitate.

Finally, a fourth aspect of an HIE community is the political jurisdiction(s) that regulate it. National and sub-national jurisdictions have significant effects on the organization and operations of an HIE community.

Despite all the variance among HIE communities, each have the same ultimate goal: increase the accessibility of patient health information so that clinicians may make more informed decisions about the care that they provide. Likewise, the essence of nearly all of the IHE ITI profiles is to help facilitate the flow of clinical information to the point of care.

1.4 Background on IHE

Explain high level IHE concepts such as profiles, actors, transactions, etc. [Chris K] Yes, I think this should include a *brief* overview of IHE (the organization) and the concept of profiling integration (i.e., the technical framework) ....which might include the concept of domains.....with a focus on the Infrastructure Domain profiles

2 Patient ID management

In most instances, the data exchanged between healthcare information systems are related to individual patients. A common problem is how to ensure that the two systems are referring to the same patient when they exchange a set of data. Most information systems assign to each patient an identifier (usually a string of letters and/or numbers) that is unique to the patient within only that information system. Thus, Gary Collins may be identified as 3562A in the General Hospital System and UO1003 in the Better Health System. If General Hospital System wants to communicate with Better Health System about Garry Collins, both systems must be able to know that 3562A is equivalent to UO1003. In more technical terms, there must be a cross-reference that links the two patient identifiers.

2.1 PIX

The PIX profile is IHE's answer to the difficulty of managing an individual patient's multiple IDs. Systems can play the role of one or more of the PIX actors: PIX manager, PIX supplier and PIX consumer.

At its simplest form, the PIX Manager is a chart which cross-links IDs (often called MRNs or medical record numbers) from connected systems. For the male patient named Jose Gonzalez who lives at 123 Elm St. in Somewheresville, Ohio and who was born on 5/20/1955, the PIX manager may have a list of five IDs that five separate information systems assigned to Jose. Systems within an HIE community who assign IDs to patients may act as PIX suppliers. The PIX suppliers send various PIX transactions (add patient, update patient, and resolve duplicate patients) to a PIX manager, whose role is to maintain cross-references between the IDs that various PIX suppliers send to the manager. It should be noted that the PIX profile does not specify how patient matching occurs. Each vendor is welcome to use their own matching algorithms to determine which IDs should be cross-referenced. Most systems that implement the PIX supplier actor also are PIX consumers. The PIX consumer role is to send queries to the PIX manager to receive a list of IDs that are cross-referenced to an ID previously known to the PIX consumer. If the Orion System assigned Jose Gonzalez the ID of 12345, Orion System would query the PIX manager for other IDs that are cross-referenced with the Orion System's ID of 12345. The PIX manager will return the other four IDs that are cross-referenced to Orion System's 12345.

2.2 PDQ

Information about patients may be divided into two major categories: clinical (information describing the patient's health) and demographic (information describing the patient in general). Both categories are equally important to efficient healthcare activities. Demographic information (e.g., date of birth, address, sex, etc.) have three major uses. First, demographics are often used to help identify the patient. With information on dates of birth and sex, information about Leslie Ramsi, a male born on 5/2/1968, can be distinguished from that of Leslie Ramsi, a female born on 7/23/1987. Second, demographics are essential for managing communication with the patient. Without accurate phone numbers, street addresses and email addresses, healthcare providers would not be able to efficiently contact their patients. Finally, patient demographic information has clinical significance. For instance, by storing patients' ages and sexes, providers can identify individuals in need of a preventive measure such as breast cancer screening.

Maintaining accurate demographic information on patients is a continual challenge in healthcare. Some demographic information is variable (e.g., phone number, street address, etc.). Other information may be multi-value in nature (e.g., Katherine Sandusky may also be known as Kay Sandusky and Kathy Sandusky). Even constants like date of birth and sex may be recorded inaccurately.

To help information systems improve their management of patient demographic information, IHE defines a profile called patient demographics query (PDQ). The premise of this profile is that some information systems will have more comprehensive and more accurate demographic information about a patient than other systems. The following paragraph describes a typical use of the PDQ profile.

AAA Laboratories' information system has a record for Justin McCarthy. The demographics include a date of birth, sex and phone number, but no other contact information. AAA knows that Justin is a patient at Chattanooga General Hospital. Thus, a staff member at AAA can send a patient demographics query to General Hospital's Horizon EHR to discover additional contact information for Justin. Horizon EHR returns a record for a Justin McCarthy who has the same birth date, same sex and same phone number as the Justin McCarthy known to AAA. Horizon EHR's record for Justin includes a street address and middle name. AAA adds this demographic information to its record for Justin McCarthy, thus rendering its data more complete.

3 Document sharing

3.1 Publish and discover

3.1.1 XDS.b

Patient identification and demographics management are simply means to an end, the end being exchange of clinical information among various systems. The following scenario describes a typical exchange of clinical information.

Dr. Suwati works for New Hope Medical Partners and uses the Apollo EMR. Her patient, Mary Gomez, just explained to the doctor that she was recently hospitalized at Norwalk General Hospital. Dr. Suwati would like to review the medical records that documented Mary's hospital stay. With the Apollo EMR, Dr. Suwati searches for recent documents for Mary Gomez created by Norwalk General Hospital's Serenity EHR. Having found several documents (lab results, radiology reports, a discharge summary, etc.), Dr. Suwati chooses first to view Mary's radiology reports. Having read the reports, she discards them. However, Dr. Suwati reads the discharge summary and then saves it to Mary's record in the Apollo EMR.

In this scenario of health information exchange, the primary actor (Dr. Suwati) has three principal objectives: find patient records available from external systems, view a selection of those records, and save a separate selection of records to her local system. This sequence of actions is repeated continually in the healthcare setting. To address this very common scenario, IHE has created the cross-enterprise document sharing (XDS) profile, a method to coordinate the sharing of medical records among separate information systems.

XDS sits at the heart of health information exchange. PIX and PDQ are essential to the information sharing process, but they provide only supporting roles. XDS is the lead actor in the health information exchange drama. The strength of XDS is that it enables effective sharing of data between two separate systems in a way that minimizes the burden that data sharing imposes on those systems. To reduce this burden, XDS requires the use of two intermediaries (the XDS registry and XDS repository), systems which handle most of the effort involved in exchanging clinical data.

Though they are separate systems, the registry and repository work hand-in-hand, the one being useless without the other. Therefore, it may be more convenient to think of the registry and repository as a single entity, like a public library. The repository is the library's set of shelves and books, an organized resting place for book (i.e., medical records) that are available to library patrons. The registry is the library's catalog, a tool for locating specific books that lie on those rows and rows of shelves.

The question to ask is how do the books get on the shelves? This is the responsibility of the publisher (i.e., the source system from which the medical record originated). It is the responsibility of the publisher to put the book on the shelf and then to update the catalog with the data needed to find the new book. In XDS jargon the publisher is called the document source, whereas the act of putting the book on the shelf and then cataloging it is referred to as "provide and register." Thus, the XDS document source sends a copy of a medical record to the XDS repository and subsequently sends meta-data (i.e., data that describes the information within that medical record) to the XDS registry.

To complete our analogy, we must consider the library patron (Dr. Suwati in our case), whose goal is to find specific books. The patron interacts with the catalog, sometimes searching for specific books, other times browsing what is available. Once the locations of interesting books are discovered, the patron fetches them from the shelves. In our XDS drama, the document consumer (our library patron) interacts with the document registry to find medical records of interest. This process is known as the "query registry" transaction. The act of fetching the medical record from the repository is known as the "retrieve document" transaction.

3.1.2 NAV

As noted above, the XDS.b profile describes how clinical information systems may exchange documents based on a publish and discover--otherwise known as "pull"--model. The NAV profile bridges the gulf between the "pull" model of XDS.b and the "push" models described in subsequent sections. NAV describes a mechanism by which notifications may be sent to interested parties when a particular document is published to the XDS.b repository. The notification recipient may then choose whether or not to retrieve the document. A common use case for NAV involves two physicians caring for the same patient. For example, Dr. Kowalski, an endocrinologist, may update Jennifer Chai's health record with a new progress note. Dr. Kowalski knows that Jennifer's primary care physician, Dr. Pierre, would be interested in reviewing the progress note. Therefore, a NAV message may be sent to Dr. Pierre once Dr. Kowalski's note has been published to the XDS.b repository. Once the NAV message is received, Dr. Kowalski can retrieve the progress note for review. Thus, while Dr. Kowalski's progress note was exchanged via a publish-and-discover mechanism, the NAV message provided a means for point-to-point communication between the two physicians.

3.1.3 XCA

Typically, HIE communities form as a means for a specific set of related organizations/facilities to exchange clinical information. Usually, the members of an HIE community are related such that they share a common base of patients. An HIE community might arise in Bangkok to facilitate record sharing for all patients living in the Thai capital. The Bangkok population is the shared patient base for such a community. Similarly, a network of British military hospitals may decide to create an HIE community to enable record sharing. This community's shared patient base would be British soldiers.

Given their shared patient base, HIE communities typically capture the majority of healthcare encounters for any given patient in their population base. However, many patients receive care outside of their home community and sometimes the care received externally can be very significant clinically. Therefore, at times there is a need to share health information between two HIE communities. The Cross-Community Access (XCA) profile was developed to address this need. To implement XCA, an HIE community builds two gateways through which all inter-HIE community transactions will flow. An Initiating Gateway is used to send queries to other communities, while a Responding Gateway is employed to receive queries and respond to them.

Like XDS.b, XCA is based on publish-and-discover mechanisms. Documents are published in the repositories of the external HIE community. A system within the local HIE community may query the external HIE community to discover (and subsequently retrieve) interesting documents. The XCA gateways are the conduit through which these transactions flow.

3.2 Push to specified recipient

Describe document sharing via XDR and XDM.

5 Security and privacy

• Explain how profiles like ATNA, XUA and CT help ensure patient privacy via various security measures.
• Explain the concept of HIEs needing to have policies in place that dictate and describe how providers "play" within the HIE.