Signal: Proactive Healthcare Infrastructure starting with DMEPOS suppliers dispensing CGM supplies for T1D patients.
https://git.forgejo.sttilsolutions.com/sttil/Signal/
The worklist now shows one row per patient carrying the rollup verdict, expanding into device coverage lines with doc checklists and rule citations. Green is earned only from the readiness verdict. Kisa-approved design (mockup v2, decisions A/B/C/D/E locked 2026-07-07): purple Plan Type Needed badge + Map-the-plan-type CTA; ◇ column-not-mapped chips; not-processed strip with download; Data-gaps filter (honest labels, no sixth status); extended legend; per-line work-queue export (backend lines[] support, audit-logged). Tabs count patients. SWO/PA cycling is device-scoped and returns the re-rolled patient through the P4 echo contract; Confirm Visit fans out across the patient's echoed lines. Legacy table remains at ?legacy=1 (its DOCS_REQUIRED stopgap intentionally kept while it exists — literal deviation from the plan's remove-in-same-change line, logged). Independent audit: SHIP; its MEDIUM (line-identity merge collision) and two LOWs fixed in-commit. 171 backend tests green; frontend builds clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .claude | ||
| context | ||
| docs | ||
| n8n-workflows | ||
| pitch | ||
| python-backend | ||
| research | ||
| scripts | ||
| signal-ui | ||
| test-data | ||
| tests | ||
| .gitignore | ||
| CLAUDE.md | ||
| Dockerfile | ||
| LICENSE.md | ||
| mempalace.yaml | ||
| railway.toml | ||
| README.md | ||
| requirements.txt | ||
| TERAX.md | ||
| vercel.json | ||
Signal CGM powered by STTIL Solutions
B2B CGM documentation worklist tool for DMEPOS suppliers. Ingests CSV shipment data (Brightree/WellSky exports), calculates coverage expiration per patient using device wear-day rules, and produces a prioritized worklist for proactive outreach — so small DME teams act before claims deny, not after.
Self-hosted. Data never leaves the supplier network.
What It Does
Most DMEPOS suppliers manage CGM coverage reactively: a claim denies, then staff scramble to appeal. Signal CGM flips that. The system watches coverage windows continuously and surfaces patients approaching expiration before the denial condition exists.
- Ingests shipment CSV from Brightree or WellSky
- Calculates coverage expiration per patient per device using payer-specific wear-day rules
- Flags each patient:
REFILL_WINDOW,VISIT_DUE,OUT_OF_COVERAGE, orOK - Delivers a prioritized worklist to DME staff via encrypted email
- Staff handle outreach locally — Signal CGM never contacts patients directly
Stack
| Layer | Technology |
|---|---|
| Backend | Python / FastAPI |
| Database | PostgreSQL (encrypted at rest) |
| Orchestration | n8n (self-hosted, 24-hour batch trigger) |
| Notifications | Mailcow (self-hosted SMTP — staff email only) |
| Hosting | Hostinger VPS — data stays on-prem |
PHI Architecture
Signal CGM is designed to minimize PHI surface area:
- Sole crosswalk key:
patient_id(the supplier's internal MRN or account number). No names, SSNs, DOBs, or contact information enter the system. - DME staff maintain the
patient_id↔ real identity mapping in their own systems (Brightree, EHR, etc.). - The calculation layer sees:
patient_id,device_type,shipment_date,quantity,payer— nothing else. - All audit logs hash
patient_idbefore storage. Raw identifiers never appear in logs.
Coverage Flag Logic
| Flag | Meaning |
|---|---|
REFILL_WINDOW |
Patient is within the refillable window — safe to ship |
VISIT_DUE |
Physician visit renewal is approaching (Medicare: 180 days) |
OUT_OF_COVERAGE |
Coverage has lapsed — outreach required before next shipment |
OK |
No action needed at this time |
Directory Structure
signal-cgm/
├── python-backend/
│ ├── core/
│ │ ├── coverage_calculator.py # Coverage clock logic
│ │ ├── audit_logger.py # PHI-safe audit logging
│ │ └── db_models.py # PostgreSQL models
│ └── config/
│ └── payer_rules.json # Wear-day rules by device and payer
├── n8n-workflows/ # n8n batch trigger exports
└── CLAUDE.md # Active dev context
BAA Status (Level 1)
| Vendor | BAA Required | Status |
|---|---|---|
| Hostinger VPS | Yes — PHI host | Pending |
| Anthropic API | Only if AI layer touches PHI | Not applicable (Level 1) |
| All other components | Self-hosted — operator is STTIL | N/A |
© 2026 STTIL Solutions LLC. Proprietary software — see LICENSE.md.