Information that guides treatment of the patient and recommendations for future treatment.

Data Element
Care Plan
Description (*Please confirm or update this field for the new USCDI version*)

Shared plan informed by members of a coordinated care team that details conditions, needs, and goals along with strategies for addressing them.

Usage notes: Includes problems, health concerns, assessments, goals, and interventions from across care settings.

Examples include but are not limited to clinical care plans, condition-specific care plans, coordinated care plan.

Submitted By: Julia Skapik / NACHC
Data Element Information
Data Element Description NACHC proposes to advance the data class "Care Plan" and its associated FHIR and CDA profiles into USCDI. The USCDI already supports the primary required components of the care plan: Health Concerns, Goals, Interventions (via procedures, immunizations, medications, nutrition and diet) etc) and and Outcomes (via labs, assessments, functional status, etc). The Care Plan is a framework to support care teams and patient-centered care. It is described in the Care Plan Domain Analysis Model (https://docs.google.com/document/d/1OJxtJiQMTVqRa5DtGrlZDd52gV5P8OR7x5suDvdYq4E/edit#heading=h.3c03cjrb5rok)


FHIR Care Plan:
http://hl7.org/fhir/careplan.html
80777-6Primary care Plan of care note

C-CDA Care Plan:
CDA-based care plan can be coded in LOINC as : 81215-6Care plan - recommended C-CDA R2.0 and R2.1 sections
and is found at the link: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=447

NACHC strongly supports the care plan as a required concept in USCDI. It currently has in production a FHIR care plan tool deployed in 6 FQHCs. Support for transmission of
Rationale for Separate Consideration This is an overlaying data class that supports several intentional existing data elements in USCDI.
Use Case Description(s)
Use Case Description NACHC currently using the FHIR care plan to support data capture and exchange in mobile health ambassadors.
Estimate the breadth of applicability of the use case(s) for this data element 100,000 care team members
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) LOINC, HL7 C-CDA and FHIR
Additional Specifications N/A
Current Use In limited use in production environments
Supporting Artifacts Use in 6 FQHCs in the US.
Extent of exchange 4
Supporting Artifacts VA and Healthflow exchange use cases.
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) The FHIR profile is preferred but C-CDA and FHIR versions should be linked to the use of the profile/standard.
Restrictions on Use (e.g. licensing, user fees) None
Privacy and Security Concerns to the extent that health data is
Estimate of Overall Burden Implementation burden should be overwhelmingly eclipsed by utility for care coordination
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 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.

Comment

Submitted by rdillaire on

CMS-CCSQ Requests Enhancing Care Plan

Recommendation:  CCSQ recommends enhancing the description for Care Plan by including “Personal Advance Care Plan" as an example. 

Rationale: “Personal Advance Care Plan” is currently represented as a separate Level 1 data element under the Advance Directives data class. However, given the current scope of the Care Plan data element in USCDI v7, it would be more appropriate to capture it within the Care Plan data element rather than as a separate element and streamlines the USCDI as a whole.

Submitted by Xueting on

Strong Support for the Care Plan Data Element in USCDI v6

As the founder and architect of a digital health platform built on wearable technologies, I strongly support the inclusion and scope of the Care Plan data element in USCDI v6. This is a landmark step toward aligning digital, preventive, and consumer-centered health tools with regulated clinical data exchange standards.

Why this matters:

  1. Care Plan is distinct from Medical Orders
    The Care Plan data element reflects patient goals, priorities, and strategies—often co-developed with care teams but not requiring clinician authorization. This distinction is critical. Many wearable-based platforms like ours generate feedback, targets, and suggested actions based on device data (e.g., temperature, sleep, HRV) that are clinically relevant but not formal medical orders. Recognizing this class of data within USCDI allows us to contribute to structured health records without overstepping regulatory boundaries.
  2. Facilitating Continuity and Interoperability
    Care Plans can serve as a bridge between device-generated insights and team-based care. For example, our platform may suggest sleep hygiene plans or glucose management routines based on continuous monitoring. With Care Plan now standardized, these data can be shared with primary care providers, specialists, or caregivers in a structured and interpretable format.
  3. Recommending Minor Enhancements
    We encourage ONC to:
  • Clarify that patient-generated health data (PGHD) and device-inferred recommendations may form the basis of assessments and interventions.
  • Provide examples of how digital health tools and consumer apps can contribute structured Care Plan entries to the broader ecosystem.
  • Encourage vocabulary alignment between PGHD and SNOMED CT or LOINC where applicable.

By formally recognizing the Care Plan as a distinct, flexible, and broadly applicable construct—separate from physician orders—ONC opens the door for meaningful integration of digital, wearable-enabled patient engagement tools into national interoperability frameworks.

Thank you for your leadership in expanding USCDI to reflect real-world, preventive, and participatory care models.

Submitted by rdillaire on

CMS-CCSQ Supports Care Plan's inclusion in USCDI v6

Recommendation: CMS CCSQ supports the inclusion of the Care Plan data element in USCDI v6 while still advocating for repurposing the Patient Summary and Plan data class to create a new Care Plan data class.

Rationale: CMS CCSQ continues to recommend a distinct Care Plan data class with a set of data elements (Care Plan Information, Assessment, Health Concerns, Goals, Interventions, and Outcomes/Evaluation). We define a Care Plan as a shared, dynamic, longitudinal plan representing all care team members (including patient/caregiver) prioritized concerns, goals, interventions, and evaluation/outcomes across health and social services settings. It can include a structured package of data elements that already exist in USCDI.
By adding Care Plan as a distinct class in the final USCDI v6, it would encompass all data elements relevant to patient care planning. We believe Patient Summary and Plan are distinct concepts, with the Patient Summary component more closely aligning with the Clinical Notes data class. Therefore, we propose repurposing the Patient Summary and Plan data class to the new Care Plan data class. Should this recommendation be adopted, we further recommend that the existing Assessment and Plan of Treatment (USCDI v6) data element, currently under the Patient Summary and Plan data class, be included in the new Care Plan data class.
   
Supporting information:
    i. HL7® Multiple Chronic Condition (MCC) Care Plan Implementation Guide (IG) defines FHIR R4 profiles, structures, extensions, transactions and value sets needed to represent, query for, and exchange Care Plan information (Multiple Chronic Care Condition Care Plan - MCC eCare Plan Implementation Guide v1.0.0). 
    ii. electronic Long-Term Services and Supports (eLTSS) IG (IG Home Page - Electronic Long-Term Services and Supports (eLTSS) Release 1 - US Realm v2.0.0).
    iii. CarePlan is about to be exchanged in FHIR (CarePlan - FHIR v4.0.1).
        1. Supporting extensions: CarePlan - FHIR v4.0.1
 

The draft definition of the Care Plan data element for the USCDI provides a strong foundation by outlining key components such as prioritized problems, health concerns, assessments, goals, and interventions. These components reflect the core elements common across different types of care plans, including nursing care plans, diabetic care plans, chronic condition care plans, and long-term services and support care plans. These elements are essential for coordinating care, tracking progress, and ensuring alignment across care teams.
However, there may be a need for further clarification regarding the specific details or granularity required for each of these components. For example, the definition mentions "prioritized problems" but does not specify whether this refers to clinical issues, psychosocial concerns, or other types of health challenges. Similarly, while it lists "goals" and "interventions," it would be helpful to clarify if these should be aligned with specific clinical outcomes, patient preferences, or evidence-based practices. Additionally, incorporating goals of care would enhance the definition, ensuring that care plans align with the patient’s values and priorities.
An important consideration is the longitudinal nature of care plans. For instance, a diabetic care plan may begin in the hospital but should follow the patient into PAC settings. The same care goals should persist across different care environments, but the plan must be adapted as necessary based on the site of care and any changes in the patient’s condition or goals. 
   
Including a Care Plan data class with relevant data elements will improve communication and care coordination across care teams, enhance patient safety and experience, and provide access to patient- and caregiver-centric data.

Submitted by mturchioe on

ANI's comment on USCDI v6: Care Plan

The Alliance for Nursing Informatics (ANI) supports the inclusion of this data element and adds our comments below. Please see previously submitted ANI comments for additional recommendations.

  • Consider reframing to a “patient care plan” that is longitudinal, interdisciplinary, and dynamic. 
  • Include patient preferences, values, and goals explicitly, and how this connects to the “patient goals” data element. 
  • Clarify how the care plan is rendered, where it fits in messaging, and how it aligns with FHIR. Certified EHRs and hospitals have a variety of ways to meet the care plan requirements (i.e., discrete, both discrete and text, text only), which should be considered with the ability to transmit this data meaningfully. This is a potential technical challenge, and a challenge in sending meaningful data.

Submitted by david_rocha on

Care plan (record artifact): 734163000

Care plan (record artifact): 734163000

 

Looking at SNOMED CT international edition for care plan (record artifact).

All of the 76 subtype (descendant) concepts (all the types of care plans) are below...

 

 

Children (76)

 

Log in or register to post comments

FormGuide

Help

1. Optional: Background Text / Cover Letter

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:

  1. In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
  2. 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.
  3. Note that the Data Class field will automatically populate based on your current location in the platform:
    1. If you are on a data class page, the field will be set to that specific data class
    2. 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:

  1. In the "Data Element" drop-down menu, select the specific data element you want to comment on.
  2. The drop-down menu will display only the elements available under the data class you selected in the previous step.
  3. You can use the search function within the drop-down to quickly locate a specific data element.
  4. 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.
 

Data Class and Data Element

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:

  1. 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."
  2. This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
  3. In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
  4. Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Propose New Data Class or Element

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:

  1. After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
  2. A new comment section will appear, allowing you to enter details for your additional comment.
  3. For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
  4. Complete the Subject and Comment fields for your additional comment.
  5. 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.

Upload Supporting Files

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:

  1. Click the "Save and Exit" button at the bottom of the form.
  2. Your comment will be saved as a draft that you can access and complete later.
  3. 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.
  4. Click this button to continue working on your draft.
  5. You will be taken to a review page where you can:
    1. Select "Submit Comment" to officially submit your feedback.
    2. Click "Edit" to return to the comment form and make changes
    3. 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:

  1. Click the "Review and Submit" button at the bottom of the form.
  2. This will take you to a review screen displaying your comment(s) in full.
  3. Review all information for accuracy and completeness.
  4. On this review screen, you have three options: 
    1. Click "Submit Comment" to officially submit your feedback
    2. Click "Edit" to return to the comment form and make changes
    3. Click "Discard Draft" to delete the comment and start fresh
  5. The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records. 
  6. If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Review and Submit

Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.

USCDI Comments

Close

Add a New Comment

Review comment and Submit

Edit
Comment #1
PDF, Doc, Docx
Max Size : 10 MB