| Submitted By: Matt Elrod on behalf of ADVault, Inc.
/ ADVault, Inc.
|
| Data Element Information |
| Use Case Description(s) |
| Use Case Description |
Interoperable advance directives information enables patient goals, preferences, and priorities to be available across the healthcare eco-system, and gives the patient a means to influence and guide his or her care even during those time when the person is unable to communicate with medical personnel Advance directive information is at the heart of person-centered care. Advance directives guide transitions of care and delivery of care that align more closely with the patient’s values and personal goals of care, which improves health outcomes, patient/family satisfaction. Advance directives have the power to remove the need for healthcare providers, caregivers, and family/friends to guess what the patient would have wanted to happen (or not to happen) during the course of care delivery. For advance directive information to be effective, however, all stakeholders in healthcare must be able to locate, retrieve, and consume the information 24/7/365, wherever they are needed.
• Use Case 1: Create and share advance directives information.
• Use Case 2: Update and share advance directives information to support a transition of care.
• Use Case 3: Request access to the current version of a person’s advance directives information.
The information below describes the three use cases and includes examples to demonstrate the use that is envisioned.
Use Case 1: Create and share advance directives information
Sherrie has Sickle Cell Disease and is concerned that if she contracts COVID-19 and becomes unable to communicate with medical personnel, they will not be familiar with her history and specific treatment needs. COVID-19 has created a reluctance in providers to allow patients to bring paper documents into a care facility, making her paper advance directive information ineligible as a replacement source of information if Sherrie is unable to communicate for herself during an episode of care. As a result of the heightened sensitivity to paper documents as a reference source during care delivery and restrictions on non-patient visitation or presence in care settings, neither healthcare agents nor traditional paper documents used by patients to express their personal healthcare goals and treatment preferences are available. Sherrie uses a consumer-facing tool to create a digital personal advance care plan and stores it in a registry so that her healthcare providers can locate and retrieve it if necessary. Sherrie also ensures her durable medical power of attorney and primary care physician have access to her electronic advance directive information so that if either are contacted by the treating provider during a health crisis or emergency, they can provide emergency access to Sherrie’s advance directive information in order to inform treatment.
Use Case 2: Update advance directives information to support a transition of care.
Samuel is an older citizen who lives in a skilled nursing facility (SNF), and he had previously created a personal advance care plan (PACP) on paper, which is provided to the SNF by a family member upon admission. However, he wants to supplement his advance directive information with situation-specific preferences, e.g., “receive care in place and do not hospitalize” in the event that he contracts COVID-19. In addition, he had previously designated his wife as his durable medical power of attorney, but as she passed away last year, Samuel needs to identify another individual to act in this capacity should he become unable to communicate. With the help of the SNF facility’s staff, he records an audio message of his situation-specific COVID-19 instructions. The facility staff also assist Samuel with update of his PACP with a new healthcare agent, thereby creating a more current version of his PACP. The facility stores a scanned copy of the updated, current advance directive information in his clinical record. They also help him share a copy of his updated advance directive information with his new healthcare agent and primary care physician, as part of ensuring the information is available to facility staff and other medical personnel should he contract COVID-19 and become unable to communicate for himself. The skilled nursing facility’s EMR is connected to the various HIE’s and registries, as part of ensuring the updated advance directives information is available to other providers and health systems, should Samuel suffer a health crisis or emergency.
Use Case 3: Request access to the current version of a person’s advance directives information.
Mary is 61 years old and scheduled for a routine screening colonoscopy which involves anesthesia. She has previously been in good health. The nurse asks her whether or not she has an advance directive, she responds affirmatively. The location of her advance directive information is recorded in the medical record, but because Mary is alert and communicating normally, there is no reason to access the content of her information at this time. She is able to speak for herself related to goals of care and treatment decisions, unless she loses decision-making capacity, at which time her advance directive information would be retrieved.
|
| Estimate the breadth of applicability of the use case(s) for this data element
|
There are over 5,000 hospitals and 231,000 small practices, long-term post-acute care centers, skilled nursing facilities and other healthcare providers who have clinical record technologies which are suitable for the capture, access, use or exchange of this data element. In addition, there are over 190 million Americans over the age of 18 who should be creating, digitally storing and exchanging advance directives data with their healthcare providers. Currently, there are over 200 health systems, four federal agencies, 59 state and regional Health Information Networks, and other healthcare organizations using a wide variety of vendor platforms who have the ability to capture, access, use or exchange this data element. |
| Healthcare Aims |
- Improving patient experience of care (quality and/or satisfaction)
- Reducing the cost of care
- Improving provider experience of care
|
| Maturity of Use and Technical Specifications for Data Element |
| Applicable Standard(s) |
HL7 CDA® R2 Implementation Guide: Personal Advance Care Plan (PACP) Document, Release 1 - US Realm STU Release 2
The PACP document is a CDA document template designed to share information created by an individual to express his or her care and medical treatment goals, preferences, and priorities for some future point in time, under certain circumstances when the individual cannot make medical treatment decisions or communicate his or her goals, preferences, and priorities with the care team. The purpose of the PACP document is to ensure that the information created by the individual is available and considered in clinical care planning, and the focus of the standard is sharing patient generated information. It should not matter if the source information is documented on a piece of paper, in a video recording, or in a consumer-controlled application that exists for this purpose. The standard provides a means to share this information in a standard way with a system that maintains a clinical record for the person. It is not intended to be a legal document or a digitization of a legal document. However, a PACP can reference a legal document, and it can represent information contained in a legal document such as the appointment of healthcare agents and the identity of witnesses or a notary.
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=434
|
| Additional Specifications |
HL7 CDA® R2 Implementation Guide: C-CDA R2.1; Advance Directives Templates, Release 1 - US Realm
Advance Directive Templates are important components of the C-CDA standard, yet to date, their usage in the standard has been optional.
New focus within the industry on patient-centered care plans and value-based care has raised implementer interest in care planning and advance care planning. As implementers have started to include advance directive information, it became clear that additional guidance was needed and that the template designs required refinement. Also, new standard developed to represent personal advance care planning information have been developed to communicate health goals and treatment preferences expressed by the patient. The older Advance Directive templates needed revisions to take the newer work into consideration.
As advance care planning information began to be shared, concern increased about the possibility that clinicians might misinterpret patient wishes in a way that would result in errors that risk patient safety or that violate patient intent. Information context is crucial when it comes to interpreting advance directives. Directives should always be maintained in their original form - not chopped up and stored as structured data. There is a very high risk that the conversion from text to structure will lose critical information. Changes were needed to the templates to clarify that these observations DO NOT convert patient wishes into structured data that acts as a decision or an order. The structured data is used to document the type of content present in the source document that describes the patient's wishes, health goals, and treatment preferences. Fixing this issue was a critical need.
For these reasons, the earlier versions of the Consolidated CDA Advance Directive Templates needed to be clarified and revised, and some additional templates needed to be added.
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=473 |
| Current Use |
In limited use in production environments |
| Supporting Artifacts |
Previous unsolicited ISA and USCDI submitted on June 4, 2020 by ADVault, Inc. L. Scott Brown and MaxMD Lisa R Nelson, MS, MBA and updated on October 20, 2020.
USCDI Proposal for Advance Directives Data Class 20201022.docx
|
| Extent of exchange
|
5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. |
| Supporting Artifacts |
The data element has been tested at scale between an advance directives registry and repository deployed and maintained by ADVault, Inc., on the one hand, and multiple hospitals and Health Information Networks, on the other hand, including eHealth Exchange and Chesapeake Regional Information System for Patients (CRISP).
|
| Potential Challenges |
| Restrictions on Standardization (e.g. proprietary code) |
There are no restrictions on the standardization of this data element. |
| Restrictions on Use (e.g. licensing, user fees) |
The identifiers, names and codes underlying the data element are all codes registered with and administered by Regenstrief Institute as part of the Logical Observation Identifiers Names and Codes (LOINC) system. Consequently, they are universally available pursuant to the LOINC and RELMA Terms of Use, Copyright Notice and License.
The value sets used for the data element are all recorded with the National Library of Medicine Value Set Authority Center (VSAC) and freely available for use under the Unified Medical Language System® Metathesaurus License (UMLS).
Finally, all of the OIDs are registered with HL7. Everything required to standardize this data element is freely and universally accessible.
|
| Privacy and Security Concerns |
The use and exchange of this data element raises concerns associated with data provenance and authentication. However, the HL7 standards developed for the advance directives class of data have focused on issues of data provenance from inception.
Templates and guidance for this class of data clearly define how to represent the semantics needed to clarify what information was authored by the patient his or herself (as in the case of a Personal Advance Care Plan), and what information was authored by a healthcare provider (as in the case of portable medical orders for life-sustaining treatments).
The recently balloted version of the Personal Advance Care Plan specification also clarifies how to record information about an organization that plays the role of an “assembler,” merely outputting patient authored information in a standardized exchange format and not authoring any new content about the patient. In addition, implementers can use the HL7 Digital Signature standard that defines how to digitally sign C-CDA documents. |
| Estimate of Overall Burden |
Implementation of the data element is not burdensome. All of the LOINC codes, value sets and data transport standards exist and are widely and freely accessible. |
| Other Implementation Challenges |
Any challenges to implementation of the data element are related to existing paper and non-interoperable electronic processes and are not technological. Natural resistance to process change and a perceived associated risk, combined with a historical culture of “a clinician has to document it for it to be correct,” result in a refusal by healthcare providers to permit patients to insert information related to their personal goals, preferences, and priorities for care into their electronic medical records. The issue is further complicated by a stigma attached to death in American culture and medical professionals’ training to view death as the enemy to be defeated by any means necessary and at all cost, often disregarding the wishes of the patient or the quality of life associated with intensive medical interventions at the end of life.
Paper documents and silo’d EMR attempts to address the capture of patient values and goals of care have created fast paths that give the illusion of person-centered care delivery, yet without interoperable standards for this important information there is not a path forward for moving to a digital, person-centered care delivery system where the patient guidance is at the center of care and not a passive bystander in their own healthcare experience. |
ONC Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
|
Criterion #1
Maturity - Current Standards |
Level 2
- Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
|
Criterion #2
Maturity - Current Use
|
Level 1
- Data element is captured, stored, or accessed in at least one production EHR or HIT module.
|
Criterion #3
Maturity - Current Exchange |
Level 1
- Data element is electronically exchanged between two production EHRs or other HIT modules using available interoperability standards.
|
Criterion #4
Use Case(s) - Breadth of Applicability |
Level 2
- Use cases apply to most care settings or specialties.
|
|
Official Website of The Office of the National Coordinator for Health Information Technology (ONC)
Submitted by pwilson@ncpdp.org on
NCPDP Comments on USCDI draft v5
NCPDP recommends the use of RxNorm for names of medications. This is being utilized by the NCPDP/HL7® Pharmacist eCare Plan and is applicable in CCDA and FHIR® R4.