Slides:Summary of US Core V7 Design for USCDI R4

![](https://hackmd.io/_uploads/rkzPgbe03.png) <style>.markdown-body { max-width: 1500px; }</style> <style> th, tbody td, p, li, h5 {font-size: 33%;}</style> ## Summary of US Core V7 Design for USCDI R4 - US Core V7 Design: https://hackmd.io/@erichaas/BJXs2R672 - Slide Deck: [Summary of US Core V7 Design for USCDI](https://confluence.hl7.org/download/attachments/184920812/Summary%20of%20US%20Core%20V7%20Design%20for%20USCDI%20R4_%20-%20HackMD.pdf?version=1&modificationDate=1693695352995&api=v2) - Note: "MS" = Must Support --- ### Allergies and Intolerance DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. If a cell is empty, an applicable vocabulary standard has not been identified.|US Core V6 Proposal ---|---|--- **Substance (Non-Medication)** Non-pharmacologic agent believed to cause a harmful or undesired physiologic response following exposure. Examples include but are not limited to latex, eggs, pollen, and peanuts| Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) U.S. Edition, March 2023 Release|**No Change**: US Core`AllergyIntolerance.code` binding to [Common substances for allergy and intolerance documentation including refutations](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1186.8/expansion) already includes "Non-pharmacologic agent" For Design Notes see [Allergies and Intolerance](/vdnc6ek3RP-n9c7mOSIJCA) --- ### Encounter DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)|US Core V6 Proposal ---|---|--- **Encounter Identifier** Sequence of characters by which an encounter is known.||**No Change**: US Core`Encounter.identifier` is a Must Support element For Design Notes see [Encounter](/WksTXCjiR7KQT1HfH-nJ8g) --- ### Procedures DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)|US Core V6 Proposal ---|---|--- **Time of Procedure** Time and/or date a procedure or other action is performed. Examples include but are not limited to vaccine or medication administration times, surgery start time, and time ultrasound performed.|| **No Change**: - US Core Procedure Profile (surgery start time) `Procedure.performed[x]` is a Must Support element - US Core DiagnosticReport Profile (time ultrasound performed) `DiagnosticReport.effective[x]` is a Must Support element - US Core Immunization Profile (vaccine administration time) `Immunization.occurrence[x]` is a Must Support element  For Design Notes see [Procedures](/NhGJEbDVT3G3PcBzJ_FIJA) --- ### Vital Signs DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)|US Core V6 Proposal ---|---|--- **Average Blood Pressure** Arithmetic average of systolic and diastolic components of two of more blood pressure readings in a specified time period or according to a specified algorithm or protocol. Examples include but are not limited to 3-day morning and evening home monitoring, clinical encounter repeat average, and 24-hour ambulatory measurement.|Both standards are required. Logical Observation Identifiers Names and Codes (LOINC) version 2.74 The Unified Code of Units for Measure, Revision 2.1|:new: US Core Mean Blood Pressure Profile* using [Vital Signs with Qualifying Elements (CIMI):Average Blood Pressure](http://hl7.org/fhir/us/vitals/STU1/StructureDefinition-average-blood-pressure.html) as a blueprint \*US Core Mean Blood Pressure Profile Details - Blood pressure panel mean (e.g., N BPs/N) systolic and mean diastolic ([LOINC 96607-7](https://loinc.org/96607-7)) - Add implementation guidance on protocol: e.g., *Information about the protocol used to determine averages SHOULD be supplied in Observation.note.text (for example, ‘ 24-hour ambulatory measurement.’)* - Add implementation guidance on CIMI and Card-X extensions ##### :arrow_right: [Average Blood Pressure Profile and Examples](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#average-blood-pressure) For Design Notes see [Vital Signs](/Z9WsUlwfTHy6yrnZXXdzLw) --- ### Facility Information DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. If a cell is empty, an applicable vocabulary standard has not been identified.|US Core V6 Proposal ---|---|--- **Facility Identifier** Sequence of characters representing a physical place of available services or resources.||:new: : US Core`Location.identifier` 0..* Must Support **Facility Type** Category of service or resource available in a location. Examples include but are not limited to hospital, laboratory, pharmacy, ambulatory clinic, longterm and post-acute care facility, and food pantry||:new:: US Core`Location.type` 0..* Must Support, Binding: [ServiceDeliveryLocationRoleType](http://terminology.hl7.org/5.0.0/ValueSet-v3-ServiceDeliveryLocationRoleType.html) (extensible) **Facility Name** Word or words by which a facility is known.||**No Change**: US Core`Location.name` is a Must Support element ##### :arrow_right: [Location Profile and Examples](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#facility_information) --- ### Facility Information To support links to the facility via Encounter add `.encounter` (or`.context`) as a MS elements (or`.context`) to the US Core Profiles listed below. These links indirectly reference the location via Encounter. - Add `.location` as a MS element to the US Core Immunization Profile to address the special circumstance with vaccinations at pop-up sites and Pharmacies. - Add implementer guidance that if the actual event location is different from Encounter.location SHOULD use that resource's `.location` element if present. Note: Current Must Support/USCDI Requirements are listed in **bold** text |US Core Resource|Reference to Encounter|Reference to Location |--- |--- |--- | |DiagnosticReport (Lab)|DiagnosticReport.encounter|None| |DiagnosticReport (Notes)|**DiagnosticReport.encounter (MS)**|None| |Encounter|Encounter.partOf|**Encounter.location (MS)**| |Immunization|Immunization.encounter|Immunization.location| |MedicationDispense|MedicationDispense.context|MedicationDispense.location| |Observation (Lab)|Observation.encounter|Not included - potential extension| |Procedure|Procedure.encounter|Procedure.location| |ServiceRequest|ServiceRequest.encounter|ServiceRequest.locationCodeServiceRequest.location For Design Notes see [Facility Information](/xmpbtnmxSzK0m2_fdm2dcA) --- ### Laboratory DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. If a cell is empty, an applicable vocabulary standard has not been identified.|US Core V6 Proposal ---|---|--- **Result Unit of Measure** Unit of measurement to report laboratory test results|The Unified Code of Units for Measure, Revision 2.1|**No Change**: US Core Laboratory Result Observation Profile`Observation.valueQuantity` 0..1 *Must Support* us-core-3: SHALL use UCUM for coded quantity units. **Result Reference Range** Upper and lower limit of test values expected for a designated population of individuals. Usage note: reference range values may differ by patient characteristics, laboratory test manufacturer and laboratory test performer.||:new: US Core Laboratory Result Observation Profile`Observation.referenceRange` 0..* *Must Support* **Result Interpretation** Categorical assessment of a laboratory value, often in relation to a test's reference range. Examples include but are not limited to high, low, critical, and normal.|Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) U.S. Edition, March 2023 Release* Optional: HL7 Code System ObservationInterpretation|:new: US Core Laboratory Result Observation Profile`Observation.interpretation` 0..* *Must Support* Binding: [ObservationInterpretationCodes](http://hl7.org/fhir/R4/valueset-observation-interpretation.html) (extensible) --- ### Laboratory DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. If a cell is empty, an applicable vocabulary standard has not been identified.|US Core V6 Proposal ---|---|--- **Specimen Source Site** Body location from where a specimen was obtained. Examples include but are not limited to right internal jugular, left arm, and right eye.|Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) U.S. Edition, September 2022 Release|:new: US Core Specimen Profile`Specimen.collection.bodySite` 0..1 *Additional USCDI Requirement* Binding: [SNOMED CT Body Structures](http://hl7.org/fhir/ValueSet/body-site) (extensible) **Specimen Identifier** Sequence of characters assigned by a laboratory for an individual specimen.||:new: US Core Specimen Profile`Specimen.identifier` 0..* Must Support **Specimen Condition Acceptability** Information regarding a specimen, including the container, that does not meet a laboratory’s criteria for acceptability. Examples include but are not limited to hemolyzed, clotted, container leaking, and missing patient name. Usage note: This may include information about the contents of the container, the container, and the label.|Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) U.S. Edition, March 2023 Release*|:new: US Core Specimen Profile`Specimen.condition` 0..1 *Additional USCDI Requirement* Binding: [hl7VS-specimenCondition](http://terminology.hl7.org/5.0.0/ValueSet-v2-0493.html) (extensible) --- ### Laboratory \* :exclamation: Issue with ONC vs HL7 terminology requirements ##### :arrow_right: [Laboratory and Specimen Profiles and Examples](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#laboratory) For Design Notes see [Laboratory](/Ed2-9T2QQNihYUksWs55TQ) --- ### Health Status Assessments DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)|US Core V6 Proposal ---|---|--- **Physical Activity** Evaluation of a patient's current or usual exercise. Examples include but are not limited to Exercise Vital Sign.||Base it on US Core's [Screening and Assessments](http://hl7.org/fhir/us/core/screening-and-assessments.html) In other words, reused Simple Observations/US Core Condition Problems and Health Concerns, The US Core Observation Screening Assessment Profile,The SDC Base Questionnaire/US Core QuestionnaireResponse Profile with recommendation to use value sets from [Physical activity IG](http://hl7.org/fhir/us/physical-activity/2023May) **Alcohol Use** Evaluation of a patient's consumption of alcohol. Examples include but are not limited to history of alcohol use, alcohol use disorder identification test and alcohol intake assessment.||Same as above with recommended domain specific value set from (TAPS or SDOH) **Substance Use** Evaluation of a patient's reported use of drugs or other substances for non-medical purposes or in excess of a valid prescription. Examples include but are not limited to substance use disorder score, and substance use knowledge assessment.||Same as above with recommended domain specific value set from (TAPS or SDOH) --- ### Health Status Assessments Provide implementer Guidance on appropriate terminology and Assessment Tools - Physical Activity IG - TAPS : The Tobacco, Alcohol, Prescription medication, and other Substance use (TAPS) Tool ##### :arrow_right: [Physical Activity Examples Based on US Core Screenings and Assessements](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#physical-activity) ##### :arrow_right: [Substance Use Examples Based on US Core Screenings and Assessements](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#substance-use) ##### :arrow_right: [Alcohol Use Examples Based on US Core Screenings and Assessements](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#alcohol-use) For Design Notes see [Health Status Assessments](/3J_QYnLGSKSx2YoawRUmBA) ---- ### Terminology Options ##### 1. Current Approach is to document that SHOULD use terminology X (not profiled as extensible binding) - Let Use Case specific Implementation Community (e.g., Quality Measures) nail it down in their implementations. ##### 2. Define Profiles with extensible bindings for each domain - :warning: Proliferation of Assessment Profiles - :warning: Extensive overlap between domains ##### 3. Something in between - :thinking_face: a table with recommended/required extensible bindings - :thinking_face: or Use R5 additional bindings extensions --- ### Medications DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)|US Core V6 Proposal ---|---|--- **Medication Instructions** Directions for administering or taking a medication. Examples include but are not limited to prescription directions for taking a medication, and package instructions for over-the-counter medications. Usage notes: May include route, quantity, timing/frequency, and special instructions(PRN, sliding scale, taper).||**No Change**: US Core`MedicationRequest.dosageInstruction` is a Must Support element **Medication Adherence** Statement of whether a medication has been consumed according to instructions. Examples include but are not limited to taking as directed, taking not as directed, and not taking.| Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) U.S. Edition, March 2023 Release*|:new: 0..* *Additional USCDI Requirement* MedicationAdherance extension on MedicationRequest --- ### Medications \*Use SNOMED CT vs MedicationStatement Adherence Codes Extensible |Code (SCT ID)|Preferred Term|Available Acceptable Term (Synonym)|Available Acceptable Term (Synonym)| ---|---|---|---| 1156699004|Complies with drug therapy (finding)| Adheres to drug therapy|Adheres to medication regime| 702565001|Non-compliance of drug therapy (finding)| Drug therapy non adherence|Medication therapy non-adherence| 275928001|Drugs - partial non-compliance (finding)||| 275927006|Drugs - total non-compliance (finding)||| 457831000124109|Medication therapy compliance variable (finding) | Medication therapy compliance variable| Medication adherence variable| 26166500**|Unknown (Qualifier) \** Note: No more specific unknown code vs FHIR DAR code??? ##### :arrow_right: [MedicationRequest with Adherance Extension Examples](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#medication) For Design Notes see [Medications](/B94huB65SnSIA5GuG28WNQ) --- ### Goals DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S) Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. If a cell is empty, an applicable vocabulary standard has not been identified.|US Core V6 Proposal ---|---|--- **Treatment Intervention Preference** Person's goals, preferences, and priorities for care and treatment in case that person is unable to make medical decisions because of a serious illness or injury. Examples include but are not limited to thoughts on cardiopulmonary resuscitation, mental health treatment preferences, and thoughts on pain management.|Logical Observation Identifiers Names and Codes (LOINC) version 2.74|:new: Observation derived from US Core Simple Observation using [PACIO'a ADI Personal Intervention Preference Profile](https://build.fhir.org/ig/HL7/fhir-pacio-adi/branches/master/StructureDefinition-ADI-PersonalInterventionPreference.html) as a blueprint. **Care Experience Preference** Person's goals, preferences, and priorities for overall experiences during their care and treatment. Examples include but are not limited to religious beliefs, dislikes and fears, and thoughts and feelings to be shared.|Logical Observation Identifiers Names and Codes (LOINC) version 2.74|:new: Observation derived from US Core Simple Observation using [PACIO's ADI Care Experience Preference Profile](https://build.fhir.org/ig/HL7/fhir-pacio-adi/branches/master/StructureDefinition-ADI-CareExperiencePreference.html) as a blueprint. --- ### Goals \* Details. - Simplified version of the PACIO Profiles. (no mandatory Narrative norMust Support text elements for codes, no [PACIO Context Extension](https://build.fhir.org/ig/HL7/fhir-pacio-adi/branches/master/StructureDefinition-adi-contextualValue-extension.html), no fixed status to "complete") - Note: Typically There will be a String Value Type and any narrative content information is available in the valueString field. - derived from US Core Simple Observation which adds adds effective[x] and performer as MustSupport elements - add 2 new category codes to [US Core Category](https://build.fhir.org/ig/HL7/fhir-pacio-adi/branches/master/StructureDefinition-adi-contextualValue-extension.html) :thinking_face: - Constrain code to extensibily bind to either the PACIO code sets or a single code - Must Support or USCDI requirement for `derivedFrom` DocumentReference ##### :arrow_right: [Care Experience and Treatment Intervention Preference Profile and Examples](https://healthedata1.github.io/USCDI4-Sandbox/artifacts.html#goals-and-preferences) For Design Notes see [Goals](/a3eMn2mMRm6fj_y1lw9MSA) --- ### Next Steps For US Core V7 1. Presentation of our decisions ( alongside CCDA decision) at the Sept WGM Wed Q3-4 1. Apply updates to US Core CI Build 1. Host a series of public HL7 calls to review these updates and address US Core Trackers (HL7 CGP Calls every Thursday 1 PM Eastern) starting Sept 21st. 4. Publication of US Core v7.0.0-ballot in Jan 2024 Ballot 1. Ballot Reconciliation Jan-April 2024 1. Publication of US Core v7.0.0 in May 2024 > Change requests for existing US Core content (JIRA trackers) are due by Sept 30th to be considered for US Core v7.0.0-ballot version. Trackers after that will only be considered if they are technical corrections or solely at the editor's discretion, otherwise, they will be considered after the Jan 2024 Ballot. --- ## :man-raising-hand: :question: :woman-raising-hand: