# 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