Agents That Identify and Route Social Determinants of Health

Why Non-Clinical Needs Keep Falling Through the Cracks

Healthcare systems have spent decades optimizing clinical workflows while leaving an enormous category of patient need essentially unaddressed at the point of care. Social determinants of health — the economic conditions, housing instability, food insecurity, transportation barriers, and social isolation that shape a person's actual health outcomes — account for a documented share of health outcomes that rivals or exceeds the influence of clinical care itself. Yet the systems that handle clinical encounters were never designed to capture, classify, or act on these signals. The result is a structural gap: patients disclose needs, those disclosures go unrecorded or unrouted, and the needs persist unchanged across visit after visit.

What Makes SDOH Routing Architecturally Distinct

Routing social determinants of health is not a CRM problem or a referral management problem dressed in new terminology. It is a fundamentally different kind of signal-processing challenge. Clinical data arrives in structured formats — diagnosis codes, lab values, medication orders — and flows through established HL7 and FHIR pipelines. SDOH data arrives through conversation, written intake forms, behavioral signals embedded in visit frequency, and community-level data that has no natural home in an EHR field.

The architectural implication is that an agent handling SDOH cannot simply read a database. It must interpret language, reconcile conflicting signals, apply eligibility logic against a constantly changing landscape of community resources, and then execute an action — a referral, a scheduled call, an alert to a care coordinator — in a system that likely was not designed to receive that action. Each of those steps requires a different capability layer, and the failure to separate those layers cleanly is why most early SDOH tools produced reports rather than outcomes.

A well-designed SDOH agent operates across at least four distinct functional layers. The first is signal acquisition — pulling structured and unstructured data from intake forms, EHR notes, chat interfaces, and external community data feeds. The second is classification, where raw signals get mapped to standardized SDOH categories such as those defined by the Gravity Project's SDOH clinical data element taxonomy. The third is eligibility and resource matching, where the classified need is checked against available community-based organization capacity, geographic constraints, and patient consent. The fourth is action execution, where the agent writes back to the EHR, triggers an outreach workflow, or routes to a human reviewer when confidence falls below a defined threshold.

Structured Screening as the Signal Foundation

Before an agent can route anything, it needs reliable input. The most defensible approach pairs a validated screening instrument with an agent layer that processes responses in real time. The Protocol for Responding to and Assessing Patients' Assets, Risks, and Experiences — commonly known as PRAPARE — provides a standardized set of questions across domains including housing, food, employment, and social support. The Accountable Health Communities Health-Related Social Needs Screening Tool offers a similar structure. Both map directly to Gravity Project codes, which means a correctly configured agent can convert a patient's screening responses into codified FHIR observations without a human intermediary touching the data.

The agent's role in this phase is not simply to collect responses. It must detect inconsistency — a patient who selects "food secure" but who has had three emergency department visits in six months for conditions commonly associated with food insecurity. It must also detect non-response, a signal in its own right, particularly when certain question domains are consistently skipped. Handling these cases correctly requires the agent to apply a confidence weighting to each SDOH signal rather than treating all data as equally reliable.

Multimodal input matters here as well. An agent deployed in a pediatric primary care setting might receive SDOH signals from a caregiver's verbal responses to a medical assistant, from a tablet-based intake form, and from a health-related quality of life questionnaire completed at home through a patient portal. Reconciling those three input streams requires deduplication logic and a temporal awareness layer — the agent must know which signal is most recent and how much weight to assign signals collected through lower-fidelity channels.

Classification Against the Gravity Project Taxonomy

The Gravity Project, convened under HL7 and now integrated into the US Core Data for Interoperability standard, has produced the most widely adopted taxonomy for SDOH clinical concepts. As of its most recent published releases, the project defines SDOH categories including food insecurity, housing instability, homelessness, inadequate housing, transportation insecurity, financial strain, social isolation, intimate partner violence, education access, and others. Each category has associated SNOMED CT codes, ICD-10-CM Z codes, and LOINC observation codes that allow EHR systems to store and exchange SDOH data in a standardized form.

An agent performing SDOH classification must map patient-reported data to these codes accurately and must handle ambiguity gracefully. A patient who reports "I sometimes skip meals because I can't afford groceries" maps clearly to food insecurity under the Gravity taxonomy. A patient who reports "things have been hard lately" does not, and an agent that overcodes vague responses will produce a dataset full of false positives that erodes clinician trust. The classification layer should use a confidence threshold below which the agent flags the response for human review rather than auto-coding.

Intersecting needs add another layer of complexity. A patient experiencing housing instability may also face food insecurity and transportation barriers, and those needs may be causally linked in ways that affect the routing logic. An agent that treats each SDOH domain as independent will produce three separate referrals to three separate organizations, which may overwhelm the patient and fragment the response. A more sophisticated classification layer detects clustering — multiple SDOH signals that co-occur at rates above baseline — and routes to a care coordinator who can address the bundle of needs through a single coordinated plan rather than three disconnected referrals.

Resource Matching and Community Inventory Challenges

Resource matching is where most SDOH routing implementations break down in practice. Identifying that a patient has a food insecurity need is solvable with the right screening and classification infrastructure. Knowing which food resource is currently accepting new clients, within the patient's transportation range, operating within the patient's work schedule, and able to serve the patient's dietary restrictions is an entirely different problem. Community-based organization inventory changes constantly, and no static database can keep pace with it.

An effective SDOH agent connects to a live resource directory — the most widely used open standard for this purpose is the Human Services Data Specification, or HSDS, which structures community resource data in a machine-readable format. Several regional aggregators maintain HSDS-compliant directories, and national platforms also publish feeds that can be consumed via API. The agent's resource-matching layer queries these directories at the time of routing rather than pulling from a cached dataset, because a resource that was accepting clients yesterday may have reached capacity this morning.

Eligibility logic adds further complexity. Many community resources have income-based eligibility thresholds, geographic service boundaries, residency requirements, or restrictions on the frequency with which a single individual can access the service. An agent that matches on need category alone without filtering for eligibility will generate referrals that patients cannot actually use, which damages the patient experience and wastes care coordinator time following up on failed connections. Building eligibility logic into the routing layer requires the agent to have access to relevant patient attributes — income documentation, insurance status, geographic location — and to apply those attributes against structured eligibility rules encoded for each resource.

How do you build agents that identify social determinants of health and route non-clinical needs?

This is the operational design question that determines whether an SDOH agent becomes a useful care delivery tool or an expensive documentation exercise. The answer requires specifying at least four decisions before writing a single line of agent logic. First, define the trigger conditions — what event causes the agent to activate? A completed PRAPARE screening, an ED visit within the past 30 days, a specific diagnosis code, or a combination of signals? Second, define the authority boundary — what actions can the agent take autonomously, and what actions require a human in the loop? Autonomously writing a FHIR observation into the EHR is appropriate. Autonomously enrolling a patient in a community program without consent is not.

Third, define the handoff protocol — when the agent routes to a human care coordinator, what information does it surface, and in what format, to make that human's decision as fast and accurate as possible? Fourth, define the feedback loop — how does the agent learn whether a routing action resulted in a successful connection, and how does that outcome data update the resource-matching logic?

Getting these four decisions right before building is not a planning formality. Agents built without explicit authority boundaries routinely exceed their intended scope in ways that create compliance exposure. In a healthcare context, that means potential HIPAA implications if the agent accesses data beyond what is necessary for the specific function, or potential liability if the agent takes an action the patient did not consent to. The 30-day deployment methodology used by TFSF Ventures FZ LLC begins with an operational scoping phase that locks in these four decisions before any agent logic is constructed, which prevents the costly rework that follows when authority boundaries are discovered post-deployment rather than defined pre-build.

Routing architecture also needs to account for the difference between synchronous and asynchronous workflows. A patient completing a screening in the waiting room before an appointment represents a synchronous context — the agent has minutes, not hours, to identify an urgent need and surface it to the clinician before the encounter begins. A patient completing a portal-based screening at home represents an asynchronous context where the agent has more time but must also manage the possibility that the patient will not respond to outreach. Designing for both contexts in a single agent architecture requires a priority-scoring layer that escalates high-severity needs — active housing crisis, food insecurity with young children in the household — into synchronous channels regardless of when the screening was completed.

Exception Handling in SDOH Workflows

SDOH routing surfaces a higher density of edge cases than most clinical workflows because the data is inherently messier and the downstream systems are less standardized. An agent that handles only the clean path — patient screens positive, resource match found, referral sent, acknowledgment received — will fail silently in the real-world cases that matter most. Designing robust exception handling is the difference between an agent that works in a demo and one that works in a live care environment.

The most common exceptions fall into four categories. Resource unavailability is the first: the agent identifies a need, queries the resource directory, and finds no available match within the patient's eligibility and geographic constraints. The correct response is not to log an error and stop. The agent should escalate to a care coordinator with a flag indicating an unmatched need, trigger a secondary search in an expanded geographic radius, and schedule a re-query at a defined interval in case capacity opens.

The second exception category is patient-declined routing — the patient was screened, a need was identified, but the patient declined the referral. This is a legitimate outcome that must be recorded in the EHR as a declined referral with the patient's stated reason, not as a failed routing attempt.

The third exception is consent ambiguity — situations where it is unclear whether the patient consented to having their SDOH data shared with a specific community-based organization. Healthcare providers operating under HIPAA have obligations around what data they can share with non-covered entities, and an SDOH agent that routes without resolving consent status creates regulatory exposure. The exception handler for this case must pause the routing action, surface the consent question to the appropriate staff member, and resume only after documented consent is obtained.

The fourth exception is data conflict — two sources providing contradictory signals about the same patient. The agent should flag the conflict rather than arbitrarily choosing one source, and it should provide the care coordinator with both data points and their provenance so the human can make an informed judgment.

Integration Architecture for EHR Write-Back

The most underestimated challenge in SDOH agent deployment is writing SDOH data back into the EHR in a way that clinicians actually see and use. Most EHR platforms support the storage of SDOH data as FHIR Observation resources, Condition resources, or ServiceRequest resources, depending on the clinical context. The Gravity Project's implementation guidance provides specific FHIR profile requirements for each SDOH concept category, and agents that write SDOH data outside those profiles may produce records that are technically stored but invisible to clinicians in their normal workflow views.

SMART on FHIR authorization is the access mechanism most EHR platforms now require for third-party agents writing to patient records. The OAuth 2.0 authorization flow, scoped to specific resource types and constrained to individual patient context, provides the access control layer that allows an SDOH agent to write to a record without accessing the full EHR dataset. Configuring these scopes correctly — requesting only the permissions needed for the specific SDOH workflow — is part of responsible deployment practice and directly relevant to HIPAA minimum necessary standards.

Bidirectional integration adds the feedback capability that makes routing self-improving over time. When a community-based organization updates a referral status — patient connected, patient not reached, program at capacity — that update should flow back into the EHR record and into the agent's resource-matching model. Closed-loop referral management is not a feature addition; it is the mechanism by which an SDOH agent accumulates operational intelligence that a static referral list never can.

Measuring SDOH Routing Performance Without Invented Metrics

Defining meaningful performance measures for an SDOH routing system requires care, because the outcomes that matter most — whether a patient's food insecurity actually resolved — are often months away from the routing event and influenced by factors the healthcare system does not control. Intermediate process measures are more actionable for operational improvement. Referral acceptance rate measures what fraction of patients who received a routing offer accepted it. Resource connection rate measures what fraction of accepted referrals resulted in the patient making contact with the resource. Referral-to-connection lag measures the time between the routing event and the first confirmed patient contact with the resource.

TFSF Ventures FZ LLC approaches SDOH deployments as production infrastructure questions rather than analytics questions, which means the performance measurement layer is built into the agent architecture from the start rather than added as a reporting module afterward. The 19-question Operational Intelligence Assessment that precedes every engagement specifically asks clients to define what a successful routing event looks like in operational terms — not in aspirational outcome terms — so that the agent's feedback loop is calibrated to measures the organization can actually observe and act on. Engagements are scoped and priced as fixed-delivery infrastructure projects rather than open-ended consulting retainers, which means clients receive a defined agent system with owned code and configuration rather than an ongoing subscription to a third-party platform. This fixed-delivery pricing model reflects TFSF's RAKEZ License 47013955 registration and its commitment to production deployment over managed service dependency.

Equity analysis is a secondary performance layer that healthcare organizations operating in safety-net contexts should build in from the start. SDOH routing systems can inadvertently reproduce the biases present in their training data or in the community resource directories they query. If the resource directory is more complete for certain geographic areas than others, patients in underserved areas will appear to have fewer options even when community resources exist but are not yet catalogued. Monitoring referral rates, acceptance rates, and connection rates stratified by race, language, insurance status, and geography allows the team operating the agent to detect these disparities and address them in the resource directory before they become entrenched in the routing behavior.

Deploying in Federally Qualified Health Centers and Safety-Net Settings

Federally Qualified Health Centers represent one of the highest-need deployment environments for SDOH routing agents because their patient populations carry disproportionate SDOH burden and their staff-to-patient ratios leave little room for manual social needs navigation. The Uniform Data System that FQHCs report to CMS already includes measures related to social needs screening, and several value-based payment models applicable to FQHCs include SDOH-related quality metrics. An agent that connects screening data to routing outcomes and captures that data in reportable form provides operational value at the care delivery level while simultaneously generating the documentation needed for quality measure reporting.

The challenge in FQHC deployment is staffing model integration. FQHCs frequently rely on community health workers as the human layer in their SDOH workflows, and a routing agent that bypasses or undermines the community health worker's role will face organizational resistance that technical capability cannot overcome. The most effective design positions the agent as a triage and prioritization tool for community health workers — surfacing the highest-need patients, providing structured information about available resources, and capturing the outcomes of community health worker contacts — rather than as an autonomous replacement for that human relationship.

Multilingual capacity is not optional in safety-net settings. An SDOH screening and routing agent deployed in a community where a substantial portion of the patient population has limited English proficiency must be capable of operating in the relevant languages. This means validated screening instrument translations, language-concordant routing communications, and resource directory filtering that surfaces resources capable of serving patients in their preferred language. An agent that defaults to English-only operation in a multilingual clinical environment will systematically underscreen and underserve the highest-risk patients in the population.

Governance, Consent, and Data Stewardship

SDOH data occupies a regulatory gray zone that requires careful governance design. Under HIPAA, health information collected by a covered entity in the course of treatment is protected health information regardless of its clinical or social character. That means SDOH screening data collected in a clinical context carries the same access controls and breach notification obligations as a lab result. However, the downstream entities to whom SDOH data might be routed — food banks, housing programs, legal aid organizations — are generally not HIPAA-covered entities.

Sharing protected health information with a non-covered entity requires either a formal business associate agreement if the entity is performing a function on behalf of the covered entity, or explicit patient authorization if the sharing goes beyond what is covered by the treatment, payment, or operations exception. Building consent management into the agent architecture means the agent must check consent status before executing any routing action that involves data sharing with a non-covered entity.

The consent record — what was disclosed, to whom, for what purpose, and when — must be stored in the EHR in a form that is accessible if the organization is ever asked to demonstrate compliance. Data minimization is the companion principle: the agent should share only the data elements that the receiving organization actually needs to provide the service. Routing a patient to a food pantry requires the patient's name, contact information, and the nature of the need. It does not require the patient's diagnosis codes, medication list, or visit history.

TFSF Ventures FZ LLC builds consent and data minimization logic directly into the agent's routing layer as part of its production infrastructure approach, rather than treating these as policy documents that exist outside the system. The firm operates across 21 verticals globally and has built specific exception handling for the regulatory boundary conditions that arise in healthcare contexts, where the intersection of HIPAA, state-level social services data sharing laws, and community-based organization data practices creates a compliance surface that a generic routing tool is not equipped to navigate.

Operationalizing Feedback Loops for Continuous Improvement

A routing agent that does not learn from its outcomes is a static rule set with an API wrapper. The distinction between a genuine agent and a sophisticated referral form lies in the feedback architecture — the mechanism by which outcome data returns to the system and modifies future behavior. In SDOH routing, feedback operates at three levels. At the resource level, feedback tells the agent which resources are reliably connecting patients and which are generating accepted referrals that never result in contact, so that resource-matching weights can be adjusted. At the patient level, feedback tells the agent which patient characteristics are associated with referral acceptance versus decline, so that the routing offer can be personalized in ways that improve uptake. At the population level, feedback tells the organization where its community resource infrastructure has gaps that no amount of routing optimization can fill.

Implementing feedback loops requires closed-loop data collection from community-based organizations, which is the hardest part of the operational design. Most community-based organizations do not have the data infrastructure to send structured referral status updates back to a healthcare system in real time. Building for this constraint means designing a feedback collection mechanism that meets community-based organizations where they are — a simple web-based form, a structured email template, or a phone call logged by a care coordinator — rather than requiring API integration that most organizations cannot support.

The 19-question operational assessment that TFSF Ventures FZ LLC uses as the entry point to every engagement specifically maps the client's existing community-based organization relationships and data-sharing infrastructure before any agent architecture is designed. This prevents a common failure mode where an agent is built assuming feedback infrastructure that does not exist, producing a system that works technically but cannot learn operationally.

About TFSF Ventures FZ LLC

TFSF Ventures FZ-LLC (RAKEZ License 47013955) is an AI-native agent deployment firm built on three pillars, all running on its proprietary Pulse engine: autonomous AI agents deployed directly into the systems a business already runs, a patent-pending Agentic Payment Protocol licensed to enterprises and payment networks globally, and a Venture Engine that compresses the full venture lifecycle from idea to investor-ready. Founded by Steven J. Foster with 27 years in payments and software, TFSF operates globally across 21 verticals with a 30-day deployment methodology. Learn more at https://tfsfventures.com

Take the Free Operational Intelligence Assessment

Run the Operational Intelligence Diagnostic — 19 questions benchmarked against HBR and BLS data. Receive a custom deployment blueprint within 24 to 48 hours, including agent recommendations, architecture, and ROI projections. Start at https://tfsfventures.com/assessment

Originally published at https://www.tfsfventures.com/blog/agents-that-identify-and-route-social-determinants-of-health

Written by TFSF Ventures Research