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 Address, Email, Phone, Url Types
6. PRE6: Pre-defined list of prefixes, name types.
7. PRE7: 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
   • Changes to birth date, gender, source identifiers
2. If an existing name, 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 reconciliation results in a change of association then the update will fail.
4. Standardization and Normalization occur per PRE7.
5. Calculated Person Re-calculated [is this a post condition] (election algorithms, etc.)
6. 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