CarePlan - HackMD

<style> #doc.markdown-body, .ui-infobar, .container-thiner { max-width: 1080px; /* Adjust this value to make wider, e.g., 1200px or 1550px */ } .ui-content #doc.markdown-body, .ui-content .ui-infobar { max-width: 1550px; /* Set a wider max-width for content */ } @media (min-width: 768px) { #doc.markdown-body, .ui-infobar { max-width: 750px; /* Optional: Adjust for smaller screens */ } } @media (min-width: 1200px) { #doc.markdown-body, .ui-infobar { max-width: 1170px; /* Optional: Adjust for larger screens */ } } </style> CarePlan ## CarePlan: Use US Core CarePlan Profile  ![image](https://hackmd.io/_uploads/B1pjMwtvex.png) **:new: Definition :point_down:** ![image](https://hackmd.io/_uploads/SJ-f7Dtwex.png)  DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)<br/>Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. Where an applicable vocabulary standard has not been identified, this field will remain empty.|US Core V8 Proposal ---|---|--- **Care Plan**<br/>Shared plan informed by members of a coordinated care team that details conditions, needs, and goals along with strategies for addressing them.<br/><br/>Usage notes: Includes prioritized problems, health concerns, assessments, goals, and interventions from across care settings.<br/><br/>Examples include nursing care plan, diabetic care plan, multiple chronic conditions care plan, and long term services and support care plan.||Use the US Core CarePlan Profile (see below) ### CCDA Design Notes [Care Plan v6 (Class was Patient Summary and Plan v5 and Before)](https://confluence.hl7.org/spaces/SD/pages/358884594/Care+Plan+v6+Class+was+Patient+Summary+and+Plan+v5+and+Before) ### Issues #### :thinking_face: What are the minimum required elements 1. About a half a dozen published US Realm CarePlan Profiles. They all are derived from US Core CarePlan. However, we need to re-evaluate the minimal common core elements. (CarePlan not part of IPA, or IPS) :thinking_face: Are there any widely supported *unpublished* CarePlan Profiles? see Person Centered Outcome (May ballot) In addition to the US Core elements (See [Analysis of Existing CarePlan Profiles](https://hackmd.io/RDdfbNNsSy-d4IBEX9L4mg?view#Analysis-of-Existing-CarePlan-Profiles) below for details ): 4/5 profiles support `CarePlan.addresses` (0..* Reference(Condition)) Definition: Identifies the conditions/problems/concerns/diagnoses/etc. whose management and/or mitigation are handled by this plan. 3/5 profiles support `CarePlan.supportingInfo` (0..* Reference(Any))Definition:Identifies portions of the patient's record that specifically influenced the formation of the plan. These might include comorbidities, recent procedures, limitations, recent assessments, etc. 1. To Functionally Align US Core CarePlan with the USCDI definition: "Shared plan informed by members of a coordinated care team that details **conditions** [aka, `CarePlan.addresses`], **needs** [aka, `CarePlan.addresses`], and **goals** [aka, `CarePlan.goal`] along with **strategies** [aka, `CarePlan.activity`]for addressing them." We address this in our Current US Core CarePlan's Profile Specific Implementation Guidance: > - Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements: > - US Core Goal SHOULD be present in CarePlan.goal > - US Core Condition SHOULD be present in CarePlan.addresses #### :thinking_face: CarePlan's Overlap with Clinical Notes We address this in our Current US Core CarePlan's Profile Specific Implementation Guidance: > - *The original Assessment and Plan design in the CarePlan was to support the "Assessment and Plan" from a narrative Progress Note. Systems have advanced significantly since the introduction of this requirement in 2015. Relaxing this to 0..1 allows more sophisticated systems to discretely encode a CarePlan instead of providing the narrative portion... > - As an alternative to the US Core CarePlan, Assessment and Plan of Treatment may be included in various types of Clinical Notes, such as Progress Notes, History & Physical (H&P), Discharge Summaries, etc. The CarePlan Data Class and Data Element Share these same issues. ### Proposals 1. Add MS elements (or additional USCDI): - CarePlan.goal - CarePlan.addresses - CarePlan.activity? > Jason: keep narrative focus and not add more elements. USCDI not a capture spec. This would be a new capture requirement. > Isaac: multiple careplans not sure which one is intended by USCDI > Fran: only support narratives currently > Dave: would like to see the goal referenced text is not adequate > Brett: Propose we do not add elements but add documentation that the Future direction of US Core CarePlan is to descretely reference conditions/needs, goals, and strategies for addressing them. 2. Map 'Assessment and Plan of Treatment' Data Element to ***both*** US Core Care Plan and Clinical Notes in the USCDI table and update the documentation in both the CarePlan profile and Clinical Notes 3. Map the 'Care Plan' Data Element to only the CarePlan profile ### Decisions Based on the Argonaut design calls ( see [Summary of Design Decisions](/u8iAyzZ0SGahQdbVzYpfoQ)) and subsequent Sept 2025 WGM discussion: - [Sept 2025 WGM Slides](https://confluence.hl7.org/download/attachments/358885005/USCDI%20v6%20Design%20for%20US%20Core%20and%20C-CDA.pptx?version=1&modificationDate=1759008895006&api=v2) - [WGM Minutes](https://confluence.hl7.org/spaces/CGP/pages/358284520/Cross+Group+Project+2025+September+-+Wed+Q3) 1. (8/7/2025 Provisional Decision Pending Further Discussion) Will **not** add MS elements (or additional USCDI) to US Core CarePlan keeping the existing CarePlan Profile unchanged. Document in the *Profile Specific Implementation Guidance* that the future direction of US Core CarePlan Profile is move from text-based content to discrete references to conditions/needs, goals, and strategies for addressing them. (proposed text is pending)NO 1. Add `CarePlan.addresses` as a new 0..* Additional USCDI element 2. **DO NOT** Map 'Assessment and Plan of Treatment' Data Element to ***both*** US Core Care Plan and Clinical Notes in the USCDI table (keep existing mapping to only US Core Care Plan) 3. Map the 'Care Plan' Data Element to US Core CarePlan (like we do for Assessment and Plan) 5. DO NOT add certification guidance" "Systems that always populate category = "AssessPlan" and always include CarePlan.addresses will consistently meet the USCDI data element requirements for both Care Plan and Assessment and Plan." because we are removing the assess-plan category. (see below) 2. Document that the future direction of US Core CarePlan Profile is move from text-based content to discrete references to conditions/needs, goals, and strategies. 2. Discussed these options for Categorization of CarePlans ( USCDI CarePlan Data Class with 2 data elements: AssessPlan and CarePlan) on !0/0 CGP call to answer these questions and chose option 3 below. - Who in the workflow decides what kind of careplan it is and does it even matter? - If it matters then the options are: 1. no change Pros - support the definition of CarePlan.category: "Identifies what "kind" of plan this is to support differentiation between multiple co-existing plan...multiple axes of categorization and one plan may serve multiple purposes." - 'assess-plan' category is a different axis than the example CarePlanCategory binding concepts - allows to differentiate assess-plan from other uses of care plans and from the "generic" careplan defined by USCDI - can have multiple category 1. create an explicit careplan category code to differentiate the careplans from assessments and plan. Pros - support the USCDI definition and makes certifcation testing easier? Cons - a contrivance? 1. ✅ Loosen `category` from 1..1Mandatory to 0..1 Must Support Pros - same as option 1 - but not mandatory Cons - ? - If it does not matters (In other words, the presence or absence of an assess-plan category does not differentiate between the two types of careplan data element defined by USCDI) then: 1. ✅ Loosen `category` from 1..1Mandatory to 0..1 Must Support, remove the assess-plan slice - and call it a day! 2. ✅ Change the CarePlanCategory *example* binding strength to *preferred* ### IG Updates - [x] USCDI Mapping Table - [x] Update US Core Profile - [x] deprecate US Core CarePlan Category Extension Codes code system - [ ] notify publishing that pink deprecate box is not showing up for codesystems. - [x] Update Introduction - [x] Implementation Specific Guidance - [x] New Example(s) pending final review of decisions - [ ] Update Example(s) pending final review of decisions --- ## Appendix ### Analysis of Existing CarePlan Profiles #### US Core CarePlan: ##### Each CarePlan Must Have: 1. a status 2. a category 3. an intent 4. a patient ##### Each CarePlan Must Support: 1. a narrative summary of the patient assessment and plan of treatment* 2. a category code of "assess-plan" #### CarePlans published by HL7. 1. [eLTSS CarePlan Profile](http://hl7.org/fhir/us/eltss/StructureDefinition/CarePlan-eltss) 2. [MCC CarePlan Profile](http://hl7.org/fhir/us/mcc/StructureDefinition/mccCarePlan) 3. [PA CarePlan Profile](http://hl7.org/fhir/us/physical-activity/StructureDefinition/pa-careplan) 5. [ADI PMO Care Plan](http://hl7.org/fhir/us/pacio-adi/StructureDefinition/ADI-PMOCarePlan) 6. [ADI PtAuthored Care Plan](http://hl7.org/fhir/us/pacio-adi/StructureDefinition/ADI-PreferenceCarePlan) Note The [PCDE Coverage Transition CarePlan Profile](http://hl7.org/fhir/us/davinci-pcde/StructureDefinition/profile-careplan) has been withdrawn #### Most commonly profiled elements (Generated by Grok, an xAI AI model, on July 31, 2025) A checkmark (✅) indicates that the element is Must Support or has a minimum cardinality of 1 for the respective profile. | CarePlan Element | US Core | eLTSS | MCC | PA | ADI PMO | ADI PtAuthored | Count | |------------------|---------|-------|-----|----|---------|----------------|-------| | CarePlan.text | ✅ (0..1, Must Support) | ✅ | ✅ | ✅ (1..1) | ✅ | ✅ | 6 | | CarePlan.text.status | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | 6 | | CarePlan.text.div | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | 6 | | CarePlan.status | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | 6 | | CarePlan.intent | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | 6 | | CarePlan.category | ✅ (1..*) | ✅ (1..*) | ✅ (1..*) | ✅ (2..*) | ✅ (1..*) | ✅ (1..*) | 6 | | CarePlan.category:AssessPlan | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (0..1) | ✅ (0..1) | 6 | | CarePlan.subject | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | ✅ (1..1) | 6 | | CarePlan.encounter | | ✅ | | | | | 1 | | CarePlan.period | | ✅ | | ✅ | | | 2 | | CarePlan.period.start | | ✅ (1..1) | | ✅ | | | 2 | | CarePlan.period.end | | ✅ | | ✅ | | | 2 | | CarePlan.author | | ✅ | | | | | 1 | | CarePlan.contributor | | | ✅ | | | | 1 | | CarePlan.careTeam | | | ✅ | | | | 1 | | :star: CarePlan.addresses | | ✅ | ✅ | | ✅ | ✅ | 4 | | :star: CarePlan.supportingInfo | | ✅ | ✅ | | | ✅ | 3 | | CarePlan.goal | | ✅ | | | | ✅ | 2 | | CarePlan.activity | | ✅ | ✅ | | | | 2 | | CarePlan.activity.reference | | ✅ | ✅ | | | | 2 | | CarePlan.activity.outcomeReference | | | ✅ | | | | 1 | | CarePlan.note | | ✅ | | ✅ | | | 2 | | CarePlan.note.author[x] | | | | ✅ (1..1) | | | 1 | | CarePlan.note.time | | | | ✅ (1..1) | | | 1 | | CarePlan.note.text | | | | ✅ (1..1) | | | 1 | | CarePlan.partOf | | ✅ | | | | | 1 | | CarePlan.category:PA | | | | ✅ (1..1) | | | 1 | | CarePlan.category:portable_medical_order | | | | | ✅ (1..1) | | 1 | | CarePlan.category:advance_care_planning | | | | | | ✅ (1..1) | 1 | | CarePlan.title | | | | | | ✅ (1..1) | 1 | In addition to the US Core elements: - 4/5 profiles support `CarePlan.addresses`: 0..* Reference(Condition) > Identifies the conditions/problems/concerns/diagnoses/etc. whose management and/or mitigation are handled by this plan. - 3/5 profiles support `CarePlan.supportingInfo` 0..* Reference(Any) > Identifies portions of the patient's record that specifically influenced the formation of the plan. These might include comorbidities, recent procedures, limitations, recent assessments, etc.