USCDI Export for the Public

Device ID where dataset or data element was originated (collected, captured, sourced), updated, verified, attested, transformed... Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Device ID is part of “where”. Device ID must be associated with each USCDI dataset or data element that has a unique provenance set. Occurs when data is originated (captured, collected or sourced), updated, verified, attested, transformed (e.g., to/from exchange artifact such as HL7 v2 message, document or FHIR resource instance). Note that Device ID is intrinsic to what the source EHR/HIT system already knows, thus it does not require extra data collection (burden) by the clinician or other end user.

Data element capturing the refugee status of a patient

Veteran Status: Z56.82 Military deployment status Farmworker Status: ICD: Z57.2 Occupational exposure to dust Z57.3 Occupational exposure to other air contaminants Z57.4 Occupational exposure to toxic agents in agriculture Z57.6 Occupational exposure to extreme temperature Z57.8 Occupational exposure to other risk factors Agricultural/animal husbandry worker (occupation) - SNOMED: 106390009 Refugee Status: Refugee family (social concept) - SNOMED: 413323004 Refugee (person) - SNOMED: 446654005 Are you a refugee? - LOINC: 93027-1 Refugee - LOINC: LA29153-6

Indicates if the diagnosis is admitting, principal, other, an external cause of injury or secondary

NUBC, CPT, HCPCS, HIPPS, ICD-9, ICD-10, DRGs, NDC, POS, NCPDP codes, and X12 codes.

Data element capturing seasonal or migrant farm work status.

Veteran Status: Z56.82 Military deployment status Farmworker Status: ICD: Z57.2 Occupational exposure to dust Z57.3 Occupational exposure to other air contaminants Z57.4 Occupational exposure to toxic agents in agriculture Z57.6 Occupational exposure to extreme temperature Z57.8 Occupational exposure to other risk factors Agricultural/animal husbandry worker (occupation) - SNOMED: 106390009 Refugee Status: Refugee family (social concept) - SNOMED: 413323004 Refugee (person) - SNOMED: 446654005 Are you a refugee? - LOINC: 93027-1 Refugee - LOINC: LA29153-6

The area of social risk documented for a patient (e.g., housing insecurity, alcohol use, transportation security). When exchanging a domain, the following constituent data components should be included: - Source/Assessment: The specific survey, questionnaire, or question set(s) used to calculate the patient’s risk value for the domain, if applicable. If a particular assessment was not used to calculate the patient’s risk value, just the risk value may be exchanged. - Risk Value: The category of risk that applies to a patient for the domain (e.g., “high risk,” “moderate risk,” “low risk,” or “unknown”). - Date: The date the assessment was completed.

LOINC can be used to express a number of assessments used to evaluate a patient’s social determinants of health. SNOMED CT can be used to document a clinical observation stemming from an assessment when it is appropriate.

The globally unique identifier for each blood or biologic product identified using the ISBT 128 international standard.

ISBT 128

A Sensitivity tag is the 0..* component of a Security Label that conforms to the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 syntax to represent the type of information deemed by policy to require a specified level of Confidentiality protection. HL7 recommends creating a value set of Sensitivity codes to value the Sensitivity tag, which are specific to priority US policies as discussed in the HL7 Cross-Paradigm US Regulatory Security Labeling Implementation Guide, which is under development. For HL7 v3 Sensitivity codes see _ActInformationSensitivityPolicy in the ActCode value set. For background on the use of Sensitivity codes, see Sensitive Information Security Label Privacy Tag Used if required by governing policy in HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, in the HL7 Version 2.9 BHS, FHS, MSH, and ARV Segments, and in the FHIR Data Segmentation for Privacy IG.

HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.

An Obligation tag is the 0..* component of a Security Label that conforms to follows the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 syntax to convey the mandated action that an information custodian, receiver, or user must perform. For HL7 Obligation tags see ObligationPolicy at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v3-ObligationPolicy.html

HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.

A Refrain tag is the 0..* component of a Security Label that conforms to follows the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 syntax to convey a prohibited action that an information custodian, receiver, or user must not perform. For HL7 Refrain tags see the Refrain value set at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v3-RefrainPolicy.html

HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.

A Policy tag is the 0..1 component of a Security Label that conforms to follows the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 syntax to represent the policy governing of the information assigned a Security Label. The policy represented by this code is the authoritative source of the type of information deemed sensitive and the level of confidentiality protection to be provided. Policies may pertain to privacy, security, research, trust, etc., and may be issued by a jurisdiction, an organization, or an individual, e.g., by a consent directive. In addition, the policy may limit the permissible purposes of use, and the obligations and prohibited actions which may be taken by senders and receivers, which are conveyed using other types of tags in the Security Label representing a specific policy. HL7 recommends creating a value set of Policy codes to value the Policy tag, which are specific to priority US policies as discussed in the HL7 Cross-Paradigm US Regulatory Security Labeling Implementation Guide, which is under development. For example, the US Controlled Unclassified Information (CUI) policy 32 CFR Part 2002, established the executive branch’s CUI Program, policy for designating, handling, and decontrolling information that qualifies as CUI, and the security mechanisms by which the confidentiality of CUI is enforced. This rule affects Federal executive branch agencies that handle CUI and all organizations (sources) that handle, possess, use, share, or receive CUI—or which operate, use, or have access to Federal information and information systems on behalf of an agency. https://www.archives.gov/cui/about As a result, most entities exchanging health information in the US will likely either mark CUI or receive CUI, and will be required to comply with this regulation. CUI exchanged using HL7 standards will need to indicate that the recipient must comply with this regulation using a security label with a Policy tag for 32 CFR Part 2002. HL7 Cross Paradigm US Security Labeling IG is under development to standardize CUI labeling for use with HL7 Version 2, CDA, and FHIR specifications. For Policy codes used to populate Security Label Policy tags, see HL7 PolicyType value set at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v3-ActPolicyType.html

HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.

Purpose of Capture describes why a dataset or data elements were originated (collected, captured, sourced), updated, verified, attested, transformed... Often needed to ensure Purpose of Capture is equivalent or compatible with each potential Purpose of Use. Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Purpose of Capture is part of “why”. Purpose of Capture should be associated with each USCDI dataset or data element that has a unique provenance set. Occurs when data is originated (captured, collected or sourced), updated, verified, attested, transformed (e.g., to/from exchange artifact such as HL7 v2 message, document or FHIR resource instance). Note that Purpose of Capture may be intrinsic to what the source EHR/HIT system already knows, thus it will not require extra data collection (burden) by the clinician or other end user.

Rationale describes why an action was taken (i.e., the action during which the dataset and/or data element was originated (collected, captured, sourced)). Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Rationale is part of “why”. Rationale should be associated with each USCDI dataset or data element that has a unique provenance set. Occurs when action-related data is originated (captured, collected or sourced), updated, verified, attested, transformed (e.g., to/from exchange artifact such as HL7 v2 message, document or FHIR resource instance). Note that Rationale may be intrinsic to what the source EHR/HIT system already knows, thus it will not require extra data collection (burden) by the clinician or other end user.

Type of the event itself in relation to the subject

adverse events are mapped to MedDRA terminology

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.

When the event occurred

adverse events are mapped to MedDRA terminology

Information on the possible cause of the event

adverse events are mapped to MedDRA terminology

The NIAAA Single-Item Screener is a single question that may be used to screen men and women (separately) for unhealthy alcohol use. It has been validated in primary care settings; the specific language for men and women appears below. Men: How many times in the past year have you had five or more drinks in a day? Women: How many times in the past year have you had four or more drinks in a day?

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

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.

The suspected agent causing the adverse event

adverse events are mapped to MedDRA terminology