Social determinants of health — the non-medical factors that influence health outcomes including housing, food security, transportation, income, and education — account for a larger share of population health outcomes than clinical care alone. CMS has embedded SDOH data requirements into multiple quality payment programmes, NCQA has added SDOH measures to HEDIS, and state Medicaid agencies are requiring SDOH screening and referral in managed care contracts. The policy momentum is clear. What is less clear for most health systems and payers is the data architecture required to collect, integrate, and act on SDOH data at scale.
Standardised SDOH Screening: PRAPARE, AHC, and Hunger Vital Sign
Multiple standardised SDOH screening tools are in use across US healthcare settings. PRAPARE (Protocol for Responding to and Assessing Patients' Assets, Risks, and Experiences) is the most widely adopted comprehensive tool. The AHC Health-Related Social Needs Screening Tool is used by health systems participating in CMS's Accountable Health Communities model. The Hunger Vital Sign is the most widely validated food insecurity screening tool. Each produces structured responses that must be mapped to FHIR QuestionnaireResponse resources for EHR integration and quality reporting.
The Gravity Project FHIR IG defines the FHIR R4 profiles for SDOH data: Condition resources using SNOMED CT Z-codes for identified social needs, ServiceRequest resources for referrals to community resources, and Task resources for tracking referral completion. The Gravity IG is the technical standard that enables SDOH data to be exchanged across EHR systems and between healthcare organisations and community-based organisations.
EHR Integration: Z-Codes, Problem Lists, and Clinical Workflow
Integrating SDOH data into the clinical record requires mapping screening responses to ICD-10-CM Z-codes. Z59 covers housing and economic problems. Z60 covers problems related to social environment. Z63 covers other problems related to primary support group. These codes can be added to the problem list, encounter diagnosis, or referral documentation.
FHIR Questionnaire and QuestionnaireResponse resources, implemented via a SMART on FHIR application, allow patients to complete SDOH screening instruments in the patient portal or waiting room and have the structured responses automatically populated into the EHR workflow for clinical review. The clinical staff reviews flagged needs and converts them to problem list entries and referral orders, eliminating manual data entry.
Community Resource Referral Networks: The Closed Loop Problem
Identifying an SDOH need and generating a referral is the easy part. Closing the loop — confirming that the patient connected with the community resource and that the need was addressed — is the hard part. Most health systems have no systematic mechanism for receiving referral completion confirmation from community-based organisations.
The HL7 FHIR IG for Bidirectional Services eReferral and the Gravity Project Referral Management workflow profiles define how EHR systems and community resource directories can exchange Task resources to track referral status. The technical infrastructure requires community-based organisations to have a system capable of accepting and updating FHIR Task resources — a capability that most CBOs currently lack. Interoperability platforms such as Findhelp and 211 networks provide middleware that translates between health system EHR FHIR APIs and CBO case management systems.
Privacy and Consent Considerations for SDOH Data
SDOH data collected in a clinical setting is PHI subject to HIPAA. Sharing SDOH data with community-based organisations for referral purposes requires a HIPAA treatment exception or patient consent. Sharing SDOH data for population health reporting, quality measurement, or payer submission may require patient authorisation depending on the specific use case and data elements shared.
Patients may be reluctant to disclose SDOH information if they are uncertain how it will be used. Health systems that collect SDOH data must communicate clearly — in language appropriate to their patient population — how the data will be used, who it will be shared with, and how it will be protected. The consent and notice architecture for SDOH data collection is a patient trust issue, not just a regulatory compliance issue.
CMS Quality Payment Programme Requirements
CMS has embedded SDOH screening and referral in MIPS quality measures and in several alternative payment model requirements. The 2024 Physician Fee Schedule includes SDOH-related add-on codes that recognise the clinical work of screening and referral. Health systems and payers building SDOH data infrastructure must ensure that their data model supports quality measure reporting — that SDOH screening completion, identified needs, referrals made, and referral completion are captured in a form extractable for HEDIS hybrid measure reporting and MIPS quality reporting.
The Algorithm Approach: SDOH Data Architecture
The Algorithm designs SDOH data architectures grounded in the Gravity Project FHIR IG, with SMART on FHIR screening tools integrated into the EHR patient workflow, Z-code problem list automation that eliminates manual data entry, and referral management integrations with leading community resource platforms. We build the quality reporting data pipeline that extracts SDOH measure elements for HEDIS and MIPS reporting, and design the consent and notice workflow that builds patient trust in SDOH data collection. The result is an SDOH programme that is operationally sustainable, not just pilotable.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.