Signal/CLAUDE.md

STTIL Solutions — Signal | Level 1 Active Context

What This Tool Does

Signal is a B2B CGM documentation readiness tracker for DMEPOS suppliers. It ingests order data from any DME order management CSV export (e.g., Brightree), evaluates each patient against documentation requirements (6-month qualifying visit, PECOS enrollment, SWO, resupply eligibility), and produces a Signal Report so supplier staff can prioritize outreach and capture revenue before it leaks. NOTE: Signal identifies gaps. It does not conduct outreach. Never write copy implying Signal contacts prescribers or patients directly.

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/config/payer_rules.json
• research/dmepos-research-v3.md (market context)
• docs/hipaa-deployment-analysis-v1.md (compliance)
• docs/sttil-brand-system-v1.md (brand)

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 — 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
AWS infrastructure (any service)	Post-pilot	Jakub (coach, 2026-05-28): mock data is sufficient for demos and pilots. AWS takes 2 hours to set up — do it right before signing live PHI contracts. Do not start during MVP or pilot phase.
Dexcom OAuth API integration	Phase 2	Requires vendor agreement + PHI scope expansion
Billing system API integration (Brightree, Bonafide, Fastrack, etc.)	Phase 2	Build after pilot reveals which systems suppliers use; vendor agreements required; PHI scope expands significantly
CMS and contact management integration (Salesforce, etc.)	Phase 2	Pilot feedback will reveal if suppliers have CMS and what they use; do not assume
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
• Use "resupply" not "refill". CGM supply allowances are exempt from Medicare refill rules