USCDI Export for the Public

Patients may be their own data stewards, or have other data stewards able to authorize permissions on their data. This term, "Data Steward" is intended to describe an individual or organization authorized and accountable for permission decisions about the health data of the individual. While this may be a RelatedPerson or a member of a CareTeam (existing elements and classes in USCDI FHIR), it may also not be part of those groups. Data stewards may be needed for individual patients who are incapacitated or for minors who lack legal capacity to consent (although be able to assent). Data stewards may also have a critical role in stewardship of health data for deceased individuals, e.g. clinical genetic counseling, research studies. Individuals may also assign stewardship to multiple individuals and organizations. Data stewardship may also authorize designated organizations and/or individuals to determine data use permissions by specific segment (e.g. medication data vs. family history data).

FHIR has standards for Person and Organization resources: https://www.hl7.org/fhir/person.html https://www.hl7.org/fhir/organization.html However, role-specific terminology and standards may be needed to describe the specific role(s) of a Data Steward if considered as a separate element, or as a member of the CareTeam.

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.

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.

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.

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.

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 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.

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

ISBT 128

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.

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

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 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

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.

A structured set of questions intended to guide the collection of answers from end-users. Questionnaires provide detailed control over order, presentation, phraseology and grouping to allow coherent, consistent data collection.

Uses LOINC for questionnaire questions and responses.

M3 Results is the output from an evidence-based, 27 question, patient rated cross cutting mental health assessment. The output is a score that is highly predictive of any mental health condition, 4 clusters for risk of anxiety, PTSD, bipolar disorder and depression and the responses to the 27 questions. Together the data elements provide clinicians and patients results that enable de-stigmatized care by providing scores and longitudinal monitoring based on those scores to hopefully drive better outcomes. M3 is used by LabCorp and others and qualifies for a Standard based on its interoperability through their network.

M3 has LOINC Codes M3 Score is an algorithm to allow a person to take a rated self-test and their clinician receive a structured report which includes a score that shows: 1) an assessment of an individuals risk of suffering from any mood disorder, and 2) a patient on a clinical map showing if they have a low, medium or high risk for each of the following: Depression, Anxiety, Bipolar, PTSD. In addition to the clusters, the report the answers for each report are included as structured data with all scores and responses having LOINC codes.

This data element captures the combined income of the patient and the family members he/she lives with.

ICD-10: Z59.5 Extreme poverty (100% FPL or below) Z59.6 Low income (200% FPL or below) Z59.7 Insufficient social insurance and welfare support Z72.4 Inappropriate diet and eating habits SNOMED-CT: 365553008 - Finding of household income (finding) 365556000 - Finding of pattern of income (finding) 365552003 - Finding of income details (finding) LOINC: 93025-5 - Protocol for Responding to and Assessing Patients' Assets, Risks, and Experiences [PRAPARE]

Same as above

LOINC

Same as above

LOINC

Same as above

LOINC

Same as above

LOINC