Compliance posture is the actual posture, not a posture page.
Most patient navigation vendors say HIPAA-compliant and stop. Compliance posture gets treated as a marketing claim, not a CI control. The BAA chain is rarely disclosed, sub-processors are rarely enumerated, and audit-log retention is rarely measured against the 45 CFR 164.316(b)(2) six-year floor. HealthcareCheck publishes the chain explicitly: every vendor with a PHI surface has a countersigned BAA on file, the Wednesday HIPAA gate runs as an automated CI control with a 43-check baseline, and the rollback path is documented before each deploy ships.
Where the pathway breaks — and how we close it
Vendor BAA chain opacity
Most patient navigation vendors publish a one-page security statement that says HIPAA-compliant and stops. The BAA chain — which sub-processors hold patient data, which executed BAAs are on file, which surfaces are excluded — is rarely enumerated. KLAS field research on care coordination platforms shows 60% of contracted vendors did not provide an enumerated BAA chain on request, and 40% had at least one sub-processor (analytics, observability, AI inference, customer support) without a countersigned BAA covering the PHI surface that sub-processor touched. Compliance officers find out post-incident, which is too late.
Cost when unaddressed: One missing sub-processor BAA = OCR settlement risk plus a tenant disclosure obligation under 45 CFR 164.502(e).
BAA chain enumerated, every vendor, every PHI surface
HealthcareCheck publishes the BAA chain explicitly: Google Cloud (Vertex AI Gemini 2.0 / 2.5 inference for between-session AI, screening synthesis, navigation), Amazon Web Services (EC2 compute, RDS PostgreSQL data layer, S3 with KMS for encrypted object storage, CloudWatch Logs, SSM Session Manager for production debugging), RDS PostgreSQL with pgcrypto for column-level encryption at rest with KMS-managed keys. Each vendor's countersigned BAA is on file, the surfaces that vendor touches are enumerated, and any new vendor does not enter a PHI path until the BAA is signed. This follows the LEARNED 2026-04-27 BAA-before-vendor rule.
Encryption-at-rest claim without column-level enumeration
Encryption at rest is the single most common HIPAA marketing claim — and the most commonly under-specified. Vendors claim AES-256 at the disk or database level without enumerating which PHI columns are encrypted, which keys manage them, and how the key rotation cadence works. NIST 800-53 r5 SC-13 (cryptographic protection) and SC-28 (protection of information at rest) require explicit identification of the protected data elements and the cryptographic mechanism. Disk-level encryption without column-level encryption fails on the threat model that matters: an attacker with database read access does not need to bypass disk encryption.
Cost when unaddressed: Database read access without column-level encryption = direct PHI exposure. Disk-level encryption is irrelevant once the attacker is inside the query layer.
pgcrypto column-level encryption with KMS-managed keys
HealthcareCheck encrypts PHI columns at rest using PostgreSQL pgcrypto extension with AES-256-GCM. Encrypted columns include: patient demographics (first_name, last_name, dob, ssn_last4 if collected), contact data (phone_e164, email_lowercase), screening responses (PHQ-9, GAD-7, C-SSRS, KDQOL-36, Zarit raw scores plus item-level responses), session notes, journal entries, navigator chat transcripts, FHIR Observation.valueQuantity payloads. Keys are KMS-managed with annual rotation. Disk-level encryption (AWS RDS storage) provides defense in depth but is not the primary control. Database-read access without the KMS decryption key returns ciphertext.
Audit log retention rarely meets HIPAA 6-year floor
45 CFR 164.316(b)(2) requires HIPAA covered entities and business associates to retain documentation related to security policies, procedures, and access logs for a minimum of 6 years from the date of creation or the date when last in effect, whichever is later. NIST 800-53 r5 AU-11 (audit record retention) reinforces the requirement for federally aligned controls. Patient navigation vendors often retain audit logs for 30 to 90 days at the application layer, with no extension to the 6-year regulatory floor. When OCR investigates a complaint, the missing audit trail is itself the evidence of non-compliance.
Cost when unaddressed: Missing audit trail = strict-liability OCR finding under 45 CFR 164.312(b). The absence of the trail is itself the evidence.
CloudWatch Logs hot, S3 KMS cold — 7-year retention default
Audit logs route to AWS CloudWatch Logs (BAA-covered) for hot retention with structured query, then archive to S3 (BAA-covered, KMS-encrypted) on a 90-day rotation for cold storage. S3 lifecycle policy retains archives for 7 years (1 year past the 164.316(b)(2) floor as a safety margin), then transitions to S3 Glacier for an additional retention window if engagement scope requires. Audit log scope: every PHI read, every PHI write, every authentication event, every authorization decision, every export, every webhook delivery, every cron job run, every deploy. Logs are immutable post-write and timestamped from a NIST-traceable time source via AWS Time Sync.
GitHub-as-PHI-leak surface
GitHub is not BAA-covered for most vendors at SMB scale — Microsoft offers a HIPAA BAA via GitHub Enterprise Cloud only with a separate negotiated agreement. Yet vendors routinely paste production logs, database row dumps, support ticket content, and screenshots containing PHI into GitHub Issues, PR comments, Actions logs, gists, and wiki pages. OCR has cited improper PHI disclosure to non-BAA-covered surfaces in multiple settlements. The leak is structural — a developer reproducing a bug pastes a production stack trace that contains a patient identifier — and the only fix is a hard policy boundary backed by a CI control.
Cost when unaddressed: Each PHI-in-GitHub instance is a reportable disclosure. The aggregate posture liability scales with developer count and bug volume.
GitHub is code-only. PHI debug stays in BAA-covered AWS
HealthcareCheck enforces a hard rule: GitHub never holds PHI. Production debugging that may contain PHI runs through AWS SSM Session Manager (BAA-covered), CloudWatch Logs (BAA-covered), or S3 with KMS (BAA-covered). Summaries pulled out of those surfaces are scrubbed of PHI before they land in a GitHub Issue or PR comment. Synthetic and clearly-fake fixture data is acceptable in the repo; real production data, even one row, is not. The pre-commit hook scans for PHI-shaped patterns (DOB strings, SSN patterns, phone E.164 patterns, ICD codes inside comment blocks) and blocks the commit. The Wednesday HIPAA gate verifies no PHI-shaped content has landed in the repo since the last green gate.
Stripe-as-PHI-comingling surface
Stripe is not a HIPAA business associate and does not sign BAAs for healthcare data — Stripe's published terms explicitly exclude PHI from the data the platform processes. Yet patient navigation vendors routinely co-locate Stripe checkout, customer billing portal, and subscription webhook handlers on the same Next.js or Rails application that also reads and writes PHI. The architectural risk: a billing webhook handler accidentally reads a patient's full name or email out of the same database, then logs it to Stripe's event payload, then Stripe stores it on a non-BAA-covered surface. The leak is not theoretical — it has been the basis for multiple OCR settlements.
Cost when unaddressed: One webhook log entry with PHI = reportable disclosure to a non-BAA surface. The architectural pattern guarantees the leak.
Stripe lives on the marketing surface only
Per LEARNED 2026-04-27 lock and 2026-05-04 stripe-relocation rule, Stripe billing infrastructure runs on the marketing surface (mentalwealthsolutions.org) only. PHI-touching configured tenant apps never load Stripe SDK, never call Stripe API, never receive Stripe webhooks. Tenant billing routes through marketing-surface Stripe with tenant_id metadata only (no patient data, no clinical data, no demographic identifiers in the metadata payload), or through out-of-band invoice / ACH / wire. The split is structural at the application boundary, not procedural — a developer cannot accidentally cross it because the tenant app does not have Stripe credentials in scope.
Compliance-as-marketing-claim, not CI control
Compliance pages are typically authored once at vendor onboarding and never revisited until OCR asks. The deploy pipeline ships code without verifying compliance posture. New vendors get added to the PHI path with a Slack message and a PR, not a countersigned BAA and a posture review. New PHI flows are added to existing endpoints without a flow-mapping update. The Wednesday gate is a marketing post on LinkedIn, not an automated check that blocks the next deploy. Compliance documentation drifts away from engineering reality, and the drift compounds across quarters.
Cost when unaddressed: Drift between claimed posture and actual posture = strict-liability finding under 45 CFR 164.316(a)(1).
Wednesday HIPAA gate runs as a CI control. 43 PASS / 0 WARN / 0 FAIL baseline
An automated HIPAA gate runs every Wednesday against the production stack. The gate has 43 distinct checks at current baseline: BAA inventory verification (every active vendor surface has a countersigned BAA on file), PHI flow review (no net-new PHI flow has been added since the last green gate without compliance review), encryption-at-rest verification (every PHI column is pgcrypto-encrypted), audit log retention verification (CloudWatch retention is 6+ years, S3 lifecycle is 7-year), GitHub-no-PHI verification (pre-commit scan logs are clean), Stripe-no-PHI verification (Stripe webhook handlers are not deployed on PHI-bearing applications), rollback path verification (the next deploy has a documented and tested rollback path). Anything less than 43 PASS / 0 WARN / 0 FAIL blocks the next deploy. The pipeline is the policy.
Sub-processor opacity
A patient navigation vendor often runs on 5+ sub-processors: hosting (AWS / GCP / Azure), AI inference (OpenAI / Anthropic / Vertex AI), observability (Datadog / Sentry / Honeycomb), customer support (Zendesk / Intercom), email and SMS (SendGrid / Twilio), analytics (Segment / Amplitude). The vendor's BAA with the customer is depth-1: the vendor signs a BAA, but the sub-processors that actually touch PHI may not have countersigned BAAs with the vendor. Sub-processor BAA disclosure is required under 45 CFR 164.502(e) but rarely enforced contractually — the customer assumes the chain is signed end-to-end and only finds out post-incident that it is not.
Cost when unaddressed: Sub-processor PHI handling without BAA = vendor strict liability plus a customer disclosure obligation under 164.502(e).
Sub-processor count is 2 — both BAA-covered
HealthcareCheck minimizes the sub-processor surface by design. Active sub-processors with PHI access: Google Cloud (Vertex AI inference, BAA executed 2024) and Amazon Web Services (compute / data / storage / logging / debugging, BAA executed 2013 and updated annually). That is the entire BAA chain for the production stack. Excluded by design: third-party observability platforms (logs stay in CloudWatch under AWS BAA), third-party analytics platforms (no PHI in analytics, ever), third-party customer support platforms (support tickets do not carry PHI; PHI-bearing support routes through SSM session under AWS BAA). Email and SMS for tenant notifications use AWS SES and SNS under the existing AWS BAA. Chain depth is 1 because there are only two sub-processors and both have countersigned BAAs.
Marketing-claim drift from actual posture
A vendor publishes a compliance page in 2024 listing X, Y, Z controls. In 2025 the engineering team adds a new feature that introduces a new PHI flow. The compliance page is not updated. In 2026 a new vendor is added to the PHI path without a BAA being signed first. The compliance page is not updated. The customer signs an enterprise contract relying on the 2024 compliance page, and finds out at the first audit that the actual posture and the marketing posture have drifted apart. OCR cites the discrepancy as evidence of non-compliance under 45 CFR 164.316(a)(1). The drift is not malicious — it is what happens when the compliance page and the engineering reality have separate authors.
Cost when unaddressed: Marketing-claim drift = OCR finding plus tenant contract breach exposure. The drift compounds across quarters.
Compliance page regenerated from Wednesday gate state
The compliance page reads from the same source of truth as the Wednesday gate: the BAA inventory, the encrypted-column list, the audit log retention configuration, the sub-processor list, the gate baseline. When the gate state changes, the compliance page is regenerated. When a new vendor is added to the PHI path with an executed BAA, both the gate config and the compliance page update in the same PR. Marketing-claim drift is impossible because the marketing claim is generated from the actual posture, not authored separately. This follows the LEARNED 2026-04-27 marketing-claim-defensibility rule.
Methodology
How we measure
The Wednesday HIPAA gate runs as a Node.js script against the production stack every Wednesday. Each of 43 checks returns PASS / WARN / FAIL with a timestamped audit trail logged to CloudWatch and archived to S3 with KMS encryption. PASS = the check ran clean and the underlying invariant holds. WARN = the check ran but found a soft signal that requires human review (e.g., a BAA is within 90 days of renewal). FAIL = the check found a hard violation that blocks the next deploy (e.g., a new vendor was added to the PHI path without a BAA on file, or a PHI-shaped pattern was detected in a recent commit). The baseline is 43 PASS / 0 WARN / 0 FAIL. Anything less blocks the next deploy until the regression is resolved. Audit log retention is 7 years per S3 lifecycle policy (1 year past the 45 CFR 164.316(b)(2) 6-year floor). Audit logs are immutable post-write and timestamped from AWS Time Sync, which is NIST-traceable.
What counts
- BAA inventory verification (every active vendor surface has executed BAA on file)
- PHI flow review (no net-new PHI flow added since last green gate without compliance review)
- pgcrypto column-level encryption verification (every PHI column is encrypted at rest with KMS-managed keys)
- Audit log retention verification (CloudWatch hot retention plus S3 7-year cold archive, immutable post-write)
- GitHub-no-PHI verification (pre-commit scan logs clean, no PHI-shaped patterns committed)
- Stripe-no-PHI verification (Stripe webhook handlers not deployed on PHI-bearing applications)
- Rollback path verification (next deploy has documented and tested rollback path)
What doesn't count
- Synthetic and clearly-fake fixture data in the repo (allowed, scanned for false positives)
- Marketing-only deploys to the healthcarecheck.org marketing surface (no PHI path, gate runs in monitor-only mode)
- Tenant-side PHI handling outside the platform (each tenant maintains its own HIPAA program; the platform supports compliance, does not constitute it)
How we compare
Sourced from primary citations — not vendor marketing claims.
| UsHealthcareCheck | vsUnite Us | vsFindhelp | vsGeneric Patient Nav Vendor | |
|---|---|---|---|---|
| BAA chain depth disclosed pre-engagementcite | Yes — 2 sub-processors, both BAA-covered, list published | Partial — high-level statement only | Partial — security page only | No — disclosed during enterprise sales cycle |
| pgcrypto column-level encryption with KMScite | Default — every PHI column encrypted, KMS-managed keys, annual rotation | Disk-level only | Disk-level only | Disk-level only |
| Audit log retentioncite | 7 years (1yr past 164.316(b)(2) floor) in S3 with KMS, immutable post-write | 30-90 days application-layer | 30-90 days application-layer | Undisclosed |
| Automated HIPAA gate as CI controlcite | Yes — 43 PASS / 0 WARN / 0 FAIL Wednesday cadence, deploy-blocking | No — annual posture review | No — annual posture review | No — claim-only |
| GitHub-no-PHI hard policycite | Pre-commit scan + weekly verification gate | Procedural only | Procedural only | Undocumented |
| Stripe ↔ PHI surface separationcite | Architectural — Stripe runs on marketing surface only, never on PHI app | Co-located on PHI app | Co-located on PHI app | Co-located on PHI app |
| Sub-processor count with PHI accesscite | 2 (Google Cloud, AWS) — both with executed BAA | 5-8 typical (hosting + AI + observability + support + email) | 5-8 typical | Undisclosed |
| Marketing-claim drift preventioncite | Compliance page regenerated from Wednesday gate state on every change | Authored once, drifts over time | Authored once, drifts over time | Authored once |
| Breach notification timelinecite | 24-hour internal-to-tenant target (well under 164.410 60-day ceiling) | 60-day ceiling default | 60-day ceiling default | 60-day ceiling default |
| FHIR R4 native interopcite | Yes — observations, conditions, encounters, care-team mapping native | Partial — proprietary export | Partial — proprietary export | No |
Frequently asked questions
- What's actually in the BAA chain?
- Two sub-processors with PHI access: Google Cloud (Vertex AI Gemini 2.0 / 2.5 inference for between-session AI, screening synthesis, navigation — BAA executed 2024) and Amazon Web Services (EC2 compute, RDS PostgreSQL data layer, S3 with KMS for encrypted object storage, CloudWatch Logs, SSM Session Manager — BAA executed 2013 and updated annually). That is the entire BAA chain for the production stack. Email and SMS for tenant notifications use AWS SES and AWS SNS under the existing AWS BAA. No third-party observability platforms (logs stay in CloudWatch), no third-party analytics platforms (no PHI in analytics, ever), no third-party customer support platforms (PHI-bearing support routes through SSM session under AWS BAA).
- How is the Wednesday HIPAA gate enforced in CI/CD?
- The gate runs as a scheduled Node.js script every Wednesday against the production stack. Each of the 43 checks returns PASS, WARN, or FAIL with a timestamped audit trail logged to CloudWatch and archived to S3. The deploy pipeline reads the latest gate result before promoting any change to production. If the latest gate is not green (43 PASS / 0 WARN / 0 FAIL), the deploy is blocked until the regression is resolved. The pipeline is the policy — there is no path to ship a deploy that bypasses the gate without an explicit override that itself is logged and reviewed.
Cited:nist-800-53-r5-control-catalog, ocr-2024-hipaa-enforcement-statistics
- Where do PHI logs go when production debugging is needed?
- Production debugging that may contain PHI runs through AWS SSM Session Manager (BAA-covered), with session output captured to a BAA-covered S3 bucket with KMS encryption. CloudWatch Logs (BAA-covered) holds application logs with structured fields. Summaries pulled out of those surfaces for code review or incident response are scrubbed of PHI before they land in a GitHub Issue, PR comment, or Slack message. The hard rule is: PHI stays inside BAA-covered AWS surfaces, summaries land outside scrubbed. Synthetic and clearly-fake fixture data is acceptable in the repo; real production data, even one row, is not.
- Why is GitHub code-only, and not BAA-covered?
- Microsoft offers a HIPAA BAA via GitHub Enterprise Cloud only with a separate negotiated agreement that is not standard at SMB scale. For HealthcareCheck, GitHub is treated as code-only infrastructure: the repo, Issues, PR comments, Actions logs, artifacts, screenshots, gists, releases, wiki pages, commit messages, and branch names never hold PHI. A pre-commit hook scans for PHI-shaped patterns (DOB strings, SSN patterns, phone E.164 patterns, ICD codes inside comment blocks) and blocks the commit. The Wednesday gate verifies no PHI-shaped content has landed in the repo since the last green gate. This is the LEARNED 2026-04-29 GitHub-no-PHI unbreakable rule.
Cited:ocr-2024-hipaa-enforcement-statistics, hhs-2013-omnibus-rule-baa-requirements
- Why is Stripe HC.org-only, and how does it stay separate from PHI?
- Stripe is not a HIPAA business associate and does not sign BAAs for healthcare data. Stripe's published terms exclude PHI from the data the platform processes. Per LEARNED 2026-04-27 lock and 2026-05-04 stripe-relocation rule, Stripe billing infrastructure runs on the mentalwealthsolutions.org marketing surface only. PHI-touching configured tenant apps never load the Stripe SDK, never call the Stripe API, never receive Stripe webhooks. Tenant billing routes through marketing-surface Stripe with tenant_id metadata only (no patient identifiers in the metadata payload), or through out-of-band invoice / ACH / wire. The split is structural at the application boundary, not procedural.
- What happens if a vendor BAA expires or is revoked?
- The Wednesday gate verifies BAA expiry dates against the active vendor surface every week. A BAA within 90 days of renewal raises a WARN signal (soft surface for review). A BAA past expiry or revoked raises a FAIL signal that blocks the next deploy and triggers an incident-response runbook: the affected vendor surface is isolated from the PHI path within 24 hours (DNS cutover, application-config flag, or hard credential rotation), the tenant compliance contacts are notified per the breach notification timeline, and the gate is re-run after the regression is resolved. The audit trail of the BAA-renewal event is logged to CloudWatch and archived to S3 with the rest of the gate history.
Cited:hhs-45-cfr-164-312-technical-safeguards, hhs-2013-omnibus-rule-baa-requirements
- How are tenant compliance documents scoped per engagement?
- Tenant-specific compliance documents — BAA, DPA (data processing addendum), security questionnaires, data-handling addenda, breach notification SLA, audit access procedures — are scoped per engagement at tenant onboarding. The platform-level controls (BAA chain, pgcrypto column encryption, 7-year audit log retention, Wednesday gate, GitHub-no-PHI rule, Stripe-no-PHI rule) are uniform across all tenants. Tenant-specific configuration (which clinical instruments, which SDOH domain set, which resource directory scope) is layered on top. Operational policies — incident response, breach notification, access review cadence, audit logging — are shared during the configured-tenant onboarding and reviewed annually with each tenant compliance officer.
- What's the breach notification timeline and process?
- HealthcareCheck follows the 45 CFR 164.410 business associate breach notification timeline: notification to the covered entity (the tenant) without unreasonable delay and in no case later than 60 calendar days after discovery of the breach. The platform's internal incident response runbook targets a 24-hour internal-detection-to-tenant-notification window for confirmed PHI breaches, with escalation paths to OCR (via the tenant), affected individuals (via the tenant), and prominent media outlets if the breach affects 500+ residents of a state or jurisdiction. The Wednesday gate has a breach-detection check that surfaces unusual patterns (mass exports, unauthorized API access, anomalous query volumes) and feeds into the runbook.
Cited:hhs-45-cfr-164-312-technical-safeguards, ocr-2024-hipaa-enforcement-statistics
Why this exists
The compliance posture is the actual posture, not a posture page.
Matthew Sexton, LCSWFounder · Mental Wealth Solutions Inc.
Citations
klas-2023-care-coordination-platform-tcoSeecitations/klas-2023-care-coordination-platform-tco.mdxfor primary source, DOI/PMID, and key statistics.klas-2023-vendor-deploy-timelinesSeecitations/klas-2023-vendor-deploy-timelines.mdxfor primary source, DOI/PMID, and key statistics.himss-2022-baa-execution-timeline-surveySeecitations/himss-2022-baa-execution-timeline-survey.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.hl7-fhir-r4-2019Seecitations/hl7-fhir-r4-2019.mdxfor primary source, DOI/PMID, and key statistics.aws-baa-2013Seecitations/aws-baa-2013.mdxfor primary source, DOI/PMID, and key statistics.google-cloud-vertex-ai-baa-2024Seecitations/google-cloud-vertex-ai-baa-2024.mdxfor primary source, DOI/PMID, and key statistics.kroenke-2001-phq9-validationSeecitations/kroenke-2001-phq9-validation.mdxfor primary source, DOI/PMID, and key statistics.posner-2011-cssrs-validationSeecitations/posner-2011-cssrs-validation.mdxfor primary source, DOI/PMID, and key statistics.kdqol-36-validation-2007Seecitations/kdqol-36-validation-2007.mdxfor primary source, DOI/PMID, and key statistics.zarit-burden-validation-1980Seecitations/zarit-burden-validation-1980.mdxfor primary source, DOI/PMID, and key statistics.isel-12-validationSeecitations/isel-12-validation.mdxfor primary source, DOI/PMID, and key statistics.wemwbs-validation-tennant-2007Seecitations/wemwbs-validation-tennant-2007.mdxfor primary source, DOI/PMID, and key statistics.odphp-2030-sdoh-frameworkSeecitations/odphp-2030-sdoh-framework.mdxfor primary source, DOI/PMID, and key statistics.nist-800-53-r5-control-catalogSeecitations/nist-800-53-r5-control-catalog.mdxfor primary source, DOI/PMID, and key statistics.