The Intersection of Providers, Patients, and Data

Inside the contents of techie blogs, magazines, and conference rooms you’ll find teams and experts talking about health interoperability – what it takes to share health care data in today’s world. We have heard these discussions and we have participated in them. Many of them lead us down the road to to the topic of Health Information Exchanges, or HIEs. Why? Because HIEs grant providers access to clinical data. HIEs are the answer to many of the challenges we face when we assess the intersection of health care with information technology today. So, what are HIEs composed of?

 

 

Clinical Data Repository (CDR)

A CDR is a clinical data warehouse that stores patient data. The patient data is often structured in a clinical model that allows for quick data transformation into medical formats. This data store is what is utilized by all the other components in the HIE when they need to find patient data. There are two common models to a CDR:

1. Centralized: All patient data is maintained and stored in a central database for the HIE. All patient records flow the centralized CDR and are stored there. Any queries against this data are done against this centralized data store.

2. Federated: All patient data is stored with the provider/creator of the data store. This allows providers to maintain ownership of their collected data, but it still grants other authorized providers access to it.

A third model combines centralized and federated models to create a hybrid:

3. Hybrid: The Hybrid model mixes the two architectures described above by allowing providers to maintain their own data store, but providing a central data repository when it is necessary.

So, put simply, the CDR is the data store for the HIE. Now the question becomes: how does the HIE utilize this data? The following sections outline two of the critical components that utilize the CDR to perform their functions.

Master Patient Index (MPI)

An MPI is a vital component to an HIE – one of its primary functions is to uniquely identify all patients in the HIE. To do this, an MPI stores a unique identifier for every patient in the system. These unique identifiers can be created in a variety of ways, but are usually created with a composite key. A composite key involves utilizing multiple data elements to create a strongly unique identifying field.

Another key function of the MPI is matching incoming patient data with patients already known to the HIE. This involves comparing the data from the “unknown” patient to the data in the CDR, and determining if enough matches are discovered to pair the data with the record. There are two main ways of doing this:

1. Deterministic: Selected fields have to match identically. For instance, looking at the image above, first and last name along with date of birth, would have to match exactly to find a match. This is not considered to be a robust way to handle patient matching and will result in a lot of manual intervention, but is very efficient due to the lack of complexity.

2. Probabilistic: Selected fields are assigned a weight and compared as part of the bigger matching effort. For example, first and last names may be given a weight of .2 while date of birth is give a weight of .1, while other fields are assigned weights as well. The system compares the fields and when it determines the “scoring” of the fields is high enough, a match is made. This method also allows for fuzzy logic, such as names that have natural shortened versions. In the example above, Elizabeth would match Liz, and Eliza and could match Elisabeth.
Once the matching occurs, regardless of method used, the data is stored in the CDR for future queries and provider use.


Record Locator Service (RLS)

While the Master Patient Index (MPI) matches patient records, the RLS finds patient records. Or, more specifically, the RLS finds the locations of the patient data. Once data is received and assigned to a patient, it is stored in the Clinical Data Repository (CDR). For a provider to find this data, the RLS is able to search the HIE’s centralized CDR, as well as in the distributed CDRs that the providers may be maintaining. The RLS then returns, either via a portal or EHR, the locations where patient encounters occurred (or where the data lives).

It is important to note that not all patient data is immediately returned to the EHR. Instead, the initial results from the RLS will give the provider enough information that they can determine what providers have seen a specific patient and what the general nature of the visit was (i.e. pharmacy, radiology). If necessary, the provider can then choose to contact other clinical data generating providers, or choose to download the data into their medical records system.

The components of an HIE all work together to find, match, and store patient data. Without these services, it would be up to providers to ensure data accuracy, storage, and transfers. With an HIE, data and provider accuracy and efficiency are improved – we maximize health care and add the benefits of information technology to create an indispensable solution.

By | 2017-04-21T10:24:12+00:00 March 1st, 2017|

About the Author:

Jeremy Dean is Chief of Business Development at Trinity Technology Group. He specializes in Health Interoperability and tackles obstacles at work like he tackles them as a Spartan. Visit him on Linkedin here.

Leave A Comment

WordPress spam blocked by CleanTalk.