Identity Overlay Detection and Prevention

  • Identity Overlay Detection
  • UMPI

When the postIdentity web service is used to submit an update for a Source + Native ID combination that already exists in Universal MPI, the Universal MPI software compares the updated core attribute values against the existing/previous core attribute values to detect whether an overlay has occurred.

What is an overlay?

An overlay is substantial change to demographic associated with the same source + Native ID resulting in identity resolution conflict. It occurs when a customer’s application or database is updated in a way where an existing record for person A is accidentally overlayed with demographic data for person B.

What causes an overlay?

Overlays are typically caused by:

  • Data entry, if an end user types over the demographics on an existing record
  • External systems or integration processes that don’t have a trusted person id

For example, imagine that person A is in line to register at the hospital.

  1. The registration personnel creates a patient record in their EMR application for person A.
  2. The next person in line, person B, steps up to the registration desk.
  3. The registration personnel accidentally enters person B’s information onto the person A record that is still on their screen, instead of creating a new record.

In this scenario:

  1. Universal MPI first receives a post identity web service call for the specific record from the EMR application. This web service call includes the demographic data for person A and it is added to Universal MPI.
  2. Universal MPI then receives another post identity web service call for the SAME record ID from the EMR, but it contains very different demographic data for person B.
  3. Universal MPI’s compares the new demographics data for person B against person A (for the same record ID from the same EMR) and recognizes this is an overlay scenario. 

How overlays are detected

Universal MPI uses two different techniques to detect overlay updates.

  • The primary technique is based on the Universal MPI’s match algorithm score. When a Source + Native ID is updated, Universal MPI compares the updated attribute values against the existing/previous attribute values. This comparison uses Universal MPI’s match algorithm and returns a match score. The match score is compared to an overlay threshold. If the match score is below the overlay threshold, then the postIdentity update does not pass the primary detection.
  • The secondary technique is based on additional rules in the Universal MPI’s match algorithm. When Universal MPI compares the updated attribute values against the existing/previous attribute values, IF the postIdentity update passes the primary detection (the match score is equal to or above the ‘overlay threshold’), a second set of rules is applied to detect more subtle overlay cases. These additional rules look for significant changes in either the SSN, DOB, First + Last Name, or First Name + Gender of the identity. If the postIdentity update scores above the overlay threshold but has significant changes in certain attribute values, then the postIdentity update does not pass the secondary detection.

Overlay detection actions table

For each of the two detection techniques described above, Verato can configure Universal MPI to do one of the following: 

Reject The web service response indicates the request failed, and the updated attribute values are not stored in Universal MPI.
Allow The web service response indicates the request succeeded, and the updated attribute values are stored in Universal MPI. No other actions are taken.
Data Stewardship Task
  • Allows the postIdentity update to proceed. In addition: 
    • The web service response indicates the request succeeded.
    • The updated attribute values are stored in Universal MPI
    • An Applied Overlay data stewardship task is created in the data stewardship task queue. 
Reject with Task
  • Reject the postIdentity update and create a new Rejected Overlay task in the data stewardship task queue. 
Refer to Data Stewardship Tasks for detailed information about these tasks.  

Customizing overlay detection actions 

Verato can configure each customer’s Universal MPI instance with different actions for each of the primary and secondary overlay detection techniques. The current default configuration is to apply the REJECT action for any updates that do not pass the primary overlay detection and the ALLOW action for all other updates.

Suggested approach

A suggested approach for more comprehensive overlay detection is to use the Reject with task action for any updates that do not pass the primary overlay detection and the DATA STEWARDSHIP TASK action for any updates that pass the primary overlay detection but do not pass the secondary overlay detection.

What this accomplishes is:

  • Blatant overlay updates, where most or all of the attribute values change, will not pass the primary overlay detection, so they will be rejected and a data 'Rejected Overlay' task will be created so the record can be reviewed later.
  • More subtle updates, where one key attribute value changes significantly, will succeed and a data stewardship task will be created so that the record in question can be reviewed later.
Verato Universal MPI can be configured to allow a record with dummy patient data to be updated with real patient data without triggering any overlay.

In cases where the postIdentity update is rejected based on the overlay detection configuration, the web service responds with an HTTP 200 (success) status, but the ‘message’ and ‘errors’ portions of the response JSON will both contain this text:

PostIdentityRequest failed. Cause : IngestionService failure: Error ingesting
entity: Overlay Error Detected

If the postIdentity update is rejected based on the overlay detection configuration, Verato also logs this event as a notification message.

Refer to Notification Messages for detailed information about notification web service.