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 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 United States. 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 veterans hospitals. The VA (Veterans Administration) hospitals dot the entire map of the US, yet significant efforts have been placed 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.

Finally, 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.

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.3 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.

Also include mention of NAV here.

3.1.2 XCA

Describe cross-community sharing via XCA.

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.

=6 Shared Value Sets