Signal/docs/superpowers/plans/2026-06-07-signal-compliance-docs.md

# Signal Demo MVP — Compliance Documents Implementation Plan

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

**Goal:** Write and publish the compliance documents required before any supplier (starting with Gaboro) uploads data to Signal. These are: Privacy Policy (published at a public URL), Incident Response Procedure, Data Handling Documentation, and payer_rules.json cadence documentation. Also verify MFA and Supabase plan posture.

**Output location:** `signal/docs/compliance/`
- `signal/docs/compliance/privacy-policy.md` — public privacy policy (deploy to sttilsolutions.com/signal/privacy)
- `signal/docs/compliance/incident-response.md` — internal procedure
- `signal/docs/compliance/data-handling.md` — data handling and minimum necessary fields doc
- `signal/docs/compliance/payer-rules-cadence.md` — payer_rules.json update procedure

**Reference:** Read `signal/docs/hipaa-deployment-analysis-v1.md` before writing any compliance doc — it contains the existing HIPAA analysis that these docs should be consistent with.

**Key Signal data facts (use these, do not invent):**
- Signal stores: hashed patient_id (SHA-256), device_type, shipment_date, quantity, payer, coverage_status, rule_version
- Signal never stores: patient names, SSNs, DOBs, addresses, phone numbers, email addresses, diagnosis codes
- Identity crosswalk stays local with the supplier — STTIL never holds it
- Infrastructure: Railway (FastAPI), Supabase (PostgreSQL + RLS), Vercel (React), Clerk (auth)
- AWS: BAA signed; RDS + S3 provisioned but parked until post-funding
- All traffic: HTTPS enforced
- Auth: Clerk JWT required on all API endpoints in production
- Audit log: WORM (append-only rules in Supabase)

---

## Task 1: Read existing compliance material

- [ ] **Step 1: Read the existing HIPAA analysis**

Read `signal/docs/hipaa-deployment-analysis-v1.md` in full. This document informs all compliance writing. Do not contradict its findings.

- [ ] **Step 2: Read the Signal CLAUDE.md compliance checklist**

Read `/Users/sttil-solutions/projects/signal/CLAUDE.md`, specifically the "Compliance Readiness Checklist" section. Note which items are PASS and which are NOT DONE — the docs in this plan are meant to address the NOT DONE items.

---

## Task 2: Privacy Policy

- [ ] **Step 1: Draft the Privacy Policy**

Create `signal/docs/compliance/privacy-policy.md`. This document will be published at a public URL. Write it for a lay audience (DMEPOS supplier staff), not lawyers.

```markdown
# Signal Privacy Policy

**Effective Date:** June 7, 2026
**Product:** Signal — Documentation Readiness Platform
**Operated by:** STTIL Solutions LLC

---

## Who We Are

STTIL Solutions LLC ("STTIL", "we", "us") operates Signal, a documentation readiness tool for DMEPOS suppliers. Signal helps supplier staff identify patients whose documentation may need attention before supplies are shipped or claims are submitted.

This Privacy Policy describes how Signal handles the data uploaded to our platform and what we do (and do not) store.

---

## What Data Signal Processes

When your staff uploads a CSV file to Signal, we process the following fields:

| Field | Purpose |
|---|---|
| Patient identifier (internal) | Your internal MRN or account number — used as a de-identified tracking key only |
| Device type | CGM device type (e.g., Dexcom G7, FreeStyle Libre 3) |
| Shipment date | Most recent supply ship date |
| Payer name | Insurance type (e.g., Medicare, Medicaid, Commercial) |
| Quantity shipped | Number of units in the shipment |
| Documentation status fields (if present) | SWO status, PA status, PECOS verification, diagnosis flag — if included in your CSV |

Signal produces a prioritized documentation worklist as output.

---

## What Signal Does NOT Store

Signal is designed to operate without storing protected health information (PHI). We never store:

- Patient names
- Social Security numbers
- Dates of birth
- Home addresses
- Phone numbers or email addresses
- Diagnosis codes (ICD codes)
- Clinical notes or records

The connection between a patient identifier and a real patient identity stays with your staff. STTIL never holds that crosswalk.

---

## How We Store What We Do Collect

Patient identifiers are **hashed using SHA-256** before storage. This means we store a cryptographic fingerprint of the identifier, not the identifier itself. The hash cannot be reversed to recover the original patient identifier.

All stored data is associated with your organization's account and is protected by row-level security (RLS) policies in our database — your data is not accessible to other Signal customers.

All data in transit is encrypted via HTTPS (TLS 1.2 or higher). All data at rest is encrypted using AES-256.

---

## Who Can Access Your Data

**Your organization's staff:** Users in your Signal account can view the worklist and documentation status for your patients.

**STTIL Solutions staff:** STTIL engineers may access system logs and aggregated platform metrics for operational purposes. Access to customer data is restricted and logged.

**No third parties:** STTIL does not sell, rent, or share your organization's data with any third party for commercial purposes.

**Law enforcement / legal process:** STTIL may disclose data if required by law, regulation, or court order. We will notify you to the extent permitted by law before complying with any such request.

---

## Data Retention

Your uploaded CSV data and scored records are retained for the duration of your subscription plus 90 days. Upon termination of your subscription or pilot agreement, all data associated with your account will be deleted within 10 business days of your written request, and we will confirm deletion in writing.

Audit logs (records of actions taken on the platform) are retained for 7 years for compliance purposes.

---

## Patient Outreach

**Signal does not contact patients.** All outreach and supply decisions remain with your staff. Signal surfaces documentation conditions — your team acts on them.

---

## HIPAA

Signal processes de-identified operational data. To the extent that any data processed by Signal could be considered protected health information under HIPAA, STTIL Solutions has executed a Business Associate Agreement (BAA) with its cloud infrastructure providers and operates appropriate administrative, physical, and technical safeguards.

If you believe a Business Associate Agreement is required for your engagement with Signal, please contact us at the address below before uploading any data.

---

## Security Incidents

In the event of a security incident affecting your organization's data, STTIL Solutions will notify you within 72 hours of discovery, consistent with our incident response obligations. We will provide a description of the incident, the data affected, and the steps taken to address it.

---

## Contact

Questions about this Privacy Policy or your data:
**STTIL Solutions LLC**
Email: kisasttil@gmail.com

---

## Changes to This Policy

We may update this Privacy Policy from time to time. We will notify active customers of material changes by email. Continued use of Signal following notice of changes constitutes acceptance of the updated policy.
```

- [ ] **Step 2: Commit**

```bash
cd /Users/sttil-solutions/projects/signal
git add docs/compliance/privacy-policy.md
git commit -m "docs: Signal Privacy Policy — publish-ready draft"
```

---

## Task 3: Incident Response Procedure

- [ ] **Step 1: Draft the Incident Response Procedure**

Create `signal/docs/compliance/incident-response.md`:

```markdown
# Signal Incident Response Procedure

**Version:** 1.0
**Date:** June 7, 2026
**Owner:** STTIL Solutions LLC / Kisa Fenn, Managing Member
**Classification:** Internal — do not publish

---

## Purpose

This document defines the steps STTIL Solutions will take if a security incident affects Signal or the data of Signal customers. An "incident" includes any unauthorized access, data breach, ransomware event, accidental deletion, or disclosure of customer data.

---

## Incident Classification

| Severity | Description | Examples |
|---|---|---|
| P1 — Critical | Active breach or confirmed data exposure | Unauthorized access to Supabase; database dump exfiltrated |
| P2 — High | Suspected breach or significant service disruption | Unusual API activity; Railway service crash with data loss risk |
| P3 — Medium | Potential vulnerability or policy violation | Misconfigured CORS; unexpected admin access |
| P4 — Low | Minor issues with no data exposure | Failed login attempts; expired SSL (auto-renewing) |

---

## Response Timeline

| Step | P1 | P2 | P3/P4 |
|---|---|---|---|
| Detect and classify | Immediate | Within 1 hour | Within 24 hours |
| Contain | Immediately | Within 2 hours | Within 72 hours |
| Notify affected customers | Within 72 hours | Within 72 hours | As appropriate |
| Root cause analysis | Within 24 hours | Within 72 hours | Within 1 week |
| Remediation complete | Within 48 hours | Within 1 week | Within 2 weeks |

---

## Step 1: Detect and Classify

Detection sources:
- Railway logs and alerts
- Supabase dashboard alerts
- Vercel deployment alerts
- Clerk auth anomaly alerts
- Customer report
- Routine audit log review

Upon detection, Kisa Fenn assesses severity and begins the response log.

---

## Step 2: Contain

**P1 (Critical):**
1. Immediately revoke all active API keys and rotate secrets (Railway env vars, Supabase service key, Clerk API key)
2. Take Signal offline if breach is active (Railway: pause service)
3. Preserve logs — do not delete or overwrite
4. Do not communicate publicly until scope is understood

**P2 (High):**
1. Revoke and rotate suspected compromised credentials
2. Isolate affected service if possible
3. Begin forensic log review

**P3/P4:**
1. Patch or reconfigure the identified vulnerability
2. Document the fix

---

## Step 3: Assess Scope

Determine:
- What data was accessed or exposed?
- Which customers (organizations) are affected?
- What is the time range of the exposure?
- Was any patient data (even de-identified hashed IDs) involved?

Signal's data architecture minimizes exposure: patient_id is hashed before storage. Even in a worst-case database exposure, the hashes cannot be reversed to reveal patient identities without the supplier's local crosswalk.

---

## Step 4: Notify Affected Customers

**Timeline:** Within 72 hours of confirming that customer data was affected.

**Notification must include:**
1. Date and time the incident was detected
2. Description of the incident (what happened)
3. Data affected (which tables, which organizations, what fields)
4. Steps STTIL has taken to contain and remediate
5. Steps the customer should take (if any)
6. Contact for follow-up questions

**Notification method:** Email to the primary contact for each affected organization. For P1 incidents also attempt phone contact.

**Breach notification under HIPAA:** If any incident involves data that may constitute PHI under HIPAA, STTIL will comply with HIPAA breach notification requirements, including notification to HHS within 60 days of discovery for breaches affecting 500+ individuals. Given Signal's de-identification architecture, PHI breach is unlikely but is addressed here for completeness.

---

## Step 5: Root Cause Analysis and Remediation

Document:
- Root cause (technical failure, human error, external attack)
- How it was detected
- Timeline of the incident
- Containment actions taken
- Remediation actions taken
- Preventive measures implemented

Store the incident report in `signal/docs/compliance/incidents/YYYY-MM-DD-incident-report.md`.

---

## Step 6: Post-Incident Review

Within one week of remediation:
- Review whether current monitoring would have caught this sooner
- Update runbooks, monitoring, or access controls as needed
- Evaluate whether additional audit log coverage is needed

---

## Key Contacts and Credentials

| System | Access | Rotation after incident |
|---|---|---|
| Railway | railway.app — sttilsolutionsllc@proton.me | Rotate SIGNAL_API_KEY, SUPABASE_SERVICE_KEY, CLERK_JWKS_URL |
| Supabase | supabase.com — Kisa's account | Rotate service_key (JWT) immediately |
| Vercel | vercel.com | Rotate VITE_API_URL if endpoint changed |
| Clerk | clerk.com — eternal-goblin-1 | Rotate API keys |

After a P1 incident, rotate ALL secrets listed above regardless of which service was directly involved.

---

## Escalation

Kisa Fenn is the sole incident commander for all Signal incidents. If Kisa is unavailable and the incident is P1, the default action is to take Signal offline (Railway: pause service) until Kisa can respond.

**Legal contact:** Nixon Law Group (Clyde) — contact for any incident that may involve regulatory notification obligations.
```

- [ ] **Step 2: Commit**

```bash
cd /Users/sttil-solutions/projects/signal
git add docs/compliance/incident-response.md
git commit -m "docs: Signal incident response procedure v1.0"
```

---

## Task 4: Data Handling Documentation

- [ ] **Step 1: Draft data handling doc**

Create `signal/docs/compliance/data-handling.md`:

```markdown
# Signal Data Handling and Minimum Necessary Fields

**Version:** 1.0
**Date:** June 7, 2026
**Classification:** Internal + shareable with pilot customers on request

---

## Overview

This document describes what data Signal collects from customers, how it is processed and stored, and the minimum necessary field policy that governs what data enters Signal systems.

---

## Minimum Necessary Fields

Signal is designed on the principle of minimum necessary data. The only fields required for Signal to produce a documentation worklist are:

| Field | Required | Why |
|---|---|---|
| Patient identifier (internal) | Yes | De-identified crosswalk key. Patient's own MRN or account number within the supplier's system. Never a name, SSN, or DOB. |
| Device type | Yes | Determines wear-day rules and payer coverage eligibility |
| Shipment date | Yes | Anchors the supply cycle clock and visit due date calculation |
| Payer name | Yes | Determines documentation requirements (PA, PECOS, visit cadence) |
| Quantity shipped | Recommended | Improves coverage cycle accuracy; defaults to 1 if omitted |
| Component type | Optional | Defaults to "sensor" if omitted |

**Doc status fields (optional — improve Signal accuracy when present):**

| Field | Improves |
|---|---|
| SWO status | SWO item in doc checklist |
| Visit date | Visit date priority (confirmed > estimated) |
| PECOS verified | PECOS item in doc checklist |
| PA status | PA item in doc checklist |
| Diagnosis on file | Diagnosis item in doc checklist |
| Transfer_From | Transferred patient detection |

Customers are encouraged to include doc status fields in their CSV exports when available from their billing system. When absent, Signal uses reasonable defaults and labels estimated values clearly.

---

## What Signal Does NOT Accept

Customers must not include the following fields in uploaded CSVs:
- Patient first or last name
- Social Security number
- Date of birth
- Home address, city, state, or ZIP
- Phone number
- Email address
- Insurance member ID (this may constitute PHI)
- Diagnosis codes (ICD-10 codes)
- Clinical notes

Signal's normalizer does not map or store these fields even if they appear in uploaded CSV headers. They are treated as unmapped noise columns and excluded from all Signal processing and storage.

---

## Data Flow

```
Supplier staff → CSV file → Signal frontend (Vercel)
                               ↓
                         Signal API (Railway)
                          - Normalizer: maps CSV headers to canonical fields
                          - Minimum necessary check: only required fields extracted
                          - Coverage calculator: scores each patient
                          - Patient_id hashed via SHA-256 before any storage
                               ↓
                         Supabase (PostgreSQL)
                          - upload_batches table: filename, row_count, org_id
                          - normalized_records: patient_id_hash, device_type, shipment_date,
                            payer, coverage_status, rule_version
                          - confirmed_visits: org_id, patient_id_hash, confirmed_date
                          - audit_events: WORM append-only
```

Signal does not transmit any customer data to third parties. The only external services that receive any customer data are:
- **Supabase** (database hosting, US-east-2) — BAA in place via Supabase's enterprise tier
- **Railway** (application hosting) — no customer data stored at Railway; data in transit only
- **Vercel** (frontend CDN) — no customer data stored; serves frontend assets only

---

## CSV Disposition Policy

Uploaded CSV files are:
1. Received by the Signal API
2. Parsed in memory
3. Content hash computed (SHA-256 of raw bytes) and stored in `source_files` table
4. Raw bytes are NOT stored in Supabase — only the hash and metadata
5. Normalized field values are stored (with patient_id hashed)

**Signal does not store copies of uploaded CSV files.** The CSV is processed in memory and then discarded. Only the scored output and metadata are persisted.

---

## Data Retention

| Data Type | Retention Period |
|---|---|
| Upload batch metadata | Duration of subscription + 90 days |
| Scored patient records (normalized_records) | Duration of subscription + 90 days |
| Confirmed visit dates | Duration of subscription + 90 days |
| Audit events | 7 years (compliance requirement) |
| Source file metadata (hash only) | Duration of subscription + 90 days |

Upon written request, all customer data except audit events (which are retained for legal compliance) will be deleted within 10 business days.

---

## Supabase Plan Tier

Signal uses **Supabase Pro tier** for production. Pro tier supports:
- Row-level security (RLS) — enforced on all tables
- Encrypted backups
- Point-in-time recovery
- SOC 2 Type II compliance (Supabase organization-level)

Verify current plan tier in Supabase dashboard before the first pilot customer uploads data.

**Action required before pilot:** Confirm Supabase plan is Pro or higher and that the `confirmed_visits` table has RLS enabled. Run in Supabase SQL editor:
```sql
SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
```
All tables should show `rowsecurity = true`.

---

## payer_rules.json Update Cadence

`python-backend/config/payer_rules.json` contains the coverage rules Signal applies when calculating documentation requirements. This file must be reviewed and updated:

- **Quarterly:** Review CMS LCD updates, MAC bulletins, and payer PA requirement changes for CGM
- **On CMS rule publication:** Update immediately when CMS publishes changes to CGM coverage (e.g., new HCPCS codes added to Required PA List, Synapse Health mandate changes, CGM competitive bidding updates)
- **On Watcher Agent alert:** The Watcher Agent monitors CMS.gov, MAC websites, and key payer portals for relevant rule changes and alerts Kisa. All updates to payer_rules.json require Kisa's approval before deployment.

**Cadence documentation maintained at:** `signal/docs/compliance/data-handling.md` (this file).
**Owner:** Kisa Fenn, STTIL Solutions LLC.
**Next scheduled review:** September 7, 2026 (90 days from launch).

---

## MFA Status

All Signal administrative accounts must have MFA enabled:

| Account | MFA Required | Verify Before Pilot |
|---|---|---|
| Railway (sttilsolutionsllc@proton.me) | Yes | [ ] |
| Supabase | Yes | [ ] |
| Vercel | Yes | [ ] |
| Clerk (eternal-goblin-1) | Yes | [ ] |
| AWS (BAA account) | Yes | [ ] |

Complete this checklist before the Gaboro pilot starts. Mark each item confirmed by checking the MFA status in each platform's security settings.
```

- [ ] **Step 2: Commit**

```bash
cd /Users/sttil-solutions/projects/signal
git add docs/compliance/data-handling.md
git commit -m "docs: data handling + minimum necessary fields + Supabase posture + MFA checklist"
```

---

## Task 5: Update CLAUDE.md compliance checklist

- [ ] **Step 1: Update compliance checklist in CLAUDE.md**

Read `signal/CLAUDE.md`. Find the "Compliance Readiness Checklist" section and update the following items from NOT DONE to PASS:

- `Data handling rules documented` → PASS (privacy-policy.md + data-handling.md)
- `payer_rules.json quarterly update cadence documented` → PASS (data-handling.md)
- Add new entry: `Privacy Policy document exists and is ready to publish` → PASS

**Note on Supabase plan tier:** Check the Supabase dashboard to confirm plan tier before marking `Real PHI blocked` items as fully PASS. If plan is confirmed Pro, mark it PASS.

- [ ] **Step 2: Recount PASS items and update the percentage**

After updating, count all PASS items in the compliance checklist and note the new percentage.

- [ ] **Step 3: Commit**

```bash
cd /Users/sttil-solutions/projects/signal
git add CLAUDE.md docs/compliance/
git commit -m "docs: compliance checklist updated — Privacy Policy, data handling, payer cadence PASS"
```

---

## Task 6: Publish Privacy Policy

The Privacy Policy needs to be at a stable public URL before Gaboro uploads any data.

- [ ] **Step 1: Identify the publish target**

The STTIL website is served from the VPS at `/var/www/sttilsolutions.com` via Caddy. The VPS is currently down (as of session start 2026-06-07). **Do not attempt VPS deployment in this task.**

Instead, create an HTML version of the Privacy Policy as a static file in the Signal frontend that can be served from Vercel at `https://signal-ui-xi.vercel.app/privacy`.

- [ ] **Step 2: Create privacy page in Signal frontend**

Create `signal-ui/src/Privacy.jsx`:
```jsx
export default function Privacy() {
  return (
    <div className="max-w-[680px] mx-auto px-6 py-12 font-body text-[var(--text-primary)]">
      <h1 className="font-heading font-bold text-[24px] mb-2">Signal Privacy Policy</h1>
      <p className="text-[12px] text-[var(--text-muted)] mb-8">Effective Date: June 7, 2026 · STTIL Solutions LLC</p>

      {/* paste the privacy policy content as JSX sections */}
      <section className="mb-8">
        <h2 className="font-heading font-semibold text-[16px] mb-3">Who We Are</h2>
        <p className="text-[14px] leading-[1.7] text-[var(--text-secondary)]">
          STTIL Solutions LLC ("STTIL", "we", "us") operates Signal, a documentation readiness tool for DMEPOS suppliers.
          Signal helps supplier staff identify patients whose documentation may need attention before supplies are shipped or claims are submitted.
          This Privacy Policy describes how Signal handles the data uploaded to our platform.
        </p>
      </section>

      <section className="mb-8">
        <h2 className="font-heading font-semibold text-[16px] mb-3">What Signal Does NOT Store</h2>
        <p className="text-[14px] leading-[1.7] text-[var(--text-secondary)] mb-3">
          Signal is designed to operate without storing protected health information (PHI). We never store:
        </p>
        <ul className="list-disc pl-5 text-[14px] leading-[1.8] text-[var(--text-secondary)]">
          <li>Patient names</li>
          <li>Social Security numbers</li>
          <li>Dates of birth</li>
          <li>Home addresses</li>
          <li>Phone numbers or email addresses</li>
          <li>Diagnosis codes (ICD codes)</li>
          <li>Clinical notes or records</li>
        </ul>
        <p className="text-[14px] leading-[1.7] text-[var(--text-secondary)] mt-3">
          The connection between a patient identifier and a real patient identity stays with your staff. STTIL never holds that crosswalk.
        </p>
      </section>

      <section className="mb-8">
        <h2 className="font-heading font-semibold text-[16px] mb-3">Patient Outreach</h2>
        <p className="text-[14px] leading-[1.7] text-[var(--text-secondary)]">
          Signal does not contact patients. All outreach and supply decisions remain with your staff.
          Signal surfaces documentation conditions — your team acts on them.
        </p>
      </section>

      <section className="mb-8">
        <h2 className="font-heading font-semibold text-[16px] mb-3">Data Retention and Deletion</h2>
        <p className="text-[14px] leading-[1.7] text-[var(--text-secondary)]">
          Your data is retained for the duration of your subscription plus 90 days.
          Upon written request, all data associated with your account will be deleted within 10 business days, with written confirmation provided.
        </p>
      </section>

      <section className="mb-8">
        <h2 className="font-heading font-semibold text-[16px] mb-3">Contact</h2>
        <p className="text-[14px] leading-[1.7] text-[var(--text-secondary)]">
          Questions: <a href="mailto:kisasttil@gmail.com" className="text-[var(--brand)] underline">kisasttil@gmail.com</a>
        </p>
      </section>

      <p className="text-[11px] text-[var(--text-muted)] border-t border-[var(--border-subtle)] pt-4 mt-8">
        Signal is operated by STTIL Solutions LLC · signal.sttilsolutions.com
      </p>
    </div>
  );
}
```

- [ ] **Step 3: Add /privacy route to App.jsx**

Read `signal-ui/src/App.jsx`. Add a route for the Privacy component. The app likely uses conditional rendering or React Router. Add the Privacy page so it renders at `/privacy`.

If the app uses hash routing or simple state-based routing, add a check: if `window.location.pathname === '/privacy'` render `<Privacy />` instead of the main app. If it uses React Router, add `<Route path="/privacy" element={<Privacy />} />`.

- [ ] **Step 4: Add vercel.json rewrite for /privacy**

Read `signal-ui/vercel.json`. Add a rewrite so `/privacy` serves the SPA:
```json
{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}
```
(This is likely already there. Verify and add if missing.)

- [ ] **Step 5: Build + deploy to Vercel**

```bash
cd /Users/sttil-solutions/projects/signal/signal-ui && pnpm build
cd /Users/sttil-solutions/projects/signal && git add signal-ui/src/Privacy.jsx signal-ui/src/App.jsx
git commit -m "feat: Privacy Policy page at /privacy on Signal frontend"
git push
```

Vercel will auto-deploy. Verify at: https://signal-ui-xi.vercel.app/privacy

---

## Delivery

After all tasks complete, report back with:
1. Public URL of the Privacy Policy
2. List of compliance checklist items updated to PASS
3. MFA checklist status (which accounts still need MFA enabled)
4. Supabase plan tier confirmed or still pending verification
5. Any items still marked NOT DONE with explanation of blocker