USCDI SDOH Data Elements are a specific subset of the United States Core Data for Interoperability that define standardized, machine-readable data classes—such as Problems, Health Concerns, and Procedures—for capturing and exchanging social determinants of health. These elements, mandated by the ONC Cures Act Final Rule, ensure certified health IT systems can represent and share critical non-clinical risk factors like food insecurity and housing instability using structured coding systems including ICD-10-CM Z-Codes and LOINC.
Glossary
USCDI SDOH Data Elements

What is USCDI SDOH Data Elements?
A mandated set of social determinant data classes and elements that certified health IT systems must be able to exchange.
The standard establishes a common vocabulary for social risk data liquidity across disparate EHR systems, enabling population health analytics and value-based care workflows. Core data classes include SDOH Assessment (capturing screening tool responses), Goals (representing patient-identified social needs priorities), and Patient Demographics enriched with granular race, ethnicity, and preferred language elements. This structured exchange framework directly supports closed-loop referral processes and health equity reporting.
Key Characteristics of USCDI SDOH Elements
The USCDI framework mandates specific data classes and elements to ensure social determinant data is structured, interoperable, and actionable across certified health IT systems.
Structured Data Capture
USCDI SDOH elements move social risk data from unstructured narratives into discrete, coded fields. This transition enables automated processing, quality reporting, and clinical decision support.
- Data Class: Problems — Captures SDOH diagnoses using ICD-10-CM Z-codes (Z55-Z65)
- Data Class: Health Concerns — Documents patient-identified social needs not yet coded as diagnoses
- Data Class: Procedures — Records interventions like counseling for food insecurity
- Eliminates reliance on free-text parsing for core exchange use cases
Granular Data Element Specification
USCDI does not just name a broad category; it defines specific, exchangeable elements. For SDOH, this includes granularity down to the level of a single screening observation.
- SDOH Assessment class includes elements for Food Insecurity, Housing Instability, and Transportation Insecurity
- Each element can be paired with a standardized screening tool name (e.g., PRAPARE, AHC-HRSN)
- Allows for the exchange of both the raw answer and the interpreted risk score
- Distinguishes between a patient's self-reported concern and a clinician's formal diagnosis
Alignment with Gravity Project Standards
The USCDI SDOH elements are harmonized with the Gravity Project's consensus-driven terminology. This alignment ensures that the codes used for exchange are clinically relevant and map to real-world screening instruments.
- Gravity Project develops value sets for FHIR SDOH Observation resources
- Standardizes concepts like 'Less than high school education' or 'Homeless shelter'
- Bridges the gap between a screening question on a form and a computable, interoperable data point
- Prevents the proliferation of local, non-standard codes that block semantic interoperability
Support for Health Equity Analytics
By standardizing SDOH data for exchange, USCDI creates the foundational data layer for population-level health equity analysis. Aggregated, de-identified data can reveal systemic disparities.
- Enables calculation of quality measures stratified by social risk factors
- Supports the integration of individual-level SDOH data with geospatial indices like the Area Deprivation Index (ADI)
- Allows accountable care organizations to identify high-risk cohorts with both medical and social complexity
- Provides the data necessary to measure the impact of social care interventions on clinical outcomes
Data Provenance and Integrity
USCDI guidance emphasizes the importance of metadata to maintain data integrity. For SDOH elements, this means tracking the source, time, and method of data capture to prevent misuse.
- Author and Authoring Time elements track who documented the data and when
- Distinguishes between patient-reported, provider-assessed, and derived data
- Prevents a historical, resolved housing issue from being misinterpreted as an active problem
- Supports data quality audits by tracing an exchanged SDOH observation back to its original source document
Frequently Asked Questions
Clarifying the mandated social determinant data classes and elements that certified health IT systems must be able to exchange under the United States Core Data for Interoperability standard.
USCDI SDOH Data Elements are a mandated set of standardized social determinant data classes and elements, such as 'Problems' and 'Health Concerns', that certified health IT systems must be able to exchange. They are defined within the United States Core Data for Interoperability (USCDI) framework by the Office of the National Coordinator for Health IT (ONC). The goal is to ensure that non-clinical factors affecting health—like housing instability, food insecurity, and transportation access—can be captured, structured, and shared across disparate electronic health record (EHR) systems using standardized terminologies and FHIR APIs. This interoperability is foundational for value-based care and health equity initiatives, moving social risk data from unstructured notes into computable, actionable fields.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding USCDI SDOH Data Elements requires familiarity with the standardized codes, extraction methods, and interoperability frameworks that operationalize social risk data in certified health IT.
ICD-10-CM Z-Codes
A subset of diagnosis codes (Z55-Z65) used to document social determinants of health in a patient's structured medical record. These codes capture specific risks such as housing instability (Z59.0), lack of adequate food (Z59.4), or unemployment (Z56.0). Unlike free-text mentions, Z-codes provide structured, billable data that can be exchanged via USCDI-compliant systems, though they remain significantly underutilized in clinical practice.
Gravity Project Terminology
A consensus-driven initiative that develops standardized data elements and value sets for representing social determinants of health in EHRs and FHIR APIs. The Gravity Project defines structured screening instruments, coded observations, and interoperable terminology that directly inform the USCDI SDOH data classes. Key contributions include standardized value sets for food insecurity, housing stability, and transportation access.
FHIR SDOH Observation
A Fast Healthcare Interoperability Resources resource used to represent a specific, screened social risk finding in a standardized, exchangeable format. This resource captures the screening instrument used, the patient's response, and the coded finding using Gravity Project value sets. It is the primary mechanism for exchanging USCDI-mandated SDOH data between certified systems.
SDOH NLP Pipeline
An automated sequence of natural language processing components designed to extract, classify, and structure social determinant risk factors from unstructured clinical narratives. Key stages include:
- Named Entity Recognition for identifying mentions like 'homeless' or 'unemployed'
- Negation detection to distinguish affirmed vs. denied risks
- Experiencer detection to identify whether the patient or a family member is affected
- Temporality classification to determine if the risk is current, historical, or future
Closed-Loop Referral
An automated workflow that tracks a patient's journey from a positive social risk screening through to a confirmed connection with a community-based service provider. When a USCDI SDOH data element flags a need—such as food insecurity—the closed-loop system initiates a referral, monitors acceptance, and verifies service delivery. This closes the gap between screening and resolution, ensuring social risk data drives actionable outcomes.
SDOH Risk Stratification
The application of predictive models to segment a patient population by their level of social risk, enabling targeted interventions and resource allocation. These models combine USCDI-structured SDOH data with area-level indices like the Social Vulnerability Index (SVI) and Area Deprivation Index (ADI) to identify high-risk cohorts. Outputs inform population health strategies and value-based care contract performance.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us