Your brand. Your patients. Our infrastructure. White-label tenant live in 48 hours.
Multi-tenant patient navigation: 100% white-label, FHIR R4 native, executed BAA chain, configurable clinical assessments, AI clinical insights under BAA. Built by a clinician, run as infrastructure.
Where the pathway breaks — and how we close it
Time-to-deploy for new patient-navigation software
Building patient navigation from scratch runs nine to eighteen months — a year of clinic payroll burned on integration, branding, and HIPAA review before the first patient is screened. Off-the-shelf tools deploy faster but ship lock-in, surrender the patient brand, and hold the referral data hostage on exit.
Cost when unaddressed: Every month of pre-launch is a month the clinic cannot report on closed-loop referral or measurement-based depression care.
Multi-tenant white-label deploy in 48 hours
A new tenant is a row in the database, a brand-skin configuration, an instrument set, an SDOH item set, a resource catalog, and an executed BAA — not a code build. The platform runs on a single FHIR R4 + Vertex AI + AWS pgcrypto stack. Tenants share infrastructure; data stays scoped to the tenant.
Vendor branding on the patient surface
Patient-engagement vendors typically ship a vendor-branded app. The patient relationship is mediated through a logo the clinic does not own. The data the patient generates is held in a system the clinic cannot export from on exit. The clinic carries the trust burden; the vendor carries the brand equity.
Cost when unaddressed: When patients meet a vendor logo first, every clinical interaction routes through somebody else's name.
100% white-label tenant — patient surface, email, SMS, PDF
The patient-facing app, every email, every SMS, and every PDF export carry the clinic's logo, color palette, copy, and domain. HealthcareCheck does not appear on the patient surface. Enterprise tenants ship to a custom domain and a separate App Store listing. Data is portable on day one — FHIR R4 export of the entire tenant on exit is contractual.
EHR integration burden for navigation tools
Patient-navigation software that does not speak the EHR's native language forces the clinic to choose between double-charting (write everything twice), data fragmentation (live in two systems), or full EHR replacement (a six- to eighteen-month project nobody wants). HL7 FHIR R4 is the federally adopted standard for healthcare interoperability — the standard most navigation tools claim and few implement natively.
Cost when unaddressed: Without native FHIR R4, the navigation system becomes a parallel chart that the EHR never sees and the clinical workflow never trusts.
FHIR R4 native — write-back to the EHR of record
Every clinical artifact in the platform — ServiceRequest for referrals, Observation for assessment scores, Communication for secure messaging, Patient for demographics — is FHIR R4 first. The athenahealth bridge is live today. eClinicalWorks is in active development. Epic, Oracle Health (Cerner), and other EHRs reach through standard FHIR R4 connections. The EHR remains the chart of record; HealthcareCheck is the navigation layer on top.
BAA chain defensibility under HIPAA
Under the 2013 HIPAA Omnibus Rule, business associates and their subcontractors are directly liable to the federal government — not just to the covered entity. A clinic inherits the chain. If a downstream subprocessor cannot show a signed BAA, the clinic owns the gap at audit. The HHS Office for Civil Rights enforcement record runs into the millions per identical violation per year.
Cost when unaddressed: An undocumented BAA chain is a tier-4 willful-neglect exposure waiting for a complaint to land.
Executed BAA list published; subprocessor chain version-tracked
Mutual BAA executed on day one. The subprocessor chain is published and version-tracked: 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, CloudWatch and S3 for log retention — all under the existing AWS BAA). 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.
Closed-loop referral completion across organizations
Patient referrals from one organization to another rarely close. Behavioral-health and social-needs referrals routed through community-based organizations almost never produce a recorded outcome back to the originating clinic. The loop stays open in everyone's chart. Quality-measure denominators count only what is documented — and an open loop is undocumented.
Cost when unaddressed: Every open loop is a quality measure that does not earn, a patient who may not have arrived, and a coordinator hour spent chasing fax confirmations.
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 30 days — or a documented patient-outreach attempt if the destination cannot confirm. Coordinators see open loops in a single dashboard scoped to the tenant.
One-size-fits-all clinical assessment instruments
Generic patient-engagement platforms ship a fixed instrument set built for the broadest possible market — usually a baseline depression screener and a single satisfaction survey. Specialty programs — CCBHCs, FQHCs, dialysis centers, transplant programs — need instruments scoped to their patient population, regulatory environment, and quality-measure reporting. Free-text screening cannot be aggregated and cannot be matched to a referral pathway.
Cost when unaddressed: An off-the-shelf instrument set is a checkbox. A configured instrument set is the quality-measure denominator.
Configurable instrument library — PHQ-9, C-SSRS, KDQOL-36, PRAPARE, custom
The platform ships a validated instrument library — PHQ-9 for depression, GAD-7 for anxiety, C-SSRS for suicide risk, KDQOL-36 for dialysis quality of life, Zarit for caregiver burden, PRAPARE-derived items mapped to the five Healthy People 2030 SDOH domains. Tenants can add custom assessments through tenant config. Scoring runs automatically; a positive C-SSRS routes to a same-shift safety-plan task with documented 24–72-hour and 7–14-day follow-up callbacks per the Stanley / Brown safety-planning intervention.
AI clinical tooling outside the BAA perimeter
Most consumer LLM endpoints train on submitted prompts by default. A clinician who pastes a session note into a public AI tool is exporting protected health information outside the BAA perimeter — a HIPAA breach event without a paper trail. Specialty programs need AI that lives inside the same BAA chain as the rest of the clinical stack.
Cost when unaddressed: An AI tool outside the BAA chain is a HIPAA breach event one paste away from a complaint.
Vertex AI clinical insights under executed Google Cloud BAA
Population-level pattern surfacing runs through Google Vertex AI under the existing Google Cloud BAA with no-training settings enforced at the project level. The model surfaces patterns in patient engagement, referral completion, and clinical risk that a coordinator would not have bandwidth to catch manually. No record is used to train any model. No de-identified data is sold downstream. Vendor-managed model updates are part of the platform — clinics do not run the AI infrastructure themselves.
Methodology
How we measure
The platform measures four units of work simultaneously and ships them as published metrics. (1) Closed-loop referral completion: a referral counts as closed when a FHIR R4 ServiceRequest is issued to a named destination, an electronic acknowledgment or documented outreach attempt is recorded, a scheduled appointment is written back or a documented disposition is captured, and the status is set within thirty days. Loops that exceed thirty days without disposition are reported as open and excluded from the closed-loop numerator. (2) Measurement-based depression care: 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. (3) Suicide-risk capture: C-SSRS is delivered through the patient surface, scored automatically, and routed by severity. A positive ideation-with-method or behavior answer triggers a same-shift safety-plan task with documented twenty-four-to-seventy-two-hour and seven-to-fourteen-day follow-up callbacks per the Stanley / Brown safety-planning intervention. (4) BAA chain: subprocessor list is published and version-tracked; 45 CFR 164.312 technical safeguards (access control, audit controls, integrity, authentication, transmission security) map one-to-one to platform controls and are re-verified on the weekly Wednesday HIPAA gate. Every clinical artifact — ServiceRequest, Observation, Communication, Patient — is FHIR R4 first.
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
- ServiceRequest status set within 30 days (completed | revoked | entered-in-error)
- PHQ-9 remission flag at < 5 at 6 / 12 months; response flag at ≥ 50% reduction
- C-SSRS positive answer triggers same-shift safety-plan task with cadenced callbacks
- Subprocessor in BAA chain with executed BAA on file
- 45 CFR 164.312 technical safeguards mapped 1:1 to platform controls and weekly-verified
What doesn't count
- Verbal-only referrals without a FHIR R4 ServiceRequest record
- Loops without acknowledgment or documented outreach attempt
- Loops exceeding 30 days without disposition (reported as open, not closed)
- PHQ-9 captured at intake only with no follow-up measurement
- C-SSRS captured without structured score and severity routing
- AI endpoints outside the BAA chain (consumer LLMs, training-opt-in defaults)
- Subprocessors without a signed BAA — not added to the chain
How we compare
Sourced from primary citations — not vendor marketing claims.
| UsHealthcareCheck | vsSalesforce Health Cloud | vsGeneric CRM with HIPAA bolted on | vsCustom in-house build | |
|---|---|---|---|---|
| Time-to-deploycite | 48 hours (tenant config against live FHIR R4 stack) | Months to a year (statement-of-work + admin onboarding) | Months (vendor onboarding + HIPAA review) | 9–18 months (build + HIPAA review) |
| Annual cost (entry-level) | Scoped per tenant; non-profit and FQHC discount | $150,000 – $400,000+ per year (industry list pricing) | Variable + custom HIPAA build cost | Engineering payroll for 9–18 months + ongoing maintenance |
| White-label depth on patient surface | 100% — patient app, email, SMS, PDF | Co-branded; vendor-mediated | Often vendor-prominent | Custom — but rebuilt from zero |
| FHIR R4 nativecite | Yes — every artifact is FHIR R4 | FHIR support exists; configuration-heavy | Bolted-on or absent | Possible — but you build it |
| Closed-loop referral measurementcite | FHIR R4 ServiceRequest + 30-day closure window | Possible — but configured per implementation | Not the product | Possible — but you build it |
| Clinical assessment library (PHQ-9, C-SSRS, KDQOL-36, PRAPARE)cite | Native + cadenced + remission flags + safety-plan trigger | Configurable — but built per tenant | Bolted-on | Possible — but you build it |
| Executed BAA list (subprocessor chain)cite | Published + weekly Wednesday gate | BAA available; subprocessor chain less commonly published | BAA inconsistent across vendors | Your responsibility to assemble |
| AI clinical insights under BAAcite | Vertex AI under Google Cloud BAA + no-training | AI features sold separately; BAA scope per add-on | AI bolt-ons frequently outside BAA perimeter | You ship the AI compliance layer yourself |
| Patient data ownership / portability | Clinic owns; FHIR R4 export on exit; no training | Vendor-mediated; export per contract | Variable | Clinic owns (you built it) |
| Built by | LCSW with 14 years across 13 clinical settings | Tech founder + healthcare advisors | Tech founder + healthcare advisors | Your in-house team |
Frequently asked questions
- What is HealthcareCheck's platform?
- HealthcareCheck is a multi-tenant, white-label patient-navigation platform for behavioral health and specialty-care organizations. Each tenant — a CCBHC, FQHC, dialysis center, transplant program, or VA-affiliated behavioral-health program — runs on its own subdomain or vanity domain with its own brand, instrument set, SDOH item set, and resource catalog. The infrastructure underneath is shared: a single FHIR R4 + Google Vertex AI + AWS pgcrypto stack with executed Business Associate Agreements at every layer. The clinical core ships closed-loop referral measurement, configurable assessments (PHQ-9, C-SSRS, KDQOL-36, PRAPARE-derived SDOH), HIPAA- compliant messaging, population analytics, and AI clinical insights under the same BAA chain. The patient sees the clinic's brand only.
Cited:hl7-fhir-r4-2019
- How fast can a tenant go live?
- Forty-eight hours to a live tenant subdomain in the standard configuration. The platform is FHIR R4 native against an already-running stack, so a new tenant is a configuration job — branding, instrument set, SDOH item set, resource catalog, BAA execution — not a code-build job. The forty-eight-hour clock assumes the BAA is executed day one and a designated tenant admin is available for the configuration call. Custom EHR integrations beyond the FHIR R4 baseline (athenahealth lives today; Epic, Oracle Health Cerner, eClinicalWorks, and others are reachable through standard FHIR R4 connections) are scoped separately and measured in weeks, not months. Multi-site enterprise rollouts run a separate timeline with a custom statement of work.
Cited:hl7-fhir-r4-2019
- How does the white-label model work?
- Each tenant gets a fully branded patient-navigation app at the tenant's subdomain (yourclinic.healthcarecheck.org) or a custom domain (yourclinic.org or app.yourclinic.org). The patient-facing app displays the tenant's name, logo, and color palette. Every email, SMS, and PDF export carries the tenant's brand. HealthcareCheck does not appear on the patient surface. Enterprise tenants ship to a separate App Store listing under the tenant's developer account. New tenant configuration is a row in the database and a brand-skin configuration — not a new codebase. Patient data is portable on day one: FHIR R4 export of the entire tenant on exit is contractual and is part of the mutual BAA.
Cited:hl7-fhir-r4-2019
- Is the platform HIPAA compliant?
- Yes. HIPAA compliance is the baseline infrastructure requirement, not an add-on tier. 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, CloudWatch and S3 for log retention — all under the existing AWS BAA). 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 Wednesday HIPAA gate. The HHS Office for Civil Rights enforcement record sits at the back of the design — tier-4 willful- neglect civil monetary penalties run from one-hundred-thirty-seven dollars to two-million-sixty- seven-thousand dollars per identical violation per year, inflation-adjusted.
Cited:hhs-2013-omnibus-rule-baa-requirements, hhs-45-cfr-164-312-technical-safeguards, ocr-2024-hipaa-enforcement-statistics
- Does the platform integrate with EHRs?
- Yes — natively, through HL7 FHIR R4. Every clinical artifact in the platform — ServiceRequest for referrals, Observation for assessment scores, Communication for secure messaging, Patient for demographics — is FHIR R4 first. The athenahealth bridge is live on the platform today. eClinicalWorks integration is in active development. Epic and Oracle Health (Cerner) are reachable through standard FHIR R4 connections; tenants on those EHRs scope a custom integration in the discovery call. The platform is EHR-agnostic by design — it adds a navigation and engagement layer on top of the existing EHR without requiring replacement. The EHR remains the chart of record. HealthcareCheck writes structured data back through FHIR R4 so coordinators do not double-chart.
Cited:hl7-fhir-r4-2019
- How is the AI tooling kept inside the BAA perimeter?
- Population-level pattern surfacing runs through Google Vertex AI under the existing Google Cloud Business Associate Agreement. No-training is enforced at the project level — submitted patient data is not used to train any Google model and is not retained outside the tenant's scope. Vertex AI sits inside the same BAA chain as the rest of the clinical stack: AWS for compute, RDS PostgreSQL with pgcrypto encryption at rest, AWS SES for transactional email, all under the existing AWS BAA. No clinician ever pastes a session note into a public consumer LLM endpoint through the platform — that is by design, not by policy alone. The HIPAA-eligible service list is part of the published subprocessor chain and is re-verified on the weekly Wednesday gate.
Cited:google-cloud-2024-vertex-ai-baa, hhs-2013-omnibus-rule-baa-requirements
- Who owns the patient data?
- The clinic 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. No patient record is used to train any model. The patient-facing app is one-hundred-percent white-label so the patient relationship belongs to the clinic, not to the vendor. If the relationship ends, the patient record leaves with the clinic in a portable structured format on a documented timeline.
Cited:hhs-2013-omnibus-rule-baa-requirements, hl7-fhir-r4-2019
Why this exists
Multi-tenant is not a deployment trick. It is the only way one LCSW can keep ten clinics audit-ready on the same Wednesday.
I am a Licensed Clinical Social Worker. Fourteen years across thirteen clinical settings — community mental health, forensic ACT, substance-abuse treatment, dialysis social work, transplant coordination, private practice. I have been the coordinator on the receiving end of the broken referral and the clinician on the sending end. I have written the safety plan at 4:47 PM on a Friday and I have watched the chart sit untouched for thirty-five days.
Patient-navigation infrastructure is what every program I have walked through tries to solve the same two ways and both lose. Build it yourself: nine to eighteen months and a payroll line nobody can defend to the board. Buy a directory tool: thirty days later your patient is staring at somebody else's logo and your referral data is somebody else's product. The platform exists because clinics deserve a third option — the same operational surface your existing EHR already trusts, scoped to your patients, branded as yours, and shippable in forty-eight hours under a BAA you can hand to compliance without a footnote.
Multi-tenant is not a deployment trick. It is the only way one LCSW can keep ten clinics audit-ready on the same Wednesday. White-label is not a marketing checkbox. It is the only way the patient relationship stays in the clinic's hands. Every clinical artifact is FHIR R4 because the EHR has to remain the chart of record. Every subprocessor sits inside a published BAA because the alternative is a tier-four exposure waiting for a complaint to land. 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.posner-2011-cssrs-validationSeecitations/posner-2011-cssrs-validation.mdxfor primary source, DOI/PMID, and key statistics.stanley-2018-safety-planning-ed-cohortSeecitations/stanley-2018-safety-planning-ed-cohort.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.odphp-2030-sdoh-frameworkSeecitations/odphp-2030-sdoh-framework.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.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.google-cloud-2024-vertex-ai-baaSeecitations/google-cloud-2024-vertex-ai-baa.mdxfor primary source, DOI/PMID, and key statistics.irani-2020-closed-loop-radiologySeecitations/irani-2020-closed-loop-radiology.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.madras-2009-sbirt-multi-site-samhsaSeecitations/madras-2009-sbirt-multi-site-samhsa.mdxfor primary source, DOI/PMID, and key statistics.betz-2020-lock-to-live-lethal-means-rctSeecitations/betz-2020-lock-to-live-lethal-means-rct.mdxfor primary source, DOI/PMID, and key statistics.costantini-2021-phq9-systematic-reviewSeecitations/costantini-2021-phq9-systematic-review.mdxfor primary source, DOI/PMID, and key statistics.