Food insecurity screening data quality: FHIR resource requirements for SDOH data

Fewer than 12% of health systems that screen for food insecurity transmit that data using the FHIR SDOH Clinical Care resources that CMS quality measures now require. The rest capture responses in free-text fields, proprietary questionnaire formats, or unlinked EHR modules that cannot be exchanged, queried, or trusted.

This is not a workflow inconvenience. It is a structural data quality failure that poisons every downstream use: population health analytics, risk adjustment, care gap identification, and AI model training. Food insecurity screening data has a trust problem, and the fix is not more screening. The fix is mapping screening data to the right FHIR resources with the right terminology bindings.

Why food insecurity data quality matters now

CMS tied SDOH screening to payment in 2024 with the CMS ACCESS Program, which pays up to $420 per beneficiary per year for organizations that screen and act on social risk factors including food insecurity. By 2026, CMS quality measures increasingly require structured SDOH screening data in formats that payers and HIEs can consume.

The Hunger Vital Sign two-question screener, embedded in the AHC-HRSN instrument, is the most commonly used food insecurity screening tool in clinical settings. The CDC estimates that 10.2% of U.S. households experienced food insecurity at some point in 2023. Among Medicaid beneficiaries, that number exceeds 30%.

But screening rates do not equal data quality. A 2023 analysis of SDOH screening data across 42 community health centers found that 67% of positive food insecurity screens had no corresponding ICD-10 Z-code recorded in the problem list. The screening happened. The data never made it into a usable format.

Key statistics

DTI dimension weights applied to food insecurity screening data

Food insecurity screening data quality failures are measurable and consistent across health systems:

88% of food insecurity screening responses are stored in non-FHIR-compliant formats, making them invisible to interoperability networks and quality measure engines.

67% of positive food insecurity screens lack a corresponding ICD-10 Z59.41 (food insecurity) code in the patient's problem list, breaking the link between screening and clinical documentation.

30%+ of Medicaid beneficiaries experience food insecurity, but only 24% of Medicaid managed care plans report receiving structured SDOH data from providers.

3 weeks to 2 hours: SuperTruth reduced data standardization timelines for imaware's 105,000 diagnostic records by 95%, demonstrating what trust-scored data pipelines achieve when applied to fragmented clinical data.

$420 per beneficiary: the CMS ACCESS Program payment that requires documented SDOH screening, creating a direct financial incentive for food insecurity data quality.

The FHIR resource map for food insecurity data

The Gravity Project, maintained by HL7, defines the specific FHIR resources and value sets for representing food insecurity data. Most implementation guides reference FHIR R4 with US Core profiles. Here is what each resource does and why it matters for data trust.

Observation (screening response)

The SDOH Clinical Care IG uses the Observation resource with the SDOH Screening Response profile to capture individual screening question responses. For the Hunger Vital Sign screener, each of the two questions maps to a distinct LOINC code:

LOINC 88122-7: "Within the past 12 months, we worried whether our food would run out before we got money to buy more."

LOINC 88123-5: "Within the past 12 months, the food we bought just didn't last and we didn't have money to get more."

Each response gets its own Observation resource with Observation.category set to sdoh and Observation.code bound to the appropriate LOINC. The Observation.value uses a coded answer (often/sometimes/never) from the LOINC answer list.

The failure mode here is common: systems store the aggregate screening result (positive/negative) without preserving individual question responses. This collapses two data points into one, destroying the granularity that risk stratification models need.

Condition (health concern)

When a screening identifies food insecurity, the clinician or system should generate a Condition resource using the SDOH Condition profile. The Condition.code binds to either:

ICD-10-CM Z59.41: Food insecurity

SNOMED CT 733423003: Food insecurity

This is where the Z-code trust problem lives. Z59.41 was introduced in ICD-10-CM in October 2021 specifically for food insecurity documentation. Before that, systems used Z59.4 (lack of adequate food) or, more commonly, nothing at all. Many EHR systems still default to the parent code or skip Z-code assignment entirely because it has no direct reimbursement value in fee-for-service billing.

The Condition.evidence element should reference the Observation resources from the screening, creating a traceable chain from screening response to clinical assessment. Without this link, the Condition floats without provenance.

ServiceRequest (referral)

When a food insecurity screen is positive and the patient is referred to a food assistance program, the ServiceRequest resource captures that action. The Gravity Project value set for food insecurity interventions includes codes for:

Referral to food bank or pantry

Enrollment in SNAP or WIC

Provision of medically tailored meals

Referral to community-based food assistance organization

The ServiceRequest.reasonReference should point back to the Condition resource, and ServiceRequest.category should be coded as sdoh. This closes the screening-to-intervention loop that CMS quality measures evaluate.

QuestionnaireResponse (instrument-level data)

The full AHC-HRSN screening instrument, which includes food insecurity alongside housing, transportation, and other domains, maps to a QuestionnaireResponse resource. This preserves the complete instrument context: which version was administered, when, by whom, and in what setting.

Systems that extract only the food insecurity questions from the AHC-HRSN and discard the QuestionnaireResponse lose the instrument metadata. That metadata matters for data trust scoring because it establishes provenance, timing, and administration context.

Where Z-code food insecurity trust breaks down

Food insecurity data quality failure rates

The ICD-10-CM Z59.41 code is the hinge point for food insecurity data quality. It connects clinical documentation to claims, quality measures, and population health analytics. When it is missing or misapplied, every system downstream receives degraded data.

Three failure patterns dominate:

Failure 1: Screening without coding. The screening is completed, responses are stored somewhere in the EHR, but no Z-code is added to the problem list or encounter diagnosis. This happens in over 67% of positive screens because clinicians do not see Z-code documentation as clinically actionable in a fee-for-service model.

Failure 2: Wrong code granularity. Systems use Z59.4 (lack of adequate food and safe drinking water) instead of Z59.41 (food insecurity) or Z59.48 (other specified lack of adequate food). The parent code conflates food insecurity with water insecurity, reducing analytical precision.

Failure 3: Code without screening linkage. A Z-code appears on a claim or problem list, but there is no linked Observation or QuestionnaireResponse establishing how the determination was made. The code exists, but it has no provenance. Was it self-reported? Clinician-assessed? Inferred from address-level data? Without the linked screening resource, there is no way to know.

How food insecurity data flows through FHIR SDOH exchange

The Gravity Project defines a specific workflow for SDOH data exchange between clinical systems and community-based organizations (CBOs). Understanding this workflow exposes additional data quality requirements.

Screening capture: Patient completes the Hunger Vital Sign or AHC-HRSN. System generates QuestionnaireResponse and individual Observation resources.

Clinical assessment: Clinician reviews positive screen. System generates Condition resource with Z59.41 and links it to Observation evidence.

Referral initiation: Clinician creates ServiceRequest referencing the Condition. System transmits the ServiceRequest to the CBO via a FHIR API or intermediary platform.

CBO task management: The CBO receives a Task resource representing the referral. The Task references the ServiceRequest and includes the patient's consent status.

Outcome reporting: The CBO updates the Task with completion status. Optionally, a new Observation captures post-intervention screening results.

At each step, data quality can degrade. The most common breakpoint is step 3, where the ServiceRequest is transmitted without the linked Condition and Observation resources. The CBO receives a referral with no clinical context, and the referring system has no structured record of what was sent.

The consent dimension of food insecurity data

Food insecurity data carries specific consent requirements that most systems ignore. Under 42 CFR Part 2, substance use data has explicit consent restrictions. SDOH data does not have equivalent federal protections, but state laws vary significantly.

More fundamentally, patients may consent to clinical screening but not to data sharing with CBOs, payers, or research networks. The FHIR Consent resource can capture these distinctions, but fewer than 5% of SDOH data exchanges include a structured Consent resource.

This creates a trust gap. When a payer receives food insecurity data for risk adjustment, was the patient informed that their screening response would be shared with their insurance company? When a research network aggregates Z-code data for population health analysis, did patients consent to that secondary use?

SuperTruth's ConsentOS addresses this directly by scoring consent governance across five tiers, from implicit clinical consent to explicit research authorization. Food insecurity data without documented consent scores poorly on the Consent dimension of the Data Trust Index, regardless of how well the FHIR resources are structured.

What food insecurity data quality means for AI models

Population health AI models increasingly incorporate SDOH variables as predictive features. Food insecurity status is among the strongest social risk predictors for hospital readmission, diabetes management outcomes, and pediatric emergency department utilization.

But model developers rarely examine the provenance of the food insecurity feature. A binary "food insecure: yes/no" variable might originate from:

A validated Hunger Vital Sign screening administered in clinic

An inferred flag based on census tract food desert designation

A Z-code pulled from claims data with no linked screening

A natural language processing extraction from a social worker's note

Each of these sources has different accuracy, recency, and consent profiles. Treating them as equivalent introduces systematic bias. Census-tract inference, for example, assigns food insecurity status based on geography rather than individual experience, which creates the mismatch problem that degrades SDOH models for rural and suburban populations.

The Data Trust Index scores each of these sources differently. A validated screening response captured via FHIR Observation with linked QuestionnaireResponse provenance, documented consent, and a recency window under 12 months scores in the Platinum tier. An inferred flag from 2019 census data with no consent documentation scores Bronze at best.

The Gravity Project value set maintenance problem

The Gravity Project maintains value sets for food insecurity screening codes, condition codes, intervention codes, and goal codes. These value sets are updated regularly as new screening instruments are validated and new intervention categories emerge.

Health systems that hard-code food insecurity terminology bindings at implementation time fall out of sync within 12 to 18 months. A system implemented in 2023 may not include the updated SNOMED CT concepts added in 2024 for specific food insecurity subtypes (e.g., inadequate food supply due to financial hardship vs. geographic access barriers).

This creates a concordance problem. Two systems using different versions of the Gravity value sets will categorize the same patient's food insecurity differently. When those systems exchange data via a health information exchange, the receiving system may not recognize the sending system's codes.

The DTI Engine's Concordance dimension (10% weight) specifically measures whether coded data aligns across sources. For food insecurity data, concordance scoring evaluates whether the LOINC codes on Observation resources match the expected Gravity Project value set version and whether Z-codes on Condition resources use the current ICD-10-CM specificity.

Recency and the 12-month screening window

Food insecurity is not a static condition. Households cycle in and out of food insecurity based on employment changes, seasonal income variation, benefit eligibility shifts, and family composition changes. The USDA measures food insecurity over a 12-month recall period, and the Hunger Vital Sign screener uses the same timeframe.

This means food insecurity screening data has a built-in expiration. A positive screen from 18 months ago may no longer reflect current status. A negative screen from 6 months ago may have been invalidated by a job loss last month.

The DTI Recency dimension (15% weight) penalizes food insecurity data that exceeds the 12-month screening window. Systems that screen annually maintain Recency scores above threshold. Systems that screen only at initial intake and never re-screen produce data that degrades predictably over time, exactly as health literacy and patient-entered data degrades when collection is treated as a one-time event.

County health rankings and the population-level view

County Health Rankings data shows that food environment factors correlate with diabetes prevalence (r=0.42), cardiovascular mortality (r=0.38), and low birth weight rates (r=0.31) at the county level. These relationships between determinant factors and health outcomes are well-established in public health research.

But county-level correlations do not substitute for individual-level screening data. NIH-funded SDOH research increasingly requires individual-level social risk data linked to clinical outcomes. The gap between county-level food environment indices and individual food insecurity status is where data quality failures cause the most analytical damage.

SuperTruth's DataSpine product maps geographic SDOH data at the census tract level, providing the contextual layer that individual screening data needs. But DataSpine data is explicitly scored as contextual, not clinical. It supplements screening data; it does not replace it. The distinction matters for how place shapes health data trust.

What health systems should implement now

The path from current-state food insecurity data chaos to FHIR-compliant, trust-scored screening data requires five specific technical changes:

Map screening instruments to FHIR Observation resources using Gravity Project LOINC codes. Each question gets its own Observation. Aggregate scores get a separate Observation referencing the components.

Auto-generate Condition resources from positive screens with Z59.41 coding and evidence references to the source Observations. Do not rely on clinician documentation for Z-code assignment.

Preserve QuestionnaireResponse resources for the full screening instrument, including administration metadata: who administered, when, in what language, via what modality (in-person, phone, patient portal).

Implement Consent resources documenting patient authorization for data sharing with CBOs, payers, and research networks. Score consent status before transmission.

Enforce 12-month re-screening to maintain Recency scores. Flag records that exceed the screening window and trigger re-screening workflows.

These are not optional enhancements. They are the minimum requirements for food insecurity data that CMS will accept for quality measurement, that AI models can trust for training, and that CBOs can act on for intervention delivery.

The DTI Engine scores every health data record 0 to 100 across 8 trust dimensions before your AI model sees it. Food insecurity screening data that lacks FHIR resource compliance, Z-code linkage, or consent documentation scores below the threshold for clinical AI use. If your team is evaluating SDOH data for training, compliance, or population health analytics, schedule a conversation with the SuperTruth commercial team or (215) 918-4140.

Further reading:

DTI™ Engine

Health systems solution

Social risk factor screening data trust: AHC-HRSN instrument quality requirements

Community health organizations and SDOH data quality: the trust gap

Address-level SDOH data trust: geocoding accuracy and the census tract mismatch problem