Design approaches for patient identification in health networks

My last few posts have looked at the role of data standardization and terminology translation in enabling healthcare organizations to exchange information that can be understand by all. Terminology translation acts as a bridge to make it possible for two organizations to share and understand health data that is "codified" differently.

The linking of patients to their health data is another important bridge in enabling heath information exchange. Being able to uniquely identify patients is central to meeting both patient and provider care objectives to lower cost and improve quality and access to healthcare, such as:




    • Simple identification and organization of health data, improving access and reducing costs




    • Linking of health records to create a longitudinal record set for an individual, enabling a complete view of patient information




    • Information aggregation for analysis and research, supporting better understanding of diseases and treatments and driving better outcomes




    • Ensuring patient privacy, confidentiality and security, to which patient identification is a pre-requisite



The challenge lies in how healthcare in delivered in practice: patients tend to receive care at many different institutions in their lifetime, such as a primary care physician, university hospital or a local health clinic.Each of these care facilities tend to assign institution-based identifiers to a patient's health records, which is adequate within that institution but becomes meaningless once those records move outside of that institution. This is especially significant in today's healthcare marketplace, where patients routinely cross both institutional and geographic boundaries for their care needs.

Design approaches for patient identification in health networks tend to fall into two categories: those that require unique patient identifiers, and those that do not. There are many interesting and innovative approaches based on unique identifiers, some of which have real merit when applied to healthcare information infrastructure on a national scale.However most call for significant investment in time and resources to implement, administer and build out supporting infrastructure. Several proposals based on unique identifiers are outlined in detail in this HHS whitepaper. In the United States, HIPAA requires unique identifiers for providers and employers, but policymakers are no longer pursuing the idea of a unique patient identifier due to significant controversy as to how it can be implemented without comprising individual privacy. Once the policy and implementation issues are ironed out, national identifiers will be an important ingredient in solution for health system interoperability and data exchange. It will never be a complete solution, however.

As such, I'd like to focus on an approach that doesn't require a unique identifier, one that is available today and in in wide use by healthcare ecosystem. In this design approach, identification methods are based on a Master Patient Index (MPI). An MPI links a patient medical record number with a limited set of common identification elements known to a patient, such as patient first/last name, sex, birth date, SSN and mother’s maiden name. The following is a very high-level scenario to illustrate how an MPI works:

Hospital A and hospital B agree to notify one another of all Admissions, Discharges and Transfer (ADT) transactions. Both hospitals have independent EMR systems, and both are augmented with a solution like Intel® SOA Expressway for Healthcare to manage the exchange of ADT messages with the help of an MPI solution. The MPI is responsible for linking and indexing all known local identifiers for a patient to "master" identifier. For example, an ADT message from hospital A for the patient "Mary Smith" with local patient identifier A012 would be linked to the MPI identifier of M002, which contains all the mappings for the other clinical systems that hold records for Mary Smith. In this scenario, the MPI would resolve Mary Smith's local identifier for hospital B e.g. B029, enabling an ADT message exchange that is seamless between the hospitals.

Typically, MPI solutions are deployed within a single care organization to link and index patient identifiers across disparate clinical and administrative systems. The ADT exchange in the example above would be more commonly addressed by an Enterprise MPI (EMPI), which is used to create an complete view of patient information from data sources (including discrete MPIs) scattered across multiple facilities, application systems and databases, to deliver the right information about patients in real time in a variety of clinical settings. Intel SOA Expressway for Healthcare includes pre-built adaptors for validated application vendors in this space, making it simple to configure EMPI lookups for the any healthcare integration scenario.

In this post I barely scratched the surface of how MPI technology helps facilitate high-quality health information exchange. In a future post, I will discuss some of the architectural considerations for patient identification in large, national health infrastructure networks. Architectures of this type and scale have a unique set of requirements which require careful attention to the areas of data integrity, security, privacy and compliance.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

For more complete information about compiler optimizations, see our Optimization Notice.

2 comments

Top
Joshua Painter (Intel)'s picture

@mps: re: the Canadian SS mixup... this is more common than one might think. So while technologies like EMPI provide enormous value in terms of improving data quality and connecting islands of patient information, they are certainly not perfect on the own. To mitigate this, patient searches that leverage EMPI lookups are frequently wrapped into workflows that require human intervention in cases where matches don't meet the configured decision confidence. But while humans are needed to solve some problems, then can create others: take the phenomenon known as "split records", which is basically fragmentation that results from the natural variation found in person-identifying information, such as name misspellings, use of aliases, and other variations in attributes like address or phone number that change over time.

Re: the use of social security numbers... I agree with you that it's good practice to restrict use identifying information and unique keys to non-sensitive attributes.

anonymous's picture

There was a case a few years ago where a child in Canada couldn't get their equivelant of a SS number because their system thought that he was a duplicate. Their system checked on first name, last name, birth date, mother's name, and town, I believe. (They were in the same town, but at different hospitals.)
I'd also be leary about using Socal Security numbers as part of a patient identifier. Patient IDs flow all over the place, and there's been a significant effort to limit the exposure of social security numbers in the past couple of years thanks to the incidents of identity theft. (Also, we have a lot of international patients who don't have Social Security numbers.) On the system that I work on, we use unique IDs, which are a tuple of ID, issuing institution, and the type of institution (research sponsor, hospital, consortium, etc.), and a patient can have multiple IDs.

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.