cf171a3f87
- lock CORS to Vercel domain via ALLOWED_ORIGINS env var (removes allow_origins=*) - add X-API-Key header auth on /api/upload and /api/export - normalizer: add mapping confidence (high/inferred), new aliases for Acct #, Member ID, External Patient Ref, DME Description, dispensedate; 63/63 CSV files pass - coverage_calculator: add RULE_VERSION = "v0.1", rule_version on every CoverageResult - main.py: audit logging wired on upload + export, rule_version + mapping_summary in response - generate_samples.py: 25 CSV files now use 25 different real-world header formats - add generate_10k.py for 10,000-patient synthetic dataset - add tests/smoke_test.py (passes against local backend) - add docs/pilot-guide-v1.md for Robert Robinson pilot onboarding - add docs/daniel-pilot-readiness-whitepaper.md and .pdf Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
76 lines
4.1 KiB
Markdown
76 lines
4.1 KiB
Markdown
# 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
|