Description (*Please confirm or update this field for the new USCDI version*)
Individual legally authorized to make healthcare decisions on behalf of a patient when the patient is unable to do so because of an illness or injury.
Submitted By: Matt Elrod on behalf of ADVault, Inc.
/ ADVault, Inc.
Data Element Information
Data Element Description
A person uses a durable medical power of attorney to appoint one or more people to serve as advocates or “healthcare agents” empowered to make medical treatment decisions on behalf of that person if the person is incapacitated and cannot communicate with medical personnel.
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.
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.
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.
Recommendation: Advance Healthcare Agent to Level 2 and include as a data element under an Advance Directives data class.
Rationale: A Healthcare Agent is a broad term that includes a healthcare proxy who is designated to speak for a patient if they are unable to speak for themselves. The current Durable Medical Power of Attorney data element is too narrow to capture the different types of proxies and representatives. Designating a Healthcare Agent is a valuable part of advance care planning that should be captured in an Advance Directives data class, if available. CMS believes Healthcare Agent is better described as a collection of data elements which may establish one or more Durable Medical Powers of Attorney, but is part of a set of data elements that may include additional details about the specific powers or limitations associated with that established role. With this context in mind, the data element Healthcare Agent is a broader term to encompass the content that could be exchanged, a subset of which might be the designation of a Durable Medical Power of Attorney. Over the past year multiple organizations have used both CDA and FHIR standards to share this important patient-generated information. There are LOINC codes that represent this data element, and it is part of both CDA and FHIR IGs.
CMS-CCSQ, along with the PACIO Project, continue to support the addition of the Advance Directives data class that was previously identified as a priority area by the USCDI Task Force and CMS. The PACIO Community believes these four data elements (only referencing Durable Medical Power of Attorney here) and Orders for End of Life Care, along with Care Experience Preferences and Treatment Preferences data elements that are currently in USCDI v4, provide the most essential information to give a holistic view of the individual’s wishes, necessary to inform care. Advance directives guide transitions and delivery of care that closely align with patient values that improve patient satisfaction. When incorporated into systems that assist healthcare professionals in decision-making, advance directives can activate customized notifications and best practice recommendations, which in turn can guide medical staff toward choices that are both well-informed and ethical. For individuals undergoing treatment from various healthcare providers or experts, the Advance Directives data class streamlines the delivery of uniform and personalized medical attention across multiple healthcare disciplines. This data class supports CMS’s objective to foster a healthcare system that is both effective and attentive to the unique healthcare preferences of each patient, thereby elevating patient well-being and satisfaction.
This information is routinely captured in patient or encounter summary documents. For the Level 1 data elements under this data class, there have been advancements in both the CDA and FHIR standards with the CDA guidance having been balloted twice within HL7 and the FHIR IGs being in later stages of ballot reconciliation with anticipated publication in the next few months. Specifically, for the Durable Medical Powers of Attorney data element, the FHIR IG currently is resolving dispositions to comments from the January 2022 ballot. There are LOINC Codes that represent this data element and it is part of both CDA and FHIR IGs (81335-2 Patient Healthcare Agent). Also, there is a well-established value set for representing a primary, secondary, or tertiary healthcare agent when multiple agents are established. (Healthcare Agent or Proxy Choices, urn: oid: 2.16.840.1.113762.1.4.1046.35).
Data Element: Durable Medical Power of Attorney (Level 1)
Recommendation: Change the name of the data element “Durable Medical Power of Attorney” to “Healthcare Agent” and include it in the USCDI V4.
Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO community believes the notion of “Healthcare Agent” is better described as a collection of data elements which may establish one or more “Durable Medical Powers of Attorney” but is part of a set of data elements that may include additional details about the specific powers or limitations associated with that established role. With this context in mind, the data element “Healthcare Agent” is a broader term to encompass the content that could be exchanged, a subset of which might be the designation of a “Durable Medical Power of Attorney”. Over the past year multiple organizations have used both CDA and FHIR standards to share this important patient-generated information. In addition, the CDA guidance has been balloted twice within HL7, the FHIR IG currently is resolving dispositions to comments from the January 2022 ballot. There are LOINC Codes that represent this data element and it is part of both CDA and FHIR IGs. (81335-2 Patient Healthcare agent) Also, there is a well-established value set for representing a primary, secondary, or tertiary healthcare agent when multiple agents are established. (Healthcare Agent or Proxy Choices, urn:oid: 2.16.840.1.113762.1.4.1046.35)
Data Element: Durable Medical Power of Attorney (Level 1)
Recommendation: Include the Durable Medical Power of Attorney data element under the Advance Directive Data Class in USCDI V4.
Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community believes the data elements Care Experience Preferences, Treatment Preferences, End of Life Orders and Durable Medical Power of Attorney included together provide the most essential information to give a holistic view of the individual’s wishes, necessary to inform care. Specifically, Durable Medical Power of Attorney enables the communication of the designated Healthcare Agent or proxy. Many individuals will designate someone to speak for them when they’re unable to communicate for themselves. If an individual doesn’t have a complete Advance Directive or Advance Care Plan, their designee can communicate their goals preferences and priorities to the care team on their behalf. Additionally, we believe the concept of “Durable Medical Power of Attorney,” would best fit within the Advance Directive data class (and not, for example in the “Care Team” data class) because: 1.) Durable Medical Power of Attorney designates a unique legal status not applicable to any other members of the care team; and 2.) as stated above, the data elements Care Experience Preferences, Treatment Preferences, End of Life Orders and Durable Medical Power of Attorney included together provide the most essential information to give a holistic view of the individual’s wishes, necessary to inform care. We encourage USCDI to advance the data element “Durable Medical Power of Attorney” to V4.
Modify “Durable Medical Power of Attorney” to “Healthcare Agent” and Advance to USCDI Level 2. The notion of “Healthcare Agent” is better described as a collection of data elements which may establish one or more “Durable Medical Powers of Attorney” but is part of a set of data elements that may include additional details about the specific powers or limitations associated with that established role. With this context in mind, the data element “Healthcare Agent” is a broader term to encompass the content that could be exchanged, a subset of which might be the designation of a “Durable Medical Power of Attorney”. Over the past year multiple organizations have used both CDA and FHIR standards to share this important patient-generated information. In addition, the CDA guidance has been balloted twice within HL7, the FHIR IG currently is resolving dispositions to comments from the January 2022 ballot.
There are LOINC Codes that represent this data element and it is part of both CDA and FHIR IGs. (81335-2 Patient Healthcare agent)
There is a well-established value set for representing a primary, secondary, or tertiary healthcare agent when multiple agents are established. (Healthcare Agent or Proxy Choices, urn:oid: 2.16.840.1.113762.1.4.1046.35)
The PACIO Community strongly recommends the Healthcare Agent data element be advanced to USCDI Level 2.
The PACIO Project strongly supports modification of the “Durable Medical Power of Attorney” data element to “Healthcare Agent” and advancement to USCDI Level 2.
Established February 2019, the PACIO Project is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO community is open to all interested parties and currently includes over 50 individuals and organizations. On behalf of the PACIO Project leadership team, the PACIO Community voted 9/29/21 and unanimously supports the document and recommendations as posted 9/28/21 by Lisa R Nelson. PACIO members were involved in the creation of that document based on experiences in advance directive content adjudication and FHIR implementation guide development.
While the concept of “Durable Medical Power of Attorney” remains important to be included in the USCDI, further community discussion led to modifying the data element from “Durable Medical Power of Attorney” to “Healthcare Agent”. The notion of “Durable Medical Power of Attorney” is better described as a collection of data elements which may establish one or more “Healthcare Agents” and may include additional details about the specific powers or limitations associated with that established role. The concept of “Durable Medical Power of Attorney” would more accurately be described as a data bundle because it includes multiple data elements, the most prominent being “Healthcare Agent”. Over the past year multiple organizations have used both CDA and FHIR standards to share this important patient-generated information. In addition, the CDA guidance has been balloted twice within HL7, the FHIR IG is preparing to be balloted in January 2022.
There are LOINC Codes that represents this data element and it is part of both CDA and FHIR IGs. (81335-2 Patient Healthcare agent)
We strongly recommend the “Durable Medical Power of Attorney” data element be modified to “Healthcare Agent” and for it to be advanced to USCDI Level 2.
The "Optional Background Text / Cover Letter" field provides space for additional context or introductory information related to your comment.
If you wish to provide context, explanation, or an introduction to your comment, enter this information in the field labeled "Optional Background Text / Cover Letter." This is entirely optional and is most useful when submitting multiple related comments or when additional background would help reviewers understand your feedback.
If you are only commenting on a single data class or element, you may leave this field blank.
2. Select the Data Class
To specify which data class your comment addresses:
In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
If you are providing a general comment that is not specific to a data element, select "General" from the options. Comments with this designation will be displayed on the USCDI landing page.
Note that the Data Class field will automatically populate based on your current location in the platform:
If you are on a data class page, the field will be set to that specific data class
If you are on a data element page, the corresponding data class will be pre-selected
3. Select the Data Element
To specify which data element your comment addresses:
In the "Data Element" drop-down menu, select the specific data element you want to comment on.
The drop-down menu will display only the elements available under the data class you selected in the previous step.
You can use the search function within the drop-down to quickly locate a specific data element.
If you are commenting on the data class itself rather than a specific element, you may leave this field blank.
Note: Comments on a specific data element will appear on the respective data element page, while comments on a data class (without a specific element selected) will appear on the landing page for that data class.
Fig 1 The "Data Class" and "Data Element" dropdown menus allow users to specify the exact content they wish to comment on.
4. Optional: Propose New Data Class or Element
If you cannot find the appropriate data class or element for your comment:
Instead of clicking the "Comment On An Existing Data Class Or Element" button, click the adjacent button labeled "Propose a New Data Class or Data Element."
This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Fig 2 The "Propose a New Data Class or Data Element" button redirects users to the ONDEC Submission System for proposing new data elements not currently available in the system.
5. Complete the Comment Form
Fill out the required fields in the comment form:
Subject: Enter a brief, descriptive title that summarizes your comment. This helps reviewers quickly understand the nature of your feedback.
Comment: In this field, provide the full details of your comment or feedback. Be as clear and specific as possible about your suggestions, concerns, or observations. Include any relevant details that support your position.
6. Optional: Add Additional Comments
If you need to comment on multiple data classes or elements:
After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
A new comment section will appear, allowing you to enter details for your additional comment.
For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
Complete the Subject and Comment fields for your additional comment.
Repeat this process for each additional comment you wish to submit.
Fig 3 The "Comment on another data element" link enables users to create multiple comments addressing different elements within a single submission.
7. Optional: Upload Supporting Files
The platform allows you to upload supporting documentation to enhance your comment:
Locate the "File Upload" section at the bottom of the comment form.
Click to upload any files (such as PDFs or documents) that provide additional context, evidence, or clarification for your comment.
Important: If you have already entered your comments using the form fields, there is no need to upload duplicate content in PDF format. The file upload feature is intended for supplementary materials only. Please avoid uploading files that contain the same information already provided in your comment text.
Fig 4 The "File Upload" section permits users to attach supporting documentation that supplements their written comments.
8. Optional: Save and Exit
If you need to pause your work and return to complete your comment later:
Click the "Save and Exit" button at the bottom of the form.
Your comment will be saved as a draft that you can access and complete later.
When you return to the platform, you will see a red triangle with an exclamation mark next to the “Return to saved Comment” button, indicating that you have saved comments in draft status.
Click this button to continue working on your draft.
You will be taken to a review page where you can:
Select "Submit Comment" to officially submit your feedback.
Click "Edit" to return to the comment form and make changes
Select "Discard Draft" to delete the saved draft and start fresh
Fig 5 A red triangle with exclamation mark indicator appears next to the “Return to saved Comment” button when draft comments are saved in the system.
9. Review and Submit
Once you have completed your comment:
Click the "Review and Submit" button at the bottom of the form.
This will take you to a review screen displaying your comment(s) in full.
Review all information for accuracy and completeness.
On this review screen, you have three options:
Click "Submit Comment" to officially submit your feedback
Click "Edit" to return to the comment form and make changes
Click "Discard Draft" to delete the comment and start fresh
The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records.
If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.
Submitted by rdillaire on
CMS-CCSQ Support for Healthcare Agent data element for USCDI v6
Data Element: Healthcare Agent