Short Description

The PACIO Advance Directive Interoperability (ADI) Connectathon track covers Portable Medical Orders (such as POLST) in preparation for an STU2 version of the standard.

Long Description

Goals

  • Testing Portable Medical Orders for STU2 development and potentially test changes to STU1 (that are adopted in STU2 work), depending on the participants that engage
  • Test and gather feedback on the design and implementation feasibility of the PACIO Advance Directive Interoperability Implementation Guide and its feasibility and applicability for real world use.
  • Facilitate discussion around planned content types found in portable medical orders for life-sustaining treatments.
  • Identify areas of improvement and expansion of the current use cases and advance directive content type of person authored advance directive information.
  • Foster mindshare and innovation ideas on potential applications of advance directive interoperability in the real world


Overview

Physician Authored Portable Medical Orders - Practitioner-created portable medical orders created with the patient and/or their advocate or proxy if they lack capacity. These are medical orders that contain concepts for the person's decisions to receive or not receive CPR, and the initial treatment orders related to life-sustaining treatment meant to restore, prolong, or sustain the life of the patient. These orders inform emergency responders and EMS staff and are commonly utilized in an emergency or during an urgent health crisis. These orders are communicated in the form of a document and typically contain information related to multiple medical intervention decisions.

Patient Generated Personal Advance Care Plan - Systems used to create and update patient-generated advance care plans through a patient-directed process need a way for individuals to communicate information about their advance medical care goals, preferences, and priorities. Individuals need a way to generate and update information related to their advance directives so that their current wishes can inform provider-generated care plans. Interoperable exchange of the advance directive documentation supports more effective sharing of this information across transitions of care and enables practitioners to create person-centered care plans that align with a patient’s values, goals of care, treatment preferences, and quality of life priorities when a patient can no longer communicate for themselves.

Advance directive interoperability is a complex area that involves many stakeholders. The HL7 sponsor for this IG is the Patient Empowerment work group. HL7 Co-sponsor workgroups include Patient Care, Community Based Care and Privacy, and Orders & Observations. In order to reach out to a broader community, the Post-Acute Care Interoperability (PACIO) Community has adopted the PACIO Advance Directives Interoperability IG as a project use case. The PACIO Community has a strong interest in the topic of advance directives and will support the community engagement and technical FHIR IG development needed for advance directives interoperability. PACIO is supported by MITRE, CMS, ONC and many other stakeholders (clinical, technical, and industry associations).

FHIR profiles are being developed for several existing FHIR resources to represent advance directive content such as: living will, durable medical power of attorney, personal health goals at end of life, care experience preferences, patient instructions (obligation, prohibitions, and consent), and portable medical orders for life sustaining treatments.

The current version of this FHIR IG covers the use of RESTful API interactions for creating, sharing, query/access, and verification of advance directive documentation between systems. It is intended to address advance directive interoperability needs where the author is the individual that is making medical intervention goals, preferences, priorities known in advance. 

Future versions of the PACIO Advance Directives Interoperability IG will address encounter-centric patient instructions and portable medical orders for life-sustaining treatment.

Type

Test an Implementation Guide

Track Lead(s)

Corey Spears  (Technical Lead)

Maria D. Moen  Maria Moen (Use Case Lead)

Matt Elrod (Domain SME)

Tina Wilkins  (Support)

Track Lead Email(s)

cspears@mitre.org; mmoen@advaultinc.com;  elrod@max.md; twilkins@mitre.org

Specification Information

PACIO Advance Directive Interoperability w/FHIR IG: https://build.fhir.org/ig/HL7/fhir-pacio-adi/branches/STU2_draft/

Call for participants

EHRs, EMRs and Electronic Clinical Record Systems

Portable Medical Order Registries & Repositories

Consumer focus applications (e.g. PHRs)

Zulip stream

https://chat.fhir.org/#narrow/stream/282785-Advance-Directives/topic/HL7.20Connectathon.2032.20-.202022-01

Track Kick off Call

Wednesday 21, 2022 2:00pm - 3:00pm ET

Join ZoomGov Meeting
Zoom: https://mitre.zoomgov.com/j/1609856747 

Kick off recording: 2022-12-21-PACIO-ADI-Track-Kickoff-video1025774132.mp4

Slides: 

Clinical Input Required?N/A
Related Tracks?None yet identified

Testing Scenario:

The ADI Track will test the exchange of patient authored advanced directive information and build upon the prior testing done in the January 2021 and May 2021 Connectathons.  The additional focus will be on the use cases of updating content [4] and verifying the current version of advanced directive content [5].


Focus areas include:

  • Portable Medical Order - (FHIR Document)

ADI Document Types

Complete Patient Story 

Scenes

Scene 0: Background

Scene 1: Create Portable Medical Order (PMO)

  • The Primary Care Physician (PCP), consulting with the patient, creates Portable Medical Order (PMO) in digital form
  • The PMO Document may be made available in the source system through a FHIR Server (e.g. an EHR with a FHIR Server)

Scene 2: Share a Portable Medical Order  

  • The source system of the PMO send the data to an external registry or repository
    • There are several technical architectures that exist throughout the US.
    • This document may be pushed out directly to a portable medical order registry or be shared with a state HIE. This HIE may act as a PMO registry or a conduit for an external registry.
    • The exact architecture tested will depend on the participants testing.

Scene 3:  Query and access of the Portable Medical Order

  • The patient wants to review their active Portable Medical Orders
    • The patient using a client facing app queries for their Portable Medical Order documents.
  • During an appointment with a specialist provider, there is a review of the Portable Medical Orders.
    • The practitioner, using an EHR, queries for active Portable Medical Orders

Scene 4:  Updating the Portable Medical Order

  • During the review of the Portable Medical Orders for the patient, it is determined that a change needs to be made to the active Portable Medical Order
    • In consultation with the patient, the specialist creates a new Portable Medical Order

Scene 5:  Sharing the updated Portable Medical Order

  • The source system of the PMO send the data to an external registry or repository
  • The source system marks the replaced Portable Medical Order as superseded with a reference to the new Portable Medical Order

Scene 6:  Query and access of the updated PMO 

    • The patient wants to review their active Portable Medical Orders
      • The patient using a client facing app queries for their Portable Medical Order documents.
    • During an emergency encounter another provider, which can be EMS, retrieves the active Portable Medical Order to determine what the order specifies for medical interventions
      • The provider, or EMS, using their EHR/EMR/clinical record system, queries for active Portable Medical Orders to guide care delivery

Bonus  Scenes (Separate Patient)

Bonus Scene 1:  Revoke Portable Medical Order

    • A provider determines, in consultation with the patient, that the information in a Portable Medical Order was issued in error or that having a Portable Medical Order for the patient is no longer appropriate
      • The provider marks the Portable Medical Order as revoked or voided and updates the source registry or repository
      • There are several technical architectures that exist throughout the US.
      • This document may be revoked in the provider's EHR/EMR/clinical record system or a registry/repository which, depending on the architecture may be propagated to other systems

Bonus Scene 2: Query and access of the Portable Medical Order

  • A provider at a skilled nursing facility needs to review the patients Portable Medical Orders as part of their standard policy.
    • The practitioner, using an EHR, queries for active Portable Medical Orders, and will not see the revoked or voided portable medical order.
    • The practitioner can query for revoked or voided orders and will be able to see the inactive order.

System Roles

AD Information Creator (Client)

  • A system that creates an ADI IG Conformant set of FHIR resources, stores, and pushes to another system (An ADI Information Receiver)
  • Advance Preparation: The system will be able to create portable medical order documents (FHIR Document Reference) and send them through a FHIR interface.

AD Information Receiver (Server)

  • A system, acting as a FHIR Server, receives an ADI IG Conformant set of FHIR resources.
  • These resources may be utilized for display only or enable them to be made available for query (Acting as an ADI Information Repository or Portable Medical Order Registry)
  • Advance Preparation: The system will be able to receive and store AD DocumentReference resources through a FHIR interface.

AD Information Repository (Server)

  • A system that stores ADI documents and makes them available for query, ADI IG Conformant FHIR resources.
  • Advance Preparation: The system will be able to store AD DocumentReference resources and make them available for query through a FHIR interface.

AD Information Requester

  • A system that queries an AD Information Repository for advance directive FHIR resources and displays or otherwise uses the information contained within.
  • Advance Preparation: The system will have the ability to query for AD DocumentReference resources through a FHIR interface.