HealthcareCheck

48 hours from BAA signature to patient enrollment — under your brand, on your subdomain.

Care coordination platform vendors quote 6-9 months. We measure deploy time in business hours and publish every step in a timestamped deploy log surfaced to the tenant's compliance officer on request. Executed BAA chain across Vertex AI, AWS, and RDS pgcrypto. FHIR R4 native interoperability. White-label by default, not by upcharge — your patients see your brand, not ours.

Where the pathway breaks — and how we close it

6-9 month deploy norm

Care coordination platform vendors typically quote 6-9 months from contract to first patient enrollment. KLAS Research summaries of CCBHC/FQHC implementations consistently show timelines compounded by serialized legal review, sequential infrastructure stand-up, branding upcharge cycles, and integration work treated as gating rather than parallelizable. The pattern is the same across vendor categories — 30-90 days for BAA execution, 30-60 days for environment provisioning, 60-90 days for branding configuration in enterprise tiers, and 60-120 days for clinical instrument encoding and resource directory verification. Each phase waits on the previous because the vendor architecture treats them as sequential. Clinical directors absorb the timeline as inevitable. It is not.

6-9 monthsIndustry deploy timeline (contract to first enrollment)cite

Cost when unaddressed: Months of clinical opportunity cost — patients fall between systems while a tenant waits for its branded portal to come online.

48-hour parallelized deploy

BAA red-line, discovery scoping, branding configuration, DNS provisioning, tenant database instantiation, admin onboarding, and patient enrollment readiness run in parallel — not sequence. Multi-tenant architecture means schema-per-tenant provisioning is a configuration step, not a build. The instrument library is pre-validated. The community resource directory is pre-verified. The sub-vendor BAA chain is pre-executed. The 48-hour clock is what is left when bundled-but-parallelizable work stops blocking itself.

48 hoursBAA signature to first patient enrollment trackablecite
Before6-9 monthsVendor norm — contract to livecite
After48 hoursHealthcareCheck — BAA to live tenant
Impact on 6-9 month deploy normMethodology →

Vendor branding lock-in

Incumbent care-coordination platforms surface vendor branding to patients by default. White-labeling is gated behind enterprise tier upcharges or post-launch phase work. Care coordinators field patient questions about a vendor logo they do not recognize while trying to drive completion of a referral the patient is already ambivalent about. The trust hit compounds because the patient experiences the platform as a third-party intermediary rather than as an extension of the clinic they already trust. Brand mismatch on the patient screen reads as institutional confusion, and institutional confusion in behavioral health surfaces as drop-off — measured in completed appointments that never happen.

Upcharge or post-launchWhen white-label becomes available with incumbent vendorscite

Cost when unaddressed: Patient trust hits whenever the brand on the screen does not match the clinic the patient just walked out of.

100% white-label by default

Logo, brand palette, body copy, custom subdomain (tenantname.healthcarecheck.org), and vanity domain support land in the standard deploy at no upcharge. Patient-facing app reflects the tenant clinic's brand at first patient impression — not the platform vendor's. The configuration surface covers logo asset, accent color, secondary palette, header copy, footer copy, login screen treatment, email-from name and address, push-notification sender label, and SMS sender ID. Brand presence is consistent at every patient touchpoint because it is the same tenant configuration object rendered everywhere — there is no place in the application where the platform vendor's brand bleeds through by default.

0 upchargesWhite-label is the default deploy mode, not a paid tier
BeforeUpcharge gatedIndustry default — branding behind paywallcite
AfterDefault deployWhite-label included in every tenant
Impact on vendor branding lock-in

30-90 day BAA legal back-and-forth

HHS Omnibus Rule (2013) made the Business Associate Agreement contractually binding for any vendor handling PHI on a covered entity's behalf. In practice the BAA execution timeline averages 30-90 days because incumbent vendors treat each red-line as a bespoke negotiation rather than a published-and-versioned legal artifact. HIMSS surveys confirm BAA legal cycle time is the single largest non-technical deploy delay.

30-90 daysAverage BAA execution timeline (HIMSS survey)cite

Cost when unaddressed: Legal-team capacity gets consumed by line-by-line PHI clause negotiation that should be a one-time platform-wide agreement.

Published BAA + 48-hour red-line turnaround

Standard BAA boilerplate published as a starting point — not a take-it-or-leave-it. Common red-lines (notification timelines, indemnification scope, audit rights) accepted and turned around inside 48 hours. Sub-vendor BAA chain (AWS, Google Cloud Vertex AI, Amazon RDS) executed and inventoried publicly on the security page.

<48 hoursBAA red-line turnaround vs. 30-90 day industry normcite
Before30-90 daysIndustry BAA executioncite
After<48 hoursHealthcareCheck red-line turnaround
Impact on 30-90 day baa legal back-and-forth

Build-your-own validated instrument library

Custom-build paths require clinical engineering teams to encode each validated assessment instrument (PHQ-9, C-SSRS, KDQOL-36, Zarit Burden, ISEL-12, WEMWBS, PRAPARE 10-domain SDOH) from primary literature, validate scoring logic, and re-test on every release. This is months of work duplicated across every tenant build. Each instrument has its own validation chain, its own scoring brackets, its own branching logic, and its own published primary-source citation. C-SSRS branches differ across pediatric, adolescent, and adult versions. PHQ-9 scoring has a discrete suicidality flag that triggers escalation logic. KDQOL-36 has CMS-mandated reporting brackets specific to dialysis. Replicating this work tenant-side is engineering cost without engineering value.

3-6 monthsTypical custom instrument library encode + validate cyclecite

Cost when unaddressed: Clinical-engineering hours that should be spent on workflow design instead get burned on PHQ-9 scoring brackets and C-SSRS branching logic.

Pre-built instrument library, validated, configurable

PHQ-9 (Kroenke 2001), C-SSRS (Posner 2011), KDQOL-36 (CMS-required dialysis), Zarit Burden (caregiver), ISEL-12 (social isolation), WEMWBS (mental wellbeing), and PRAPARE 10-domain SDOH ship in the platform — validated against primary literature, configurable per population, scoring logic locked.

Day 1Validated instrument library available at tenant provisioningcite
Before3-6 monthsCustom-build instrument encode cyclecite
AfterDay 1Pre-built, configurable, validation-traceablecite
Impact on build-your-own validated instrument library

Build-your-own community resource directory

Closed-loop SDOH workflows require a verified, insurance-aware community resource directory. ODPHP's Healthy People 2030 SDOH framework calls for measurable community-resource matching, but each tenant build typically restarts directory verification from zero because resource state (open hours, eligibility rules, capacity, accepted insurance) drifts weekly. A community resource that closed three months ago looks identical in a stale directory to one that just doubled its capacity — and the care coordinator only finds out which is which when the patient calls back to say the referral did not work. The directory verification problem is a labor problem, not an architecture problem, and labor has to be amortized across many tenants to be sustainable.

Build from scratchIndustry default — tenant builds resource directory tenant-sidecite

Cost when unaddressed: Care coordinators send referrals into resources that closed last quarter, hit capacity caps, or never accepted the patient's insurance.

691,000+ verified, insurance-aware resources

Pre-built directory with weekly verification cadence, insurance-aware filtering, and geographic coverage scoping configured during deploy. Tenants scope their service area; we scope the data layer. Verification cadence captures hours, eligibility rules, capacity caps, accepted insurance plans, and intake-language coverage. Insurance-aware filtering means a care coordinator searching for a behavioral-health provider does not see a result that does not accept the patient's plan — the directory pre-filters the noise before it reaches the coordinator.

691,000+Verified community resources at tenant deploycite
Before0 recordsCustom-build starts emptycite
After691K recordsPre-verified, insurance-aware, geo-scoped
Impact on build-your-own community resource directory

Verbal BAA chain assertions

OCR's 2024 HIPAA enforcement statistics show that the majority of finalized covered-entity penalties trace to gaps in business associate documentation — not encryption failures. Many vendors verbally assert subprocessor BAA coverage (AWS, cloud AI, database hosting) without publishing the executed chain. When OCR audits the covered entity, the covered entity is on the hook to produce sub-vendor BAAs even though the platform vendor was the one who selected those subprocessors. Compliance officers then spend audit cycles reconstructing chains that should have been published once and dated. The risk surface is documentation, not technology — but the documentation gap is what triggers the finding.

Verbal assertionsIndustry default — sub-vendor BAA chain unpublishedcite

Cost when unaddressed: Compliance team has to reconstruct the BAA chain themselves from vendor security questionnaires that are months stale.

Published, executed, dated BAA chain

AWS BAA (executed 2013), Google Cloud Vertex AI BAA (executed 2024), Amazon RDS PostgreSQL pgcrypto. Compliance posture documented at /compliance — your security officer verifies coverage in minutes, not weeks.

PublishedSub-vendor BAA inventory documented on the security pagecite
BeforeVerbalIndustry default — chain unpublishedcite
AfterPublishedInventoried, executed, datedcite
Impact on verbal baa chain assertions

Ticket-queue L1/L2/L3 escalation tree

Incumbent care-coordination vendors route post-deploy clinical questions through tier-1 generalist support, escalate to tier-2 implementation specialists, and only reach the engineering team via tier-3 after multi-day SLAs. Clinical directors cannot afford that latency on a workflow question that is blocking a discharge. The escalation tree exists because the vendor needs to gate engineering capacity, not because clinicians need to talk to non-engineers first. The cost is borne by the clinical director who waits two business days for a tier-3 callback to confirm whether a workflow change is feasible. Pilot decisions get made on the basis of what the vendor support tier can answer, not what the platform can do.

Multi-day SLAsAverage escalation cycle for clinical workflow questionscite

Cost when unaddressed: Ticket queue cycle time becomes the rate-limiter on every workflow change a clinical director wants to make post-deploy.

Founder-on-call, no L1/L2/L3 tree

The founder is on the discovery call. The founder is on the post-launch debug call. There is no tier-1 generalist support layer. Clinical directors and care coordinators have direct access to the engineer who can change the platform.

Same-dayWorkflow change request to platform deploy
BeforeMulti-dayIndustry default — L1/L2/L3 escalationcite
AfterSame-dayFounder-direct workflow change
Impact on ticket-queue l1/l2/l3 escalation tree

Pilot exit lock-in

Standard health-IT contracts include multi-year minimums and data-export gates. Tenants who try a vendor for one pilot end up locked into a three-year contract with referral data treated as the vendor's product rather than the clinic's. Exit terms typically require advance notice, written cause, and proprietary-format export through a paid services engagement. The result is that clinical leadership avoids piloting promising tools because exit cost is non-trivial — and the tools that win are not necessarily the tools that perform best, but the ones that lock in the fastest. Standard-format export and no-minimum contract structure flip the incentive: the platform earns the contract every month or it loses it.

Multi-year minimumsIndustry default — pilot exit costcite

Cost when unaddressed: Clinical leadership avoids piloting promising tools because exit cost is non-trivial.

No lock-in. Tenant export on request.

No multi-year contract minimum. Tenant data export available on request in standard formats — CSV for tabular data, FHIR R4 (HL7 2019) for clinical data. The platform earns its keep month over month.

FHIR R4Standard-format export, no proprietary lock-incite
BeforeMulti-yearIndustry contract minimumscite
AfterMonth-over-monthNo lock-in, standard-format export
Impact on pilot exit lock-in

Methodology

How we measure

The 48-hour clock is wall-clock time, business hours, measured from BAA countersignature to first patient enrollment trackable on the tenant's branded subdomain. The clock excludes the discovery call (typically a same-week 30-minute scope) and excludes any custom EHR integration scoping (which runs in parallel and ships when end-to-end verified, not as a deploy gate). The clock includes everything that historically blocks first patient enrollment — branding configuration, DNS provisioning, tenant schema instantiation, instrument library activation, resource directory geo-scoping, admin onboarding, and audit-log start. Each milestone is timestamped in our deploy log and surfaced to the tenant's compliance officer on request, which means the 48-hour figure is not a marketing approximation — it is a measured median across deploys.

What counts

  • BAA red-line cycle — turnaround inside 48 hours for typical legal-team revisions to notification timelines, indemnification scope, and audit rights.
  • Branding configuration — logo, brand palette, body copy, custom subdomain or vanity domain DNS provisioning, SSL auto-issuance.
  • Tenant provisioning — schema instantiation under multi-tenant isolation, KMS-managed encryption keys, instrument library configured for the population.
  • Resource directory geographic-coverage scoping — 691,000+ verified records filtered to the service area.
  • Admin onboarding — care coordinator and clinical director account provisioning, 30-minute live walkthrough of dashboard, referral pipeline, instrument capture surface, and quality-measure reporting export.
  • Closed-loop referral pipeline activation, quality-measure capture turn-on, and audit-log start under the tenant-specific KMS key boundary.
  • Patient-portal smoke test against a non-PHI synthetic enrollment record to confirm end-to-end branding rendering, DNS routing, SSL handshake, login flow, instrument capture, and referral pipeline behave correctly under the tenant's specific configuration before the first real patient lands.

What doesn't count

  • Discovery-call scheduling time (separate from the 48-hour clock — typically a same-week 30-minute slot).
  • Custom EHR integration timelines (Epic, Cerner, NextGen) — these run in parallel post-deploy and ship when verified end-to-end.
  • Tenant-side change-management work (clinical workflow redesign, coordinator re-training) outside the platform.
  • Patient enrollment volume itself — the clock measures readiness for first enrollment, not the patient acquisition curve afterward.

How we compare

Sourced from primary citations — not vendor marketing claims.

UsHealthcareCheckvsUnite UsvsFindhelpvs9-month custom build
Time-to-deploy (standard)cite48 hours3-6 months2-4 months9+ months
BAA execution turnaroundcite<48 hrs red-line30-60 days30-60 days60-120 days
White-label brandingciteDefaultEnterprise tier upchargeLimitedCustom build
Validated instrument librarycitePHQ-9 + C-SSRS + KDQOL-36 + Zarit + ISEL-12 + WEMWBS + PRAPAREConfigurable formsSDOH onlyBuild-from-scratch
Community resource directorycite691K verified, insurance-awareNetwork resourcesPublic directoryBuild-from-scratch
Sub-vendor BAA chaincitePublished + datedVerbalVerbalTenant builds
Support escalation pathciteFounder-directL1 → L2 → L3 ticket queueL1 → L2 → L3 ticket queueInternal team
Pilot exit costciteNo lock-in, FHIR R4 exportMulti-year minimumMulti-year minimumSunk cost

Frequently asked questions

Is 48 hours actually realistic for a white-label deploy?
Yes — for the standard deploy. The 48-hour clock starts after the BAA is countersigned and the discovery call is complete. KLAS Research summaries of care-coordination implementations show 6-9 months as the industry norm because incumbents bundle work that does not need to be sequential. We have parallelized BAA red-line, branding configuration, DNS provisioning, tenant schema instantiation, and admin onboarding. Custom EHR integrations (Epic, Cerner, NextGen) add scoping time but are measured in weeks and run in parallel — they do not gate first patient enrollment.

Cited:klas-2023-care-coordination-platform-tco, klas-2023-vendor-deploy-timelines

What does the BAA cover?
The HealthcareCheck Business Associate Agreement covers PHI handling across the platform itself, AWS infrastructure (BAA executed 2013), Google Cloud Vertex AI for AI clinical insights (BAA executed 2024), and Amazon RDS for PostgreSQL with pgcrypto column-level encryption. Coverage anchors to HHS Omnibus Rule (2013) and 45 CFR 164.312 technical safeguards. Sub-vendor BAAs are executed and listed transparently on the /compliance security page.

Cited:hhs-2013-omnibus-rule-baa-requirements, hhs-45-cfr-164-312-technical-safeguards, aws-baa-2013, google-cloud-vertex-ai-baa-2024

Can my legal team red-line the BAA?
Yes. The published BAA is a starting point, not a take-it-or-leave-it. Common red-lines (breach notification timelines, indemnification scope, audit rights, sub-processor change consent) are negotiable. Send the redline; turnaround is typically inside 48 hours. HIMSS surveys consistently identify BAA legal cycle time as the largest non-technical deploy delay — we treat it as parallelizable, not gating.

Cited:himss-2022-baa-execution-timeline-survey

What if my organization needs an EHR integration that is not live yet?
FHIR R4 with athenahealth is live today. eClinicalWorks integration is in active development. Custom integrations with Epic, Cerner, NextGen, and Allscripts are scoped during the discovery call and run in parallel. The platform itself goes live in 48 hours regardless — patient enrollment, closed-loop referral, instrument capture, and quality-measure reporting are not gated on EHR integration. The integration ships when verified end-to-end against your specific HL7 FHIR R4 resource configuration.

Cited:hl7-fhir-r4-2019

What happens if our pilot does not work out?
Tenant data export is available on request, in standard formats — CSV for tabular data, FHIR R4 for clinical data. The BAA remains in effect for the data-handling period. There is no lock-in clause and no multi-year contract minimum. The platform earns its keep month over month. Standard-format export means your historical referral, instrument, and SDOH data lands inside your EHR or your next platform without proprietary translation cost.

Cited:hl7-fhir-r4-2019

Who handles post-deploy support — and what is the escalation path?
The founder. There is no L1 generalist support layer. Clinical directors, IT/compliance leads, and care coordinators have direct access to Matthew Sexton, LCSW, who is the engineer who can change the platform. The discovery call, the post-launch walkthrough, and the post-deploy debug call all happen with the same person. Workflow change requests typically deploy same-day for non-architectural changes. Architectural changes scope inside the same week. The model breaks past a certain customer scale, and we will hire when it does — but until then, support latency is whatever it takes to get one engineer on the call.
What does the discovery call actually cover, and how do I prepare?
Thirty minutes, no slide deck. We walk through the patient population you serve (CCBHC clients, FQHC panel, dialysis cohort, post-transplant cohort), the validated instruments you need turned on at deploy (PHQ-9, C-SSRS, KDQOL-36, Zarit, PRAPARE — pick the subset), the geographic coverage area for community-resource matching, and the EHR integration surface (Epic, Cerner, NextGen, athenahealth, eClinicalWorks). To prep, send your service-area ZIP codes, the EHR vendor and version, and any existing closed-loop referral workflow you want to preserve. The 48-hour deploy clock starts after this call and after BAA countersignature, whichever lands second.

Cited:kroenke-2001-phq9-validation, posner-2011-cssrs-validation

Can we use a vanity domain instead of a subdomain on healthcarecheck.org?
Yes. Standard deploy uses tenantname.healthcarecheck.org because it provisions instantly under our wildcard SSL and DNS. Vanity domains (yourorganization.org/care, navigate.yourorganization.org, etc.) are supported at no additional charge — provide your DNS records during branding configuration, point CNAME or A records at our load balancer, and we issue an SSL certificate via automated ACME flow. The vanity-domain path adds DNS-propagation time outside the 48-hour clock but does not change the deploy-readiness milestone. Patient-facing app URL is whatever your organization decides.
How is tenant data isolated from other HealthcareCheck tenants?
Schema-per-tenant on Amazon RDS PostgreSQL with row-level security enforced at the database layer and tenant-scoped JWT claims enforced at the application layer. PHI columns are encrypted at rest with pgcrypto using tenant-specific keys held in AWS KMS. No tenant can issue a query that returns rows belonging to another tenant — the access path is enforced four times: at the load balancer, at the application middleware, at the database connection pool, and at the row-level security policy. The architecture maps to NIST 800-53 r5 control families AC-3 (access enforcement), SC-28 (protection of information at rest), and SC-13 (cryptographic protection).

Cited:nist-800-53-r5-control-catalog, hhs-45-cfr-164-312-technical-safeguards

Founder thesis

Why this exists

The 6-9 month deploy timeline is not a law of physics. It is bundled work that nobody bothered to parallelize.

— Matthew Sexton, LCSW

I have watched 13 clinical settings try to deploy patient navigation infrastructure across 14 years as an LCSW. Every single one paid the same tax — six to nine months of legal back-and-forth, branding upcharges, instrument-form rebuilding, and resource-directory verification — for software that was supposed to ship in weeks. The deploy timeline became the rate-limiter on every clinical innovation a director wanted to make.

That tax is not engineering. It is bundled work that nobody bothered to parallelize. The BAA is a published artifact, not a bespoke negotiation. The instrument library is validated against primary literature once, not re-encoded per tenant. The resource directory is verified weekly in one place, not rebuilt by every clinic. The branding is the default, not the upcharge.

HealthcareCheck deploys in 48 hours because we stopped serializing what does not need to be sequential. Your BAA, your branding, your DNS, your tenant schema, your admin accounts, and your patient enrollment readiness all happen in parallel — under an executed BAA chain across Vertex AI, AWS, and RDS pgcrypto. We earn the contract month over month, not through three-year minimums. That is the deal.

Matthew Sexton, LCSWFounder · Mental Wealth Solutions Inc.

Citations

  1. klas-2023-care-coordination-platform-tcoSee citations/klas-2023-care-coordination-platform-tco.mdx for primary source, DOI/PMID, and key statistics.
  2. klas-2023-vendor-deploy-timelinesSee citations/klas-2023-vendor-deploy-timelines.mdx for primary source, DOI/PMID, and key statistics.
  3. himss-2022-baa-execution-timeline-surveySee citations/himss-2022-baa-execution-timeline-survey.mdx for primary source, DOI/PMID, and key statistics.
  4. hhs-2013-omnibus-rule-baa-requirementsSee citations/hhs-2013-omnibus-rule-baa-requirements.mdx for primary source, DOI/PMID, and key statistics.
  5. hhs-45-cfr-164-312-technical-safeguardsSee citations/hhs-45-cfr-164-312-technical-safeguards.mdx for primary source, DOI/PMID, and key statistics.
  6. ocr-2024-hipaa-enforcement-statisticsSee citations/ocr-2024-hipaa-enforcement-statistics.mdx for primary source, DOI/PMID, and key statistics.
  7. hl7-fhir-r4-2019See citations/hl7-fhir-r4-2019.mdx for primary source, DOI/PMID, and key statistics.
  8. aws-baa-2013See citations/aws-baa-2013.mdx for primary source, DOI/PMID, and key statistics.
  9. google-cloud-vertex-ai-baa-2024See citations/google-cloud-vertex-ai-baa-2024.mdx for primary source, DOI/PMID, and key statistics.
  10. kroenke-2001-phq9-validationSee citations/kroenke-2001-phq9-validation.mdx for primary source, DOI/PMID, and key statistics.
  11. posner-2011-cssrs-validationSee citations/posner-2011-cssrs-validation.mdx for primary source, DOI/PMID, and key statistics.
  12. kdqol-36-validation-2007See citations/kdqol-36-validation-2007.mdx for primary source, DOI/PMID, and key statistics.
  13. zarit-burden-validation-1980See citations/zarit-burden-validation-1980.mdx for primary source, DOI/PMID, and key statistics.
  14. isel-12-validationSee citations/isel-12-validation.mdx for primary source, DOI/PMID, and key statistics.
  15. wemwbs-validation-tennant-2007See citations/wemwbs-validation-tennant-2007.mdx for primary source, DOI/PMID, and key statistics.
  16. odphp-2030-sdoh-frameworkSee citations/odphp-2030-sdoh-framework.mdx for primary source, DOI/PMID, and key statistics.
  17. nist-800-53-r5-control-catalogSee citations/nist-800-53-r5-control-catalog.mdx for primary source, DOI/PMID, and key statistics.

Ready to close the gap?