SDOH Interoperability

The foundational specification that defines how to represent social risk data using FHIR R4 resources. It standardizes the exchange of screening assessments, observations, and goals.

• Uses US Core Patient and US Core Observation Screening Assessment profiles
• Mandates specific LOINC codes for screening instruments like PRAPARE
• Defines Condition, Goal, and ServiceRequest resources for closed-loop referrals
• Aligns with the Gravity Project value sets for food insecurity, housing instability, and transportation access

An HL7 standard that enables real-time, context-aware clinical decision support directly within the clinician's EHR session.

• Triggers on patient-view or order-select events
• Launches an SDOH screening card when a patient meets risk criteria
• Passes FHIR context (patient ID, encounter) to external services
• Returns actionable guidance without disrupting clinical workflow

The authorization framework that governs secure, patient-authorized access to sensitive SDOH data during exchange.

• SMART App Launch enables patient-facing apps to request SDOH data
• Scopes like patient/Observation.rs control granular access to social risk observations
• PKCE flow secures native mobile app authorization
• Ensures compliance with HIPAA and 42 CFR Part 2 for sensitive social and behavioral health data

A Fast Healthcare Interoperability Resources resource designed to represent a specific, screened social risk finding in a standardized, exchangeable format. It captures the screening instrument used (e.g., PRAPARE, AHC-HRSN), the question and answer pair, and the coded value from a standardized terminology like LOINC or SNOMED CT. This resource enables point-of-care applications and population health systems to consume SDOH data consistently.

• Key components: code (what was asked), value (the answer), derivedFrom (the screening instrument)
• Example: A food insecurity finding coded as LOINC 88124-3 with a value of LA30138-6 (Often true)

A consensus-driven initiative that develops standardized data elements and value sets for representing social determinants of health in electronic health records and FHIR APIs. The project defines how to code SDOH domains—such as food insecurity, housing instability, and transportation access—using LOINC for screening questions, SNOMED CT for findings, and ICD-10-CM for diagnoses. These terminologies form the semantic backbone of SDOH interoperability.

• Outputs: FHIR Implementation Guide bindings, USCDI submissions, and value sets
• Domains covered: 17 social risk domains including intimate partner violence, financial strain, and social isolation

A subset of diagnosis codes (Z55-Z65) used to document social determinants of health in a patient's structured medical record. These codes capture persons with potential health hazards related to socioeconomic and psychosocial circumstances, including housing instability (Z59.0), lack of adequate food (Z59.4), and unemployment (Z56.0). Z-codes enable SDOH data to flow through claims-based systems and billing workflows, bridging clinical and administrative interoperability.

• Limitation: Historically underutilized due to lack of clear reimbursement incentives
• Trend: CMS is increasingly encouraging Z-code documentation for value-based care and health equity measures

A mandated set of social determinant data classes and elements that certified health IT systems must be able to exchange under the ONC Cures Act Final Rule. USCDI v3 added Health Concerns, Problems, and Procedures as data classes that can carry SDOH information. This regulatory requirement ensures that EHR systems can capture, store, and transmit structured SDOH data using standardized APIs, making social risk data a first-class citizen in health information exchange.

• Current version: USCDI v4 (added Goals and Care Team Members)
• Impact: Drives EHR vendor roadmaps and API certification requirements

An HL7 standard for triggering real-time, context-aware clinical decision support within a clinician's EHR workflow. A CDS Hook fires when a clinician opens a patient's chart or signs an order, prompting an external service to evaluate the patient's data and return actionable cards—such as an SDOH screening reminder or a positive risk alert. This enables SDOH interoperability at the point of care without requiring clinicians to navigate to a separate application.

• Relevant hooks: patient-view, order-select, appointment-book
• Card example: 'This patient screened positive for food insecurity. Refer to community resource?'

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. Interoperability standards like the FHIR SDOH Clinical Care IG define the exchange of referral requests (ServiceRequest), task status updates (Task), and outcome observations (Observation) between clinical systems and community resource platforms. This closes the loop between identification and resolution.

• Key resources: ServiceRequest, Task, Procedure
• Goal: Ensure that identified social needs result in measurable outcomes, not just documentation