Reconciliation post January 2012 of Person

Back to Patient_Administration#Submission / Proposals

This page holds action items after analysis of the January 2012 Person R-MIMs in relation to each other and the D-MIM Author: --[User:Alexander Henket|Alexander Henket] 14:21, 20 February 2012 (UTC)

D-MIM PRPA_DM000000UV

Role.statusCode is V:RoleStatus on just about every Role, but in all R-MIMs it is D:RoleStatus, except for asOtherIDs which is V:RoleStatus in all cases.

1. Action item: should update D-MIM and R-MIMs, except documented why it should be V:RoleStatus, to say D:RoleStatus
2. Action item: should not have attribute required on Person.name as this effectively makes a validly derived Person [identified] impossible.

1 060712 Alex – This inconsistency seems to need to be resolved. On the surface it seems that the D-MIM Role.statusCode (V:RoleStatus) should be used in all the R-MIMs, but this may depend on the meaning of the “V:” versus “D:”. In discussions and research, it seems that the “V: “ designation signifies a value set, or a set of codes taken from one or more code systems, while a concept domain. This might mean that the D should be used in the D-MIM and V might be used in the RMIM.

2 060712 Alex – This refers to the constraint on Person that reads “At least one of the id or name must be valued”. I read the note to say either Name or ID is required. Does this still cause a problem with the possibility of validly deriving a Person [identified]?

R-MIM PRPA_RM101301UV02 Person Activate

Used as the basis for comparison. It aligns with the D-MIM, except for Role.statusCode (see D-MIM paragraph above)

1. Action item: Change all Role.statusCode from D:RoleStatus to V:RoleStatus to match D-MIM or change the D-MIM from V:RoleStatus to D:RoleStatus

1 060712 Alex – This inconsistency seems to need to be resolved. Please see note above.

R-MIM PRPA_RM101302UV02 Person Revise

1. Action item: Change Nation.code from D:EntityCode to D:NationEntityType to match D-MIM and PRPA_RM101301UV as per the documentation.
2. Action item: Change asOtherIDs.statusCode from V:RoleStatus to D:RoleStatus to match PRPA_RM101301UV as per the documentation -- note: must also update D-MIM

1 060712 Alex – This inconsistency seems to need to be resolved. Please see note above. 2

R-MIM PRPA_RM101303UV02 Person Demographics

1. Action item: Change asOtherIDs.statusCode from V:RoleStatus to D:RoleStatus to match PRPA_RM101301UV as per the documentation -- note: must also update D-MIM

1 060712 Alex – This inconsistency seems to need to be resolved. Please see note above.

R-MIM PRPA_RM101304UV02 Person Identifiers

1. Action item: Change Member.effectiveTime from IVL<TS> to QSET<TS> to match D-MIM and all other Person models that carry this attribute
2. Action item: Either document R-MIM to say that asOtherIDs was omitted, explain that asRole also covers asOtherIDs, or add it to the model
3. Action item: Document why asRole has gained the attributes id, statusCode and effectiveTime as well as the relationship E_Organization identified/confirmable, or remove from the model

R-MIM PRPA_RM101305UV02 Person Nullify

1. Action item: <none>

R-MIM PRPA_RM101306UV02 Person Registry Query By Demographics

1. Action item: Document why most query parameters are 0..*, which means AND logic. It is unlikely that someone has e.g. multiple birthTime, or deceasedInd values. All value attributes are already 1..*, so the OR logic is covered.

R-MIM PRPA_RM101307UV02 Person Registry Query By Identifier

1. Action item: Document why query parameter IdentifiedPersonIdentifier is 0..* (AND logic), while its value attribute is also 1..* (OR logic). Use case could be "Person with id 1 AND id 2" versus "Person with id 1 OR id 2".

R-MIM PRPA_RM101310UV02 Person Registry Find Candidates Response

1. Action item: Change asOtherIDs.statusCode from V:RoleStatus to D:RoleStatus to match PRPA_RM101301UV as per the documentation -- note: must also update D-MIM