Three PC/PA harmonization issues

The Encounter (ENC) act is a specialization of the Care Provision (PCPR) Act - and yet there are inconsistencies between the Patient Administration models and the Patient Care models when it comes to a number of issues. This proposal seeks to harmonize/address some of these issues.

These issues were initially touched upon during the October 2010 WGM In Cambridge. See also the Requirements for an Universal Encounter model wiki page and the links near the top of that page. Author: Rene Spronk, Ringholm bv, (consultants disclosure:) volunteer work on behalf of HL7 Norway.

Use of Author/Performer/Responsible

The Patient Administration and Patient Care domains are using some of the key participations in slightly different ways; or they are present bin one D-MIM and not in another. This makes it difficult to manage hierarchies in which some of the Acts are CareProvisions and others are Encounters.

From the Patient Administration D-MIM:

• Author: Not present; no such association with the Encounter act.
• Performer: Optional association to one or more practitioners who will principally carry out the actions in a scheduled patient encounter. Need not be the principal responsible actor, e.g. a surgery resident operating under supervision of attending surgeon. Note: this participation is used only in appointment messages.
• Responsible: Optional association to one or more healthcare provider organizations that hold clinical responsibility for the patient encounter. Note: only one responsibleParty participation should be in the active state at a time.

From the Patient Care D-MIM:

• Author: The party that requests, promises or records the Care Provision. This may be an assigned person or organization (R_AssignedParty) such as a healthcare provider, a related party (R_RelatedParty) such as a family member or court, or the patient (R_Patient) themselves.
• Performer: The party or parties, who are responsible for the scope of care identified by the Care Provision Act and its related conditions and care plans. However, this person or organization may have "supervisors" or "monitors" who carry related management or regulatory responsibilities for the care.
  • Care may be provided to a target of care by a broad range of providers. In a patient care example, care may be provided by the patient (R_Patient) themselves, the family members or other lay care takers (R_RelatedParty), a myriad of individual professional care providers or care provider organizations (R_AssignedParty). Medical devices may participate in care, but obviously cannot take responsibility for care. In a non-patient care scenario, care may be provided to geographic sites by environmental engineers (R_AssignedParty).
  • In many cases, the "author" and the "performer" are the same party. However, in a request for care, the "author" is requesting and the "performer" is the one who will take on a responsibility for care.
• Responsible: Not present, no such association with the CareProvision act.
  • Responsible is however present in the care statement pattern.

From the RIM:

• Author: (originator) A party that originates the Act and therefore has responsibility for the information given in the Act and ownership of this Act.
• Performer: A person, non-person living subject, organization or device that who actually and principally carries out the action. Device should only be assigned as a performer in circumstances where the device is performing independent of human intervention. Need not be the principal responsible actor.
• Responsible: The person or organization that has primary responsibility for the act. The responsible party is not necessarily present in an action, but is accountable for the action through the power to delegate, and the duty to review actions with the performing actor after the fact. This responsibility may be ethical, legal, contractual, fiscal, or fiduciary in nature. Example: A person who is the head of a biochemical laboratory; a sponsor for a policy or government program.

Proposed changes:

1. Add the Responsible participation to the CareProvision Act in the Patient Care D-MIM. This to a) align it with the encounter model, b) to align it with the clinical statement pattern, and c) to allow one to identify some party that is legally responsible but otherwise not involved.
2. When it comes to Author: looking at the D-MIMs this seems to play a key role in moods other than EVN, notably in INT mood. The Patient Care D-MIM explicitely documents this; the Scheduling domain (which can be used to schedule encounters, or to schedule care provisions) contains Author and Performer. The moodCode in the Patient Administration D-MIM isn't fixed, as such an Author participation should be added to the Patient Administration D-MIM.
   • Requires discussion: both domains may wish to constrain it out in EVN-mood based R-MIMs - a common policy should be defined by both WGs when Author should be constrained out of R-MIMs.
   • Needs discussion within PA, probably to distinguish between the Performer and the (encounter specific participations) Attender or Admitter.
3. Performer: the fact that one is allowed to use this in an appointment, but not in the actual encounter which is a result from that appointment points out that there is an inconsistency in the Patient Administration domain.
   • Needs discussion within PA, probably to distinguish between the Performer and the (encounter specific participations) Attender or Admitter.

'Encounter Context' CMET defined by PatientCare

The A_CareEvent[universal] CMET, as used in the Patient Administration D-MIM, is used to identify the 'context' of the encounter. It currently contains a rather minimalistic version of a CareProvision Act. An encounter may be part of either an encounter or a care provision, or it may be part of a concern. (See Requirements for an Universal Encounter model for details). As such this CMET (or a replacement thereof to be included in the Patient Administration D-MIM) should be modified to allow for the proper identification of the context of an encounter.

Note that the modeling depends in part on the outcomes of the discussion regarding the harmonization of some key participations.

Add Reason to CareProvision D-MIM

xx and show why reason in clinical statement is not a solution to the use-case

• Patient Administration D-MIM:
  • reason (ObservationDx) - an optional association from the focal encounter (source) to one or more diagnoses (target). The contextConductionInd is set to "true" because the encounter and the observation have the same subject (the patient). Each diagnosis is sent in a separate A_ObservationDx CMET. The type of diagnosis is determined by the Observation.code within the A_ObservationDx CMET; "ADMX" for an admission diagnosis, "INTDX" for an interim diagnosis, and "DISDX" for a discharge diagnosis. Multiple diagnoses of the same type can be rank ordered using the reason.priorityNumber.