USCDI Export for the Public

Classification Level Sort descending Data Class Data Class Description Data Element Data Element Description Applicable Standards Submitter Name Submitter Organization Submission Date
Level 0 Provenance

The metadata, or extra information about data, regarding who created the data and when it was created.

Rationale

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.

Gary Dickinson EHR Standards Consulting
Level 0 Provenance

The metadata, or extra information about data, regarding who created the data and when it was created.

Network Address

Network Address 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. Network Address is part of “where”. Network Address 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 Network Address 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.

Gary Dickinson EHR Standards Consulting
Level 0 Provenance

The metadata, or extra information about data, regarding who created the data and when it was created.

Physical Location

Location where action was taken and/or where dataset or data element was collected (captured, sourced). Location should include room (within) building (within) organization. Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Physical Location is part of “where”. Physical Location 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 Physical Location 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.

Gary Dickinson EHR Standards Consulting
Level 0 Provenance

The metadata, or extra information about data, regarding who created the data and when it was created.

Data State

Data State, in context of data lifecycle. States should include: origination (capture, collection), update (from previous content/value), verification (of data sourced by others (e.g., transcriptionist, scribe, student) or from automated device), transformation (e.g., from source system internal representation to exchange artifact (such as HL7 message, CDA document or FHIR resource), from exchange artifact to receiver internal representation). Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Data State is part of “what”. Data State 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 Data State 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.

Gary Dickinson EHR Standards Consulting
Level 0 Cancer Care Tumor Laterality

The side of a paired organ, or the side of the body on which the tumor originated.

Tumor Histologic Type: International Classification of Diseases for Oncology 3.2, with additional values accepted by the WHO-IARC but not included in the official published documents. SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, 2021 Release (month TBD) Tumor Behavior: International Classification of Diseases for Oncology 3.2 Tumor Primary Site: International Classification of Diseases for Oncology 3.2. SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2020 Release Tumor Laterality: SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2020 Release – mCODE Laterality Value Set Tumor Clinical Grade: North American Association of Central Cancer Registries Grade Clinical

Wendy Blumenthal Centers for Disease Control and Prevention (CDC)
Level 0 Problems

Condition, diagnosis, or reason for seeking medical attention.

Alcohol abuse or dependence

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

Laura Kwako National Institute on Alcohol Abuse and Alcoholism
Level 0 Substance Use Average daily alcohol intake

This data element provides a measure of an individual’s average daily alcohol intake, i.e., how many drinks per day someone has

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

Laura Kwako National Institute on Alcohol Abuse and Alcoholism
Level 0 Substance Use Ever drink alcohol

This data element denotes whether an individual currently consumes alcohol or not

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

Laura Kwako National Institute on Alcohol Abuse and Alcoholism
Level 0 Orders

Provider-authored request for the delivery of patient care services.

Obligation or Prohibition Instruction for Life Sustaining Treatment

The 2020 Interoperability Standards Advisory (ISA) includes the concept of “patient preference/consent” in the content and structure section. (https://www.healthit.gov/isa/section/patient-preferenceconsent) The proposed data element, Obligation or Prohibition Instruction for Life-Sustaining Treatment, is loosely related to both the data class of “patient instructions” and the data element of “care experience preference”. A patient preference regarding a treatment for which the patient has provided consent to perform (obligation) or not to perform (prohibition) is aligned with the notion of a Patient Instruction. Episodic patient instruction records a patient’s consent to have or not have a particular medical treatment under certain circumstances during an episode of care. These consents provide the patient’s care team with information needed to establish the patient’s plan of care. When a person is about to undergo a medical procedure where he or she will be sedated, or about to have an inpatient stay, or a stay at a nursing or rehab care facility, care providers may ask the patient to make episode-of-care-specific decisions about medical treatments he or she does or does not want should a circumstance arise when this choice would need to be taken into consideration. A patient may make these decisions for himself or herself, or if the patient cannot make these decisions, the surrogate decision-maker may decide. These consents are made in the present and apply to the current episode of care. They are instructions provided by the patient or a surrogate decision-maker. The patient makes these decisions by himself or herself and communicates them to the care team. There is no requirement for the patient to make decisions which are consistent with the goals, preferences, and priorities they may have previously documented in advance directives or their PACP, but it is possible their prior thoughts may influence their current choices. If the patient is unable to communicate, then a patients previously appointed healthcare agent or a surrogate decision-maker if a healthcare agent was not appointed may make these decisions on the patient’s behalf. Ideally, these decisions are informed by the values, beliefs, and quality of life priorities documented previously by the patient as advance directives or PACP. Episodic patient instructions are closely related to advance directives, in that they say, for this episode of care if x happens, then do y. Or, if x happens, do not do y. For this reason, episodic patient instructions are often recorded in the clinical record along with a person’s advance directives. However, episodic patient instructions are not advance directives because they represent actual treatment decisions not input to inform potential treatment decisions. A set of recognized obligation or prohibition instructions that a patient or his or her surrogate decision-maker may make is documented in the value set Obligation or Prohibition Instruction Type urn:oid:2.16.840.1.113883.11.20.9.69.17. This value set is openly available for reference in the National Library of Medicine’s Value Set Authority Center. It can be referenced using this url: • https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.69.17/expansion/Latest

HL7 CDA® R2 Implementation Guide: C-CDA R2.1; Advance Directives Templates, Release 1 - US Realm 2.4 Obligation Instruction [act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.205:2018-01-01 (open)] Draft as part of Advance Directives - Template Revisions The Obligation Instruction template is designed to be used within the Advance Directives Section. However, this information also may be relevant within an Interventions Section or a Plan of Treatment Section. It is an adaptation of the Instruction V2 template. It follows the structure of an instruction template, but modifies the semantics in two ways. First, the code element comes from a value set containing concepts that are types of Obligation Instructions that a patient, or a patient's healthcare agent or other type of surrogate decision-maker may decide to make when the patient is unable to communicate. Second, the author of this template is the person who made the decision documented in the Obligation Instruction. The Obligation Instruction template and Prohibition Instruction template are designed as a "matched pair" to permit either prohibitions or obligations to be clearly expressed in an unambiguous way. The use of negation is explicitly expressed, and the semantic design of the recommended value sets takes into consideration the logical meaning of an obligation versus a prohibition. The Obligation Instruction template explicitly prohibits the use of negationInd. It always expresses activities that care providers have been instructed to perform. Coded concepts used in this template express activities in the positive. For decisions that establish prohibition instructions, refer to the Prohibition Instruction template. For decisions that establish prohibition instructions, refer to the Prohibition Instruction template. 2.5 Prohibition Instruction [act: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.4.206:2018-01-01 (open)] Draft as part of Advance Directives - Template Revisions The Prohibition Instruction template is designed to be used within the Advance Directives Section. However, this information also may be relevant within an Interventions Section or a Plan of Treatment Section. It is an adaptation of the Instruction V2 template. It follows the structure of an instruction template, but modifies the semantics in several ways. First, the code element comes from a value set containing concepts that are types of care instructions about activities that a patient, or a patient's healthcare agent or other type of surrogate decision-maker (when the patient is unable to communicate) does not want care providers to perform. Second, the author of this template is the person who made the decision documented in the Prohibition Instruction. The Prohibition Instruction template and Obligation Instruction template are designed as a "matched pair" to permit either prohibitions or obligations to be clearly expressed in an unambiguous way. The use of negation is explicitly expressed, and the semantic design of the recommended value sets takes into consideration the logical meaning of an obligation versus a prohibition. . The Prohibition Instruction template explicitly requires the use of negationInd=”true”. It always expresses activities that care providers have been instructed not to perform. Coded concepts used in this template express activities in the positive and add sematics for negation through the structural negationInd attribute. For decisions that establish prohibition instructions, refer to the Prohibition Instruction template. For decisions that establish prohibition instructions, refer to the Prohibition Instruction.

Matt Elrod on behalf of ADVault, Inc. ADVault, Inc.
Level 0 Cancer Care Tumor Clinical Grade

The degree of abnormality of cancer cells; or the extent to which cancer cells are similar in appearance and function to healthy cells of the same tissue type before any treatment (surgical resection or initiation of any treatment including neoadjuvant).

Tumor Histologic Type: International Classification of Diseases for Oncology 3.2, with additional values accepted by the WHO-IARC but not included in the official published documents. SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, 2021 Release (month TBD) Tumor Behavior: International Classification of Diseases for Oncology 3.2 Tumor Primary Site: International Classification of Diseases for Oncology 3.2. SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2020 Release Tumor Laterality: SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2020 Release – mCODE Laterality Value Set Tumor Clinical Grade: North American Association of Central Cancer Registries Grade Clinical

Wendy Blumenthal Centers for Disease Control and Prevention (CDC)
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Line Other Payer Paid Amount

The reduction in the payment amount to reflect the current carrier as a secondary, tertiary, etc, payer. May be multiple occurrences if the current carrier is a tertiary, etc. carrier.

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

Mark Roberts Leavitt Partners
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Claim Payer Name

Name of the payer responsible for the claim

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

Mark Roberts Leavitt Partners
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Claim Payee Type

Identifies the type of recipient of the adjudication amount; i.e., provider, subscriber, beneficiary or another recipient

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

Mark Roberts Leavitt Partners
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Claim Payee

Recipient reference.

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

Mark Roberts Leavitt Partners
Level 0 Provenance

The metadata, or extra information about data, regarding who created the data and when it was created.

Signature

(Per https://www.hl7.org/fhir/provenance.html): “Provenance.signature: A digital signature on the target Reference(s). The digital signature, inclusive of a hash on the resource being signed (Provenance.signature.type = 1.2.840.10065.1.12.1.14), will ensure that the integrity of the particular electronic health information (EHI) is maintained and not altered in any way. This allows recipients of this EHI to trust the integrity of the content regardless of its most recent origin. • As patient-mediated EHI becomes more prevalent, maintaining the chain of trust via this digital signature will be instrumental in patient-provided health information exchange.

HL7 FHIR R4 (v4.01: R4 – Mixed Normative and STU)

KarenP-SSA Social Security Administration (SSA)
Level 0 Provenance

The metadata, or extra information about data, regarding who created the data and when it was created.

Author Credential(s)

Author Credential(s), in context of action taken and/or in context of USCDI dataset or data element authorship. Should allow credentials such as MD, DO, RN, DDS, PharmD...

Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Author Credential(s) are part of “who”.

Author Credential(s) 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.

Note that Author Credential(s) are 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.

Gary Dickinson EHR Standards Consulting
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Statement Thru Date

On Institutional claims, the last day on the billing statement covering services rendered to the beneficiary (i.e. 'Statement Covers Thru Date’)
On Professional and Non-Clinician claims, the latest of any of the line-item level dates.

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

Mark Roberts Leavitt Partners
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Claim Payer Identifier

The identifier assigned to the Operating Surgeon.

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

Mark Roberts Leavitt Partners
Level 0 Explanation of Benefit

Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.

Claim Payment Status Code

Indicates whether the claim was paid or denied.

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

Mark Roberts Leavitt Partners
Level 0 Substance Use Prescription Medication Misuse

A person's stated observation of how often in the past year they used medications, from identified opiate pain relievers, sedatives, stimulants or sleeping medications, just for the feeling, to get high, or more often or in larger doses than prescribed, using a 5 point Likert scale. TAPS Tool: In the PAST 12 MONTHS, how often have you used any prescription medications just for the feeling, more than prescribed or that were not prescribed for you? Prescription medications that may be used this way include: Opiate pain relievers (for example, OxyContin, Vicodin, Percocet, Methadone) Medications for anxiety or sleeping (for example, Xanax, Ativan, Klonopin) Medications for ADHD (for example, Adderall or Ritalin). Value: 1. Daily or almost daily (displayed as "0"): a subjective response that something happens daily or almost daily 2. Weekly (displayed as "1"): Every week 3. Monthly (displayed as "2"): Every month 4. Less than Monthly (displayed as "3"): An event that occurs less frequently than once a month 5. Never (displayed as "4"): Not ever, at no time in the past (or future).

Elements were recently submitted for inclusion in LOINC.

Jessica Cotto National Institute on Drug Abuse