SDOH Community Intelligence
Inspiration
80% of health outcomes are driven by social determinants. Housing, food access, transportation, employment. Most clinicians know this but don't have time to screen for it. The tools that exist are manual, fragmented, and only look at what's in the patient's chart.
The chart misses a lot. It doesn't know the patient lives in a census tract where 97% of residents face socioeconomic vulnerability. It doesn't catch that "husband lost job" buried in a clinical note means household income risk. It doesn't connect food insecurity with transportation barriers and recognize the compounding spiral.
We built SDOH Screener to give any AI agent on Prompt Opinion the ability to run a real social risk assessment, one that fuses clinical data with community-level public health intelligence. That's something rule-based systems can't do.
What it does
SDOH Screener is an MCP server that exposes 5 tools:
screen_patient_sdoh pulls FHIR data (conditions, observations, notes), geocodes the patient's address to a census tract, retrieves CDC Social Vulnerability Index scores, then uses GenAI to synthesize everything into a clinician-facing risk narrative. Deterministic safety guardrails run on top, so coded diagnoses can never be downgraded and critical risk combinations always get escalated.
get_community_risk_profile returns CDC SVI vulnerability scores for any ZIP code or census tract. Four themes: socioeconomic status, household characteristics, minority/language, housing/transportation.
suggest_interventions takes identified risks and generates a personalized intervention plan. Prioritizes by urgency, identifies which interventions bundle together, notes barriers given the patient's combined risk profile, and suggests realistic sequencing. Outputs coded FHIR ServiceRequest templates.
generate_sdoh_fhir_bundle produces a Gravity SDOH Clinical Care IG-conformant FHIR R4 transaction Bundle. Proper LOINC, ICD-10, and SNOMED coding. Ready to POST back to the EHR.
extract_sdoh_from_notes is a standalone NLP extraction tool. Feed it clinical text (faxed referrals, PDFs, transcripts) and it maps SDOH signals to ICD-10 Z-codes and SNOMED codes with confidence scores.
How we built it
TypeScript and Node.js with the official MCP SDK. StreamableHTTP transport for remote deployment. SHARP extension (ai.promptopinion/fhir-context) for receiving patient context from the platform.
The LLM inference comes through MCP's sampling capability, so the server asks the host for completions. No API keys, no model vendor lock-in. The organization controls which model runs.
External data comes from two public APIs: CDC SVI via ArcGIS REST (community vulnerability by census tract) and the US Census Geocoder (address to FIPS tract code). Both free, no keys required.
The whole thing bundles to 35kb with esbuild in 6ms.
Safety Architecture
Three code-enforced rules the LLM cannot override:
- Clinical floor. Any coded SDOH diagnosis (ICD-10 Z55-Z65) sets a minimum risk of HIGH. The AI can add context but can't downgrade it.
- Critical combinations. Known compounding pairs (food insecurity + transportation barriers, housing instability + unemployment) automatically escalate the lower risk. These interactions are documented in SDOH literature.
- Vulnerable population flags. Patients who are elderly (65+), have limited English proficiency, or are widowed get automatic risk floor elevation for relevant domains.
100% of coded diagnoses assessed at HIGH or above across our benchmark. Zero false negatives on critical combinations.
Validation
Tested against 3 synthetic patients with pre-labeled expected outcomes:
| Metric | Result |
|---|---|
| Clinical floor activations | 6/6 |
| Critical combination escalations | 3/3 |
| Vulnerable population flags | 4/4 |
| AI signals from unstructured notes | 6+ per patient |
The AI catches things rules fundamentally can't: "husband lost job" maps to household income risk, "stopped attending church" signals loss of social outlet, "single mother, no family nearby" means childcare barriers compounding employment.
Challenges
The MCP SDK's Zod types caused TypeScript's compiler to OOM. Switched to esbuild for transpilation.
SHARP headers arrive as HTTP headers, not in the JSON-RPC payload. Required per-session header capture in Express middleware and a lookup map keyed by session ID.
Designing LLM prompts that produce clinically appropriate narratives without making diagnostic claims took iteration. The prompt needs to synthesize data without overstepping into medical advice.
Multiple external API calls (FHIR + Census geocoder + CDC SVI + LLM sampling) all need to fit within the platform's timeout window.
What makes this different
We're the only entry on the marketplace that combines clinical FHIR data with external public health datasets. Every other SDOH tool only looks at the chart. The CDC Social Vulnerability Index adds community context that individual patient records can't provide.
The safety architecture means the AI adds value without introducing risk. Five composable tools that work standalone or as a full pipeline (screen, intervene, document). Zero API keys required, true open access.
What we learned
MCP's sampling capability is the right pattern for healthcare AI tools. The server requests inference from the host, so there's no API key management and the organization controls model selection.
The Gravity Project's SDOH Clinical Care IG provides solid structure for representing social risk in FHIR. Community-level data adds context that individual records alone miss. And the hybrid approach (deterministic rules where safety matters, AI where reasoning matters) is the right architecture for clinical tools.
What's next
- 211.org API integration for real-time local resource matching
- Longitudinal tracking to measure intervention effectiveness over time
- Expanded benchmark with more patients
- Support for AHC-HRSN and SEEK screening frameworks
- Batch mode for population health managers screening entire panels
Log in or sign up for Devpost to join the conversation.