Summary of Design Decisions

![](https://hackmd.io/_uploads/rkzPgbe03.png) <style>.markdown-body { max-width: 1500px; }</style>  source: https://hackmd.io/@erichaas/rk0FJ7wKp/%2Fr-VtK_20Rw25Vf81p5Lyvg # Summary of US Core V9 Design for USCDI R6 Note: - MS = Must Support for all implementers - Add'l USCDI = Must Support for Certifying Systems --- <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: Use US Core CarePlan Profile Note that the Data Class name changed to *Patient Summary and Plan* DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) 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 V9 Proposal ---|---|--- **Care Plan** 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 prioritized problems, health concerns, assessments, goals, and interventions from across care settings. Examples include nursing care plan, diabetic care plan, multiple chronic conditions care plan, and long term services and support care plan.||1. Use the US Core CarePlan Profile 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. ### Issues Considered 1. Alignment with existing US Realm Care Plan Profiles 2. Alignment 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." 3. CarePlans can be part of Clinical Notes - **[CarePlan Design Notes](/RDdfbNNsSy-d4IBEX9L4mg)** - **[CCDA Design Notes](https://confluence.hl7.org/spaces/SD/pages/358884594/Care+Plan+v6+Class+was+Patient+Summary+and+Plan+v5+and+Before)** ---  ## Family Health History: Create a :new: US Core FamilyMemberHistory Profile DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) 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 V9 Proposal ---|---|--- **Family Health History** Family member's health conditions that are relevant to a patient's care.| • Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) U.S. Edition, March 2025 Release • International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) 2025 |1. Create a :new: US Core FamilyMemberHistory Profile use the [ US Core Condition Problems and Health Concerns Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-condition-problems-health-concerns.html)`Condition.code` [binding](https://hl7.org/fhir/us/core/ValueSet-us-core-condition-code.html) to support Family Health History concepts ### Issues Considered 1. Condition codes in US Core Condition Problems and Health Concerns Profile vs [FamilyMemberHistory](https://hl7.org/fhir/R4/familymemberhistory.html) resourcs 2. Alignment with existing US Realm FamilyMemberHistory Profiles 3. Alignment of Relationship binding 4. "small-p" provenance - **[Family Health History Design Notes](/PJg540_xTv6TbJ-b7rUC_A)** - **[CCDA Design Notes](https://confluence.hl7.org/spaces/SD/pages/358884592/Family+Health+History+v6)** --- ## Facility Address: Use US Core Location Profile  DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) 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 V9 Proposal ---|---|--- **Facility Address** Physical location of available services or resources.|| Use the [US Core Location Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-location.html). `Location.address` is already a *Must Support* element. - **[Facility Address Design Notes](/I0j6EPn6SmGF1vTtp_WR8A)** - **[CCDA Design Notes](https://confluence.hl7.org/spaces/SD/pages/358884586/Facility+Information+v6)** --- ## Date of Onset: Use US Core US Core Condition Problems and Health Concerns Profile  DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) 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 V9 Proposal ---|---|--- **Date of Onset** Date or estimated date when signs or symptoms of a condition began. Usage note: This may be a specific day, week, month, or year, or it may be an estimate||Use the [US Core Condition Problems and Health Concerns Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-condition-problems-health-concerns.html). Remove the [*Must Support - Choice of Profile Elements*](https://build.fhir.org/ig/HL7/US-Core/must-support.html#presentation-of-must-support-mandatory-and-uscdi-requirement-elements-in-the-formal-profile-views) on the assertedDate Extension, `Condition.onsetDateTime`, and `Condition.recordedDate` They are all now *Must Support*. ### Issues Considered 1. In practice, the 'Date of Onset' is often conflated with the USCDI Data Element 'Date of Diagnosis'. - **[Date of Onset Design Notes](/0aZXIcJ2SUe2c70L8jyh6A)** - **[CCDA Design Notes](https://confluence.hl7.org/spaces/SD/pages/358884596/Problems+v6)** --- ## Unique Device Identifier (UDI): Rename US Core Implantable Device Profile to US Core Device Profile  DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) 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 V9 Proposal ---|---|--- **Unique Device Identifier** Numeric or alphanumeric code that uniquely identifies a medical device. Usage note: Contains a device identifier (DI) and may contain one or more production identifiers (PI).|FDA Unique Device Identification (UDI) System|1. Rename the [US Core Implantable Device Profile]([#](https://hl7.org/fhir/us/core/StructureDefinition-us-core-implantable-device.html)) to "US Core Device Profile". 2. Changes: - UDI constraints from *Must Support* to *Add'l USCDI* - No longer required to always have a patient. ### Issues Considered 1. How renaming US Core Profile will impact implementers 2. What are medical devices? How would this profile be scoped? 3. Alignment with existing US Realm Care Device Profiles - **[Unique Device Identifier (UDI) Design Notes](/9wtIE4WlTnGAlY4zPtUZdQ)** - **[CCDA Design Notes](https://confluence.hl7.org/spaces/SD/pages/358884588/Medical+Devices+v6)** ---  ## Portable Medical Order: Create a :new: US Core PMO ServiceRequest Profile  DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) 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 V9 Proposal ---|---|--- **Portable Medical Order** Provider-authored request for end-of-life or life-sustaining care for a person who has a serious life-limiting medical condition. Usage note: These are meant to follow a person regardless of when and where such an order might be needed (e.g., hospital, care facility, community, home). There are variations in requirements and names for portable medical orders based on jurisdiction. Examples include, but are not limited to, POLST (Portable Medical Order for Life-Sustaining Treatment), MOLST (Medical Orders for Life-Sustaining Treatment), and out-of-hospital DNR (do-not-resuscitate).||Create a :new: US Core PMO ServiceRequest Profile ### Issues Considered - USCDI definition is ambiguous and could mean a a PMO* document or instantiated orders based on it. - There could be many ServiceRequest orders generated - Typically PMO documents are shared through scanned images - No standard terminology, often text *For example, the [National Polst Model Form](https://polst.org/wp-content/uploads/2021/03/2020.05.11-National-POLST-Form-with-Instructions-r2.pdf) - :point_right: [Draft Profile](https://healthedata1.github.io/test-stuff/StructureDefinition-us-core-pmo-servicerequest.html) :point_left: - :point_right: [Example DNR Order](https://healthedata1.github.io/test-stuff/ServiceRequest-example-pmo-servicerequest.html) :point_left:  - **[Portable Medical Order Design Notes](/PbvJwFrkTTqI2CNfBWyOYw)** - **[CCDA Design Notes](https://confluence.hl7.org/spaces/SD/pages/358884590/Orders+v6)** --- ## Other USCDI V6 Changes: No Changes to US Core - **[Other USCDI V6 Changes Design Notes](/HI9irNnZSYijIYdDNYl1_A)**

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.