HealthcareCheck

Your brand on every screen the patient ever sees — by default, not by upcharge.

Care coordination platform vendors charge an enterprise-tier upcharge for what we treat as the baseline. Logo, accent colors, copy, subdomain or vanity domain, instrument library, and resource matching scope all configured per tenant during the 48-hour deploy. Patients never see the vendor name. Auditors never see the vendor name. Configuration is mutable post-deploy from the admin dashboard without a vendor ticket. Compliance posture stays vendor-side — your brand, our spine.

Where the pathway breaks — and how we close it

Branding-as-upcharge tier gating

Care coordination platform vendors typically gate white-label branding behind enterprise-tier pricing — a clinic on a starter or mid-market tier sees the vendor logo, vendor name, and vendor color palette on every patient screen until they upgrade. KLAS Research summaries of CCBHC and FQHC implementations consistently show branding configured during enterprise-tier onboarding takes 60-90 days of design-team back-and-forth, and patients in the meantime are interacting with a brand they did not choose to engage with. The deploy timeline absorbs the branding cycle as if it were unavoidable scope. It is not — it is a tier-pricing artifact.

60-90 daysBranding configuration timeline (enterprise-tier vendor norm)cite

Cost when unaddressed: Patients form trust associations with the vendor brand instead of the tenant brand. Tenant marketing investment leaks to a vendor that did not earn it.

White-label is the default, not a tier

Every HealthcareCheck tenant — starter, mid-market, enterprise — gets full white-label from day one. 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 are all configured per tenant during the 48-hour deploy. Brand presence is consistent at every patient touchpoint because it is the same tenant configuration object rendered everywhere — patient app, patient-facing email, login screen, push notification, SMS, receipt, crisis resources page. The vendor name does not appear in any patient-facing surface, period.

0patient-facing surfaces showing vendor branding
Before60-90 daysVendor norm for enterprise-tier branding configurationcite
After<48 hoursHealthcareCheck branding configuration window
Impact on branding-as-upcharge tier gatingMethodology →

Vendor branding visible on dashboards and audit exports

Even when patient-facing branding is white-labeled, vendor lock-in patterns persist on the admin side — care coordinator dashboards, clinical director reports, and audit-trail exports retain vendor logos, vendor watermarks, and vendor-named export filenames. Compliance officers handing reports to auditors reveal the vendor relationship every time a report leaves the building. HIMSS surveys of care coordination tooling consistently show admin-side branding parity is treated as a separate professional-services line item by incumbent vendors, often quoted as $15,000-$40,000 of additional configuration work, and frequently delivered partially even when paid for.

$15K-$40KAdmin-side branding parity quoted as professional servicescite

Cost when unaddressed: Auditors infer vendor relationships from report formatting. Tenant control over the audit narrative leaks every time a PDF is generated.

Tenant-branded all the way down — admin, dashboards, exports

Care coordinator and clinical director dashboards reflect tenant brand by default. Reporting exports use tenant header, tenant footer, tenant filename prefix, tenant color palette in chart elements, and tenant signature block on PDFs. What you hand auditors looks like it came from you because it did come from you — the vendor name is only present in administrative documentation and audit trails maintained for vendor-side compliance, never in tenant-facing or auditor-facing exports. Reporting templates are tenant-editable from the admin dashboard.

100%tenant-branded admin surfaces by default
Before$15K-$40KVendor norm for admin-side branding paritycite
After$0HealthcareCheck admin-side branding parity (default)
Impact on vendor branding visible on dashboards and audit exportsMethodology →

Subdomain or vanity domain with manual SSL operations

Tenants who want patients on a domain they already own (care.theirorganization.org) typically face manual SSL certificate procurement, manual DNS validation, manual renewal scheduling, and manual cipher-suite hardening — work that incumbents either decline outright or charge as a custom infrastructure engagement. NIST 800-53 r5 SC-8 (transmission confidentiality) and SC-13 (cryptographic protection) require TLS 1.2 minimum on patient-facing surfaces touching ePHI, and renewal-cycle gaps are a documented cause of HIPAA breach notifications when certificates expire silently and sessions fall back to weaker ciphers.

ManualVendor norm for vanity-domain SSL provisioning + renewalcite

Cost when unaddressed: Expired certificates create breach-notification triggers. Manual rotation cycles are a documented operational risk.

Auto-SSL provisioning, auto-renewal, TLS 1.3 default

Default tenant URL is tenantname.healthcarecheck.org with auto-SSL via the platform CDN — no DNS work required from the tenant. If the tenant wants a vanity domain (care.theirorg.org or similar), they provide DNS access during the 48-hour deploy and we provision SSL automatically with auto-renewal. TLS 1.3 by default with TLS 1.2 fallback for older patient devices. Cipher-suite hardening matches NIST 800-53 r5 SC-13 requirements. Renewal cycles run automatically before expiry — tenants do not schedule them.

TLS 1.3default cipher with auto-renewalcite
BeforeManualVendor norm for vanity-domain SSL operationscite
AfterAutomaticHealthcareCheck SSL provisioning + renewal
Impact on subdomain or vanity domain with manual ssl operationsMethodology →

Custom instrument requests in months-long vendor backlog

Tenants frequently need clinically validated instruments that fall outside generic SDOH-only screeners — KDQOL-36 for dialysis populations, the Zarit Burden Interview for caregivers, ISEL-12 for social support, WEMWBS for mental wellbeing, the Columbia Suicide Severity Rating Scale (C-SSRS) for crisis triage, AUDIT and DAST-10 for substance use screening. Incumbent vendors treat custom instrument requests as feature-request tickets that enter a quarterly product roadmap and frequently emerge 6-12 months later partially implemented. The clinical director who needed KDQOL-36 for a dialysis pilot finds themselves running paper forms while the vendor backlog churns.

6-12 monthsVendor norm for custom instrument request fulfillmentcite

Cost when unaddressed: Clinical workflows fall back to paper forms. Instrument capture data does not enter the dashboard. Trending and longitudinal analysis become impossible.

Validated library standard plus custom instruments on request

Standard library includes PHQ-9, PHQ-2, GAD-7, C-SSRS, KDQOL-36, Zarit Burden Interview, AUDIT, DAST-10, ISEL-12, WEMWBS, and the SDOH 10-domain screen — all configured during the 48-hour deploy with cadence, branching logic, and dashboard trending pre-built. Custom instruments are added on request: provide the validated instrument with primary citation and scoring logic, and we configure cadence, branching, dashboard trending, and FHIR R4 Observation mapping inside the deploy window. The vendor backlog model does not apply.

11+ standardvalidated instruments configured by defaultcite
Before6-12 monthsVendor norm for custom instrument request fulfillmentcite
After<48 hoursHealthcareCheck custom instrument configuration window
Impact on custom instrument requests in months-long vendor backlogMethodology →

Generic resource directory without geographic or specialty scope

Care coordination tools frequently expose patients to a national or regional resource directory without scoping to the tenant's geographic coverage area or clinical specialty. A CCBHC in upstate New York sees Texas resources. A dialysis center sees behavioral-health crisis lines that are not relevant to the active patient population. Care coordinators waste cognitive load filtering noise the platform should have pre-filtered. ODPHP Healthy People 2030 SDOH framework documentation consistently shows resource matching effectiveness drops sharply when scope is not geographically and specialty-bounded — referrals to out-of-scope resources have completion rates below 10%.

Below 10%Out-of-scope referral completion ratecite

Cost when unaddressed: Care coordinators spend time filtering instead of placing referrals. Patients receive irrelevant suggestions and lose trust in the platform.

Geographic and specialty-scoped resource matching

Resource matching is scoped per tenant during the 48-hour deploy: geographic coverage area (county, multi-county region, or service-area polygon) plus clinical specialty (CCBHC mental-health-first, FQHC primary-care-first, dialysis nephrology-first). 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. The 691,000-row resource graph filters to your population.

691K verifiedresources, geo+specialty-scoped, insurance-awarecite
BeforeBelow 10%Out-of-scope referral completion ratecite
AfterGeo+specialtyHealthcareCheck scoping default
Impact on generic resource directory without geographic or specialty scopeMethodology →

App-store presence treated as separate vendor engagement

Tenants who want a native iOS or Android app on the App Store and Google Play under their own organization name typically face a separate professional-services engagement with the vendor — Apple Developer enrollment, Google Play Developer enrollment, build configuration, screenshot generation, App Review submission, and post-approval maintenance all quoted as a multi-quarter project. KLAS summaries show native-app deploys frequently exceed $50,000 in vendor professional services, and tenants often abandon the work mid-engagement when the timeline outpaces clinical priorities.

$50K+Vendor norm for native white-label app store engagementcite

Cost when unaddressed: Tenants without app-store presence lose patient acquisition channels. The investment frequently fails mid-deploy when timelines overrun clinical priorities.

PWA default, optional white-label native app on tenant developer account

Default patient-facing surface is a Progressive Web App on the tenant subdomain — no App Store enrollment required, instant updates without review cycles, full offline capability for instruments and crisis resources. Most tenants ship to PWA on day one and observe patient adoption before deciding on native-app investment. Optional white-label native app is published under the tenant's Apple Developer and Google Play Developer accounts — tenant owns the developer relationship, tenant owns the app listing, vendor handles build configuration and submission inside the configuration scope. App Store comes later only if patient demand justifies the developer fee and review cycle.

PWA day 1patient-facing surface, native optional
Before$50K+Vendor norm for native white-label app store engagementcite
AfterPWA defaultHealthcareCheck patient-facing surface
Impact on app-store presence treated as separate vendor engagementMethodology →

Copy and tone written for vendor, not tenant

Welcome screens, onboarding microcopy, instrument intros, and crisis resources pages are typically written by the vendor in a generic clinical voice that does not match the tenant's organizational tone or population literacy level. CCBHCs serving Medicaid populations need 6th-grade reading-level copy with culturally responsive framing. Dialysis centers need clinical precision balanced with caregiver empathy. FQHCs need bilingual surfaces. Generic vendor copy underperforms across all three segments — patient comprehension drops, instrument completion rates drop, and care coordinators absorb the support burden.

GenericVendor norm for patient-facing copy and tonecite

Cost when unaddressed: Patient comprehension drops. Instrument completion drops. Support burden lands on care coordinators.

Tenant-editable copy with clinically reviewed defaults

Welcome screens, onboarding microcopy, instrument intros, and crisis resources pages are tenant-editable from the admin dashboard without a vendor ticket. Defaults are clinically reviewed and ship at 6th-grade reading level with culturally responsive framing as the baseline. Tenants override per-population — bilingual surfaces, clinical-precision tone, caregiver-empathy framing all configured during the 48-hour deploy and mutable post-deploy. Copy review uses the same workflow as instrument cadence configuration.

6th-gradedefault reading level, tenant-editablecite
BeforeGenericVendor norm for patient-facing copycite
AfterTenant-editedHealthcareCheck copy default with clinical review
Impact on copy and tone written for vendor, not tenantMethodology →

Compliance posture configurable creates audit-failure risk

Some incumbent vendors expose compliance configuration to tenant administrators — BAA terms, encryption-key rotation cadence, audit-log retention policy, FHIR schema modification — under the framing of giving tenants control. The reality is that tenant-side compliance configuration creates audit-failure risk: tenants without dedicated security officers misconfigure rotation cadence, shorten retention windows below 6-year HIPAA requirements per 45 CFR 164.316(b)(2), and modify FHIR R4 schema in ways that break interoperability. OCR enforcement statistics document tenant-misconfiguration as a recurring breach root cause, and the resulting penalties land on the tenant, not the vendor.

Tenant-sideSome vendors expose compliance configuration to tenantscite

Cost when unaddressed: Audit failures land on tenants. Breach penalties land on tenants. Vendor-side compliance posture protects the tenant from configuration errors they did not need to make.

Vendor-side compliance posture, tenant-side brand control

BAA terms across the sub-vendor chain (Vertex AI, AWS, RDS pgcrypto), encryption-key rotation cadence, audit-log retention policy (7-year default, exceeds 6-year HIPAA minimum per 45 CFR 164.316(b)(2)), and FHIR R4 schema all stay vendor-side and immutable. Tenants control brand, copy, instruments, resource scope, and configuration — the surfaces that reflect organizational identity. Vendors control compliance posture — the surfaces that protect the tenant from audit failure. The split is the deal: your brand, our spine.

7-yearaudit-log retention default, exceeds 6-year HIPAA minimumcite
BeforeTenant-sideSome vendors expose compliance configuration to tenantscite
AfterVendor-sideHealthcareCheck compliance posture default
Impact on compliance posture configurable creates audit-failure riskMethodology →

Methodology

How we measure

White-label depth is measured by enumerating every patient-facing and tenant-facing surface a patient or auditor encounters during a normal care coordination cycle, and verifying which entity's brand renders on that surface. Patient-facing surfaces include the login screen, the patient app home, every instrument intro, every push notification, every email, every SMS, every receipt, the crisis resources page, and the appointment confirmation screen. Tenant-facing surfaces include the care coordinator dashboard, the clinical director reporting view, audit-log exports, referral pipeline reports, and reporting PDFs handed to auditors. The white-label benchmark is zero vendor-branded patient-facing surfaces and zero vendor-branded tenant-facing exports — the vendor name appears only in administrative documentation and audit trails maintained for vendor-side compliance, never in tenant-facing or auditor-facing surfaces. Configuration depth is measured by enumerating every brand element a tenant can configure during the 48-hour deploy and post-deploy from the admin dashboard without filing a vendor ticket — logo, accent color, secondary palette, header copy, footer copy, login screen treatment, email-from name and address, push-notification sender label, SMS sender ID, instrument cadence, resource matching scope, and dashboard layout. The configuration surface is documented in a per-tenant configuration object surfaced to the tenant's compliance officer on request.

What counts

  • Patient-facing surfaces — login screen, patient app home, instrument intros, push notifications, emails, SMS, receipts, crisis resources page, appointment confirmation
  • Tenant-facing admin surfaces — care coordinator dashboard, clinical director reporting view, referral pipeline reports, reporting PDFs
  • Auditor-facing exports — audit-log exports, compliance reports, reporting PDFs handed to external auditors
  • Configuration object enumeration — every brand element a tenant can configure during deploy and post-deploy from admin dashboard without vendor ticket
  • 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

  • Vendor-side administrative documentation — internal runbooks, vendor-side audit trails, sub-vendor BAA chain documentation maintained for vendor-side compliance
  • Compliance posture configuration — BAA terms, encryption-key rotation, audit-log retention policy, FHIR R4 schema (these stay vendor-side immutable per the white-label trade)
  • Source code or platform architecture — tenants do not modify routing, encryption, or data-layer code paths
  • Sub-vendor identity — Vertex AI, AWS, and RDS pgcrypto are surfaced in the published BAA chain for tenant compliance officers but do not appear in patient-facing or auditor-facing surfaces

How we compare

Sourced from primary citations — not vendor marketing claims.

UsHealthcareCheckvsUnite UsvsFindhelpvs9-month custom build
White-label patient appciteDefault — every tierEnterprise-tier upchargeNetwork-branded onlyTenant builds
Branding configuration timelinecite<48 hours60-90 days60-90 days60-180 days
Admin dashboard branding parityciteDefault$15K-$40K professional servicesNot offeredTenant builds
Vanity domain SSL provisioningciteAuto, TLS 1.3 defaultManual, custom engagementNot supportedTenant builds
Validated instrument librarycitePHQ-9 + C-SSRS + KDQOL-36 + Zarit + ISEL-12 + WEMWBS + PRAPAREConfigurable formsSDOH onlyBuild-from-scratch
Custom instrument turnaroundcite<48 hours inside deployQuarterly product roadmapNot supportedTenant builds
Resource directory scopingcite691K verified, geo+specialty+insurance-awareNetwork resources onlyPublic directory, genericBuild-from-scratch
Native white-label app store presenceciteOptional, tenant developer account$50K+ professional servicesNetwork app onlyTenant builds
Copy and tone editingciteTenant-editable from adminVendor ticket requiredVendor-controlledTenant builds
Compliance posture controlciteVendor-side immutableMixed — some tenant-sideMixedTenant builds

Frequently asked questions

Is white-label an upcharge?

No. White-label is the default — it is not a tier, an add-on, or a premium feature. Every tenant gets their own brand on every patient screen from day one of the 48-hour deploy. Branding configuration runs in parallel with BAA execution, DNS provisioning, and tenant schema instantiation.

Vendor norms quote 60-90 days of design-team back-and-forth for enterprise-tier branding configuration. We treat that as the baseline expectation, not a billable engagement.

Cited:klas-2023-care-coordination-platform-tco

Can patients see HealthcareCheck branding anywhere?

No. Patients interact with your organization's name, logo, and colors across every patient-facing surface — login screen, patient app home, instrument intros, push notifications, emails, SMS, receipts, crisis resources page, and appointment confirmation. The vendor name does not appear in any patient-facing surface, period.

The only place the platform name shows up is in administrative documentation and audit trails maintained for vendor-side compliance — never patient-facing, never tenant-facing exports, never auditor-facing reports.

Subdomain or vanity domain — which one?

Either. Default is tenantname.healthcarecheck.org with auto-SSL via the platform CDN — no DNS work required from the tenant. If you want patients on a domain you already own (care.yourorganization.org or similar), provide DNS access during the 48-hour deploy and we provision SSL on your domain with auto-renewal.

TLS 1.3 by default with TLS 1.2 fallback for older patient devices. Cipher-suite hardening matches NIST 800-53 r5 SC-13 cryptographic protection requirements. Renewal cycles run automatically before expiry.

Cited:nist-800-53-r5-control-catalog

What instruments can we configure?

Standard library includes PHQ-9, PHQ-2, GAD-7, C-SSRS, KDQOL-36, Zarit Burden Interview, AUDIT, DAST-10, ISEL-12, WEMWBS, and the SDOH 10-domain screen — all configured during the 48-hour deploy with cadence, branching logic, dashboard trending, and FHIR R4 Observation mapping pre-built.

Custom instruments are added on request: provide the validated instrument with primary citation and scoring logic, and we configure cadence, branching, dashboard trending, and FHIR mapping inside the deploy window. The vendor-backlog model where instrument requests enter a quarterly product roadmap does not apply here.

Cited:kroenke-2001-phq9-validation, posner-2011-cssrs-validation, kdqol-36-validation-2007, zarit-burden-validation-1980

Can we control which resources patients see?

Yes. Resource matching is scoped to your geographic coverage area (county, multi-county region, or service-area polygon) and your clinical specialty (CCBHC mental-health-first, FQHC primary-care-first, dialysis nephrology-first). A CCBHC in upstate New York does not see Texas resources. A dialysis center matches transportation partners and dietary support, not behavioral health crisis lines unless KDQOL-36 or C-SSRS triggers escalation.

The 691,000-row resource graph filters to your population. 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 provider does not see a result that does not accept the patient's plan.

Cited:odphp-2030-sdoh-framework

What about admin dashboards and audit exports — do those show vendor branding?

No. Care coordinator and clinical director dashboards reflect tenant brand by default. Reporting exports use tenant header, tenant footer, tenant filename prefix, tenant color palette in chart elements, and tenant signature block on PDFs. What you hand auditors looks like it came from you because it did come from you.

Vendor norms charge $15,000-$40,000 of professional services for admin-side branding parity, and frequently deliver it partially even when paid for. We treat tenant-branded admin surfaces as the default deploy state.

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

Can we ship a native iOS or Android app under our organization name?

Yes — optional. Default patient-facing surface is a Progressive Web App on the tenant subdomain with full offline capability for instruments and crisis resources, instant updates without App Review cycles. Most tenants ship to PWA on day one and observe patient adoption before deciding on native-app investment.

Native white-label apps are published under your Apple Developer and Google Play Developer accounts — you own the developer relationship, you own the app listing, we handle build configuration and submission inside the configuration scope. App Store comes later only if patient demand justifies the developer fee and review cycle.

Cited:klas-2023-care-coordination-platform-tco

What can we NOT customize, and why?

Compliance posture stays vendor-side and immutable. Tenants do not edit BAA terms across the sub-vendor chain (Vertex AI, AWS, RDS pgcrypto), encryption-key rotation cadence, audit-log retention policy (7-year default, exceeds 6-year HIPAA minimum per 45 CFR 164.316(b)(2)), or the FHIR R4 schema. Source code, routing, encryption, and data-layer code paths also stay vendor-side.

The split is intentional and protective. OCR enforcement statistics document tenant-misconfiguration as a recurring HIPAA breach root cause when vendors expose compliance configuration to tenant admins without dedicated security officers. Vendor-side compliance posture protects you from configuration errors you did not need to make. Brand belongs to the tenant — compliance belongs to the vendor. That is the trade.

Cited:ocr-2024-hipaa-enforcement-statistics, hhs-45-cfr-164-312-technical-safeguards

Founder thesis

Why this exists

White-label as an enterprise-tier upcharge is a tier-pricing artifact masquerading as engineering complexity.

— Matthew Sexton, LCSW

Vendor branding on a patient screen is a tax I have watched 13 clinical settings pay across 14 years as an LCSW. Patients form trust associations with the brand on the screen — when that brand is the vendor's, the tenant's marketing investment leaks to a vendor that did not earn it. Every clinical director I have ever worked with has paid that tax without recognizing it as a tax. They were told it was an enterprise-tier feature. It is not. It is a tier-pricing artifact masquerading as engineering complexity.

White-label is not hard. Logo, accent color, copy, subdomain, instrument library, resource matching scope, dashboard branding, app-store presence — all of these are configuration objects rendered everywhere consistently. The work is one-time. The recurring labor is verification, which we already run for our own audit posture. The reason vendors charge $15,000 to $40,000 for admin-side branding parity is the same reason they quote 60-90 days for enterprise-tier configuration: revenue, not engineering.

HealthcareCheck ships white-label as the default because the alternative is a brand-leakage tax that should not exist. Compliance posture stays vendor-side because the alternative is audit-failure risk for tenants without dedicated security officers. The split is the deal — your brand, our spine. We earn the contract month over month, not through three-year minimums and not through enterprise-tier upcharges on something that should never have been gated.

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?