This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Reconciliation post January 2012 of Patient"

From HL7Wiki
Jump to navigation Jump to search
Line 30: Line 30:
 
''16-5-2012: it's the other way around, the CMET was the newer solution, that needs to be fixed in the DMIM''
 
''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.
 
* 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
 
* Added Member2 and relationship to ObservationEvent to support conveying households
 
* Added Citizen.code
 
* Added Citizen.code

Revision as of 23:24, 15 May 2012

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

PRPA RM201301UV PostJan2012.png

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
  • Added Citizen.code
  • Added Employee.code
  • Added Guardian.code

R-MIM PRPA_RM201302UV02 Patient Revise

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

R-MIM PRPA_RM201303UV02 Patient Demographics

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

R-MIM PRPA_RM201304UV02 Patient Identifiers

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

R-MIM PRPA_RM201305UV02 Patient Nullify

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

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.

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

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