Guideline- Identification Management -System Requirements wiki

Title page

MDM - Identification Management

Guideline to Software Requirements Specification

Overview
One of the main purposes of the Client Hub is to raise alert for suspect duplicate profiles that may exist within the system for a given party and provide with tools to manage the duplicate profiles (e.g. merge profile). Identification Management process is necessary to support these requirements.

A key component of the Identification Management process is GUID Management. A GUID is an identifier used to tag profile records that potentially belong to the same party. Put another way, a GUID can be viewed as representation of critical data element values that are specific to a Party. The process that evaluates the critical data elements for the population of profile records in order to assign GUID is called the Matching Process.

Purpose
This document describes the Software Requirements for Identification Management by assigning GUID to the profile records maintained within the Client Hub.

Definitions, Acronyms and Abbreviations
The following table describes terms used within this document and a brief definition of each:

Introduction
The following sections cover use cases within the Identification Management space.

Actor Survey
The following table lists the typical Actors within Business

Assumptions and Dependencies
The key assumptions are as follows:


 *  < List of Assumptions and Dependencies > 

GUID Computation - Initial Load
When the source data from Enterprise Business Systems is loaded into the staging area then client hub profiles are created. Each profile created in the staging area will be assigned a unique profile id. The goal of the GUID computation process is to assign GUID to each profile. The same GUID assigned to multiple profiles signifies that the profiles belong to the same party based on the matching rules defined.

If minimum requirements for an External Identification Link assignment are met for the profile, the name and address information along with the profile key will be sent to Vendor. Vendor will return the External Link. If minimum requirements for GUID calculation are met, GUID will be computed. For some profiles the data may not be sufficient to obtain the External Identification Link and / or GUID. The GUID values will remain blank in these scenarios.

The following table illustrates the order of invocation of the use cases required for implement the scenario along with corresponding functionality provided by each use case.

GUID Computation - Chaining
When a critical piece of data changes on a profile, GUID may need to be recomputed. This GUID change may trigger GUID re-assignment on other profiles. This dependency scenario is known as chaining. The example below illustrates chaining.



Initially all three records were assigned different GUIDs, which indicates that the profiles represent three different parties. The end user updated the second record by providing the SSN and DOB.



After the change the first record is linked to the second one through the SSN and address. The second and the third records are linked by the name, address, and date of birth. As a result all three records are linked by the same GUID. The chaining effect caused the linkage between record 1 and record 3 even though no data change occurred on these profiles and they represented different parties before the change in the second record.

GUID Computation - Critical Data Element Update
An update to a critical data element can trigger GUID recalculation. In this example the end user enters the SSN for a profile record.



The GUID is recalculated. As a result all five profiles are linked with the same GUID.



The following table illustrates the order of invocation of the use cases required for implement the scenario along with corresponding functionality provided by each use case.

GUID Computation – External Identification Link Update
External Identification Link change can be initiated from Firm due to a correction on the name and / or profile. The link change can also be initiated from Vendor. In both scenarios if a profile receives an updated maintained External Identification Link, the GUID can be recalculated. This may or may not result in a GUID change.

The following table illustrates the order of invocation of the use cases required for implement the scenario along with corresponding functionality provided by each use case.

Identification Management -GUID Computation
 < Matching Rules > 

 < Critical Data Element list that comprises a Profile > 

 < Exception Rules > 

Reliability

 *  < Mean Time Between Failures (MTBF) > 
 *  < Mean Time To Repair (MTTR) – TBD > 

Batch Mode – GUID Computation
 < The performance requirements for Identification Management > 

Near Real-time Operation – GUID Computation
 < The response time for GUID Computation in online mod > 

Capacity
 < Volume of Profile records > 

Design Constraints
 < Provide here > 

Online User Documentation and Help System Requirements
 < Provide here > 

Purchased Components
 < Provide here > 

Licensing Requirements
 < Provide here > 

Legal, Copyright and Other Notices
 < Provide here > 

Applicable Standards
 < Provide here >