70c1f28230
Live validation of the deployed Signal stack: engine verified (5k-patient upload, PHI-clean, export, confirm-visit), live app outage diagnosed and restored (Clerk dev-instance revert), 3 product blockers + master-key exposure + compliance gaps documented for Pi to design remediation. Includes Pi's current-state.md design updates. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
97 lines
7 KiB
Markdown
97 lines
7 KiB
Markdown
# Signal — Production Readiness Whitepaper
|
||
|
||
**Date:** 2026-06-21
|
||
**Author:** Claude Code
|
||
**Companion to:** `pilot-e2e-validation-2026-06-21.md` (validate the pilot first; this is the road from there to production)
|
||
**Purpose:** Define exactly what it takes to move Signal from its current posture to (1) a controlled pilot and (2) full production where a supplier's own staff log in and rely on Signal with **real patient identifiers**. For Pi to design the sequence; Claude Code builds it.
|
||
|
||
---
|
||
|
||
## 1. Where we are today (verified 2026-06-21)
|
||
|
||
- **Auth:** Clerk migration is **half-done and broken**. Front-end deployed with a production key pointing at `clerk.sttilsolutions.com`, but that domain's DNS is wrong (CNAME'd to Vercel, not Clerk), so the live app is a blank screen. Backend still validates against the **dev** Clerk instance. (See pilot validation P0-1.)
|
||
- **Database:** Supabase **Pro** ($25/mo). No BAA. Reachable, 1 org.
|
||
- **Host:** Railway. No BAA available.
|
||
- **MFA:** not confirmed on any admin console.
|
||
- **Data:** synthetic / de-identified only. No live PHI has entered the system.
|
||
- **Audit log:** code exists but never writes to the DB.
|
||
|
||
The single most important framing: **Signal has two very different finish lines**, and conflating them is what produced the "100% ready" overstatement. Keep them separate.
|
||
|
||
---
|
||
|
||
## 2. Two finish lines
|
||
|
||
### Finish line A — Controlled pilot (zero live PHI)
|
||
|
||
The supplier substitutes synthetic patient IDs and offsets dates **before** export, keeping the real crosswalk on their side. Because no PHI reaches STTIL, the full HIPAA Security Rule build is **not triggered**. Reference: `docs/hipaa-deployment-analysis-v1.md` (zero-PHI path) and `docs/pilot-guide-v1.md`.
|
||
|
||
**Required for Finish line A:**
|
||
- **Clerk:** A production instance is **strongly recommended** (dev `pk_test_` instances carry usage caps, a dev banner, and can be reset — not appropriate for a real supplier's staff). Custom domain + full DNS are *not strictly required* at zero-PHI, but the front-end/back-end Clerk instances must **match** and the app must actually load. Fastest correct state: either finish the prod instance properly, or revert both halves to one working instance.
|
||
- **BAA:** not required (no ePHI). The LOI must state plainly that no live ePHI is transmitted.
|
||
- **Host:** Railway is fine.
|
||
- **MFA:** required on all admin consoles; any method acceptable at zero-PHI.
|
||
- **Config:** confirm `ALLOWED_ORIGINS` is locked to the real Vercel domain (today the regex accepts **any** `*.vercel.app` with credentials), `CLERK_JWKS_URL` and `SIGNAL_API_KEY` set, and the deployed URL serves the Clerk-gated React app (not the static demo in `vercel.json`).
|
||
- **Trust copy:** remove the false BAA claim from the privacy page.
|
||
- **Operational proof:** deletion test run, incident tabletop run, access scope documented.
|
||
- **Paperwork:** LOI + NDA executed (attorney-reviewed), FDA CDS exemption memo written.
|
||
|
||
### Finish line B — Full production (real patient identifiers / ePHI)
|
||
|
||
This crosses into ePHI and turns on the **entire** Real-PHI gate. Reference: `docs/hipaa-deployment-analysis-v1.md` (Option B "HIPAA SaaS") and the Real-PHI checklist in `CLAUDE.md`.
|
||
|
||
**Required for Finish line B (all mandatory):**
|
||
|
||
1. **Business Associate Agreements** — per relationship: STTIL ↔ supplier (before any ePHI, §164.308(b)); STTIL ↔ host; STTIL ↔ Anthropic if any AI layer touches ePHI. **Supabase Pro has no BAA** — requires Supabase **Team** ($599/mo) or migration to AWS RDS.
|
||
2. **BAA-capable host** — Railway must be replaced (AWS ECS Fargate / Atlantic.Net / equivalent). Railway offers no HIPAA BAA.
|
||
3. **Clerk production, properly** — `pk_live_`, custom domain (`clerk.sttilsolutions.com`), and the full Clerk DNS set:
|
||
- `clerk` → `frontend-api.clerk.services` ← **this is the record currently wrong**
|
||
- `accounts` → `accounts.clerk.services` ← already correct
|
||
- `clkmail` → `mail.<id>.clerk.services`
|
||
- `clk._domainkey` → `dkim1.<id>.clerk.services`
|
||
- `clk2._domainkey` → `dkim2.<id>.clerk.services`
|
||
- and switch the **backend** `CLERK_JWKS_URL` to the production instance so both halves match.
|
||
4. **Phishing-resistant MFA (FIDO2/WebAuthn)** — mandatory under 2026 §164.312(d). SMS OTP does not satisfy it.
|
||
5. **Encryption** — AES-256 at rest confirmed/attested (RDS or Supabase Team), TLS 1.3 enforced.
|
||
6. **Effective, immutable audit logging** — DB-trigger immutability or nightly export to object storage with Object Lock (RLS alone is bypassed by the service role), AND the audit table must actually receive rows.
|
||
7. **Governance** — documented annual risk assessment (HHS SRA Tool), tested incident response, tested 72-hour restoration, continuous monitoring/alerting, full administrative-safeguards review with attorney.
|
||
8. **FDA CDS exemption memo** finalized and attorney-reviewed.
|
||
|
||
**Timeline estimate (from `hipaa-deployment-analysis-v1.md`):** ~6–11 weeks to compliant first-ePHI contact; critical path = host BAA execution + FIDO2 MFA rollout.
|
||
|
||
---
|
||
|
||
## 3. One-line distinction
|
||
|
||
> **Controlled pilot** = paperwork + MFA + correct env config + corrected privacy copy on the existing zero-PHI stack.
|
||
> **Full production** = a new BAA-capable host, Supabase Team/RDS under a BAA, Clerk production with custom domain + DNS, phishing-resistant MFA, effective WORM audit logging, encryption attestation, and an attorney-reviewed Security Rule posture.
|
||
|
||
---
|
||
|
||
## 4. Recommended sequence (for Pi to design)
|
||
|
||
**Phase 0 — Unbreak (today):** restore the live app to one consistent, working Clerk instance (pilot validation P0-1). This is a prerequisite for any demo and must not wait on the full prod build.
|
||
|
||
**Phase 1 — Production Clerk, done right:** stand up the prod instance, fix the `clerk` CNAME → `frontend-api.clerk.services`, add the remaining DNS records, migrate the **backend** JWKS to prod, verify login end-to-end on `signal.sttilsolutions.com`. (This is the Clerk work Kisa is routing to Pi.)
|
||
|
||
**Phase 2 — Trust & security hardening (no host change):** correct privacy copy, delete the `VITE_SIGNAL_API_KEY` path, wire the audit log to write real rows, confirm MFA, lock CORS to the real domain.
|
||
|
||
**Phase 3 — Compliance build for ePHI (the heavy lift):** BAA-capable host migration, Supabase Team/RDS + BAA, FIDO2 MFA, effective WORM, encryption attestation, risk assessment, attorney review.
|
||
|
||
Phases 0–2 are reachable quickly and unlock a credible controlled pilot. Phase 3 is a 6–11 week project that should begin only when a real-PHI contract is in sight and funded.
|
||
|
||
---
|
||
|
||
## 5. Cost deltas to anticipate
|
||
|
||
| Item | Today | Production |
|
||
|---|---|---|
|
||
| Database | Supabase Pro $25/mo | Supabase Team **$599/mo** (BAA) or AWS RDS |
|
||
| Host | Railway (no BAA) | AWS ECS Fargate / Atlantic.Net (BAA) |
|
||
| Auth | Clerk dev (free tier) | Clerk production (paid tier as users grow) |
|
||
| MFA | none | FIDO2 hardware/passkeys |
|
||
| Legal | — | BAAs, Security Rule review, FDA CDS memo |
|
||
|
||
---
|
||
|
||
*All technical claims here are corroborated by the live 2026-06-21 validation (`pilot-e2e-validation-2026-06-21.md`) and `docs/hipaa-deployment-analysis-v1.md`.*
|