PACIO Advance Directive Interoperability Implementation Guide, published by HL7 International / Patient Empowerment. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-pacio-adi/ and changes regularly. See the Directory of published versions

General Guidance

This section provides additional guidance on the relationship between the associated profiles and the structure of the interoperable advance directive document.

ADI Content Types

There is a very important distinction for the three types of ADI content that will be covered in this IG. Below is a description of each type of content that will be covered by the ADI FHIR IG with versions.

 

	Type I: Person-Authored Advance Directive Information
		Person-authored information Used as a tool for sharing an individual’s medical treatment and intervention goals, preferences, and priorities (GPP) Provides guidance that a person would want known to inform treatment and care planning during a potential future medical emergency, in the case where the patient is unable to communicate with caregivers and medical personnel There is NO “contract” between the author (patient) and any other party involved in the future medical emergency that the GPP is required to be followed (i.e., no offer or acceptance, no consideration, no consequences for failure to follow the patient’s directives)
	Type II: Encounter-Centric Instructions
		Clinician or Practitioner-authored Instructions are related to the current, immediate episode of care The patient, or their healthcare agent, provides direct input in the creation of the instructions which specify decisions that have been made about treatments that may, or may not be, utilized during a medical emergency occurring within the current episode of care.
	Type III: Portable Medical Orders for Life-Sustaining Treatments
		Practitioner-authored A set of medical orders intended to follow a patient and be available across the continuum of care The patient, or their healthcare agent, provides direct input in the creation of the orders. These orders are used to document a provider’s orders for, or preferences against, treatments that are to be utilized during a future medical emergency that would necessitate life-sustaining treatment and interventions, and are based on the patient’s expressed goals, preferences, and priorities for such care.

The current version, STU1, of this ADI with FHIR IG covers the use of RESTful API interactions for creation, sharing, query/access, and verification of advance directive information between systems. It is intended to address advance directive interoperability needs for Content Type 1, where the author is the individual that is making medical intervention goals, preferences, priorities known in advance. This IG is not intended to cover medical intervention goals, preferences, priorities for individuals who are not able to create and document their own advance healthcare decisions.

STU1 supports only Person-authored Advance Directives (ADI Content Type 1) and Portable Medical Order (ADI Content Type 3) documents. Future versions of this FHIR IG will address encounter-centric patient instructions, Content Type 2.

Structure and Resource Relationships

Advance healthcare decision documents may take several forms, including scanned PDF documents, CDA documents, other binary documents, as well as native FHIR documents (using the Composition and other ADI-specific profiled FHIR resources). This guide defines the interoperable guidance necessary to support creation, update, query, and access to all of these types and other potential ADI document types (through encoding in a Binary resource). Today, most of these documents are shared through scanned images housed in EMRs, EHRs and other systems.

This implementation guide is designed to guide a range of digitization levels, ranging from scanned documents to fully discrete FHIR documents. Additionally, this guide provides the capability for different types of ADI data to be more interoperably digitized than others inside the same document, which is structured as a FHIR Composition, and is described in more detail in the ADI FHIR Document Structure section.

The DocumentReference is the resource that is used for “indexing” of documents, similar to the way a library uses a card catalog to index books based on different search criteria, for example, by title, author, date, or classification code. The DocumentReference can be used in the same way for searching and finding documents with specific attributes such as type of document, subject (e.g., patient), author, dates. These attributes are provided in the metadata of the DocumentReference so that the actual documents do not have to be accessed for most common searches. A complete list of search capabilities on DocumentReference can be found in the Search Parameters section.

Digital signatures are defined as optional in this guide, for a myriad of factors including maturity of systems that can create and exchange digital ADI. If supported by a Content Creator system, the digital signature will be a captured in a Binary resource that is referenced by an additional DocumentReference resource.

There is movement within the FHIR community to move towards using the Provenance resource as a standard way to apply a digital signature to a document in FHIR. The signature within the Provenance resource would be used to encrypt the binary (the actual document itself), not the DocumentReference. A future version of the implementation guide will be updated to follow the standard FHIR guidance on signatures when it is finalized.

ADI FHIR Document Structure

ADI native documents using FHIR are instances of the Bundle resource with the type = document. The document should have all content contained within the Bundle with no external references except for the references to external documents in the DocumentationObservation through the focus data element. FHIR Bundle documents consist of multiple entry resources within it, with the first entry being a Composition resource. The Composition resource acts as the header and organizational construct. It contains information about the document such as the category of document, dates, and references to the various participants of the document, as well as document sections used to categorize or organize the contained entries.

This structure at the highest level is common to all ADI content types. Additional FHIR representation requirements will depend on:

• the form of advance directive document
• the ADI content type

Reference the IG section, Advance Directive Structure Requirements, for further guidance.

Clause Extension

Advance directive documents often contain additional information, or clauses, related to specific areas of the document. This may include things like additional observations about which named healthcare agent is to be primary versus back-up, or a healthcare agent has been selected, or a statement by the author of the document that is felt to be important to the overall contents, and other information that provides context to the data otherwise expressed in the sections or entries of an ADI document. To support this information this guide has defined a Clause extension to all of the Composition sections and various profiles and elements.

ADI Profiles

The table below describes the FHIR profiles relevant to each of the ADI Content Types.

CONTENT TYPE I: Advance Directive Information (in STU1 scope)
Name of Profile to be developed		Short description	Based On
1	ADI Document Reference	This profile defines constraints that represent the information needed to register an advance directive information document on a FHIR server.	US Core DocumentReference
2	ADI Header	This profile defines constraints that represent common administrative and demographic concepts for advance directives information used in US Realm clinical documents.	ClinicalDocument
3	ADI Personal Advance Care Plan Composition	This profile encompasses information that makes up the author’s advance care planning information.	ADI Header
4	ADI Participant	This profile represents a person participating in a person's advance directives in some designated capacity such as healthcare agent or healthcare agent advisor.	RelatedPerson
5	ADI Participant Consent	This profile is used to represent the author’s consent for an ADI participant such as a healthcare agent or advisor and can include powers granted to, or limitations imposed upon, such persons.	Consent
6	ADI Documentation Observation	This profile is used to indicate if additional advance directive documents, such as physician order for life sustaining treatment (MOLST or POLST) or Do Not Resuscitate Order (DNR) exist and a reference to the document.	Observation
8	ADI Personal Intervention Preference	This profile is used to represent personal medical intervention preferences under certain health conditions.	Observation
9	ADI Care Experience Preference	This profile is used to express the author's personal thoughts about something he or she feels is relevant to his or her care experience which can be important to know when planning or delivering his or her care.	Observation
10	ADI Personal Goal	This profile is a statement that presents the author's personal health goals that are important to be mindful of when planning his or her care.	US Core Goal
11	ADI Personal Priorities Organizer	This profile is used to represent a set of personal goals, preferences or care experiences in a preferred ranked order.	List
12	ADI Organ Donation Observation	This profile is used to represent the author's thoughts about organ donation.	Observation
13	ADI Autopsy Observation	This profile is used to represent the author's thoughts about autopsy.	Observation
13	ADI Preference Care Plan	The Preference Care Plan is a means for an individual to express their goals and preferences under certain circumstances that may be pertinent when planning his or her care.	Care Plan
13	ADI Provenance	Advance Directive Interoperability Provenance based on US Core to capture, search and fetch provenance information associated with advance directive interoperability data.	US Core Provenance
CONTENT TYPE II: Encounter-Centric Patient Instructions (after STU2)
Name of Profile to be developed		Short description	Based On
15	ADI Obligation Instruction	This profile always expresses activities that care providers have been instructed by the person or their healthcare agent to perform.	Consent
16	ADI Prohibition Instruction	This profile always expresses activities that care providers have been instructed by the person or their healthcare agent not to perform.	Consent
17	Advance Directives Organizer	This profile groups a set of ADI observations documented together at a single point in time and are ONLY relevant during the episode of care being documented.	List
18	ADI Advance Directives Observation	This profile is used to record information about ADI authored by the person which contains goals, preferences, and priorities for care.	Observation
19	ADI Advance Care Planning Intervention	This profile is used to record a planned intervention that will involve reviewing and verifying a person’s goals, preferences or priorities for treatment or will involve educating and supporting a person on establishing or modifying his or her ADI.	US Core Procedure
CONTENT Type III: Portable Medical Orders (PMO) (STU2)
Name of Profile to be developed		Short description	Based On
20	ADI Portable Medical Order Composition	This profile encompasses information that makes up a practitioner's portable medical order.	Composition
21	ADI Portable Medical Order Care Plan	This profile is used to specify the plan of care that represents the persons wishes, preferences, and experiences as documented in the PMO.	Care Plan
22	ADI Portable Medical Order ServiceRequest	This profile is used to represent a practitioner authored portable medical order.	Care Plan
23	ADI Portable Medical Order Hospice Observation	This profile is used to represent a finding that the individual is under hospice care.	Observation
24	ADI PMO Participant Observation	This profile is used to represent the portable medical orders participant observation.	Observation
25	ADI PMO Review Observation	This profile is used to represent the review status of the portable medical order.	Observation
26	ADI Consent for Portable Medical Orders	This profile is used to express the person, or their healthcare agent’s, consent that is not bound by an encounter.	Consent
27	ADI Consent for DNR Orders	This profile is used to express the patient’s or healthcare agent consent that is not bound by an encounter.	Consent
Sharing Documents
Name of Profile to be developed		Short description	Based On
28	ADI Consent to Share	This profile is used to enable someone else to act on their behalf if they are unable to do so themselves.	Consent

Globals Profiles

There are no Global profiles defined

Package Dependencies

This Implemention Guide is based on FHIR R4.

Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.uv.bulkdata#2.0.0 FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00)

Package hl7.fhir.r4.examples#4.0.1 Example resources in the R4 version of the FHIR standard

Package hl7.fhir.uv.sdc#3.0.0 The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR. This includes two components: * Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains. *Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package ihe.formatcode.fhir#1.1.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00)

Package hl7.fhir.us.core#6.1.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Fri, Jun 30, 2023 14:02+0000+00:00)

Package hl7.fhir.uv.extensions#5.1.0-cibuild This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Mon, Apr 15, 2024 16:10+0000+00:00)