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. 06/25/12 PA telecom. Both D-MIMs and RMIMs should use the “D:RoleStatus” notation. Wendy noted that if we do come across any that are noted as value set, they should be changed to concept domain. Wendy will contact Alexander Henket to attempt to get this done for the Person models.

1 260712 Alexander Henket - Fixed all occurrences of statusCode (Act/Entity/Role) in the D-MIM to say Concept Domain rather than Value Set.

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]? 062512 PA telecon It seems that cardinality of Person.name is the same in the D-MIM and the Person (identified) CMET. The WG is not sure to what the comment refers.

2 260712 Alexander Henket - After speaking to Irma: The D-MIM is ok, the problem applies to CMETs not Person/Patient topics. Hence this is resolved/never been a problem

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. 062512 PA telecon The WG agrees that the models should consistently use the concept domain notation.

1 260712 Alexander Henket - Changed OtherIDs.statusCode in PRPA_RM101301UV from Concept Domain RoleStatus to Value Set RoleStatus. All D-MIM statusCode attributes were changed from Value Set to Concept Domain. This R-MIM is now a valid constraint on the R-MIM.

2 260712 Alexander Henket - Changed Role.subjectOf.CareProvisionEvent into PatientOfOtherProvider.subjectOf.A_PrincipalCareProvision in PRPA_RM101301UV conformant to the D-MIM where same change was applied

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 062512 PA Telecon – the PAWG accepts this change.

1 260712 Alexander Henket - Changed has been applied. Change Nation.code from D:EntityCode to D:NationEntityType to match D-MIM and PRPA_RM101301UV

2 062512 PA Telecon - the PAWG accpts this change.

2 260712 Alexander Henket - Change asOtherIDs.statusCode from V:RoleStatus to D:RoleStatus to match PRPA_RM101301UV. D-MIM change documented elsewhere

3 260712 Alexander Henket - Changed Role.subjectOf.CareProvisionEvent into PatientOfOtherProvider.subjectOf.A_PrincipalCareProvision in PRPA_RM101302UV conformant to the D-MIM where same change was applied

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 062512 PA Telecon – the PAWG accepts this change.

2 260712 Alexander Henket - Changed Role.subjectOf.CareProvisionEvent into PatientOfOtherProvider.subjectOf.A_PrincipalCareProvision in PRPA_RM101303UV conformant to the D-MIM where same change was applied

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

1 062512 PA Telecon – the PAWG accepts this change.

1 062512 Alexander Henket – Change applied. Change Member.effectiveTime from IVL<TS> to QSET<TS> to match D-MIM

2 062512 PA Telecon - The PAWG considers this an error in this model. It should be otherIDs instead of role.

2 062512 Alexander Henket – Change applied. Changed Role into OtherIDs.

3 062512 PA Telecon - As a result of item #2 above, this was modeled correctly.

3 062512 Alexander Henket – No change

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.

1 062512 PA telecon - The cardinality 0..* is to support the query infrastructure.

1 262512 Alexander Henket - The query infrastructure does not require 0..* on parameters. Currently I could ballot negative minor on our own model for implying that one person could e.g. have more than one birthTime. No change applied

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".

1 062512 PA Telecon - The cardinality 0..* is to support the query infrastructure.

1 262512 Alexander Henket - The query infrastructure does not require 0..* on parameters. Currently I could ballot negative minor on our own model for implying that one person could e.g. have more than one birthTime. No change applied

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

1 062512 PA telecon - The WG agrees that the models should consistently use the concept domain notation.

1 260712 Alexander Henket - Changed OtherIDs.statusCode in PRPA_RM101301UV from Concept Domain RoleStatus to Value Set RoleStatus. All D-MIM statusCode attributes were changed from Value Set to Concept Domain. This R-MIM is now a valid constraint on the R-MIM.

2 260712 Alexander Henket - Changed Role.subjectOf.CareProvisionEvent into PatientOfOtherProvider.subjectOf.A_PrincipalCareProvision in PRPA_RM101310UV conformant to the D-MIM where same change was applied