Add SoR Person

Owned by ScottS
Last updated: Sept 02, 2009Version comment
3 min read

Actors

  • System of Record
  • User
  • Database
  • OpenRegistry

Pre-Conditions

  • PRE1: User is authenticated and authorized.
  • PRE2: User has chosen a system of record to work with (assuming permissions)
  • PRE3: Algorithm to reconcile users is defined outside of use-case
  • PRE4: Pre-defined list of identifiers that can be entered is configured
  • PRE5: Appropriate Prefix information has been provided as reference information
  • PRE6: Defined list of required identifiers and the algorithm for creating them. Algorithms come in two flavors: those that depend on data from the person and identifiers that are automagically generated (i.e. random, sequence, etc.)
  • PRE7: Defined list of election algorithms to be executed.
  • PRE8: Defined list of calculation rules to be executed.
  • PRE9: Defined transformation and normalization workflow/rules.

Flow

  1. User provides the following information to the OpenRegistry System:
    1. Required:
      • One or More Names (each name is required to have a Name Type and First Name, all other portions are optional).
      • Gender
    2. Optional:
      • System of Record Identifier (recommended that systems that have it, send it)
    3. Selection - Per PRE3, the additional required fields for reconciliation are defined by the algorithm. The default algorithm has the following rules: The following attributes are required:
      • System of Record Identifier (if known)
      • Name
      • One or more of Identifiers (such as NetId, SSN, etc.) or Two or more of Date of Birth, home/personal email address, home/cellular telephone number
  2. OpenRegistry attempts to reconcile system based on the reconciliation algorithm defined by PRE3.
    1. If there is 1 EXACT match, do
      1. If the exact match already contains an SoR record for this person, ERROR is thrown. This may mean displaying, "this person already exists. Did you want to "update" then or "add a role?".
      2. If the exact match DOES NOT contain an SoR record, the SoR record is added.
    2. If there are 0 matches do: create a new SoR record for this person.
    3. If there are > 1 matches:
      1. Return the following fields to the user:
        • Confidence Level
        • Matched Fields
        • Official Name
        • Gender
        • Current Title/Affiliation
      2. User has two options: choose who they meant, or add a new person
      3. If they choose to add a new person, a new SoR record is created (NOTE: does this assume things like we checked to make sure SSN is not entered twice, etc.) and no link is created between an SoR person and an existing Calculated Person. A NEW calculated person should be created.
      4. If they choose who they meant, and an SoR record does not exist, a new SoR record is created and the link between SoR person and Calculated Person is created. If an SoR Record DOES exist, its an ERROR, and the user will most likely be transitioned to an Update Person Use Case.
  3. SoR Record stored in the repository is transformed and normalized per PRE10.
  4. When a new calculated person WILL BE created, the appropriate identifiers should be created. See PRE6.
  5. When a new calculated person WILL BE created, an activation code MUST be created for them. See PRE9.
  6. Election Algorithms execute See PRE7.
  7. Trigger of business rule calculations. See PRE8
  8. If a System of Record Identifier is not supplied, one should be created.
  9. Return constructed SoR Person, as well as SoRId and activation code to user.

Post Conditions

  • In most scenarios, if a person is added, we should transition to the Add Role Use Case. In the event of a UI related transfer, fields may be pre-populated with email address and phone number.

Business Rules

  • BR1: Provided phone number should be stripped of all characters besides numbers for comparison
  • BR2: Email Address should be of the standard format
  • BR3: First Name, Last Name, Gender are required reconciliation fields when the person is not known to exist in OpenRegistry.
  • BR4: Ultimately, the returned fields are dependent on permissions.
  • BR5: All errors MUST be logged.
  • BR6: All actions from this use case are logged for auditing purposes.
  • BR7: Per the Generate Activation Key use case, creating a new person creates a new Activation Key.

Exceptions

  • EX1: If any of the identifiers cannot be created, the flow should fail.
  • EX2: If any rule calculation fails, the flow should fail.
  • EX3: If for some reason, a decision can't be made about whether to create a new person or link to an existing person, an ERROR should be flagged.