#enterpriseid

For enterprises with many applications, identity management solutions prove useful in matching records across these systems using common characteristics.  Algorithms to perform this matching can become complicated, but a simple example would be matching patient records in different systems should those records share the same last name, date of birth, and SSN.

Information could of course be updated so two records that may have been matched together previously may shift and be matched with different records.  In other words, the enterprise ID is useful at a specific point in time (i.e. now) to identify similar records across applications.  It is not a permanent identifier that can always be used to identify a specific record across enterprise applications.

Let's look at an example.

Sample Data

Our identity management solution has matched records coming from various systems resulting in three patients as seen in the image below: Jon Doe, Sally Doe, and John Doe.

The patient Sally Doe for instance has an enterprise ID of 543 used to group her records found in Cerner and Epic.

The important concept to note is that the enterprise ID simply buckets these records together at a specific point in time.  It is not a permanent identifier that can always be used to identify Sally Doe's records across enterprise applications.

List of IDs to Track

Let's say someone is analyzing data from Cerner, finds what they need, and stores the enterprise IDs of these patients to track them going forward:

The context in which these enterprise IDs has NOT been stored.  No information exists to note that the enterprise ID was found based on records identified in Cerner.  Since enterprise IDs serve to group records as of "now," storing them for future use can prove problematic.

Enterprise ID Shift

Now, let's assume that information was corrected in the source systems and a couple records move from enterprise ID 100 to the other buckets.  The Athena record from enterprise ID 100 is corrected in the source system and now matches to enterprise ID 543.  The Cerner record from enterprise ID 100 is corrected in the source system and now matches to enterprise ID 850.

Now, given the enterprise IDs that were previously stored...

...it is impossible to know whether removing ID 100 is appropriate here. 

Food for Thought

Storing just an enterprise ID is problematic as records shift between buckets.  Some buckets may disappear altogether depending on what records survive the matching logic.

Storing key pieces of information used in the matching algorithm may be better than storing the enterprise ID itself.