Public health and HIE: MPI synchronization

By Noam Arzt, PhD, FHIMSS
01:43 PM
Share
a:2:{s:5:"title";s:22:"Noam Artz, PhD, FHIMSS";s:3:"alt";s:0:"";}

One of the key elements of an HIE is the Master Patient Index (MPI), which associates records from multiple sources accurately with a single patient. Various software techniques are available to ensure accurate matching to prevent erroneous association of data from different patients (false “positive”), or failure to associate data from the same patient together (false “negative”). Deterministic tools are rules-based; probabilistic tools rely on mathematical algorithms and constructs. In either case, there is usually some manual intervention necessary to resolve ambiguous record matches where the automated algorithms cannot establish a match (or non-match) with sufficient certainty. An additional issue that HIEs face is deciding exactly who should be responsible for this activity: central HIE administrative staff, staff from participating organizations (particularly hospitals who provide larger sets of records), or both.

[See also: The 5 roadblocks HIEs face. And this Q&A: On the trials and tribulations of unlocking patient data.]

Interestingly, public health agencies have been operating registries for many years that typically include robust and sophisticated MPI functions, either for significant subsets of a population (e.g., immunization information systems) or more targeted subsets (e.g., disease surveillance systems). When receiving data from an HIE, public health agencies need to ensure that the records they receive can be accurately linked to their MPI entries to ensure that a minimum of matching errors occur. Projects have several choices:

Synchronization: Under this option, each MPI receives an initial registration of records from the other, stores each other’s MPI ID, then continues to synchronize any changes. Messages and queries for data sent by the HIE could include either the public health or HIE MPI ID of the corresponding patient to be used to match the records. Issues include:

  • Initial loads may result in different numbers of records in each system.
  • Public health has to trust that the correct MPI ID is being sent by the HIE.
  • Transactions are potentially processed faster with MPI IDs available.
  • Synchronization generates additional transaction load, which may have a performance impact.

Build as You Go: Under this option, no pre-registration of patients is performed. As a data submission or query from the HIE occurs, public health stores the HIE MPI ID for patients encountered for the first time, and looks up the record based on the HIE MPI ID provided for existing patients. As public health responds to queries, the HIE stores the MPI ID returned by public health for the corresponding patient to be used later. Issues include:

  • Queries may be slower as no pre-loaded MPI is available to rely upon.
  • Public health has to trust that the correct MPI ID is being sent by the HIE.
  • Lower transaction load than Option 1 since no synchronization is taking place.

Independent Operations: Under this option, each system treats the other as it does any other external EHR-S and stores the other’s MPI ID as it would a medical record number. Data submissions and queries for data sent by the HIE are evaluated by public health on a transaction-by-transaction basis. MPI IDs may be used by either system to corroborate matching decisions. Issues include:

  • Community does not gain the benefits of a unified MPI.
  • Public health is not aided by HIE MPI matching.
  • Same demographics may yield different matches in each system and at different times.

HIEs and public health agencies need to examine these issues carefully and determine which strategy is best for their organization and community.

Noam H. Arzt, PhD, FHIMSS, is president and founder of HLN Consulting, LLC, San Diego, and does consulting in healthcare systems integration, especially in public health. This article originally published on the HIMSS.org News page.