USCDI Export for the Public

The date the vaccination event occurred.

LOINC:30952-6- Date and time of vaccination: https://loinc.org/30952-6/

For both Clinical (cT), Pathological (pT) and Neoadjuvant (ycT or ypT), the T Category is defined as the size and/or contiguous extension of the primary tumor. Note: The roles of the size component and the extent of contiguous spread are specifically defined for each cancer site. Primary Tumor (T) Categories: Primary tumor categories have specific notations to describe the existence, size, or extent of the tumor. TX: No information about the T category for the primary tumor, or it is unknown or cannot be assessed T0: No evidence of a primary tumor Tis: Carcinoma in situ T1, T2, T3, or T4: Primary invasive tumor, for which a higher category generally means • an increasing size • an increasing local extension, or • both

SNOMED CT has content related to the AJCC T category under the hierarchy of 385356007 'Tumor stage finding' but it is outdated and inaccurate. SNOMED CT codes do not always make a distinction between clinical and pathological classifications (e.g. cT1 and pT1) and are represented by the same SNOMED CT code 23351008 'T1 category'). SNOMED CT does not have complete T,N,M staging terminology and is an incomplete data set. Most importantly, the SNOMED structure is not a good fit for the AJCC data elements that can change as new editions/versions of the AJCC Cancer Staging System are published. However, the AJCC is planning on submitting the data elements to the National Library of Medicine’s Value Set Authority Center (VSAC), in parallel to the submission to USCDI. The AJCC feels that VSAC would be an appropriate centralized repository for AJCC data elements. This would facilitate EHR systems' use of the data elements that the AJCC develops and maintains.

The AJCC Cancer Staging System describes the severity of an individual's cancer based on the magnitude of the original (primary) tumor as well as on the extent cancer has spread in the body. Understanding the stage of the cancer helps doctors to develop a prognosis and design a treatment plan for individual patients. The AJCC Cancer Staging System classifies cancers by the size and extent of the primary tumor (T), involvement of regional lymph nodes (N), and the presence or absence of distant metastases (M), supplemented in recent years by evidence-based prognostic and predictive factors. There is a T,N,M staging algorithm for cancers of virtually every anatomic site and histology, with the primary exception of pediatric cancers. The three categories—T, N, and M—and the prognostic factors collectively describe, with rare exceptions, the extent of tumor, including local spread, regional nodal involvement, and distant metastasis. It is important to stress that each component (T, N, and M) is referred to as a Category. The term stage is used when T, N, and M and cancer site–specific required prognostic factors are combined. The Criteria for T, N, and M are defined separately for cancers in different anatomic locations and/or for different histologic types.

SNOMED CT has content related to the AJCC T category under the hierarchy of 385356007 'Tumor stage finding' but it is outdated and inaccurate. SNOMED CT codes do not always make a distinction between clinical and pathological classifications (e.g. cT1 and pT1) and are represented by the same SNOMED CT code 23351008 'T1 category'). SNOMED CT does not have complete T,N,M staging terminology and is an incomplete data set. Most importantly, the SNOMED structure is not a good fit for the AJCC data elements that can change as new editions/versions of the AJCC Cancer Staging System are published. However, the AJCC is planning on submitting the data elements to the National Library of Medicine’s Value Set Authority Center (VSAC), in parallel to the submission to USCDI. The AJCC feels that VSAC would be an appropriate centralized repository for AJCC data elements. This would facilitate EHR systems' use of the data elements that the AJCC develops and maintains.

Method for estimating gestational age, e.g., ultrasound, date of LMP.

Value Set: Estimated Date of Delivery Including Method (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.81/expansion)
Value Set: Pregnancy Status Determination Method (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.80/expansion)
Postpartum Status (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.87/expansion)

Name of the job position held by an individual.

The postpartum status of a patient, i.e. whether or not the patient is in the postpartum perio

Value Set: Estimated Date of Delivery Including Method (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.81/expansion)
Value Set: Pregnancy Status Determination Method (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.80/expansion)
Postpartum Status (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.87/expansion)

A clinical trial protocol is a detailed document that outlines the objectives, design, and methodology of a trial, ensuring consistency and regulatory compliance. It includes the study rationale, participant eligibility criteria, interventions, outcomes, randomization and blinding methods, procedures for data collection, safety monitoring, and adverse event reporting. The protocol also addresses data management, ethical considerations, and trial administration, providing a comprehensive framework for conducting the study.

For a clinical trial protocol, the following terminology code systems are commonly used or may be used for greater interoperability:

1. SNOMED CT: Standardizes clinical concepts like medical conditions, procedures, and outcomes (e.g., inclusion/exclusion criteria).
2. LOINC: Standardizes lab tests, clinical measurements, and observations collected during the trial.
3. RxNorm: Used for medication coding, especially when the protocol involves drug interventions or dosing regimens.
4. ICD-10/ICD-11: Defines diagnoses and health conditions for eligibility or adverse event reporting.
5. MedDRA: Used to code adverse events, ensuring consistent reporting across trial sites.
6. CDISC Terminology: Supports standardization of clinical trial data elements (e.g., protocol design, trial outcomes) in regulatory submissions. Accessible via NCI terminology services.
7. WHODrug: Standardizes coding for medications in clinical trials, especially for drug safety and efficacy reporting in global trials.
8. NDC: Used to identify medications in the U.S. for protocol interventions or treatments.
9. CPT: Standardizes medical procedures and services for protocol-specified interventions, such as diagnostic tests or treatments.
10. UCUM: Standardizes units of measurement (e.g., mg, mL) used in clinical observations or lab results.
11. HCPCS: Complements CPT by coding medical products, services, and equipment used in U.S. trials.

These code systems ensure global semantic interoperability, consistency, compliance, and accuracy in clinical trial data collection and exchange.

A record of the patient’s authorizations and directions regarding disclosure and use of the patient’s SDOH data.

Yes, structural standards exist for each of these six elements in current HL7 standards. Specifically, in FHIR, (1) Assessments are Observation resources; (2) Problems/Health Concerns are Condition resources; (3) Goals are Goal resources; (4) Interventions are ServiceRequest and Procedure resources; (5) Outcomes are represented by the status on any of the previously mentioned resources or creation of new Observation resources; and (6) Consent is represented by the Consent resource. Yes, a vocabulary/terminology standard and/or technical specification exists for each proposed data element. The technical specifications for value sets under each data element are described below: • Assessments: LOINC • Health Concerns/Problems/Diagnoses: SNOMED-CT, ICD-10-CM • Goals: LOINC • Procedures/Interventions: SNOMED-CT (clinical), CPT/HCPCS (billing) • Outcomes: LOINC (NCQA measures) • Consent (where needed): based on existing HL7 code systems For the respective SDOH domains: For (1) Food Insecurity: LOINC, SNOMED-CT, ICD-10-CM, and CPT/HCPCS terminologies are specified by value sets in NLM’s Value Set Authority Center (VSAC). For (2) Housing Instability and Homelessness, (3) Inadequate Housing, (4) Transportation Insecurity, (5) Financial Strain, (6) Social Isolation, (7) Stress, (8) Interpersonal Violence, (9) Education, (10) Employment, and (11) Veteran Status: • The corresponding value sets are under development by the Gravity Project. • The value sets will be complete prior to publishing of USCDI v2.0; • Even if a particular value set might be incomplete, the value set will be citable. The details of the domains and specific consensus-approved value sets for each of the activities will be externally maintained as part of a hierarchy of LOINC panels and, where necessary, VSAC value sets referenced by the LOINC panels. The proposed structure is as follows: Survey (Panel) LOINC code a. Food Insecurity Domain (Panel) (LOINC code) i. Food Insecurity Assessment (Panel) (LOINC code) 1. Value set (LOINC codes) ii. Food Insecurity Health Concerns (Panel) (LOINC code) 1. Value set (SNOMED-CT and ICD-10-CM) iii. Food Insecurity Goals (Panel) (LOINC code) 1. Value set (LOINC codes) iv. Food Insecurity Interventions (Panel) (LOINC code) 1. Value set (SNOMED-CT, HCPCS, CPT, LOINC) v. Food Insecurity Outcomes (Panel) (LOINC code) 1. Value set (LOINC codes) b. Domain: Housing Instability and Homelessness c. Etc.

The date and time at which the EHR system sends the report.

Unique, disambiguating identifier components for Organization-related elements. e.g. Provenance, identifier.assigner, and other elements and components that rely upon Organizations, especially those that may not be provider organizations nor have a URL. USCDI may need to support (or even consider requiring) organization.identifier.system to improve data portability. The parent way of identifying the system that enumerates multiple Organization identifiers may best be modeled as Organization.identifier.system, where the identifier uses existing FHIR properties for Identifiers data type. These include: identifier.system (URI namepsace) identifier.assigner (itself an organization!) identifier.value (a unique value)

For organizations like payers and ACOs, while health plan ID is no longer being pursued by industry, existing, in-production Payer IDs exist in multiple EDI (Electronic Data Interchange) environments. There are a set of Payer IDs in use today already; in concert with a clear description of the system that enumerates the Payer ID, these can be an example of the standards that may be used in uniquely identifying organizations beyond a free-text string description/label. These IDs may, however, be proprietary, but also already permissioned for use by the trading partners of the entities using the IDs for treatment, payment, and health care operations.

This variable contains the date consent was obtained or changed. When a provider queries ImmTrac for a patient and a patient who has already consented is found, the query will return the Texas IIS Consent Date stored in the registry. The provider, at the patient’s (or parent/guardian’s direction, as appropriate) can change the consent status. If there is a change, the updated Texas IIS Consent Date should be submitted to the IIS. Texas IIS Consent Date should be stored in date format: YYYYMMDD.

This element will document the patient’s consent for participating in the Texas statewide immunization information system (IIS). Under state statute, the Texas immunization registry is opt-in.. The following are the different values Texas currently uses to desctibe a patient’s consent status: TXA - Consented Adult, >=18 years old TXY - Consented ImmTrac Child, <18 years of age TXR - First Responder, >=18 years old TXF - Adult Family Member of a First Responder, >=18 years old TXM - Minor Family Member of a First Responder, <18 years old - no consent is on file. After the first initial consent is sent to the registry, the EHR vendor would need to be able to leave the field blank when the patient's information is sent again to the registry.

The following value should be used to document patient consent during a disaster or pandemic in Texas: TXD – Disaster consent In Texas, there is legislation that requires health care providers to report antiviral, immunization or other medications (AIM) administered to patients in response to a disaster such as COVID-19. When the AIM information is reported the TX IIS (ImmTrac) flags the information as disaster-related. If the patient signs the disaster-related consent form, their personal and disaster related AIMs are stored for the patient’s lifetime. If the patient does not sign the disaster related consent form or the regular, applicable consent form but receives a disaster related AIM, then their personal information and disaster related AIMs are stored in Texas’ IIS for up to 5 years after the end of the disaster. It is crucial for Electronic Health Records to capture, store, and exchange information regarding whether the patient received an AIM that was administered in response a disaster/pandemic so that this information can be shared with others to ensure appropriate medications are delivered and patient health can be maximized..

Indicates the reason the immunization event was not performed.

Immunization Code: CVX: Vaccines Administered 2.16.840.1.113762.1.4.1010.6: https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.6/expansion Immunization Code: National Drug Codes (NDC): http://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp Immunization Status: FHIR Immunization Status Codes: http://hl7.org/fhir/ValueSet/immunization-status Immunization Administered Date: FHIR datatypes: dateTime, String: https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-immunization-definitions.html#Immunization.occurrence[x] Reason Immunization Not Performed: FHIR Immunization Status Reason Codes: http://hl7.org/fhir/R4/valueset-immunization-status-reason.html

Medical orders guide what medical interventions providers will perform for a patient. A portable medical order is a type of medical order. Portable medical orders are not authored by patients. They are authored by practitioners in the context of an electronic medical record system. The medical orders are provided to the patient in the form of a document so the orders can travel with the patient and be exchanged with other care providers who do not have access to the EMR where the orders originated. Medical orders regarding life-sustaining treatments are established by a practitioner regarding treatments that restore, sustain or prolong a patient’s life. These types of medical orders are intended to be consistent with the patient’s instructions and wishes. Orders to perform or not perform specific types of life-sustaining treatments are documented by physicians as medical orders within the EMR system used by the organization providing medical interventions or the practitioner’s EMR. When medical orders regarding life-sustaining treatment are produced in a portable format, they are portable medical orders for life-sustaining treatment. Currently, there is no national standard for the expected content in a portable medical order for life-sustaining treatments, as the content can vary by State and EMR system. All doctors, emergency medical professionals, and other healthcare professionals, must follow these medical orders as the patient moves from one location to another (hospital, care facility, home, etc.), unless a treating physician examines the patient, reviews the medical order for life-sustaining treatment, and through conversation with the patient detects the need for a replacement order or as a result of their own clinical judgement creates a replacement order. In an emergency situation, characterized by a life-threatening health crisis, if the patient is unable to speak for themselves, life-sustaining treatments and procedures that are legally required of medical and emergency personnel can be overridden by a valid portable medical order. Depending on the state, a portable medical order may go by any of the following names: • MOLST (Medical Orders for Life-Sustaining Treatment) • POLST (Physician Orders for Life-Sustaining Treatment) • MOST (Medical Orders for Scope of Treatment) • POST (Physician Orders for Scope of Treatment) • TPOPP (Transportable Physician Orders for Patient Preferences) • Out-of-hospital Do Not Resuscitate (DNR) Orders The above forms have historically been paper-based and siloed in EMRs that might contain a scanned image, or a clinical note that details the decisions documented in the portable medical order. Emergency and treating care teams do not have mechanisms for establishing that the copy they are provided is the most current version and that another, more recent portable medical order doesn’t exist that would contradict the order they are reviewing. These uploaded copies of the portable medical order for life-sustaining treatment are considered to be just as valid as the original paper medical order that was provided by a physician to the patient for whom it was written. The currently supported digital interchange format for portable medical orders is a pdf document, as there are not standard interoperable data elements. The pdf document can be represented as a C-CDA Unstructured Document or a FHIR DocumentReference to enable key administrative information to be processed.

Portable Medical Orders for Life Sustaining Treatment The currently supported digital interchange format for portable POLST orders is a pdf document. The pdf document can be represented as a C-CDA Unstructured Document or a FHIR DocumentReference to enable key administrative information to be processed. There is no standard guidance about the expected content in a portable medical order for life sustaining treatments. The content varies by state and by EMR system. Portable Medical Orders for Life Sustaining treatment are a type of Medical Order. Data Element Code Definition Portable medical order form 93037-0 LOINC urn:oid:2.16.840.1.113883.6.1 Physician Order for Scope of Treatment which encompasses Physician Orders for Life-Sustaining Treatment (POLST) or Medical Orders for Life-Sustaining Treatment (MOLST). MOLST Observation In the context of a Patient Summary or Encounter Summary authored by a clinician or assembled by clinician’s EMR system, observations verifying a patient’s advance directive information and medical orders for life sustaining treatments using established standards for recording this type of information documented by providers. If a person has a medical order or physician order for life sustaining treatment (MOLST or POLST). This observation does not indicate what orders are included in the MOLST or POLST. It indicates if a MOLST or POLST exists. If a MOLST or POLST exists, the template includes a reference structure that can be used to point to the MOLST or POLST document. The vocabulary and structure needed to express this observation is provided in the HL7 CDA® R2 Implementation Guide: Personal Advance Care Plan (PACP) Document, Release 1 - US Realm STU Release 2 August 2020 Volume 2 – Templates. This observation can be used to document a patient authored statement about portable medical orders for life sustaining treatments or physician authored statements about there being portable medical orders for life sustaining treatments. Note that a physician’s own medical orders placed for life sustaining treatments are documented as medical orders placed within the physician’s own EMR.

This data element includes whether an individual has received a diagnosis of alcohol abuse or dependence, as per the DSM-IV nosology

Most of the requested data elements are in LOINC, as per the codes below. We have requested the addition of the NIAAA Single-Item Screener and the diagnosis of Alcohol Use Disorder to LOINC. AUDIT-C : 72109-2 Ethanol in blood: 5640-8 Ever drink alcohol: 69721-9 Average daily alcohol intake: 74013-4 Alcohol binge episodes/month: 11286-2 Alcohol abuse or dependence: 74043-1 Alcohol help during pregnancy: 64718-0

Represents a location in a person’s travel plans (either an address or a coded location).

§ SNOMED: 420008001 |Travel (event)| § Geographical location history (https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.do 11.3201) § ISO 3166 country codes (https://www.iso.org/iso-3166-country-codes.html) § NCI_Thesaurus 22.08e: code C173619 § LOINC v2.72 code: PhenX measure - international travel history:-:Pt:^Patient:-:PhenX (Code 62887-5)

This data element describes whether an individual sought help for alcohol-related problems during pregnancy

Most of the requested data elements are in LOINC, as per the codes below. We have requested the addition of the NIAAA Single-Item Screener and the diagnosis of Alcohol Use Disorder to LOINC. AUDIT-C : 72109-2 Ethanol in blood: 5640-8 Ever drink alcohol: 69721-9 Average daily alcohol intake: 74013-4 Alcohol binge episodes/month: 11286-2 Alcohol abuse or dependence: 74043-1 Alcohol help during pregnancy: 64718-0

This data element captures the Alcohol Use Disorder (AUD) diagnosis, which reflects the current nosology for the Diagnostic and Statistical Manual of Mental Disorders, Fifth Edition (DSM-5).

Most of the requested data elements are in LOINC, as per the codes below. We have requested the addition of the NIAAA Single-Item Screener and the diagnosis of Alcohol Use Disorder to LOINC. AUDIT-C : 72109-2 Ethanol in blood: 5640-8 Ever drink alcohol: 69721-9 Average daily alcohol intake: 74013-4 Alcohol binge episodes/month: 11286-2 Alcohol abuse or dependence: 74043-1 Alcohol help during pregnancy: 64718-0

The AUDIT-C is a three-item measure to screen for alcohol-related problems. Questions and answers include: 1. How often do you have a drink containing alcohol? (Response choices: Never/Monthly or less/2-4 times per month/2-3 times per week/4 or more times per week) 2. How many standard drinks containing alcohol do you have on a typical day? (Response choices: 1-2/3-4/5-6/7-9/10 or more) 3. How often do you have six or more drinks on one occasion? (Response choices: Daily or almost daily/Weekly/Monthly/Less than monthly/Never)

Most of the requested data elements are in LOINC, as per the codes below. We have requested the addition of the NIAAA Single-Item Screener and the diagnosis of Alcohol Use Disorder to LOINC. AUDIT-C : 72109-2 Ethanol in blood: 5640-8 Ever drink alcohol: 69721-9 Average daily alcohol intake: 74013-4 Alcohol binge episodes/month: 11286-2 Alcohol abuse or dependence: 74043-1 Alcohol help during pregnancy: 64718-0