From aa653f2343d4b80575ab9d2d6c751b9f04e513b2 Mon Sep 17 00:00:00 2001
From: Kisa <kisasttil@gmail.com>
Date: Sat, 11 Apr 2026 19:38:51 -0400
Subject: [PATCH] =?UTF-8?q?init:=20Signal=20CGM=20Level=201=20=E2=80=94=20?=
 =?UTF-8?q?clean=20start?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .gitignore |  9 +++++++
 CLAUDE.md  | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 CLAUDE.md

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..313b597
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,9 @@
+venv/
+.env
+**/*.env
+*.pyc
+__pycache__/
+*.csv
+data/
+node_modules/
+.DS_Store
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..bf2fd07
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,71 @@
+# STTIL Solutions — Signal CGM | Level 1 Active Context
+
+## What This Tool Does
+Signal CGM is a B2B CGM coverage worklist tool for DMEPOS suppliers.
+It ingests shipment data (CSV from Brightree/WellSky), calculates
+coverage expiration per patient using device wear-day rules, and
+produces a prioritized worklist so small DME teams can do proactive
+outreach BEFORE claims deny.
+
+## Core Value Proposition
+Shifts supplier staff time from reactive (appeals after denial)
+to proactive (preventing denial conditions).
+The workload curve: appeals volume drops over time as proactive
+coverage management replaces it. Outreach volume starts manageable
+and stays predictable.
+
+## PHI Architecture — Non-Negotiable
+- STTIL never stores patient names, SSNs, DOBs, or contact info
+- Sole crosswalk key: patient_id (DME's internal MRN or account #)
+- DME staff maintain the patient_id ↔ real identity mapping locally
+- AI/calculation layer sees: patient_id, device_type, shipment_date,
+  quantity, payer — NOTHING else
+- All logs use hashed patient_id, never raw
+
+## Level 1 Stack (Active)
+- Hosting: Hostinger VPS (self-hosted, data never leaves VPS)
+- Language: Python (FastAPI or Flask)
+- Database: PostgreSQL (encrypted at rest, audit logs)
+- Orchestration: n8n self-hosted (24-hr batch trigger)
+- Notifications: Self-hosted Mailcow — encrypted email to DME staff only
+- Frontend: Simple dashboard (Vercel or self-hosted)
+- Auth: Session tokens in PostgreSQL (no Convex needed for MVP)
+
+## Active Files
+- python-backend/core/coverage_calculator.py
+- python-backend/core/audit_logger.py
+- python-backend/core/db_models.py
+- python-backend/config/payer_rules.json
+- Projects/DMEPOS/dmepos-research-v3.md (market context)
+- Projects/DMEPOS/compliance-roadmap-v1.md
+- Projects/Newsletter/newsletter-strategy-v1.md
+
+## Current BAA Obligations (Level 1 Only)
+- Hostinger VPS: Request BAA (PHI host)
+- Anthropic API: Request BAA if AI layer touches PHI
+- Everything else: self-hosted = you are the operator
+
+## Workload Impact Model (Build This)
+Two-curve graph showing supplier staff time over months:
+- Curve A: Appeals/denials workload (reactive) — starts HIGH, trends DOWN
+- Curve B: Proactive outreach via Signal CGM — starts MANAGEABLE, stays FLAT
+- X-axis: Months 1–12 post-onboarding
+- Crossover point = ROI moment to show on discovery calls
+
+## What Is Tabled (Do Not Build Yet)
+
+| Item | Phase | Reason deferred |
+|------|-------|----------------|
+| Dexcom OAuth API integration | Phase 2 | Requires vendor agreement + PHI scope expansion |
+| Prescriber fax automation | Phase 2 | Workflow complexity; Level 1 manual outreach sufficient |
+| Patient-facing SMS (Twilio, not SignalWire) | Phase 3 | PHI transmission to third-party; requires BAA + consent layer |
+| Consortium strategy (Level 2/3) | 18–24 months | Depends on 15+ paying Level 1 suppliers first |
+| Convex | Phase 2+ | Not needed until real-time sync requirements emerge |
+
+## Instructions for Claude Code Sessions
+- Work only on Level 1 scope
+- Never suggest adding PHI fields beyond patient_id
+- Flag any vendor integration that would require a new BAA
+- When building calculations, reference payer_rules.json for wear days
+- When building audit logs, always hash patient_id before storing
+- If asked about Phase 2/3, acknowledge and defer — do not spec or build