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 align it with a) the encounter model, and b) the clinical statement pattern.
2. xxxxxxxxx

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