Resources
USCDI and SDOH: data classes that close the loop
The Office of the National Coordinator for Health Information Technology maintains the United States Core Data for Interoperability (USCDI). Recent versions added Social Determinants of Health as a required data class hierarchy, with assessments, conditions, goals, and interventions as distinct sub-classes. For clinical informaticists, this is the structural change that lets closed-loop SDOH workflows be interoperable across systems.
What USCDI is, in one paragraph
USCDI is the standardized set of health data classes that certified electronic health record technology (CEHRT) is required to support for interoperable exchange. Vendors of certified products have to implement the data classes in the current version of USCDI to maintain certification. New versions add data classes over time, reflecting where the field has agreed structured exchange is required. SDOH was added in USCDI v3 and expanded in subsequent versions.
The four SDOH sub-classes
SDOH Assessment
The screening instrument itself, captured as discrete observations.
When a patient completes an AHC-HRSN, PRAPARE, or other validated instrument, each item lands as an Observation resource with the SDOH category and the standardized item code. This is what makes a screen searchable, reportable, and analyzable. Without this data class, the screen exists only as free text and is invisible to the population health and quality reporting pipelines.
SDOH Condition
The structured social diagnosis derived from a positive screen.
A positive food-insecurity screen lands as a Condition resource (food insecurity, ICD-10 Z59.41) on the patient's problem list. The Condition links the screening result to a clinical diagnosis that the rest of the system can act on. Without it, the screen does not produce a problem-list entry and the next clinician is unaware of the social need.
SDOH Goal
The clinical goal the program is working toward, tied to the social need.
Programs that take social need seriously set goals: stable housing within 90 days, food access established within 30 days, transportation to follow-up appointments arranged. Goals are tracked over time and tied to the underlying Condition. They are how a closed-loop program differs from a one-time-screen-and-refer program.
SDOH Intervention
The structured action taken in response to a positive screen.
Intervention is the most important data class for closed-loop work because it captures what the program actually did. A referral to a community-based organization, a dispatched home visit, a food-box order, a navigation appointment with a CHW, all become Procedure or ServiceRequest resources tied back to the SDOH Condition. Reporting that an intervention occurred and what it produced is what makes the loop visible.
Why the data class hierarchy matters
Before USCDI added SDOH as a structured data class, there was no required way for one certified system to send SDOH information to another. Programs that ran SDOH screening produced data in their EHR, but there was no agreed mechanism to exchange that data with a community-based organization, a referral platform, or a downstream care manager.
With assessments, conditions, goals, and interventions defined as USCDI sub-classes, certified vendors are now obligated to support their structured exchange. That obligation is the foundation that the Gravity Project FHIR Implementation Guide and the HL7 eReferral specifications build on. A certified ordering system can now produce a ServiceRequest with the SDOH category, send it to a receiving system that can read it, and receive structured updates back as the intervention proceeds.
The work is far from done. Receiving systems on the community-based-organization side are not all certified, and many lack a FHIR endpoint. But the standards layer no longer treats SDOH as an afterthought, and that is what makes the next wave of closed-loop work possible.
What this means in practice
For an informatics team building or evaluating an SDOH workflow, the USCDI data classes give a checklist. For each class, ask: where is this captured today, is it discrete or free text, does it leave the system, and where does it go?
A workflow that produces an SDOH Assessment but no Condition is producing screens that never become problems. A workflow that produces an Intervention but no Goal is intervening without a target. A workflow that produces all four but exchanges none of them is closed inside one EHR but invisible to the rest of the patient's care team. The data class lens makes those failure modes legible.
For program leaders, the question to ask vendors is no longer "do you support SDOH". It is "which of the USCDI SDOH data classes do you produce, consume, and exchange, and through which FHIR resources". Vendors that cannot answer that specifically are not yet operating at the standards layer.
Further reading
USCDI (HealthIT.gov)
Primary source. Current versions, change log, and public-comment cycle.
The Gravity Project
FHIR Implementation Guide profiling the SDOH resources.
Anatomy of a closed-loop referral
The data classes mapped to the operational stages of a referral.
SDOH screening instruments comparison
The instruments whose output populates the SDOH Assessment data class.
Building closed-loop on top of the standards?
We work with informatics teams designing the workflow that produces these data classes structurally instead of after the fact.