Reconciliation post January 2012 of Patient

Back to Patient_Administration#Submission / Proposals

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

D-MIM PRPA_DM000000UV

1. Action item: <>

R-MIM PRPA_RM201301UV02 Patient Activate

This R-MIM is completely out of sync with Person, and does not align with the D-MIM for at least the relationship PatientOfOtherProvider that has a CMET A_PrincipalCareProvision that was replaced by a class CareProvision in the D-MIM

1. Action item: Replace content from patientEntityChoiceSubject with the current Activate Person R-MIM

16-5-2012: decided to only replace the member structure in the Patient Activate RMIM with the member structure in the Person Activate.

Click on the thumbnail to see the resulting R-MIM

Note: that the Person topic covers non-Patients as well, which means that certain attributes are specific to Patient:

1. Person.quantity: PQ 0..1
2. Person.educationLevelCode: CD CWE 0..1
3. Person.disabilityCode: DSET<CD> CWE 0..1
4. Person.livingArrangementCode: CD CWE 0..1
5. Person.religiousAffiliationCode: CD CWE 0..1
6. Person.raceCode: DSET<CD> CWE 0..*
7. Person.ethnicGroupCode: DSET<CD> CWE 0..*
8. R_Guarantor universal
9. CareGiver class

Non-exhaustive list of changes versus the current Patient Activate:

• Replace PatientOfOtherProvider.A_PrincipalCareProvision with Role.CareProvision.performer.R_ResponsibleParty -- this could be open for debate but A_PrincipalCareProvision was removed form the D-MIM as well

16-5-2012: it's the other way around, the CMET was the newer solution, that needs to be fixed in the DMIM

• Changed PersonalRelationship relationship from E_LivingSubject to E_Person -- this should align with Person Activate so change both or none.

16-5-2012: change into E_Person in the Patient RMIM

• Added Member2 and relationship to ObservationEvent to support conveying households

16-5-2012: accept change

• Added Citizen.code

16-5-2012: accept change

• Added Employee.code

16-5-2012: accept change

• Added Guardian.code

16-5-2012: accept change

R-MIM PRPA_RM201302UV02 Patient Revise

1. Action item: Give this R-MIM the exact same content below the patientEntityChoiceSubject as Activate Patient

16-5-2012: accepted

R-MIM PRPA_RM201303UV02 Patient Demographics

1. Action item: Give this R-MIM the exact same content below the patientEntityChoiceSubject as Activate Patient

16-5-2012: accept change

R-MIM PRPA_RM201304UV02 Patient Identifiers

1. Action item: Replace comparable content in this R-MIM with Person Identifiers (PRPA_RM101304UV02

16-5-2012: accepted to use the new patient demographic RMIM as the basis for the new PatientIdentifier and apply all the constraints that are listed in the RMIM walkthrough

R-MIM PRPA_RM201305UV02 Patient Nullify

1. Action item: Replace comparable content in this R-MIM with Person Nullify (PRPA_RM101305UV02

16-5-2012: We don't see any differences

R-MIM PRPA_RM201306UV02 Patient 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.

16-5-2012: The cardinality 0..* is to support the query infrastructure.

R-MIM PRPA_RM201307UV02 Patient Registry Query By Identifier

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

16-5-2012: The cardinality 0..* is to support the query infrastructure.

R-MIM PRPA_RM201310UV02 Patient Registry Find Candidates Response

1. Action item: Give this R-MIM the exact same content below the patientEntityChoiceSubject as Activate Patient, with the exception of QueryMatchObservation

16-5-2012: Accepted.