You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »


DRAFT - DRAFT- DRAFT

TIER Registry and DATA and API workgroups have provided an ID Match POC in September 2017 This followed work done in earlier projects and Benn Oshrin brought this out for demo purposes.  During December and January of 2018 refinement of a proposed architecture and of the POC ID Match has been underway.   Calling structures to the RESTFUL API and discussions on how it can fit into the TIER Entity Registry - Identity OnBoarding process.

An architecture flow and event document for  TIER ENTITY REGISTRY - Identity OnBoarding  can be found at 

TIER Entity Registry - Identity Onboarding (1).pdf


The intent of this document is to indicate in a high level sense how to align ID Match in your institutions processes.  It is intended to describe a pattern for institutions to use when building a Registry Onboarding process.  

The ID Match is a restful API that can be called in many architectural patterns and or sources.   The workgroups have discussed over several iteration and about 2.5 months and suggest calling ID Match component from the "Registry Update Controller" shown within the Identity OnBoarding flow.

Entity Registry - onboarding ID Match detail

Step-by-step guide

Determine your initial System of Record(s)  (SOR) to be onboarded or interfaced into your entity registry. 

      


  1. Person is entered or updated (or self enters) into any of an  institutions SORs.  The event/action needs to be captured and or acted upon for updates that must be forwarded to the registry.  

    1. Map the attributes in your SOR into the normalized TIER information structure.  This would have been done during the process of configuring  the SOR to forward data to the registry.

      1. This structure will reflect the TIER minimal registry structure plus any additional person attributes or extensions you desire to store in your registry. 
      2. The TIER registry working group encourages you to maintain only data needed for access management in the registry.  OF course you may extend as needed of course. 
      3. It is intended that in Entities other than people will be accommodated by the registry.  Additional entities beyond person are intended to  be added in later work.  There are proposed structures for application entities in early stages of design.
      4. Attributes are normalized into a consistent to allow the disparate data formats often encountered in each SOR to be brought into a single agreed upon form and format.  Normalized data is more easy to match and compare to locate existing individuals in the registry. 
    2. Some institutions may have only a couple SORs while others could easily have 10 or more significant sources of persons being onboarded into a single Identity Registry.   
    3. There is value in following the normalization and onboarding pattern even if your institution only has a single SOR at implementation time.  You will be ready and insured for the eventual addition of additional SOR(s).   
    4. Activities above result in a connector to normalize and feed info from the Source to registry onboarding.

  2. Once you determine the data format.  Determine how you will trigger API call or messages (choice is your institutions to make)

    1. When data changes in the SOR it must communicate that change to the registry.

    2. API or Messaging can be used to move the data. 
    3. You must process the changed data (add, update and deletes), the lifecycles of individuals within the SOR and your institution.
    4. SIS, HR, Alumni, hospital staff HR, etc all may be managed in distinct manner by the specific SOR,  when moved to the registry the key is determining a unique person. Normalized data should be in place before matching is attempted.  The SOR itself is generally unaware of what (or if) another SORs may have already provided to the registry.
    5. Ideally the SOR systems move data in near real time to the registry.  If the SOR systems lag in time before sending you can expect to have issues in data currency and accuracy based on SOR data being consumed with time lags.  Depending on the specifics of your system cycles this is manageable, expected. 
  3. Call the messaging or restful API to transmit data to the registry intake Receive Source Person Info. 
    1.   This is well suited for a message based solution, TIER working groups have built demos with Rabbit MQ.  However,  you can choose other messaging tools or use an restful API approach if you prefer.
    2. Receive 'Source Person' info/message,  this component of the Registry Update Controller is responsible for
    3. Handling the SOR information as it arrives for processing. 
      1. Is it correctly normalized
      2. Is it "complete" to process further (and other such data handling checks
    4.  Call the TIER ID Match component to see if this person has already been onboarded into the registry at a previous date time.
  4.  IdMatch
    1. This is a restful API
    2. This component stores information related to previous matching history/experience.  These are identified by the idMatch reference identifier.
    3. Id Match can return three basic responses.  ID Match returns a result after recording the results internally.
      1. This is a "new entity no match found",
      2. This entity matches this "existing registry entity matched exactly",
      3.  This entity has "multiple potential matches"  but Matching component needs help from a data steward.
      4.  An ID Match reference identifier will be returned identifiers will be returned by the API for additional processing options.
  5. The onboarding Registry update controller will need to be configured to handle the returns from the idMatch based on institutional choices.  
    1.  New person no match found  - the controller will invoke the no match  to ADD a new person in the registry path
    2. Existing registry person matches exactly - the controller will invoke the update the person in the registry path
    3. Multiple possible matches requires additional insight of a person to do onboarding.  Data Stewards should work with these entries to assure accurate result and minimize duplicates.
      1. A choice to be made:
        1. Add the possible match in a "pending resolution" state to the registry. You may also want to mark all possible matches in a pending resolution state.
        2. Do not add to the registry.   Wait for the data steward to review the data involved of the possible matches and the incoming data and then take action to move the data forward.
        3. Persons with appropriate knowledge at your institution can steward the data and provide the resolution in either case. 
          1. the pending resolution can allow for processes to move forward with the knowledge that  this could be a duplicate and corrective action may be needed once the case is resolved.
          2. do not allow pending entries to move forward.  This avoids the need to undo processes  that were allowed to proceed.  It does create a delay in processes that consume the Institutional Person - pending resolution
        4. Institutions should carefully consider the choice of whether to use "pending resolution updates" or not.  This is a key decision that has consequences regardless of the path chosen.
          1. Delay entry to the registry for pending resolution
            1. ...  
          2. Allow update to registry before pending resolution is cleared.
            1. ...
    4. Manual Investigation of Pending resolution entries.
    5. Create / Update the registry Entry based on data steward decision
  6. Institutional Person established and changes communicated.  


Other considerations for managing the IdMatch service. 

  1. Should the Institutional Identifier be contained in the ID Match data content with Institutional Identifier.
    1. This is backfeed to the IdMatch data is a good feature.    
  2. Periodic updates of Id Match database from the registry.
    1. IdMatch  database contains certain information that should be periodically refreshed from the source.  (name, phone, etc)
      1. periodic refresh
      2. event based update when changes occur to the data elements in the Match database.
      3. both ( this would be the preferred solution )

There are more steps (7 thru 11 from the identity onboarding ) to consider related to the Identity Onboarding, however since this document is focusing on the ID Match they are not covered here.  The Credential Management controller and the Groups Update Controller will not be treated in this document.

 

  • No labels