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.
  • Note: PA view sees Admitter as the author of Encounter Activate and the authors of subsequent events are authorOrPerformer of the ControlActProcess.- grs 20110111
  • Rene: which presumably means that during the lifecycle of the encounter the author (of the Encounter) will remain one and the same.
  • Gregg: agree, assuming that the encounter type does not change during lifecycle
• 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.
  • Note: at the October 2010 PA agreed to add pertinentInformation ActRelationship to Procedure. Does it make sense to have a set of performers and a separate set of procedures linked only through encounter? - grs 20110111
  • Rene: when it comes to the PA encounter model
    1. there is a requirement for procedure.code (without any particopations, the performer of such procedures is of no interest)
    2. the performer in an encounter model is the performer of the Encounter. If indeed a performer of an encounter covers the concept Attender (as we now believe it does), then you probably realize that this is certainly not the performer of the procedure which happened during the encounter.
• 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.
  • Note that Performer and ParticipationAncillary (parent of ADM, ATND) are siblings. PRF is A person, non-person living subject, organization or device that who actually and principally carries out the action whereas ATND is The practitioner that has responsibility for overseeing a patient's care during a patient encounter. Suggests that Performer is a doer rather than responsible. - grs; 20110111
  • 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 ResponsibleOragnization 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.
     • This issue/question is only relevant should PA come to the conclusion that Author and Admitter are not the same, or not in a specialization hierarchy
   • Needs discussion within PA, probably to distinguish between the Author and the (encounter specific participations) Attender or Admitter. (PA: if, any: 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. (PA: if any: Attender)

20110111 - PA / Q1: (see PA minutes for full details) discussed the three issues above. Use of Concern as the topmost grouper needs to be investigated. Outcomes:

1. makes sense if the responsible organization can be different on the PCR than on the ENC
2. needs to be investigated, are we talking about the same semantics, is Admitter perhaps a specialization of Author?
3. needs to be investigated, are we talking about the same semantics, is Attender perhaps a specialization of Performer?

20110111 - PC / Q2: (see PC minutes for full details).

• Rene presented a summary of the discussion in Cambridge as well as the 'encounter/care provision/concern' hierarchy.
• Charlie Bishop notes that the use of '<=PCPR' in the PC D-MIM is probably in error, it should be '='. This is related to the specific way in which patient Care uses the PCPR act.
• The issues themselves are worthwile to investigate.

'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

The reason act relationship (in general) is used to show the reason or rational for a service. The focal act in most D-MIMs has a reason relationship. The Patient Administration domain contains a reason-for-Encounter; the Patient Care domain doesn't contain a reason-for-CareProvision.

• Clinical Statement Pattern:
  • [Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply] RSON [Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply]
  • Used to show the reason or rational for a service (for instance source "treadmill test" has reason "chest pain").
• Pharmacy D-MIM:
  • reason to SupportingClinicalInformation - this allows the description of the indication for the medication treatment using the A_SupportingClinicalInformation[universal] CMET. This act relationship has a priority number attribute; therefore if more than one reason for the medication act, the "order" in which these should be evaluated may also be communicated.
• 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.

Proposed change:

• add reason to the CareProvision D-MIM.
  • Alternatives considered/rejected: the clinical statement pattern could be used to model 'the reason for an Act X' (inclusive of that Act X itself). This set of objects in turn is associated with the CareProvision through act relationships - this is however not the same semantic concept as the "reason for CareProvision".

20110111 PC / Q2. Charlie: this may actually be a reason to look again at the act relationship used between the PCPR act and the clinical statement model. One of those may be RSON.