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

3.3 KiB Raw Blame History Unescape Escape