Consolidated CDA Release 2.2 - Local Development build (v2.2). See the Directory of published versions

USCDI Guidance

The United States Core Data for Interoperability (USCDI)^138 is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. To support implementers in meeting this data policy, the HL7 community recommends following guidance in this section.

General USCDI Guidance

This section contains high level guidance that applies across USCDI Data Classes and Data Elements.

Best Practices for Implementing Templates revised to support USCDI v2 and v3

See Section 4.1.5 Declaring Section Template Conformance which includes a subsection on best practices for including templateIds when using new or revised templates supporting USCDI v2 and v3.

Social Determinant of Health Vocabulary Design Notes

The ONC US Core Data for Interoperability (USCDI) v2 update in July 2021 included several social determinants of health concepts, including problems, goals, procedures, and service requests. The HL7 Accelerator Gravity Project launched in 20 20 to improve how we use and share information on social determinants of health and built an SDOH clinical care implementation guide.

For the SDOH Clinical Care HL7 Implementation Guide, the Gravity project has defined the following value sets across specific social risk factor domains for problems/health concerns, goals, procedures, and service requests:

• Social Determinants of Health Conditions Value Set
• Social Determinants of Health Procedures Value Set
• Social Determinants of Health Goals Value Set
• Social Determinants of Health Service Requests Value Set (Used in the Planned Procedure Template)

The Figure below illustrates how the Gravity value sets are grouped for use in the C- CDA Problem Observation template.

Figure 8: Example of SDOH Grouping Value set in VSAC (Conditions)

As Gravity did not focus upon detailed work information, such concepts are not included in this value set. For communicating detailed observations related to an individual’s work information, implementers can consider utilizing the templates in the C-CDA 2.1 Supplemental Templates for Occupational Data for Health implementation guide.

USCDI Data Class and Data Element Guidance

In the sections below, specific guidance is included related to each of the USCDI v2 and V3 Data Classes and Data Elements.

Assessment and Plan of Treatment

Represents a health professional’s conclusions and working assumptions that will guide treatment of the patient.

Table 68: USCDI v2 Data Elements - Assessment and Plan of Treatment

SDOH Assessment

Assessment Screenings can represent a structured evaluation of risk (e.g., PRAPARE, Hunger Vital Sign, AHC-HRSN screening tool) for any Social Determinants of Health domain such as food, housing, or transportation security. The assessment scale responses are represented in C-CDA with the Assessment Scale Observation (V2) 2.16.840.1.113883.10.20.22.4.69:2022- 06 -01 and its contained Assessment Scale Supporting Observation 2.16.840.1.113883.10.20.22.4.86. The Social History Observation (V4) 2.16.840.1.113883.10.20.22.4.38:2022-06- 01 is for simple observations made by an individual about a patient’s social history status during the course of care. Both can contribute to the identification of SDOH Problems (Conditions) or Observations or can be the reason for Service Requests (Planned Procedures) or Procedures.

Assessment Scale Observation (V2) 2.16.840.1.113883.10.20.22.4.69:2022- 06 -01 and its contained Assessment Scale Supporting Observation 2.16.840.1.113883.10.20.22.4.86 are designed to represent LOINC Panels that are collections of LOINC terms that represent specific sets of information, intended for forms or assessments related to health that are completed by patients and/or providers.

When an Assessment Scale Observation is contained in a Problem Observation, a Social History Observation, a Procedure, or a Planned Procedure instance that is Social Determinant of Health focused, that Assessment scale may contain assessment scale observations that represent question and answer pairs from SDOH screening instruments.

For communicating detailed observations related to an individual’s work information, implementers can consider utilizing the templates in the C- CDA 2.1 Supplemental Templates for Occupational Data for Health implementation guide.

SDOH Observations and Survey Screenings and the resultant plans and interventions are foundational towards improving a person’s overall health and wellness when confronted with health problems.

Figure 9: SDOH Assessment and Planning Process

Care Team Member(s)

Represents information about a person who participates or is expected to participate in the care of a patient.

Table 69: USCDI V2 Data Elements - Care Team Member(s)

Care Team Member Name

No additional guidance

Care Team Member Identifier

No additional guidance

Care Team Member Role

No additional guidance

Care Team Member Location

No additional guidance

Care Team Member Telecom

No additional guidance

Clinical Tests

Includes non-imaging and non-laboratory/pathology tests performed on a patient that results in structured or unstructured (narrative) findings specific to the patient, such as electrocardiogram (ECG), visual acuity exam, macular exam, or graded exercise testing (GXT), to facilitate the diagnosis and management of conditions.

Please see 5.2.11.1 Pathology and Laboratory Result Domain for examples of types of imaging and laboratory/pathology tests to clarify what is not a clinical test.

Appendix B in U.S. Core Data for Interoperability (USCDI) Task Force 2021 HITAC Phase 3 Recommendations Report Letter identifies a starter set of example LOINC codes for “clinical tests’’.

Table 70: USCDI v2 Data Elements - Clinical Tests

Clinical Test

The organizer/code in the Result Organizer Template (2.16.840.1.113883.10.20.22.4.1) or the Observation/code in the Result Observation template (2.16.840.1.113883.10.20.22.4.2) records a test that has been performed. To align with common implementer practice with C- CDA Lab Result Observations, each Clinical Test Result Observation Template instance should be wrapped in a Result organizer, and the Result/Organizer/code should equal the Result Observation/code, except when the Clinical Test performed has Test Results that are logically resulted together. In this case the result observations should not each be wrapped in its own result organizer but should be resulted together as a bundled result inside the Clinical Test represented by the Organizer/code as described in the next paragraph.

The Result Organizer Template is designed to be used to wrap Result (test) Observations that are components of the same test. For example, a visual acuity study (28631-0) Visual acuity study (LOINC) code could be the test identified at the Result Organizer/code, and the Organizer then contains two Result Observations stating the visual acuity of each eye (79882-7 LOINC code for Visual acuity uncorrected Right eye by Snellen eye chart and 79883- 5 LOINC code for Visual acuity uncorrected Left eye by Snellen eye chart ) If a system needs to record a planned test, the Planned Procedure template in the Plan of Treatment section is used

Clinical Test Result/Report

The Result Organizer Template (2.16.840.1.113883.10.20.22.4.1) or the Result Observation template (2.16.840.1.113883.10.20.22.4.2) fulfills the need of the clinical test performed with the Result observation/value containing the Clinical Test Result/Report. Observation/Value in the Result Observation Template (2.16.840.1.113883.10.20.22.4.2) contains the result (fi nding) of the test. Observation/value may be an encoded value, physical quantity or text.

• Text (ST dataType)

<observation classCode="OBS" moodCode="EVN">
    <observation classCode="OBS" moodCode="EVN">
        <templateId root="2.16.840.1.113883.10.20.22.4.2"/>
        <templateId root="2.16.840.1.113883.10.20.22.4.2" extension="2023-05-01"/>
        <id root="f1aa44dd-6f39-4f5c-b267-897c3824b563"/>
        <code code="8601-7" displayName="EKG Impression"
            codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
        <statusCode code="completed"/>
        <effectiveTime value="20231023090823-0500"/>
        <!-- Representing a result returned as unstructured string-->
        <value xsi:type="ST">Irregular sinus arrhythmia with both sinus tachycardia
            sinus bradycardia (tachy-brady syndrome).</value>
        <interpretationCode code="A" codeSystem="2.16.840.1.113883.5.83"
            displayName="Abormal" />
    </observation>

• Encoded (datatype CD):

<observation classCode="OBS" moodCode="EVN">
    <observation classCode="OBS" moodCode="EVN">
        <templateId root="2.16.840.1.113883.10.20.22.4.2"/>
        <templateId root="2.16.840.1.113883.10.20.22.4.2" extension="2023-05-01"/>
        <id root="f1aa44dd-6f39-4f5c-b267-897c3824b563"/>
        <code code="69428-1" displayName="Jugular vein distension"
            codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
        <statusCode code="completed"/>
        <effectiveTime value="20231023090823-0500"/>
        <value xsi:type="CD" code="52101004" displayName="Present"
            codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
        <interpretationCode code="A" codeSystem="2.16.840.1.113883.5.83"
            displayName="Abormal" />
    </observation>

• Physical Quantity (dataType PQ)

<observation classCode="OBS" moodCode="EVN">
    <observation classCode="OBS" moodCode="EVN">
        <templateId root="2.16.840.1.113883.10.20.22.4.2"/>
        <templateId root="2.16.840.1.113883.10.20.22.4.2" extension="2023-05-01"/>
        <id root="f1aa44dd-6f39-4f5c-b267-897c3824b563"/>
        <code code="41355-9" displayName="Elbow - right Flexion Active Range of Motion
            Quantitative"
            codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
        <statusCode code="completed"/>
        <effectiveTime value="20231023090823-0500"/>
        <value xsi:type="PQ" value="110" unit="deg"/>
        <interpretationCode code="A" codeSystem="2.16.840.1.113883.5.83"
            displayName="Abormal" />
    </observation>

Diagnostic Imaging

Tests that result in visual images requiring interpretation by a credentialed professional.

Table 71: USCDI v2 Data Elements - Diagnostic Imaging

Diagnostic Imaging Test

Diagnostic Imaging Tests can have several statuses as they move through different systems. Common statuses are ‘ordered’, ‘performed’, and ‘resulted’. The companion guide recommends the use of Result Organizer and the statuses of ‘active’ (ordered /performed), and ‘completed’ (resulted). The statuses of Cancelled and Aborted may also be allowed.

Diagnostic Imaging Report

When the report is narrative, an entry reference from the observation to the narrative is preferred. See example.

Encounter Information

Information related to interactions between healthcare providers and the subject of care in which healthcare- related activities take place.

Table 72: USCDI v2 Data Elements - Encounter Information

Encounter Diagnosis

A Hospital Discharge Diagnosis [Hospital Discharge Diagnosis (V3) [act, 2.16.840.1.113883.10.20.22.4.33] “counts” as an Encounter Diagnosis where the encounter is a hospital stay or the last day of a hospital stay. If there are other (ambulatory, for example) encounters included in the document, those other encounters would need to have a separate instance of a diagnosis for Encounter Diagnosis (using Encounter Diagnosis [act, 2.16.840.1.113883.10.20.22.4.80], even if it’s the same diagnosis.

Encounter Disposition

Implementers should note that a Discharge Disposition is not appropriate for all document types

• Hospital Discharge Summary documents SHOULD have a discharge disposition
• Progress Notes, or H&P, typically won’t have a discharge disposition.

In Encounter Summaries the Encounter Disposition will also be present in the document header at componentOf/encompassingEncounter/dischargeDispositionCode, but in Patient Summaries, componentOf/encompassingEncounter SHALL NOT be present. While an Encounter Summary provides a snapshot of the patient’s condition at the time of the encounter as authored by the clinician, a Patient summary provides the most current information available from the sending system across multiple encounters.

Encounter Location

In Encounter Summaries the Encounter Location will also be present in the document header at componentOf/encompassingEncounter/location, but in Patient Summaries, componentOf/encompassingEncounter SHALL NOT be present.

Encounter Time

In Encounter Summaries the Encounter Time will also be present in the document header at componentOf/encompassingEncounter/effectiveTime, but for Patient Summaries, componentOf/encompassingEncounter SHALL NOT be present.

Encounter Type

In Encounter Summaries the Encounter Type will also be present in the document header at componentOf/encompassingEncounter/code, but for Patient Summaries, componentOf/encompassingEncounter SHALL NOT be present.

Implementers should note that only conveying Encounter Type in the document header at componentOf/encompassingEncounter/code is insufficient.

Goals

An expressed desired health state to be achieved by a subject of care (or family/group).

Table 73: USCDI v2 Data Elements - Goals

SDOH Goals

The updated Goals Observation template includes a value set for conveying SDOH goals.

​For SDOH value sets, see Section 6.1.2 Social Determinant of Health Vocabulary Design Notes

Health Insurance Information

Identifiers are integral components of health insurance information and processing. The table below includes key common identifiers and where they are located within C-CDA health insurance related templates. Typically, organizations own Object Identifiers (OIDs) that are used to computably identify the organization. These are held in the roots of IDs in CDA documents. Occasionally, an organization may not have an OID identifier. While it is recommended that organizations obtain OIDs, if the organization has no identifying root, the root may be omitted, the null flavor attribute set to “UNK”, and the ID still sent in the extension attribute.

• Example for an organization without an OID:
• Example for an organization with an OID (Medicare):

Coverage Status

The C-CDA model records the coverage status for a patient using the coverage activity effectiveTime.

The act/effectiveTime@value records the date when you checked the coverage for a patient, and applies for all policies within the coverage activity. If systems choose to include a time they may need multiple Coverage Activity Acts to represent the moment of the eligibility check. Details on a specific Policy coverage period, or self-pay period, systems can record an additional effectiveTime inside the Policy Activity. Systems may prioritize Coverages using the sequenceNumber.

Coverage Type

No additional guidance

Relationship to Subscriber

See the latest guidance added to Policy Activity V4 which includes a new value set.

Member Identifier

No additional guidance

Subscriber Identifier

No additional guidance

Group Identifier

No additional guidance

Payer Identifier

See the latest guidance added to Policy Activity V4.

Health Status/Assessments

An expressed desired health state to be achieved by a subject of care (or family/group). Proposed Text: Assessments represent health-related matters of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.

Functional Status

A clinician, or caregiver, may record the functional status of a patient (e.g., mobility status, activities of daily living, self-care status) using a formal assessment tool, or a simple assertion. When a clinician uses a formal instrument, such as the Glasgow Coma scale, systems are encouraged to use the Assessment Scale Observation to group a series of Assessment Scale Supporting Observations. See the approved Functional Assessment - Glasgow Coma example. Note, the best practice is to include the final ‘score’ in both the Assessment Scale Observation/value in addition to an individual Assessment Scale Supporting Observation. Use of the prior

Functional Status Organizer and Functional Status Observation is discouraged since the it promotes inconsistent generation of an Organizer/Observation when a generic Assessment Scale Observation/Assessment Scale Supporting Observation is sufficient. In a future release of C-CDA, Structured Documents will deprecate these legacy templates.

In certain situations a clinician may make a judgement about a patient’s physical function. The Functional Status Observation is the appropriate place to record this judgement. See approved Functional Impairment example.

Disability Status

A clinician can use the new Disability Status Observation to assert a specific concern about a patient. A prior HL7 standard, the electronic initial case report (eICR), created a Disability Status Observation template constrained to 8 concepts (see VSAC (log-in required): Disability Status). The eICR project is restricted to report “minimum necessary” data needed for public health case reporting. The new Disability Status Observation is not limited to these 8 concepts, and adds the ability to include an Assessment Scale Observation/Assessment Scale Supporting Observation.

Mental/Cognitive Status

A clinician, or caregiver, may record the Mental/Cognitive Status of a patient’s psychological and mental competency using a formal assessment tool, or a simple assertion. When a clinician uses a formal instrument, such as the Patient Health Questionnaire-9 (PHQ-9), systems are encouraged to use the Assessment Scale Observation to group a series of Assessment Scale Supporting Observations. See the approved Patient Health Questionnaire PHQ- 9 example. Note, the best practice is to include the final ‘score’ in both the Assessment Scale Observation/value in addition to an individual Assessment Scale Supporting Observation. Use of the prior Mental Status Organizer and Mental Status Observation is discouraged since the it promotes inconsistent generation of an Organizer/Observation when a generic Assessment Scale Observation/Assessment Scale Supporting Observation is sufficient. In a future release of C-CDA, Structured Documents will deprecate these legacy templates.

In certain situations a clinician may make a judgement about a patient’s Mental/Cognitive Status function. The Mental Status Observation is the appropriate place to record this judgement. See approved Memory Impairment example.

Pregnancy Status

The existing C-CDA Pregnancy Observation represents current and/or prior pregnancy dates. Systems wishing to capture the intent to become pregnant can include the Pregnancy Intention in Next Year in the Social History Section.

Laboratory

Analysis of clinical specimens to obtain information about the health of a patient.

Table TODO

Specimen Type

The Result Organizer/specimen is used when all Result Observations are from the same specimen. If any of the Result Observations use a different specimen they must be recorded individually at the Organizer/observation/specimen.

Result Status

The observation/statusCode uses the Result Status value set (2.16.840.1.113883.11.20.9.39) to allow systems to record result status, such as ‘in process’ (active) or ‘final’ (completed).

Medication

Dose

Dose (doseQuantity) represents how many of the consumables (a medication code that is precoordinated with the dose) are to be administered at each administration event. As a result, the dose is always relative to the consumable. Dose (doseQuantity) will often be unitless number that indicates the number of products given per administration (e.g., “2”, meaning 2 x “metoprolol 25mg tablet” per administration).