Signal/docs/hipaa-deployment-analysis-v1.md

Signal CGM — HIPAA Deployment Analysis v1

STTIL Solutions LLC | Confidential | April 2026

Purpose: Analyze Signal CGM's HIPAA compliance posture and deployment options in light of the 2026 HIPAA Security Rule updates. This document informs the compliance cost and timeline estimates in signal-cgm-business-model-v1.md.

---

Table of Contents

1. STTIL Solutions' Legal Position
2. 2026 HIPAA Security Rule: What's Now Mandatory
3. Three Deployment Models vs. Compliance Requirements
4. PHI Architecture Review — Signal CGM Specific
5. Pilot Strategy — Zero PHI Path

---

1. STTIL Solutions' Legal Position

Business Associate vs. Covered Entity

Signal CGM is not a covered entity. STTIL Solutions does not bill payers, provide healthcare treatment, or operate as a health plan. STTIL is a Business Associate (BA) when Signal CGM processes, creates, or transmits Protected Health Information (PHI) on behalf of a covered entity (i.e., a DMEPOS supplier billing Medicare/Medicaid).

The trigger is contact with ePHI — not the nature of STTIL's business.

COVERED ENTITY (DMEPOS Supplier)
    │
    │  Discloses patient data to run Signal CGM
    ▼
STTIL SOLUTIONS (Business Associate)
    │
    │  If STTIL sub-contracts any ePHI processing
    ▼
SUB-BA (e.g., HIPAA-eligible cloud host)

When a BAA Is Required and With Whom

Relationship	BAA Required?	Notes
STTIL ↔ DMEPOS supplier customer	Yes	Before any ePHI is processed. Required by §164.308(b)
STTIL ↔ Hosting provider (ePHI at rest)	Yes	Atlantic.Net, AWS, GCP all offer BAAs
STTIL ↔ Hostinger VPS (current Level 1)	Yes — request pending	Noted in CLAUDE.md; must be executed before ePHI contact
STTIL ↔ Anthropic (if AI layer touches ePHI)	Yes	Anthropic offers BAAs on enterprise tiers; required if the AI layer processes identifiable data
STTIL ↔ n8n (self-hosted)	No — self-hosted means STTIL is the operator	Self-hosted tools eliminate third-party BA obligations
STTIL ↔ Mailcow (self-hosted)	No — same as above	Self-hosted = no BA relationship

2026 Expanded BA Scope — What It Means for SaaS/AI Vendors

The 2026 HIPAA Security Rule updates (Final Rule published December 2024, effective March 2025, compliance deadline March 2026) did not fundamentally change who qualifies as a BA. However, they significantly raised the operational floor for all BAs:

• AI tools that process ePHI are now explicitly addressed in HHS guidance. Any AI model that receives patient identifiers — even pseudonymized ones — in the context of a covered function is likely a sub-BA.
• SaaS vendors that previously argued "we only process data, we don't store it" lost that argument definitively. Processing ePHI in transit counts.
• Software-as-a-service platforms are now held to the same mandatory controls as large health systems for the specific systems that touch ePHI.
• Audit and logging requirements now apply to AI inference endpoints that touch ePHI — not just traditional databases.

Signal CGM's PHI-minimal architecture (patient_id only, hashed logs) was designed to minimize this exposure. That design decision is now more valuable than when it was made.

---

2. 2026 HIPAA Security Rule: What's Now Mandatory

The Final Rule (45 CFR Parts 160 and 164) published December 2024 converted many previously "addressable" safeguards to mandatory. Below are the changes most directly relevant to Signal CGM.

Multi-Factor Authentication — §164.312(d)

What changed: Phishing-resistant MFA is now required for all ePHI access. SMS-based one-time codes no longer satisfy the requirement. FIDO2/WebAuthn (hardware security keys or platform authenticators like Touch ID, Windows Hello) is the standard that satisfies "phishing-resistant."

Signal CGM gap: Current Level 1 auth uses session tokens in PostgreSQL. No MFA is implemented. This is the most critical compliance gap before first ePHI contact.

Implementation options:

• Authelia (self-hosted, free) — supports FIDO2/WebAuthn; compatible with the Hostinger VPS stack
• Duo Security — $3–$6/user/mo; integrates with FastAPI; simpler to deploy
• Passkeys (native FIDO2) — can be implemented directly in the FastAPI auth layer using the py_webauthn library

Encryption — §164.312(a)(2)(iv) and §164.312(e)(2)(ii)

What changed: Encryption at rest and in transit is now mandatory (previously addressable for encryption at rest).

Specific requirements:

• At rest: AES-256 minimum for all ePHI-containing storage
• In transit: TLS 1.2 minimum; TLS 1.3 strongly recommended (and now the practical standard)

Signal CGM posture: PostgreSQL with full-disk encryption satisfies at-rest requirements if the host supports it. Hostinger VPS supports disk encryption; must be verified and documented. TLS 1.3 must be configured at the reverse proxy layer (Nginx or Caddy).

WORM-Standard Audit Logging — §164.312(b)

What changed: Audit logs must now meet a WORM (Write Once, Read Many) standard. Logs must be immutable and retained for a minimum of 6 years from the date of creation (§164.530(j) unchanged; WORM standard now explicit).

Signal CGM posture — significant strength: The existing audit_logger.py already:

• Hashes all identity fields (patient_id, user_id, IP address) via SHA-256
• Captures ISO-8601 UTC timestamps
• Writes structured JSON to PostgreSQL and the Python logging sink
• Documents the 6-year retention policy in its module docstring

Remaining gap: PostgreSQL audit_log table allows deletion (default). WORM enforcement requires one of:

1. PostgreSQL row-security policy making DELETE impossible for normal users
2. Export pipeline to immutable object storage (AWS S3 with Object Lock, or Backblaze B2 with Object Lock) on a nightly schedule
3. A dedicated WORM-compliant logging sink (Papertrail with immutable storage, or Loki with immutable volumes)

The simplest MVP solution: nightly export of audit_log rows to S3-compatible object storage with Object Lock enabled. Approx. cost: $2–$5/month at Signal CGM audit log volumes.

Annual Risk Assessment — §164.308(a)(1)(ii)(A)

What changed: Annual risk assessment is now mandatory (was addressable). The assessment must be documented, retained, and updated when operational changes occur.

What it must cover:

• Inventory of all systems touching ePHI
• Threat and vulnerability identification
• Current control assessment
• Residual risk rating
• Remediation plan with timelines

For Signal CGM at MVP stage: A self-conducted assessment using the HHS Security Risk Assessment (SRA) Tool (free, from HHS.gov) is acceptable. A one-time consultant review ($500–$1,500) is worth it before the first customer signature to ensure nothing is missed.

72-Hour ePHI Restoration — §164.312(a)(2)(ii)

What changed: Emergency access and restoration capability is now mandatory with a 72-hour restoration target for ePHI systems.

Implementation: Automated daily backups with tested restore procedures. Hostinger VPS supports automated backups. Document the restore test procedure and last test date.

Continuous Monitoring — §164.308(a)(1)(ii)(D)

What changed: Continuous monitoring of ePHI access and security controls is now explicitly required. Point-in-time assessments are not sufficient.

Practical implementation for solo founder at MVP stage:

• Log aggregation with alerting on anomalous patterns (failed logins, off-hours access, bulk data exports)
• Uptime monitoring with alert on service unavailability
• Monthly review of audit logs for anomalies

Tools: Grafana + Loki (self-hosted, free), or Papertrail ($7/mo starter).

---

3. Three Deployment Models vs. Compliance Requirements

Option A — Asset Sale to Compliant Operator

STTIL's BA Obligations After Sale: What Transfers, What Ends

Obligation	After Asset Sale
HIPAA compliance for the software	Transfers to buyer. Buyer is now the BA/operator.
Existing BAAs STTIL signed	Terminate. STTIL is no longer a BA for any downstream supplier.
Liability for pre-sale PHI processing	Remains with STTIL for the period STTIL operated the system. Statute of limitations applies.
Knowledge transfer obligations	Contractual. 30-day transfer period should be defined in the sale agreement.
Ongoing payer rule updates	Buyer's responsibility unless explicitly included in post-sale agreement.

Contracts Required at Point of Sale

1. IP Assignment Agreement — transfers copyright, trade secrets, all assets
2. Asset Sale Agreement — defines what's included, warranties, representations
3. Non-Disclosure Agreement — protects research library and market analysis
4. BAA Termination / Transition Agreement — documents when STTIL's BA obligations end and buyer assumes them (critical for clean liability handoff)
5. Knowledge Transfer Agreement — scope, duration, deliverables of the 30-day transfer period

Why This Is the Cleanest HIPAA Path Pre-Launch

If Signal CGM has not yet processed live ePHI (i.e., the sale occurs during or after the zero-PHI pilot phase but before full deployment), STTIL's actual HIPAA exposure is minimal. The buyer assumes the full compliance build-out. STTIL avoids:

• The 6–11 week compliance build effort
• Ongoing BAA management per customer
• Annual risk assessment obligation
• Continuous monitoring overhead

This is the right path if STTIL needs to exit before building the compliance stack or if the buyer is a well-resourced health IT operator who already has HIPAA infrastructure.

---

Option B — HIPAA SaaS (STTIL Solutions as Operator)

Minimum Viable Compliance Stack for First Customer

The following must be complete before any supplier customer's ePHI touches Signal CGM systems:

1. HIPAA-Eligible Hosting with BAA

Provider	BAA Available	Notes
Atlantic.Net	Yes — standard offering	HIPAA-compliant hosting product; BAA included; $50–$150/mo for VPS
AWS (EC2 + RDS)	Yes — via AWS Artifact	Most flexible; BAA covers 130+ services; $60–$200/mo at MVP scale
GCP (Compute Engine + Cloud SQL)	Yes — via Google Cloud BAA	Similar to AWS; $50–$180/mo at MVP scale
Hostinger VPS (current)	Must request	Not a standard HIPAA offering; BAA availability uncertain; do not store live ePHI until BAA is confirmed

2. FIDO2/WebAuthn MFA

• Required on all admin access, all staff user access
• Implement via Authelia (self-hosted) or Duo
• Must be in place before first ePHI contact

3. Encryption

• At rest: Full-disk encryption (provider-level) + PostgreSQL encryption confirmed
• In transit: TLS 1.3 enforced at Nginx/Caddy reverse proxy; no HTTP fallback

4. WORM Audit Logging

• Existing audit_logger.py provides the data structure — it is already HIPAA-compliant in design (hashed identifiers, structured JSON, 6-year retention policy documented)
• Add nightly export to immutable object storage (WORM enforcement)
• Verify audit_log table has appropriate delete protections

5. Documented Risk Assessment

• Use HHS SRA Tool or engage a consultant ($500–$1,500)
• Complete before first customer onboarding; update annually

6. Incident Response Plan

• Document procedures for suspected breach: detection → containment → notification
• HIPAA breach notification rule: 60-day notification to affected individuals and HHS; 500+ person breaches require media notice
• 72-hour ePHI restoration target documented and tested

7. BAA Per Customer

• Executed before any ePHI is transmitted
• Use existing BAA template as starting point; have a healthcare attorney review it

Hosting Cost Comparison

Provider	Monthly Cost (MVP)	BAA Availability	Complexity for Solo Founder
Atlantic.Net	$50–$150	Yes — standard product	Low — HIPAA hosting is their core offering; support is healthcare-aware
AWS	$60–$200	Yes — via Artifact portal	Medium — powerful but requires knowing which services are BAA-covered
GCP	$50–$180	Yes — via GCP BAA	Medium — similar to AWS
Hostinger (current)	~$20–$40	Uncertain — must request	Low cost but uncertain compliance posture for live ePHI

Recommendation for solo founder: Atlantic.Net for simplicity. Their HIPAA-compliant hosting product is designed for exactly this use case and includes the BAA as a standard part of the service agreement. AWS is the better long-term platform if scale requires it, but the overhead of managing service-level BAA coverage is higher for a solo operator.

Timeline to Compliant Launch

Step	Duration
Hosting selection + BAA execution (Atlantic.Net or AWS)	1–2 weeks
FIDO2/WebAuthn MFA implementation (Authelia or Duo)	1–2 weeks
TLS 1.3 enforcement + encryption audit	1 week
WORM audit log storage (nightly S3 export + Object Lock)	1–2 weeks
Risk assessment documentation (HHS SRA Tool)	1 week
Incident response plan	3–5 days
BAA template legal review	1–2 weeks
Total: compliant to first ePHI contact	6–11 weeks

Most steps can run in parallel. Critical path is hosting BAA execution (can take 1–2 weeks for review/signature) and MFA implementation.

Compliance Automation Tools Worth Considering at MVP Stage

Tool	Monthly Cost	What It Does
Accountable HQ	$100–$200/mo	HIPAA compliance platform: policy templates, risk assessment wizard, BAA management, training tracking
Aptible	$500+/mo	Full HIPAA-compliant deployment platform; overkill for solo founder at MVP stage but excellent if scaling
Compliancy Group	$125–$299/mo	Similar to Accountable HQ; includes "HIPAA Seal of Compliance"
HHS SRA Tool	Free	Self-guided risk assessment from HHS.gov; sufficient for MVP

Recommendation: Accountable HQ at MVP stage ($100–$200/mo). It covers the policy documentation, BAA tracking, and annual assessment workflow with minimal overhead. Graduate to Aptible if you exceed 10 customers or bring on staff.

---

Option C — Self-Deploy with Contractual Delegation

Legal Exposure for STTIL Solutions

In this model, STTIL provides Signal CGM as software the supplier self-deploys on their own infrastructure. STTIL's position: "We wrote the software; the supplier operates it."

This model does not fully eliminate STTIL's BA exposure. Under HIPAA, a BA relationship is created by the function of the software in handling ePHI, not merely by who hosts it. If STTIL provides ongoing support, updates, or access to production systems, HHS may treat STTIL as a BA regardless of the deployment agreement language.

Key risks:

• Support access to a supplier's running instance constitutes potential BA exposure — requires a BAA even in self-deploy scenarios
• Payer rule updates pushed to a running system create ongoing BA-like contact
• If a supplier mishandles PHI using STTIL's software, STTIL faces potential shared liability without a BAA in place

Why This Fails for Small DMEPOS Suppliers in 2026

Small DMEPOS suppliers (5–50 employees) typically lack:

• A dedicated IT team to manage a self-hosted deployment
• The technical capacity to implement FIDO2 MFA, WORM logging, and TLS 1.3
• Internal HIPAA compliance expertise to satisfy the 2026 mandatory controls

Self-deploy means the supplier inherits the compliance build-out. Most small suppliers will not execute it correctly, creating ePHI risk for which STTIL may share liability. This is not a viable path for Signal CGM's primary market.

What a Strong BAA + Deployment Agreement Must Say

If self-deploy is pursued (e.g., for a large health system or sophisticated DMEPOS operator), the agreement must include:

1. Clear BA/operator designation: The supplier is the BA/covered entity; STTIL's role is software licensor only
2. Security implementation warranty from the supplier: The supplier warrants it has implemented all required 2026 safeguards before deploying
3. No-support clause: STTIL provides no access to the production environment; all updates are delivered as versioned releases, not direct system access
4. Indemnification: Supplier indemnifies STTIL for any PHI breach arising from the supplier's deployment
5. Audit rights: STTIL retains the right to request documentation of the supplier's security posture annually

When Self-Deploy Might Be Appropriate

• Large health system or integrated delivery network with existing HIPAA compliance infrastructure
• DMEPOS operator with an in-house IT team and existing BAA management process
• A billing system partner (Model C) deploying Signal CGM as a module within their existing HIPAA-compliant environment

For these buyers, self-deploy reduces STTIL's compliance overhead while the buyer's existing infrastructure absorbs the implementation requirements.

---

4. PHI Architecture Review — Signal CGM Specific

Current PHI-Minimal Design Strengths

Signal CGM was architected from the start to minimize PHI surface. These design decisions are HIPAA assets, not just good engineering practice.

Design Decision	HIPAA Benefit
patient_id only (no name, SSN, DOB, contact info)	Minimizes the scope of a potential breach; reduces identifiability
SHA-256 hashing of all identity fields in audit_logger.py	Audit logs cannot be reverse-engineered to recover patient identity
Supplier maintains the patient_id ↔ identity mapping locally	PHI crosswalk never enters STTIL systems
Self-hosted default (Hostinger VPS)	Data never leaves the operator's network
payer_rules.json contains no PHI	Configuration layer is fully safe to transfer, backup, and update
n8n self-hosted orchestration	No third-party BA relationship for the batch workflow
Self-hosted Mailcow	Email notifications never touch a third-party BA

What's Already HIPAA-Ready in the Codebase

Component	Status
audit_logger.py	Fully HIPAA-aligned: hashed identifiers, UTC timestamps, 6-year retention policy documented, PostgreSQL sink
coverage_calculator.py PHI contract	PHI-minimal by design: only patient_id, device_type, shipment_date, quantity, payer accepted
db_models.py	Needs review — verify no PHI fields have been added beyond the contract
payer_rules.json	No PHI; safe
Audit log schema (audit_log table)	Structure is correct; WORM enforcement and retention automation are the remaining gap

What Gaps Remain Before First ePHI Contact

Gap	Priority	Estimated Effort
FIDO2/WebAuthn MFA on all access paths	Critical	1–2 weeks
HIPAA-eligible hosting BAA (Hostinger or migrate to Atlantic.Net/AWS)	Critical	1–2 weeks
WORM audit log enforcement (nightly S3 export with Object Lock)	High	3–5 days
TLS 1.3 enforced at reverse proxy	High	1–3 days
Documented annual risk assessment	High	1 week
Incident response plan with 72-hr restoration target	High	3–5 days
BAA template review by healthcare attorney	High	1–2 weeks
Continuous monitoring / log alerting	Medium	3–5 days
db_models.py PHI field audit	Medium	1–2 days

No gaps affect the current zero-PHI pilot path. All gaps must be closed before live ePHI from a DMEPOS supplier enters any STTIL-operated system.

---

5. Pilot Strategy — Zero PHI Path

Goal

Run a proof-of-concept pilot that generates real denial-prevention data without touching live ePHI — eliminating all HIPAA compliance obligations during the pilot phase. This enables STTIL to collect the supplier testimonials and accuracy data needed for the billing system licensing conversation (Model C) before the compliance stack is fully built.

How It Works

DMEPOS SUPPLIER                          STTIL SOLUTIONS
─────────────────────────────────────    ─────────────────────────────
Supplier exports a historical            Receives ANONYMIZED file:
shipment CSV from Brightree/WellSky      - patient_id replaced with
                                           sequential fake IDs
Supplier REPLACES patient_id             - All dates offset by a
with synthetic IDs before export           random interval
                                         - No names, SSNs, DOBs ever
Supplier RETAINS the real                  included
patient_id ↔ synthetic_id mapping
in their own system                      Signal CGM runs coverage
                                         calculation + produces worklist
                                         with SYNTHETIC IDs

                                         Supplier cross-references
                                         synthetic IDs back to real
                                         patient_id in their own system

                                         Supplier validates: did Signal CGM
                                         correctly flag the patients that
                                         actually had denials?

What Data the Supplier Provides vs. What Stays in Their System

Data Element	Supplier Action	STTIL Receives
Real patient names, SSNs, DOBs	Never exported	Nothing — not in scope
Real patient_id (MRN/account #)	Replaced with synthetic ID	Synthetic ID only
Device type	Export as-is	device_type
Shipment dates	Offset by random interval OR export as-is (not identifiable alone)	shipment_date
Quantity	Export as-is	quantity
Payer	Export as-is	payer
Synthetic_id ↔ real patient_id mapping	Stays with supplier	Nothing

Why This Avoids ePHI

A synthetic patient_id with no crosswalk accessible to STTIL is not PHI. PHI requires that the information "identifies or could reasonably be used to identify an individual" (45 CFR §160.103). A random synthetic ID with no name, SSN, DOB, or other direct identifier — and with the crosswalk held exclusively by the supplier — does not meet this definition.

Caveat: If shipment dates are not offset and the patient population is small or unique enough, re-identification could theoretically be possible. Offsetting dates by a random interval (e.g., ±30–90 days, applied uniformly within the export) eliminates this risk while preserving the coverage calculation logic (relative intervals are what matter, not absolute dates).

Pilot Duration and Data Collected

Pilot Metric	What It Proves
Coverage flag accuracy (REFILL_WINDOW, VISIT_DUE, OUT_OF_COVERAGE) vs. actual claim outcomes	Core product functionality
False positive rate (flags that didn't result in denials)	Operational burden assessment
False negative rate (denials not flagged)	Product risk assessment
Staff time saved on worklist vs. manual review	ROI narrative
Payer rule accuracy (Medicare 180-day visit cycle, refill windows)	Compliance accuracy

Suggested pilot duration: 30–60 days of historical data covering at least 100 active CGM patients. This provides sufficient volume for statistical validity.

Letter of Intent Template — Free Pilot

LETTER OF INTENT — SIGNAL CGM FREE PILOT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Date: [DATE]
Supplier: [SUPPLIER NAME]
Contact: [NAME, TITLE]
STTIL Solutions Contact: [CONTACT]

PURPOSE
This Letter of Intent confirms [SUPPLIER NAME]'s intent to
participate in a 30–60 day free proof-of-concept pilot of
Signal CGM, a documentation worklist tool for DMEPOS suppliers.

PILOT SCOPE
- Historical shipment data for approximately [N] CGM patients
- Data will be anonymized/de-identified before transfer to STTIL
  Solutions (see Data Protocol below)
- No live ePHI will be transmitted to STTIL during this pilot
- Pilot is free of charge; no payment or commitment is implied

DATA PROTOCOL
Supplier will:
1. Export a historical CGM shipment CSV from [Brightree/WellSky/other]
2. Replace all patient_id values with sequential synthetic identifiers
   (e.g., P001, P002, ...) before transfer
3. Retain the synthetic_id ↔ patient_id mapping internally
4. Offset all shipment dates by a uniform random interval before transfer

STTIL Solutions will:
1. Process the anonymized file using Signal CGM's coverage calculator
2. Return a documentation worklist with synthetic patient IDs
3. Not attempt to re-identify any patient from the anonymized data
4. Delete the anonymized data file within 30 days of pilot conclusion

SUCCESS CRITERIA
Both parties agree to evaluate the pilot against:
- Coverage flag accuracy rate
- False positive and false negative rates
- Operational value for supplier back-office staff

NO COMMITMENT
This LOI does not create a contractual obligation to purchase,
license, or continue using Signal CGM. It confirms only mutual
intent to conduct the described pilot.

Signed:

[SUPPLIER AUTHORIZED REPRESENTATIVE]          [STTIL SOLUTIONS]
Name: ____________________                    Name: ____________________
Title: ___________________                    Title: ___________________
Date: ____________________                    Date: ____________________

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

Document version: v1 | April 2026 | STTIL Solutions LLC Cross-reference: signal-cgm-business-model-v1.md 2026 HIPAA Security Rule Final Rule: 89 Fed. Reg. 25550 (Dec. 2024), effective March 2025, compliance deadline March 2026