7.7 KiB
Signal Data Handling and Minimum Necessary Fields
Version: 1.0 Date: June 7, 2026 Classification: Internal + shareable with pilot customers on request
Overview
This document describes what data Signal collects from customers, how it is processed and stored, and the minimum necessary field policy that governs what data enters Signal systems. It also documents the payer_rules.json update cadence and the MFA verification checklist required before any supplier uploads data.
Minimum Necessary Fields
Signal is designed on the principle of minimum necessary data. The only fields required for Signal to produce a documentation worklist are:
| Field | Required | Why |
|---|---|---|
| Patient identifier (internal) | Yes | De-identified crosswalk key. Patient's own MRN or account number within the supplier's system. Never a name, SSN, or DOB. |
| Device type | Yes | Determines wear-day rules and payer coverage eligibility |
| Shipment date | Yes | Anchors the supply cycle clock and visit due date calculation |
| Payer name | Yes | Determines documentation requirements (PA, PECOS, visit cadence) |
| Quantity shipped | Recommended | Improves coverage cycle accuracy; defaults to 1 if omitted |
| Component type | Optional | Defaults to "sensor" if omitted |
Doc status fields (optional — improve Signal accuracy when present):
| Field | Improves |
|---|---|
| SWO status | SWO item in doc checklist |
| Visit date | Visit date priority (confirmed over estimated) |
| PECOS verified | PECOS item in doc checklist |
| PA status | PA item in doc checklist |
| Diagnosis on file | Diagnosis item in doc checklist |
| Transfer_From | Transferred patient detection |
Customers are encouraged to include doc status fields in their CSV exports when available from their billing system. When absent, Signal uses reasonable defaults and labels estimated values clearly.
What Signal Does NOT Accept
Customers must not include the following fields in uploaded CSVs:
- Patient first or last name
- Social Security number
- Date of birth
- Home address, city, state, or ZIP
- Phone number
- Email address
- Insurance member ID (this may constitute PHI)
- Diagnosis codes (ICD-10 codes)
- Clinical notes
Signal's normalizer does not map or store these fields even if they appear in uploaded CSV headers. They are treated as unmapped noise columns and excluded from all Signal processing and storage. The normalizer discards any column header it does not recognize as a canonical Signal field.
Data Flow
Supplier staff CSV file Signal frontend (Vercel)
Signal API (Railway)
- Normalizer: maps CSV headers to canonical fields
- Minimum necessary check: only required fields extracted
- Coverage calculator: scores each patient
- patient_id hashed via SHA-256 before any storage
Supabase (PostgreSQL)
- upload_batches: filename, row_count, org_id
- normalized_records: patient_id_hash, device_type,
shipment_date, payer, coverage_status, rule_version
- confirmed_visits: org_id, patient_id_hash, confirmed_date
- audit_events: append-only (WORM enforcement pending)
Signal does not transmit any customer data to third parties. The only external services that receive any customer data are:
- Supabase (database hosting, US-east-1) — row-level security enforced on all tables
- Railway (application hosting) — no customer data stored at Railway; data in transit only
- Vercel (frontend CDN) — no customer data stored; serves frontend assets only
CSV Disposition Policy
Uploaded CSV files are:
- Received by the Signal API
- Parsed in memory
- Content hash computed (SHA-256 of raw bytes) and stored in upload metadata
- Raw bytes are NOT stored in Supabase — only the hash and row count
- Normalized field values are stored (with patient_id hashed via SHA-256)
Signal does not store copies of uploaded CSV files. The CSV is processed in memory and then discarded. Only the scored output and metadata are persisted.
Data Retention
| Data Type | Retention Period |
|---|---|
| Upload batch metadata | Duration of subscription + 90 days |
| Scored patient records (normalized_records) | Duration of subscription + 90 days |
| Confirmed visit dates | Duration of subscription + 90 days |
| Audit events | 6 years minimum (HIPAA compliance requirement, per 45 CFR §164.530(j)) |
| Source file metadata (hash only) | Duration of subscription + 90 days |
Upon written request, all customer data except audit events (which are retained for legal compliance) will be deleted within 10 business days. STTIL will confirm deletion in writing.
Supabase Plan Tier
Signal uses Supabase for its PostgreSQL database. The production plan must be Pro tier or higher before any pilot customer uploads data. Pro tier supports:
- Row-level security (RLS) — enforced on all tables
- Encrypted backups
- Point-in-time recovery
Action required before pilot: Confirm Supabase plan is Pro or higher and that all tables have RLS enabled. Run in Supabase SQL editor:
SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
All tables should show rowsecurity = true. Mark the "Supabase plan tier confirmed" item in the compliance checklist after verifying.
payer_rules.json Update Cadence
python-backend/config/payer_rules.json contains the coverage rules Signal applies when calculating documentation requirements. This file must be reviewed and updated:
- Quarterly: Review CMS LCD updates, MAC bulletins, and payer PA requirement changes for CGM
- On CMS rule publication: Update immediately when CMS publishes changes to CGM coverage (e.g., new HCPCS codes added to Required PA List, Synapse Health mandate changes, CGM competitive bidding updates)
- On Watcher Agent alert: The Watcher Agent monitors CMS.gov, MAC websites, and key payer portals for relevant rule changes and alerts Kisa. All updates to payer_rules.json require Kisa's approval before deployment.
Cadence owner: Kisa Fenn, STTIL Solutions LLC.
Next scheduled review: September 7, 2026 (90 days from launch).
Change log: Record each update in python-backend/config/payer_rules_changelog.md with the date, changed values, and the source document (LCD number, MAC bulletin, CMS rule reference) that triggered the update.
MFA Verification Checklist
All Signal administrative accounts must have MFA enabled before any supplier uploads data. The 2026 HIPAA Security Rule Final Rule (45 CFR §164.312(d)) requires phishing-resistant MFA for all ePHI access. Verify and check each item before the Gaboro pilot start date.
| Account | MFA Required | Status |
|---|---|---|
| Railway (sttilsolutionsllc@proton.me) | Yes | NOT VERIFIED |
| Supabase | Yes | NOT VERIFIED |
| Vercel | Yes | NOT VERIFIED |
| Clerk (eternal-goblin-1) | Yes | NOT VERIFIED |
| AWS (BAA account) | Yes | NOT VERIFIED |
Update this table by replacing "NOT VERIFIED" with "CONFIRMED [date]" for each account after checking MFA status in the respective platform's security settings.
Note: SMS-based one-time codes do not satisfy the 2026 phishing-resistant MFA requirement for systems touching ePHI. FIDO2/WebAuthn (hardware security key or platform authenticator such as Touch ID) is the compliant standard. For the zero-PHI pilot phase, any MFA method is sufficient. Phishing-resistant MFA is required before live patient identifiers enter Signal.