FQHC patient navigation that documents the closed loop — and lines up with UDS the day you submit.
UDS-aligned referral-completion tracking, PRAPARE SDOH workflow, PHQ-9 follow-up, 691,000+ community resources, executed BAA chain, white-label tenant in 48 hours. Built by a clinician who watched the loop never close.
Where the pathway breaks — and how we close it
UDS-aligned referral completion documentation
HRSA's Uniform Data System expects health centers to document whole-person care coordination — including whether patients actually connected with referred services. The EHR records that the referral was made; almost no FQHC EHR records what happened next. The closed loop is tribal knowledge held in a coordinator's head, lost when the coordinator turns over.
Cost when unaddressed: UDS reports the referral. The grant reviewer reads the gap. The site visit reads the gap. The next funding cycle reads the gap.
FHIR R4 ServiceRequest with 30-day closure tracking
Every outbound referral generates a FHIR R4 ServiceRequest with a destination, an electronic acknowledgment, a scheduled appointment write-back, and a status update closed within thirty days — or a documented patient-outreach attempt when the destination cannot confirm electronically. Completion data exports in formats aligned with HRSA UDS referral tracking.
PRAPARE SDOH capture across the federal domains
The Protocol for Responding to and Assessing Patient Assets, Risks, and Experiences (PRAPARE) is the FQHC-purpose-built SDOH instrument developed by NACHC, the Oregon Primary Care Association, the Institute for Alternative Futures, and the Robert Graham Center — explicitly aligned to the federally recognized social-determinants domains organized in Healthy People 2030. Most FQHCs administer PRAPARE on paper at intake, score it inconsistently, and have no workflow that connects a positive answer to a referral pathway.
Cost when unaddressed: Free-text SDOH is a checkbox. Structured SDOH is a referral list. The two are not the same and the funder reads the difference.
PRAPARE-derived items mapped to the federal SDOH domains
PRAPARE-derived items are delivered through the patient app and mapped 1:1 to the federally recognized SDOH domains organized in Healthy People 2030. A positive answer in any domain triggers a referral to a vetted community resource and reports back into the SDOH dashboard at the cohort level for medical-director and care-coordination-lead review.
Care coordinator time per patient referral
FQHC care coordinators routinely spend thirty to forty-five minutes per patient identifying insurance-aware community resources, calling to confirm capacity, drafting referral outreach in plain prose, and following up on whether the patient connected. That time is unrecoverable from a panel where the productivity expectation is set by the medical visit, not the navigation layer underneath it.
Cost when unaddressed: An hour of coordinator time on the wrong work is a coordinator who never gets to the high-touch follow-up the patient actually needed.
Insurance-aware matching with AI-drafted outreach under BAA
Positive screens (PRAPARE / PHQ-9 / depression follow-up plan / SBIRT) auto-surface matched resources from a verified database of more than six-hundred-and-ninety-one-thousand community resources. Vertex AI under the Google Cloud BAA drafts the outreach email, SMS, or letter — PHI is sanitized before any AI call and no record is used to train any model. The coordinator reviews, edits, and sends.
PHQ-9 depression-screening follow-up loop
Depression screening and follow-up is a HRSA UDS clinical-quality measure for FQHCs (CMS eCQM 2/CMS2v13). The denominator is patients twelve and older screened with a standardized instrument; the numerator is patients with a documented follow-up plan on the date of a positive screen. PHQ-9 is the strongest single-instrument depression screener available — and the follow-up plan is the gap that opens the measure score.
Cost when unaddressed: PHQ-9 captured at intake without a documented follow-up plan is a measure-score zero. The loop is the score.
Longitudinal PHQ-9 with documented follow-up plan trigger
PHQ-9 is captured on a measurement-based-care cadence. A positive screen (score ≥ 10) automatically opens a documented follow-up-plan task on the day of the screen — the artifact required for the CMS eCQM numerator. Subsequent administrations are tracked longitudinally; the dashboard flags response (≥ 50% reduction) and remission (< 5 at six and twelve months).
Insurance-aware community-resource matching
FQHC patients carry Medicaid, Medicare, dual-eligible, sliding-scale, marketplace, and self-pay coverage in roughly equal weight. A community-resource referral that does not check coverage at the moment of match is a referral the patient cannot use — and a patient call-back that never happens. The 211 directory is a phone number; the FQHC needs an insurance-aware list keyed to the actual screen result.
Cost when unaddressed: A wrong-insurance referral is a no-show in advance. The metric records the referral; the patient is unchanged.
691,000+ verified resources with insurance + geographic + need filters
Resources are filtered by accepted insurance, geographic catchment, and the specific need triggered by the screen. The match runs on the screen result — not on the coordinator's memory of which agency was open last time. Resources are version-controlled and verified on rolling cadence.
Time-to-deploy and EHR integration depth
Build-it-yourself patient navigation runs nine to eighteen months — a year of FQHC payroll burned on integration, branding, and HIPAA review before the first patient is screened. Off-the-shelf vendors deploy faster but ship lock-in and surrender the referral data. Most FQHCs run athenahealth, eClinicalWorks, NextGen, or Epic — a navigation layer that cannot speak FHIR R4 to the chart of record is a third silo.
Cost when unaddressed: Every month of pre-launch is a month UDS reports the referral and not the close.
FHIR R4 native white-label tenant in 48 hours
Tenant subdomain configured against an existing FHIR R4 + Vertex AI + AWS pgcrypto stack. Branding, instrument set, PRAPARE item set, resource catchment, and EHR connection provisioned through tenant config — not net-new code. athenahealth runs on a live FHIR R4 connection today; eClinicalWorks integration is in active development; Epic and NextGen are reachable through standard FHIR R4 calls.
BAA chain defensibility under HRSA + HHS oversight
FQHCs sit under HRSA grant oversight and HHS Office for Civil Rights enforcement simultaneously. Under the 2013 HIPAA Omnibus Rule, business associates and their subcontractors are directly liable to the federal government — not just to the covered entity. An FQHC inherits the chain. If a downstream subprocessor cannot show a signed BAA, the health center owns the gap at audit and at site visit.
Cost when unaddressed: An undocumented BAA chain is a tier-4 willful-neglect exposure waiting for a complaint or a HRSA site visit to land.
Executed BAA list published; subprocessor chain documented
Mutual BAA executed on day one. Subprocessor chain (Vertex AI under Google Cloud BAA, AWS under existing BAA, RDS pgcrypto encryption at rest, AWS SES under AWS BAA) published and version-tracked. 45 CFR 164.312 technical safeguards mapped 1:1 to platform controls and re-verified on the weekly HIPAA gate (Wednesday cadence). HRSA-style site-visit packet pre-assembled.
Methodology
How we measure
A "completed loop" is the unit of work. HealthcareCheck counts a referral as closed when all four of the following are recorded against a single FHIR R4 ServiceRequest within thirty days of issue: (a) the ServiceRequest is generated with a named destination organization or practitioner; (b) an electronic acknowledgment is received from that destination, or — when the destination cannot confirm electronically — a documented patient-outreach attempt is recorded by the originating coordinator; (c) a scheduled appointment is written back to the originating record, or a documented disposition is recorded (declined, no-contact, alternative-route); (d) the ServiceRequest status is set to completed, revoked, or entered-in-error within the thirty-day window. Loops that exceed thirty days without disposition are reported as open and excluded from the closed-loop numerator. PHQ-9 follow-up-plan capture follows the CMS eCQM 2 / CMS2v13 convention: a positive screen (score ≥ 10) on a patient twelve or older opens a documented follow-up-plan task on the screen date, which is the artifact the measure numerator requires. PHQ-9 remission is defined per the Kroenke / CMS quality-measure convention as a score below five at six and twelve months; response is defined as a fifty-percent or greater reduction from baseline. PRAPARE SDOH is captured against the federally recognized Healthy People 2030 domains using PRAPARE-derived items and is referable from the same workflow.
What counts
- FHIR R4 ServiceRequest with named destination organization or practitioner
- Electronic acknowledgment from destination or documented patient-outreach attempt
- Scheduled appointment write-back or documented disposition
- Status set within 30 days (completed | revoked | entered-in-error)
- PHQ-9 follow-up plan opened on day of positive screen (CMS eCQM 2 / CMS2v13 numerator)
- PHQ-9 remission flag at < 5 at 6 / 12 months and response flag at ≥ 50% reduction
- PRAPARE-derived SDOH items mapped to the federal Healthy People 2030 domains
What doesn't count
- Verbal-only referrals without a FHIR R4 ServiceRequest record
- Loops without an acknowledgment or a documented outreach attempt
- Loops exceeding 30 days without disposition (reported as open, not closed)
- PHQ-9 captured at intake only with no documented follow-up plan
- Free-text SDOH narratives outside the PRAPARE-derived structured item set
How we compare
Sourced from primary citations — not vendor marketing claims.
| UsHealthcareCheck | vsUnite Us | vsFindhelp | vsCustom build | |
|---|---|---|---|---|
| Time-to-deploy | 48 hours (tenant config against live FHIR R4 stack) | Months (vendor onboarding cycle) | Weeks (network configuration) | 9–18 months (build + HIPAA review) |
| White-label depth | 100% — patient surface, email, SMS, PDF | Co-branded / vendor-prominent | Vendor-branded (Findhelp surfaces directly to patient) | Custom — but rebuilt from zero |
| UDS-aligned referral-completion documentationcite | Native (FHIR R4 + 30-day closure window + UDS-format export) | Network-mediated; depends on partner integration depth | Search + connect; closure depends on partner reporting | Possible — but you build it |
| PRAPARE SDOH workflow (federal-domain-mapped)cite | Native (PRAPARE items + Healthy People 2030 mapping + referral trigger) | Vendor-defined screening; mapping varies | Network-defined screening; mapping varies | Possible — but you build it |
| PHQ-9 + follow-up-plan capture (CMS eCQM 2)cite | Native (cadenced + same-day follow-up-plan trigger + remission flags) | Not the product (referral routing focus) | Not the product (resource directory focus) | Possible — but you build it |
| Community-resource directory (insurance-aware)cite | 691,000+ verified, insurance-aware filtering at point of match | Network-restricted to onboarded partners | Open directory; insurance match varies | Your responsibility to assemble |
| FHIR R4 nativecite | Yes — every artifact is FHIR R4 | Partial / network-dependent | Partial / network-dependent | Possible — but you build it |
| Executed BAA list (subprocessor chain)cite | Published + weekly-verified | Vendor BAA available; subprocessor chain less commonly documented | Vendor BAA available; subprocessor chain less commonly documented | Your responsibility to assemble |
| Patient data ownership / portability | Health center owns; FHIR R4 export on exit; no training | Network-mediated | Directory-mediated | Health center owns (you built it) |
| Built by | LCSW with 14 years across 13 clinical settings — not a tech founder | Tech founder + healthcare advisors | Tech founder + healthcare advisors | Your in-house team |
Frequently asked questions
- How does HealthcareCheck support FQHC UDS reporting?
- HealthcareCheck tracks the full referral lifecycle — not just that the referral was made. Every outbound referral is a FHIR R4 ServiceRequest with electronic acknowledgment, scheduled-appointment write-back, and a status disposition closed within thirty days. Completion data exports in formats aligned with HRSA Uniform Data System referral tracking and is filterable by coordinator, patient panel, resource type, and SDOH domain. The dashboard view is built so the medical director or clinical-quality lead can pull the report on the morning of UDS submission rather than reconstruct it from the EHR encounter notes.
Cited:hrsa-2023-uds-national-rollup, baker-2021-closed-loop-tobacco
- What SDOH framework does HealthcareCheck use for FQHCs?
- PRAPARE-derived items mapped 1:1 to the federally recognized social-determinants domains organized in Healthy People 2030. PRAPARE — the Protocol for Responding to and Assessing Patient Assets, Risks, and Experiences — is the FQHC-purpose-built SDOH instrument developed by the National Association of Community Health Centers, the Oregon Primary Care Association, the Institute for Alternative Futures, and the Robert Graham Center. Items are delivered through the patient app, scored automatically, and routed to matched community resources on a positive answer. Cohort results are visible to the medical director and care-coordination lead and are exportable for HRSA and CMS reporting.
Cited:prapare-2016-validation-nachc, odphp-2030-sdoh-framework, billioux-2017-cms-ahc-screening-tool
- How does the 691K+ community resource database work?
- HealthcareCheck maintains a verified database of more than six-hundred-and-ninety-one-thousand community resources. When a patient screens positive for an SDOH domain or for depression requiring a follow-up plan, the platform identifies resources that accept the patient's insurance, sit within the patient's geographic catchment, and match the specific need triggered by the screen. Vertex AI under the Google Cloud BAA drafts the outreach in plain prose for the coordinator to review and send — PHI is sanitized before any AI call and no record is used to train any model. Resources are version-controlled and re-verified on rolling cadence; the provenance per resource is visible in the coordinator workflow.
- Does HealthcareCheck integrate with FQHC EHR systems?
- Yes. HealthcareCheck runs a native FHIR R4 integration with athenahealth live today and is adding eClinicalWorks integration in active development. The platform is EHR-agnostic by design — the patient-navigation layer sits on top of the chart of record, not in place of it. FQHCs running Epic, NextGen, or any other EHR with a FHIR R4 endpoint are reachable through standard FHIR R4 calls; bespoke integrations beyond the FHIR R4 baseline are scoped separately and measured in weeks rather than months. The forty-eight-hour deploy assumes the BAA is executed on day one and a designated clinic admin is available for the configuration call.
Cited:hl7-fhir-r4-2019
- Who owns the patient data?
- The health center owns the patient data. HealthcareCheck is a processor under the BAA, not a data owner. A tenant can export every record in FHIR R4 on exit — that is contractual and is part of the mutual BAA. No de-identified data is sold downstream and no patient record is used to train any model. Vertex AI runs under the existing Google Cloud BAA with no-training settings enforced at the project level. The patient-facing app is one-hundred-percent white-label so the patient relationship belongs to the health center, not to the vendor. If the relationship ends, the patient record leaves with the health center in a portable, structured format on a documented timeline.
Cited:hhs-2013-omnibus-rule-baa-requirements, hl7-fhir-r4-2019
- BAA execution path?
- Mutual BAA executed on day one. The subprocessor chain is published: Google Cloud (Vertex AI) under the Google Cloud BAA with no-training enforced at the project level; AWS (compute, RDS PostgreSQL with pgcrypto encryption at rest, SES for transactional email) under the existing AWS BAA; CloudWatch and S3 for log retention under that same BAA. The 45 CFR 164.312 technical safeguards (access control, audit controls, integrity, person-or-entity authentication, transmission security) map one-to-one to platform controls and are re-verified on the weekly HIPAA gate every Wednesday. No subprocessor is added without a signed BAA in place. The BAA list is publicly maintained on the compliance page so the health center's compliance lead can verify the chain without an email thread — and so the HRSA site-visit packet is pre-assembled.
Cited:hhs-2013-omnibus-rule-baa-requirements, hhs-45-cfr-164-312-technical-safeguards
Why this exists
Patient navigation should be infrastructure an FQHC owns — not a vendor relationship that holds the health center's referral data hostage.
I am a Licensed Clinical Social Worker. Fourteen years across thirteen clinical settings — community mental health, forensic ACT, substance-abuse treatment, dialysis social work, private practice. I have written the SDOH note that nobody read and I have run the PHQ-9 that never had a follow-up plan opened on it. I have made the warm-handoff phone call from a county clinic on a Friday afternoon and I have watched the chart sit untouched for thirty-five days.
I built HealthcareCheck because every FQHC I have walked through tries to solve patient navigation the same two ways and both lose. Build it yourself: nine to eighteen months and a payroll line you cannot defend at the grant cycle. Buy a directory tool: thirty days later your referral data is somebody else's product and your patient is staring at somebody else's logo where the health-center brand should have been.
The closed loop is the unit of work. UDS reads the loop. The grant reviewer reads the loop. The site visit reads the loop. We measure the loop, we publish the BAA chain that protects it, and we hand the health center a tenant they own. Patient navigation should be infrastructure an FQHC owns — not a vendor relationship that holds the health center's referral data hostage. That is the entire pitch.
Matthew Sexton, LCSWFounder · Mental Wealth Solutions Inc.
Citations
baker-2021-closed-loop-tobaccoSeecitations/baker-2021-closed-loop-tobacco.mdxfor primary source, DOI/PMID, and key statistics.kroenke-2001-phq9-validationSeecitations/kroenke-2001-phq9-validation.mdxfor primary source, DOI/PMID, and key statistics.archer-2012-cochrane-collaborative-care-metaSeecitations/archer-2012-cochrane-collaborative-care-meta.mdxfor primary source, DOI/PMID, and key statistics.prapare-2016-validation-nachcSeecitations/prapare-2016-validation-nachc.mdxfor primary source, DOI/PMID, and key statistics.billioux-2017-cms-ahc-screening-toolSeecitations/billioux-2017-cms-ahc-screening-tool.mdxfor primary source, DOI/PMID, and key statistics.odphp-2030-sdoh-frameworkSeecitations/odphp-2030-sdoh-framework.mdxfor primary source, DOI/PMID, and key statistics.stille-2010-care-coordination-timeSeecitations/stille-2010-care-coordination-time.mdxfor primary source, DOI/PMID, and key statistics.hrsa-2023-uds-national-rollupSeecitations/hrsa-2023-uds-national-rollup.mdxfor primary source, DOI/PMID, and key statistics.hrsa-2023-uds-manual-tablesSeecitations/hrsa-2023-uds-manual-tables.mdxfor primary source, DOI/PMID, and key statistics.cms-2024-ecqm-2-depression-followupSeecitations/cms-2024-ecqm-2-depression-followup.mdxfor primary source, DOI/PMID, and key statistics.hl7-fhir-r4-2019Seecitations/hl7-fhir-r4-2019.mdxfor primary source, DOI/PMID, and key statistics.hhs-2013-omnibus-rule-baa-requirementsSeecitations/hhs-2013-omnibus-rule-baa-requirements.mdxfor primary source, DOI/PMID, and key statistics.hhs-45-cfr-164-312-technical-safeguardsSeecitations/hhs-45-cfr-164-312-technical-safeguards.mdxfor primary source, DOI/PMID, and key statistics.ocr-2024-hipaa-enforcement-statisticsSeecitations/ocr-2024-hipaa-enforcement-statistics.mdxfor primary source, DOI/PMID, and key statistics.katon-2010-team-care-diabetes-depression-nejmSeecitations/katon-2010-team-care-diabetes-depression-nejm.mdxfor primary source, DOI/PMID, and key statistics.unutzer-2002-impact-collaborative-care-trialSeecitations/unutzer-2002-impact-collaborative-care-trial.mdxfor primary source, DOI/PMID, and key statistics.gottlieb-2017-sdoh-screening-pediatricsSeecitations/gottlieb-2017-sdoh-screening-pediatrics.mdxfor primary source, DOI/PMID, and key statistics.