Hi Brian,
Introducing an Enterprise ID has always led to interesting conversations in my opinion. Often times folks (e.g., management) want to establish a "persistent" ID that identifies an individual that never changes - ever. However, that simply isn't possible since 2 individuals assigned an ID who are eventually merged must result in a winner and loser. I know, stating the obvious to a community of MDM practitioners! :-)
When I've introduced an Enterprise ID in the past, I favored using something that isn't easily consumable (e.g., a non-numeric identifier like the entity URI) and wrapped processes around the use of the ID to ensure the latest is used. That being said, I like Angela's use of a numeric value with survivorship being based on the minimum value. Not only does it reduce the frequency of change but it also tends to favor the "older" record.
In either case, you have to expect the value to change and ensure downstream processes leverage the latest and correct value. Another obvious statement right!
As for suspect records and the assignment of an ID, I'd say it depends on the reliability of the data source but typically an ID would be assigned regardless since the data source was worthy enough to be added to the MDM pool.
If you are able to share, I'd love to know the driver behind the need for an Enterprise ID!
------------------------------
David Starnes
Director, Enterprise Information Management & Architecture
RedHill Biopharma, Inc.
Raleigh NC
------------------------------