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)
Contents
- 1 D-MIM PRPA_DM000000UV
- 2 R-MIM PRPA_RM201301UV02 Patient Activate
- 3 R-MIM PRPA_RM201302UV02 Patient Revise
- 4 R-MIM PRPA_RM201303UV02 Patient Demographics
- 5 R-MIM PRPA_RM201304UV02 Patient Identifiers
- 6 R-MIM PRPA_RM201305UV02 Patient Nullify
- 7 R-MIM PRPA_RM201306UV02 Patient Registry Query By Demographics
- 8 R-MIM PRPA_RM201307UV02 Patient Registry Query By Identifier
- 9 R-MIM PRPA_RM201310UV02 Patient Registry Find Candidates Response
D-MIM PRPA_DM000000UV
- 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
- 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:
- Person.quantity: PQ 0..1
- Person.educationLevelCode: CD CWE 0..1
- Person.disabilityCode: DSET<CD> CWE 0..1
- Person.livingArrangementCode: CD CWE 0..1
- Person.religiousAffiliationCode: CD CWE 0..1
- Person.raceCode: DSET<CD> CWE 0..*
- Person.ethnicGroupCode: DSET<CD> CWE 0..*
- R_Guarantor universal
- 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
1 260712 Alexander Henket - Changed in D-MIM
- 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
1 260712 Alexander Henket - Changed E_LivingSubject into E_Person
- Added Member2 and relationship to ObservationEvent to support conveying households
16-5-2012: accept change
1 260712 Alexander Henket - Applied change
- Added Citizen.code
16-5-2012: accept change
1 260712 Alexander Henket - Applied change
- Added Employee.code
16-5-2012: accept change
1 260712 Alexander Henket - Applied change
- Added Guardian.code
16-5-2012: accept change
1 260712 Alexander Henket - Applied change
R-MIM PRPA_RM201302UV02 Patient Revise
- 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
- 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
- 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
- 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
- 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
- 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
- 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.