One term used for this is "The Join".
We (UT Houston HSC) wrote our own.
There are off-the-shelf products that claim to do this but from what I have
seen they only provide a framework that requires you to invest as much
effort configuring as it would to write your own.
I believe that the Nexus project may be an up and coming open source
solution for this. (http://www.nmi-edit.org/releases/index.cfm#Nexus)
I'll answer your questions inline.
From: Benn Oshrin [mailto:[log in to unmask]]
Sent: Thursday, June 08, 2006 2:11 PM
To: [log in to unmask]
Subject: [IDM] Person/Identity Matching
One of the issues we're about to (re)examine here is matching people who
come from multiple sources.
A typical case is a student who we already know about from the student
system gets hired as a casual or work study employee, and we want to make
sure their information from the personnel system gets attached to their
existing identity rather than have a new (second) identity created for them.
We already perform weak matching that catches most cases, but we are
looking to signficantly improve our handling of these individuals. We
would prefer to get a better idea of what others are doing before we make
our plans, and so I'd like to throw out a few questions to the list.
1. Did you write your own matching algorithms or do you use a
Wrote our own.
2. If you wrote your own, what criteria do you match on?
System of Record generated identifier (employee number etc.)
Any other unique identifier the SOR may store such as driver license
First and Last name
Birth information (Date, place (city), and country)
3. If you use a vendor solution
a. Which one do you use?
b. Is it a full vendor implementation, or do you just call
hooks from your own existing applications?
c. Who implemented your solution? (vendor, consultants, staff,
I have not seen a vendor solution that really does this but you
might investigate Novell Identity Manager. It may come close. We use it to
populate AD and Exchange from our Enterprise Directory. It was implemented
by our staff.
4. What has been your success rate with your implementation?
We have been very successful. Our rate of duplicate accounts is
very low and the administration required to reconcile possible duplicate
accounts is very manageable.
5. What are your procedures for handling close/multiple potential
Possible or multiple matches are flagged for manual reconciliation
before the account is created. We have an administrator that investigates
these matches before allowing account creation to proceed.
6. What are your procedures for recovering incorrect matches?
This is normally caused by data entry error in the SORs or human
error during manual reconciliation. Once the SOR data is corrected the data
for the distinct persons is manually separated.
7. If not otherwise covered above, what are the interfaces to your
system? (manual data entry via web, batch feeds, real time api,
We get daily batch feeds from all SORs. Manual identity
reconciliation and management of the person registry is done via a secure
I will summarize off-list replies.