When the postIdentity web service is used to submit an update for a Source + Native ID combination that already exists in Universal Identity, Verato 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.
- The registration personnel creates a patient record in their EMR application for person A.
- The next person in line, person B, steps up to the registration desk.
- 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:
- Universal Identity 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 Identity.
- Universal Identity 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.
- Universal Identity 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 Identity uses two different techniques to detect overlay updates.
- The primary technique is based on the Universal Identity platform's match algorithm score. When a Source + Native ID is updated, Universal Identity compares the updated attribute values against the existing/previous attribute values. This comparison uses Universal Identity'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 Identity platform's match algorithm. When Universal Identity 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
For each of the two detection techniques described above, Verato can configure Universal Identity 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 Identity. |
| Allow | The web service response indicates the request succeeded, and the updated attribute values are stored in Universal Identity. No other actions are taken. |
| Data Stewardship Task |
|
| Reject with Task |
|
Customize Overlay Detection Actions
Verato can configure each customer’s 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
The following is a suggested approach for more comprehensive overlay detection:
- For any updates that do not pass the primary overlay detection, use the Reject with Task action.
- For any updates that pass the primary overlay detection, but do not pass the secondary overlay detection, use the Data Stewardship Task action.
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.
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 DetectedWhen the postIdentity update is rejected with the creation of a task, 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. Rejected Task Configuration Enabled: This will create/update a task with the overlay data.
If the postIdentity update is rejected based on the overlay detection configuration, Verato also logs this event as a notification message.