Main Nav

How does your school manage its reconciliation process?  What types of attributes do you use to determine if someone is a match or new person?  Do you do any sort of encryption with values such as SSN? 

 

We are working on a project to centralize identities amongst other campuses and would like input on how other schools are doing this.  One topic of conversation is not using SSN’s for reconciliation, I didn’t know if others had thoughts on this.

 

Thanks,

Paul

 

IT Accounts & Remedy Administration Manager

University of New Hampshire

Client Services

Primary: (603) 862-2377

Alternate: (603) 862-4242

Paul.Hodgdon@unh.edu

http://accounts.unh.edu

 

The information transmitted in this e-mail, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential/privileged material.  Any review, retransmission, dissemination, taking any action or other use thereof, by anyone other than the intended recipient, is prohibited.  Responses to this e-mail must not include any restricted or sensitive information.  If you received this in error, please contact the sender and destroy any copies of this message, including any attachments.

 

AttachmentSize
image001.png1.58 KB

Comments

Message from dedra.chamberlin@ucsf.edu

Hi Paul,

UC Berkeley and UCSF are working with the Registry workstream of the Community Identity Federation for Education and Research (CIFER) project to build our next gen ID match engine. The Registry workgroup developed a strawman proposal for building an ID Match engine and also spent time evaluating existing open source options. We are hoping to make significant headway on this project over the next few months, working in partnership with Kuali, which is also hoping to incorporate ID Match capability into its IAM tools. 

I will send out more info on this effort in a few days. 

Dedra Chamberlin
Deputy Director, IAM
UCB and UCSF



We are implementing a commercial product for identity matching, Oracle HECH 
(Higher Education Constituency Hub), at least partially because of strong integration with
Peoplesoft applications (such as Campus Solutions which we use for our student information
system).  HECH represents a central service that all SORs that onboard new members of
the community will interface with, and will replace ad hoc, home-grown matching code.

- Gary Chapman
  Sr IT Architect & Program Director, Identity Services
  New York University

Message from jeremy_rosenberg@sfu.ca

Hi Gary When we looked at HECH, the gotcha seemed to be that it wanted to write the matched information back to the SORs, which isn't really what we were after, we just need the match for downstream systems. Is that also your understanding? For the record, we have a home grown matching system that we are hoping to replace with an open source solution from the CIFER project mentioned previously in this thread. Jeremy On Jul 24, 2012, at 7:52 PM, Gary Chapman wrote: > We are implementing a commercial product for identity matching, Oracle HECH > (Higher Education Constituency Hub), at least partially because of strong integration with > Peoplesoft applications (such as Campus Solutions which we use for our student information > system). HECH represents a central service that all SORs that onboard new members of > the community will interface with, and will replace ad hoc, home-grown matching code. > > - Gary Chapman > Sr IT Architect & Program Director, Identity Services > New York University > >

We (The University of Texas Health Science Center at Houston) use NetIQ Identity Manager to implement our reconciliation matching rules.

We use the system generated identifier from each system of record (employee id, student id, etc), SSN if we have it, name fields, and birth information (date, city/place, country) to reconcile identities in our Systems of record (HR, Student System, Residents, UT Physicians, Guests) with identities in our central Person Registry.

We do not encrypt SSN in our Person Registry but we do treat it with the same care as any system that stores SSN such as an HR system.

 

Regarding the use of SSN… 

If you have it use it!  SSN is one of the most dependable attributes you will have access to for matching.  Yes, you must keep SSN safe.  You must restrict access to the Registry because it will store SSN.  Deciding to use SSN is serious.  It means that you must consider the privacy issues and security issues.  But I believe that the use of SSNs that have already been collected is justified and so is the extra security that must be applied to your Person Registry .  Don’t let the fear of mishandling SSN keep you from using it for identity reconciliation.  Just do it right.  Note that part of doing it right is to not require SSN.  Just use it if you have it. 

 

Regarding matching rules…

No matter what you choose to use to implement your matching rules (any off the shelf or home grown solution) you will have to design the set of rules that will be used.  And no matter what set of rules you design the results will include positive matches, false positive matches, negative matches, and false negative matches.  And most likely you will want to divide the negative matches into ‘no’ match and ‘possible’ match categories.  The thing to note about all this is that all errors (false positives and false negatives) and all ‘possible’ matches require regular manual effort to resolve.  So the design goal of your matching rule set is to minimize the manual effort required.  Note that false positives are most difficult to resolve.  Minimizing false positives will increase the number of false negatives.  Our way of mitigating the false negatives is to flag a subset of the negative matches as ‘possible’ matches and manually evaluate them.

 

In general our rules are:

Positive match = any identifier match (employee id, student id, SSN, driver license, etc)

Possible match = similar name/birth information (manual evaluation required)

Negative match = no identifier match and no similar name/birth information

 

But we have also found that with some systems of record we can use more loose rule sets and still maintain low error rates, so we adjust our rule sets per source in order to further minimize the manual effort required.

 

 

 

It sounds like HECH is assuming that you are an all PeopleSoft shop. Is that the case? If you only have one product that does HR and Students you may have something of a built in registry because you really only have one system of record. -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg Sent: Tuesday, July 24, 2012 10:00 PM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Reconciliation Process Hi Gary When we looked at HECH, the gotcha seemed to be that it wanted to write the matched information back to the SORs, which isn't really what we were after, we just need the match for downstream systems. Is that also your understanding? For the record, we have a home grown matching system that we are hoping to replace with an open source solution from the CIFER project mentioned previously in this thread. Jeremy On Jul 24, 2012, at 7:52 PM, Gary Chapman wrote: > We are implementing a commercial product for identity matching, Oracle HECH > (Higher Education Constituency Hub), at least partially because of strong integration with > Peoplesoft applications (such as Campus Solutions which we use for our student information > system). HECH represents a central service that all SORs that onboard new members of > the community will interface with, and will replace ad hoc, home-grown matching code. > > - Gary Chapman > Sr IT Architect & Program Director, Identity Services > New York University > >
Message from jeremy_rosenberg@sfu.ca

I believe HECH has connectors to interface with all kinds of systems. It was a spin off of their Multi Data Management solution, wrapped in a higher ed package. When the Oracle guys gave me the demo, it was the two way relationship with the upstream systems that represented the real value proposition. It seemed a little heavy if you only intended to merge the data and push it downstream, like you would be paying full price buy only using a fraction of the functionality. We actually use PeopleSoft HR and Student and in our legacy system I trust those SoRs to do the identity matching between them. Unfortunately, the matching is questionable sometimes and mistakes still get through that shouldn't. But the bigger problem is that it limits us in adding other SoRs. We've done pilots with our continuing studies department but without better identity match, I'm getting way too many duplicates. The identity match isn't only valuable for matching among SoRs, I've found that continuing studies has challenges just identifying the same person in subsequent terms. So people are getting a new ID every time they take a course. So in addition to SoR matching, I'm finding that we have a real need for temporal identity matching. (I just made that term up, somebody notify the jargon police) Jeremy On Jul 24, 2012, at 10:17 PM, Jones, Mark B wrote: > It sounds like HECH is assuming that you are an all PeopleSoft shop. Is that the case? > > If you only have one product that does HR and Students you may have something of a built in registry because you really only have one system of record. > > -----Original Message----- > From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg > Sent: Tuesday, July 24, 2012 10:00 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Reconciliation Process > > Hi Gary > > When we looked at HECH, the gotcha seemed to be that it wanted to write the matched information back to the SORs, which isn't really what we were after, we just need the match for downstream systems. Is that also your understanding? > > For the record, we have a home grown matching system that we are hoping to replace with an open source solution from the CIFER project mentioned previously in this thread. > > Jeremy > > On Jul 24, 2012, at 7:52 PM, Gary Chapman wrote: > >> We are implementing a commercial product for identity matching, Oracle HECH >> (Higher Education Constituency Hub), at least partially because of strong integration with >> Peoplesoft applications (such as Campus Solutions which we use for our student information >> system). HECH represents a central service that all SORs that onboard new members of >> the community will interface with, and will replace ad hoc, home-grown matching code. >> >> - Gary Chapman >> Sr IT Architect & Program Director, Identity Services >> New York University >> >>
In reading up on HECH, Oracle mentions this: "Rationalizing the person data to achieve the unique, complete and correct profile. This includes the ability to cross reference multiple records in various systems that point to the same individual, constructing a 'master' version of the record including a single linking ID across all systems." For those using HECH, what data elements are used/required from your source systems to make this happen? Paul -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg Sent: Wednesday, July 25, 2012 12:50 PM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Reconciliation Process I believe HECH has connectors to interface with all kinds of systems. It was a spin off of their Multi Data Management solution, wrapped in a higher ed package. When the Oracle guys gave me the demo, it was the two way relationship with the upstream systems that represented the real value proposition. It seemed a little heavy if you only intended to merge the data and push it downstream, like you would be paying full price buy only using a fraction of the functionality. We actually use PeopleSoft HR and Student and in our legacy system I trust those SoRs to do the identity matching between them. Unfortunately, the matching is questionable sometimes and mistakes still get through that shouldn't. But the bigger problem is that it limits us in adding other SoRs. We've done pilots with our continuing studies department but without better identity match, I'm getting way too many duplicates. The identity match isn't only valuable for matching among SoRs, I've found that continuing studies has challenges just identifying the same person in subsequent terms. So people are getting a new ID every time they take a course. So in addition to SoR matching, I'm finding that we have a real need for temporal identity matching. (I just made that term up, somebody notify the jargon police) Jeremy On Jul 24, 2012, at 10:17 PM, Jones, Mark B wrote: > It sounds like HECH is assuming that you are an all PeopleSoft shop. Is that the case? > > If you only have one product that does HR and Students you may have something of a built in registry because you really only have one system of record. > > -----Original Message----- > From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg > Sent: Tuesday, July 24, 2012 10:00 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Reconciliation Process > > Hi Gary > > When we looked at HECH, the gotcha seemed to be that it wanted to write the matched information back to the SORs, which isn't really what we were after, we just need the match for downstream systems. Is that also your understanding? > > For the record, we have a home grown matching system that we are hoping to replace with an open source solution from the CIFER project mentioned previously in this thread. > > Jeremy > > On Jul 24, 2012, at 7:52 PM, Gary Chapman wrote: > >> We are implementing a commercial product for identity matching, >> Oracle HECH (Higher Education Constituency Hub), at least partially >> because of strong integration with Peoplesoft applications (such as >> Campus Solutions which we use for our student information system). >> HECH represents a central service that all SORs that onboard new members of the community will interface with, and will replace ad hoc, home-grown matching code. >> >> - Gary Chapman >> Sr IT Architect & Program Director, Identity Services New York >> University >> >>
If it helps, I've received some clarification from Oracle re: HECH:

To the matching question and HECH, Campus Solutions delivered an HECH Connector that makes use of our External Search/Match functionality to perform searches against an external solution like HECH using rules defined in the Campus Solutions search/match set up, so it is easy to define the attributes you want to search on and the prioritization of the matches (what constitutes a more exact match, etc.) Obviously, if a school isn’t using Campus Solutions as an SIS, they’ll need to find a different way to tie into the HECH’s inherent search/match functionality.

In terms of publishing information out of the HECH, it includes a sophisticated data governance capability that allows an institution to define publication rules to spoke systems – as far as I know it doesn’t require that spoke systems subscribe but of course one of the values of a master data management system is the maintenance of a “golden record” that then provides that golden record to spoke systems.


-- 
Paul Erickson
Enterprise Architect
Information Services
University of Nebraska–Lincoln

tel:402 472 1657
http://is.unl.edu/        mailto:phe@unl.edu

Together, making the vision of UNL come alive through technology leadership





On 7/25/12 11:54, "Hodgdon, Paul" <Paul.Hodgdon@UNH.EDU> wrote:

In reading up on HECH, Oracle mentions this:
"Rationalizing the person data to achieve the unique, complete and correct
profile.  This includes the ability to cross reference multiple records in
various systems that point to the same individual, constructing a 'master'
version of the record including a single linking ID across all systems."

For those using HECH, what data elements are used/required from your source systems to make this happen?

Paul

-----Original Message-----
From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg
Sent: Wednesday, July 25, 2012 12:50 PM
Subject: Re: [IDM] Reconciliation Process

I believe HECH has connectors to interface with all kinds of systems.  It was a spin off of their Multi Data Management solution, wrapped in a higher ed package.  When the Oracle guys gave me the demo, it was the two way relationship with the upstream systems that represented the real value proposition.  It seemed a little heavy if you only intended to merge the data and push it downstream, like you would be paying full price buy only using a fraction of the functionality.

We actually use PeopleSoft HR and Student and in our legacy system I trust those SoRs to do the identity matching between them.  Unfortunately, the matching is questionable sometimes and mistakes still get through that shouldn't.  But the bigger problem is that it limits us in adding other SoRs.  We've done pilots with our continuing studies department but without better identity match, I'm getting way too many duplicates.  The identity match isn't only valuable for matching among SoRs, I've found that continuing studies has challenges just identifying the same person in subsequent terms.  So people are getting a new ID every time they take a course.  So in addition to SoR matching, I'm finding that we have a real need for temporal identity matching. (I just made that term up, somebody notify the jargon police)

Jeremy


On Jul 24, 2012, at 10:17 PM, Jones, Mark B wrote:

It sounds like HECH is assuming that you are an all PeopleSoft shop.  Is that the case?
If you only have one product that does HR and Students you may have something of a built in registry because you really only have one system of record.
-----Original Message-----
From: Identity Management Constituent Group Discussion list
[mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg
Sent: Tuesday, July 24, 2012 10:00 PM
Subject: Re: [IDM] Reconciliation Process
Hi Gary
When we looked at HECH, the gotcha seemed to be that it wanted to write the matched information back to the SORs, which isn't really what we were after, we just need the match for downstream systems.  Is that also your understanding?
For the record, we have a home grown matching system that we are hoping to replace with an open source solution from the CIFER project mentioned previously in this thread.
Jeremy
On Jul 24, 2012, at 7:52 PM, Gary Chapman wrote:
We are implementing a commercial product for identity matching,
Oracle HECH (Higher Education Constituency Hub), at least partially
because of strong integration with Peoplesoft applications (such as
Campus Solutions which we use for our student information system).  
HECH represents a central service that all SORs that onboard new members of the community will interface with, and will replace ad hoc, home-grown matching code.
- Gary Chapman
  Sr IT Architect & Program Director, Identity Services  New York
University
I think having a two way relationship is important. For us, two very important values are generated in our Person Registry and are back fed to each System of Record: email address, and our campus wide ID (UUID). This allows these two values to follow a person through affiliation changes and absence. -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg Sent: Wednesday, July 25, 2012 11:50 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Reconciliation Process I believe HECH has connectors to interface with all kinds of systems. It was a spin off of their Multi Data Management solution, wrapped in a higher ed package. When the Oracle guys gave me the demo, it was the two way relationship with the upstream systems that represented the real value proposition. It seemed a little heavy if you only intended to merge the data and push it downstream, like you would be paying full price buy only using a fraction of the functionality. We actually use PeopleSoft HR and Student and in our legacy system I trust those SoRs to do the identity matching between them. Unfortunately, the matching is questionable sometimes and mistakes still get through that shouldn't. But the bigger problem is that it limits us in adding other SoRs. We've done pilots with our continuing studies department but without better identity match, I'm getting way too many duplicates. The identity match isn't only valuable for matching among SoRs, I've found that continuing studies has challenges just identifying the same person in subsequent terms. So people are getting a new ID every time they take a course. So in addition to SoR matching, I'm finding that we have a real need for temporal identity matching. (I just made that term up, somebody notify the jargon police) Jeremy On Jul 24, 2012, at 10:17 PM, Jones, Mark B wrote: > It sounds like HECH is assuming that you are an all PeopleSoft shop. Is that the case? > > If you only have one product that does HR and Students you may have something of a built in registry because you really only have one system of record. > > -----Original Message----- > From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeremy Rosenberg > Sent: Tuesday, July 24, 2012 10:00 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Reconciliation Process > > Hi Gary > > When we looked at HECH, the gotcha seemed to be that it wanted to write the matched information back to the SORs, which isn't really what we were after, we just need the match for downstream systems. Is that also your understanding? > > For the record, we have a home grown matching system that we are hoping to replace with an open source solution from the CIFER project mentioned previously in this thread. > > Jeremy > > On Jul 24, 2012, at 7:52 PM, Gary Chapman wrote: > >> We are implementing a commercial product for identity matching, Oracle HECH >> (Higher Education Constituency Hub), at least partially because of strong integration with >> Peoplesoft applications (such as Campus Solutions which we use for our student information >> system). HECH represents a central service that all SORs that onboard new members of >> the community will interface with, and will replace ad hoc, home-grown matching code. >> >> - Gary Chapman >> Sr IT Architect & Program Director, Identity Services >> New York University >> >>

If your Person Registry is upstream from your SoRs writing corrections to the SoR might make sense, but if your Person Registry is downstream from your SoRs my opinion is that such changes should not be accepted from downstream.  If the Person Registry is downstream the assumption is that the SoR is authoritative for matching attributes and thus treated as always correct.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Gary Chapman
Sent: Wednesday, July 25, 2012 11:58 AM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Reconciliation Process

 

We expect each of our SORs to communicate with HECH via web services over an enterprise service bus, and for 

SORs to accept corrections to data fields (that have been used for matching) that may derive from other systems

having newer (or better or more authoritative) data.  Precedence rules and manual decision-making processes TBD!

 

So if, say, SSN, Name, and DOB were used for matching, then we want all participating SORs to have these fields 

(plus our university identifiers like NetID) synchronized on an ongoing basis (and which presumably they will pass 

along to their downstream systems).

 

So, the "writing back" is what we are looking for.

 

- Gary

 

Just to add 2cents as someone who maintains the data in our (homegrown but based on OpenRegistry) downstream person registry – Even though your feeds may (and ideally should) treat your SoRs “as always correct”, remember that they are not always correct and can be the victims of typos and inconsistent data entry, by both employees and students.  In addition to having “match rules/rakings” that can vary by SoR, you want to be sure your person registry has features that allow you to merge or split identities in response to data corrections made in your SoRs.

 

Also, in case this wasn’t already mentioned, you should also consider whether you really want to feed ALL person records from your SoRs into your central person-registry, or whether you should have a threshold of identity quality and completeness that your SoR records must meet before your person registry will accept them (and use them during matching).  Obviously there are trade-offs when doing that, but we’ve been fortunate enough here to be able to enforce that identities must have at least a first-name, last-name, and {date-of-birth or SSN} or the central person-registry will ignore them and the person will not receive any services provisioned by our central systems.  That’s been extremely valuable in keeping our potential-match population reasonable and workable.

 

Thanks,

Randy Smith

Identity Management Program Office within the Office of Information Security, Information Technology, http://www.it.usf.edu

LIB628C, 813-974-1338, rwsmith@usf.edu

University of South Florida

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jones, Mark B
Sent: Monday, July 30, 2012 1:54 AM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Reconciliation Process

 

If your Person Registry is upstream from your SoRs writing corrections to the SoR might make sense, but if your Person Registry is downstream from your SoRs my opinion is that such changes should not be accepted from downstream.  If the Person Registry is downstream the assumption is that the SoR is authoritative for matching attributes and thus treated as always correct.

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Gary Chapman
Sent: Wednesday, July 25, 2012 11:58 AM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Reconciliation Process

 

We expect each of our SORs to communicate with HECH via web services over an enterprise service bus, and for 

SORs to accept corrections to data fields (that have been used for matching) that may derive from other systems

having newer (or better or more authoritative) data.  Precedence rules and manual decision-making processes TBD!

 

So if, say, SSN, Name, and DOB were used for matching, then we want all participating SORs to have these fields 

(plus our university identifiers like NetID) synchronized on an ongoing basis (and which presumably they will pass 

along to their downstream systems).

 

So, the "writing back" is what we are looking for.

 

- Gary

 

Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.