Our students and employees are all managed via the same system -
SCT/Banner. But we still have the matching problems with "guests" - we
wrote our own system to handle that matching/entry problem.
Our primary point of contact for this is the ID card office, to issue
University ID cards (and parking transponders). They request name, SSN,
DOB and Gender before issuing ID cards - they will accept a University
ID number in place of SSN/DOB/Gender if the person has one (and knows
it). The goal is to link to an entry in Banner if it exists and load
data from there, otherwise we make the entries in the IDM system
(locally developed, Oracle based).
Matches are attempted based on SSN, then by Lastname+Firstname, then
Lastname+First Initial, and finally Lastname. This is a manual process
with the ID desk staff looking for good matches and selecting one (or
deciding that there isn't a match, and making a new entry.) In some
questionable cases, they will wait for the person to show up and ask
them additional questions - they will also check address information -
requesting a catalog will get you into the student database.
Incorrect matches require manual intervention - they are very infrequent
(I don't recall doing any in the past few years). A much more common
problem is someone who gets in twice - sometimes in Banner, others in
the IDM. We have a "merge" tool that helps a staff member sort through
all the records, fixing foreign keys and marking others "DO NOT USE".
This system works pretty well in part due to some very dedicated line
staff who are very aggressive about getting good data into the system
and weeding out the bad stuff (I know that I don't have the patience to
Jon Finke - Senior Systems Programmer - CMT - RPI
518 276 8185 (voice) - 518 276 2809 (fax) - http://www.rpi.edu/~finkej
From: Benn Oshrin [mailto:[log in to unmask]]
Sent: Thursday, June 08, 2006 3: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
sure their information from the personnel system gets attached to their
existing identity rather than have a new (second) identity created for
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
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
2. If you wrote your own, what criteria do you match on?
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,
4. What has been your success rate with your implementation?
5. What are your procedures for handling close/multiple potential
6. What are your procedures for recovering incorrect matches?
7. If not otherwise covered above, what are the interfaces to your
system? (manual data entry via web, batch feeds, real time api,
I will summarize off-list replies.
Teach CanIt if this mail (ID 3968911) is spam:
Not spam: http://respite.rpi.edu/b.php?c=n&i=3968911&m=7416b25b0541
Forget vote: http://respite.rpi.edu/b.php?c=f&i=3968911&m=7416b25b0541