Update or Edit SoR Person

Actors

• User
• OpenRegistry
• Database

Pre-Conditions

1. PRE1: User is authenticated and authorized to use system.
2. PRE2: User has chosen SoR to work with.
3. PRE3: User has chosen Person to update (most likely via Search Person Use Case)
4. PRE4: User has permissions to update person.
5. PRE5: Pre-defined list of prefixes, name types.
6. PRE6: Defined Standardization and Normalization Algorithms

Flow

1. User modifies and submits changes to the person. The following changes are allowed:
   • Modification to an existing name (i.e. changing name type)
   • Addition of a new name
   • Deletion of an existing name
   • Changes to birth date, gender, source identifiers (generated identifiers cannot be changed by an SoR)
2. If birth date, gender, or source identifier is modified, reconciliation MUST be re-executed similar to the rules in the Add Person Use Case.
3. If the legal or formal name changes, reconciliation MUST be re-executed similar to the rules in the Add Person Use Case.
4. If reconciliation results in a change of association then the update will fail.
5. Standardization and Normalization occur per PRE6.
6. Calculated Person Re-calculated [is this a post condition] (election algorithms, etc.)
7. Attribute Re-calculation

Post-Conditions

1. POST1: Changes are sent to downstream systems.

Business Rules

• User can only have one preferred and official name. All other names, can have multiple values (i.e. Formerly Known As).
• For Name: Name Type and First Name are required
• Changes to fields are controlled by authorization rules.
• Additional required fields or validations may be defined in meta data. They may be per deployment, or SoR.

Exceptions