HIE via IHE whitepaper

Note: This is a draft.

Title: Using IHE profiles to build communities for health information exchange

1 Introduction

[Karen W] We need to add a section where we tell them what we are going to tell them. Explain about the diverging needs of information exchange, that we will focus on the needs of patient identification, document sharing, security & privacy, value sets in each of the following sections. And we should include a one or two sentence explaination of each of these topics which are covered in more detail later

1.1 Purpose

Healthcare providers face the difficult challenge of 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. Across the world various communities have developed or are developing methods for exchanging health information betweeen enterprises. The purpose of this white paper is to describe how these communities, both existing and nascent ones, may apply IHE IT Infrastructure profiles to exchange information between enterprises.

1.2 Intended Audience

The assumed audience for this white paper includes anyone involved in a current or planned health information community. Furthermore, the paper makes no assumptions about the reader's knowledge level.

1.3 Overview of Health Information Exchange Communities

A health information exchange community (community) exists for the purpose of increasing the accessibility of patient health information across multiple enterprises so that clinicians may make more informed decisions about the care that they provide. Many communities are already in production and many more are being planned. The nature and scope of communities varies widely but can be characterized by a number of different aspects.

First, some communities are geographically focused while others are not. What often comes to mind when speaking of a 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 locales. On the opposite extreme of the geographic aspect of 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 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 a community. Lately, there have been significant initiatives to create state-level communities, which typically take the form of a network of individual communities that already exist in the state. [KW: this last sentence is very US specific]

A third means by which to describe 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 exchange activities that they facilitate.

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

Despite all the variance among communities, each have the same ultimate goal: increase the ability to exchange patient health information across enterprises 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

The core goal of the IHE (Integrating the Healthcare Enterprise) initiative is to facilitate health information exchange. The IHE IT Infrastructure domain has defined a collection of profiles which can be used for a coordinated approach to exchange healthcare information across enterprises. While this approach defines some abstract constructs that tie systems together into organized structures (e.g., XDS Affinity Domains), IHE does not make any recommendations about the actual human/business organizations that should exist to achieve effective health information exchange.

It is very important to note that IHE does not have solutions for all the problems involved in exchanging health information. Instead, it provides solution components that may be used to address specific, well-defined problems. These components should be plugged into a master plan that is designed and executed by the exchange communities themselves.

2 Patient ID management

When data related to individual patients is exchanged between healthcare information systems it is critical to ensure that the two systems are referring to the same patient. The Patient Identifer Cross-Referencing (PIX) profile support the linking of patient identifiers from multiple patient identifier domains. The Patient Demographics Query (PDQ) profile supports the ability to query for a set of demographics and get in response a complete set of demographics, usually including patient identifiers in domains of interst. The Patient Administration Management (PAM) profile ...

2.1 PIX

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.

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 a 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, communities form as a means for a specific set of related organizations/facilities to exchange clinical information. Usually, the members of a community are related such that they share a common base of patients. A 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 a community to enable record sharing. This community's shared patient base would be British soldiers.

Given their shared patient base, 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 communities. The Cross-Community Access (XCA) profile was developed to address this need. To implement XCA, a community builds two gateways through which all inter-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 community. A system within the local community may query the external 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

3.2.1 XDR

In some cases an XDS infrastructure does not exist (i.e., there is not an XDS registry nor repository to facilitate exchange of clinical documents), but clinical system in the community wish to reliably exchange documents. IHE's Cross-Enterprise Document Reliable Exchange (XDR) profile addresses this situation. Many of the components of XDS are re-used in XDR such as the Provide and Register Document Set transaction, the Document Source actor, document meta-data, etc. As mentioned, what is missing in XDR is the intermediary functions of the XDS repository and registry which facilitate the publish and discover model of information exchange. XDR provides a point-to-point method of exchanging data with the same advantages of XDS (content agnosticism, document meta-data, reliable transactions, etc.). XDR may also be used in a community that has an XDS infrastructure when point-to-point exchange is preferred.

The typical use case for XDR is the patient referral. Dr. Suwati may wish to refer her patient Mary to a specialist, Dr. Lima, that works across town. XDR may be used to send the referral document (and possibly other clinical documents) from Dr. Suwati's Apollo EMR to Dr. Lima's Great Charts EMR.

3.2.2 XDM

Within a community, there may arise situations where the electronic exchange of clinical information does not rely on networked connections between the parties exchanging the information. In these cases, electronic media such as CDs and USB drives may be employed to transport the data from one system to another. The Cross-Enterprise Document Media Interchange (XDM) profile addresses these scenarios where electronic media a required. Like XDS and XDR, XDM is document format agnostic. Also, XDM employs the same meta-data as XDS and XDR (it does not require any additional meta-data).

Again, the patient referral use case is a typical one that may employ XDM. Dr. Suwati may wish to refer her patient Mary to an orthopedist who does not have an electronic endpoint to receive the referral documentation. Dr. Suwati's decides to write a referral letter and to create an image file of the X-ray of Mary's leg. Dr. Suwati employs her Apollo EMR to write this letter and the image file to a USB key using the XDM profile. She then gives the USB key to Mary so that the patient may take the files with her to the orthopedist.

4 Common Provider Directory

As with patient identity management, the management of data related to healthcare providers (both individual providers and provider organizations) is a fundamental challenge for communities. IHE has defined the Healthcare Provider Directory (HPD) profile to addresses this challenge. There are two principal benefits of using the HPD profile. First, HPD provides a means to disambiguate the identity of providers (i.e., allow one to distinguish between the 58 year-old male pediatric nurse named Lindsay Smith and the 32 year-old female orthopedic surgeon Lindsay Smith). Second, HPD offers a method to discover a provider's contact information (e.g., phone numbers, street address, etc., as well as an electronic endpoint that may be used for trusted commuication).

The referral process (one provider referring a patient to the care of another provider) is one of the most common uses of the HPD profile. When Dr. Palov wishes to send his patient Mary Blythe to a female endocrinologist who speaks Spanish, he may query the Directory to find contact information for providers that match those criteria. Similarly, Dr. Palov may wish to refer another patient, Thomas Reed, to the local Mercy Hospital. Dr. Palov could query the Directory to discover the hospital's electronic endpoint (e.g., a secure email address or an XDS repository endpoint) so that he may forward some of Mr. Reed's medical records to the hospital in advance of his visit.

In technical terms, the Healthcare Provider Directory profile describes both how to store data regarding healthcare providers and also how to subsequently access that information. As previously mentioned, the concept of a provider in HPD includes both individual people (e.g., a nurse, a physician, a respiratory therapist, etc.) and organizations of people (e.g., integrated delivery networks, private clinics, etc.). Within the directory, one may also store relationships between providers such that nurse Joe may be an individual provider who belongs to the organizational provider General Hospital.

The Directory is populated by means of information feeds from Provider Information sources (e.g., state licensing bureaus, national associations, etc.). Information Sources may add new providers, delete providers currently stored in the Directory or update providers currently stored in the Directory. Any clinical system may act as a Provider Information Consumer. Consumers send queries to the Directory (such as the ones that Dr. Palov sent in the examples above) with specific search criteria. The Directory responds with zero, one or more providers (and the requested information associated with those providers) that match those search criteria.

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.