strategy+compliance: business model analysis v1 + HIPAA deployment analysis v1
Three-model business analysis (asset sale, direct SaaS, distribution licensing) with compliance costs, revenue projections, phased roadmap, SSDI/SGA notes, and founder recommendation. Paired HIPAA deployment analysis covers 2026 mandatory controls, PHI architecture gaps, hosting cost comparison, and zero-PHI pilot strategy. Documents cross-reference each other. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Kisa
parent
69dcbb36c1
commit
83e823a9a0
2 changed files with 1038 additions and 0 deletions
563
Projects/Compliance/hipaa-deployment-analysis-v1.md
Normal file
563
Projects/Compliance/hipaa-deployment-analysis-v1.md
Normal file
|
|
@ -0,0 +1,563 @@
|
||||||
|
# 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](../Strategy/signal-cgm-business-model-v1.md).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [STTIL Solutions' Legal Position](#1-sttil-solutions-legal-position)
|
||||||
|
2. [2026 HIPAA Security Rule: What's Now Mandatory](#2-2026-hipaa-security-rule-whats-now-mandatory)
|
||||||
|
3. [Three Deployment Models vs. Compliance Requirements](#3-three-deployment-models-vs-compliance-requirements)
|
||||||
|
4. [PHI Architecture Review — Signal CGM Specific](#4-phi-architecture-review--signal-cgm-specific)
|
||||||
|
5. [Pilot Strategy — Zero PHI Path](#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 coverage 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 coverage 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](../Strategy/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*
|
||||||
475
Projects/Strategy/signal-cgm-business-model-v1.md
Normal file
475
Projects/Strategy/signal-cgm-business-model-v1.md
Normal file
|
|
@ -0,0 +1,475 @@
|
||||||
|
# Signal CGM — Business Model Analysis v1
|
||||||
|
### STTIL Solutions LLC | Confidential | April 2026
|
||||||
|
|
||||||
|
> **Purpose:** Evaluate three monetization paths for Signal CGM, including
|
||||||
|
> compliance obligations, delivery and customer acquisition costs, revenue
|
||||||
|
> projections, and a recommendation for a solo pre-revenue founder in 2026
|
||||||
|
> who wants to retain IP and maximize long-term upside.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [Market Baseline](#1-market-baseline)
|
||||||
|
2. [Model A — Asset Sale](#2-model-a--asset-sale)
|
||||||
|
3. [Model B — Direct SaaS Licensing to DMEPOS Suppliers](#3-model-b--direct-saas-licensing-to-dmepos-suppliers)
|
||||||
|
4. [Model C — Distribution Licensing to Billing System](#4-model-c--distribution-licensing-to-billing-system)
|
||||||
|
5. [Phased Roadmap](#5-phased-roadmap)
|
||||||
|
6. [Revenue Milestone Table](#6-revenue-milestone-table)
|
||||||
|
7. [SSDI/SGA Risk Notes by Phase](#7-ssdisga-risk-notes-by-phase)
|
||||||
|
8. [Founder Recommendation](#8-founder-recommendation)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Market Baseline
|
||||||
|
|
||||||
|
| Metric | Figure | Basis |
|
||||||
|
|--------|--------|-------|
|
||||||
|
| Medicare-enrolled DMEPOS suppliers billing CGM | ~7,500 | CMS data, Signal CGM TAM estimate |
|
||||||
|
| CMS projected CGM beneficiaries by 2028 | 3.2 million | CMS projections |
|
||||||
|
| Improper Medicare CGM payments (2024) | ~$278.5M | CMS OIG report |
|
||||||
|
| DMEPOS total Medicare spend | $7B+ annually | OIG |
|
||||||
|
| Target supplier size | 5–50 employees | Most common segment |
|
||||||
|
|
||||||
|
**TAM math (annual recurring revenue):**
|
||||||
|
|
||||||
|
```
|
||||||
|
1% penetration (75 suppliers) × $3,600 ARR = $270K ARR
|
||||||
|
3% penetration (225 suppliers) × $3,600 ARR = $810K ARR
|
||||||
|
5% penetration (375 suppliers) × $3,600 ARR = $1.35M ARR
|
||||||
|
```
|
||||||
|
|
||||||
|
**Key 2026 urgency drivers:**
|
||||||
|
|
||||||
|
- CMS expanded prior authorization requirements effective April 13, 2026
|
||||||
|
- 2028 Competitive Bidding expansion to CGM categories → margin compression
|
||||||
|
- CMS enrollment moratoria tightening the supplier pool → consolidation pressure
|
||||||
|
- 2026 HIPAA Security Rule updates adding mandatory compliance costs
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Model A — Asset Sale
|
||||||
|
|
||||||
|
### Overview
|
||||||
|
|
||||||
|
A one-time sale of the full Signal CGM asset package to a qualified buyer.
|
||||||
|
No ongoing operational obligations for STTIL Solutions after the knowledge
|
||||||
|
transfer period.
|
||||||
|
|
||||||
|
**Price range:** $25,000 – $60,000 (one-time)
|
||||||
|
|
||||||
|
### What the Buyer Inherits
|
||||||
|
|
||||||
|
| Asset | Description |
|
||||||
|
|-------|-------------|
|
||||||
|
| Full source code | Python/FastAPI backend, coverage_calculator.py, audit_logger.py, db_models.py, payer_rules.json |
|
||||||
|
| Research library | dmepos-research-v3.md, compliance roadmap, CB/PA regulatory analysis |
|
||||||
|
| BAA templates | Hostinger VPS BAA request template; operator BAA framework for customer agreements |
|
||||||
|
| Newsletter strategy | Subscriber acquisition strategy for DMEPOS supplier outreach |
|
||||||
|
| n8n workflows | Self-hosted batch trigger workflow exports |
|
||||||
|
| CLAUDE.md handoff | Full AI-assisted development context — new owner continues building without ramp-up loss |
|
||||||
|
| 30-day knowledge transfer | Live sessions covering architecture, payer rule updates, compliance posture, go-to-market |
|
||||||
|
|
||||||
|
### IP Transfer Implications
|
||||||
|
|
||||||
|
- **Full IP assignment:** All copyright, trade secrets, and documentation
|
||||||
|
transfer to buyer on payment. STTIL Solutions retains no license unless
|
||||||
|
negotiated.
|
||||||
|
- **PHI exposure ends:** STTIL's Business Associate obligations to any
|
||||||
|
future buyer-operated system are governed by the buyer's BAAs, not STTIL's.
|
||||||
|
- **No residual royalty** in the standard asset sale structure — buyer owns it
|
||||||
|
outright. This is the simplest exit but permanently caps STTIL's upside.
|
||||||
|
- **Confidentiality:** Buyer likely requires an NDA covering the research
|
||||||
|
library and market analysis. Build this into the sale agreement.
|
||||||
|
|
||||||
|
### Cost Structure (STTIL Side)
|
||||||
|
|
||||||
|
| Cost Item | Estimate |
|
||||||
|
|-----------|----------|
|
||||||
|
| Legal: IP assignment agreement + NDA | $1,500 – $3,000 |
|
||||||
|
| Knowledge transfer labor (30 days) | 40–80 hours founder time |
|
||||||
|
| Opportunity cost of not operating | Forgone SaaS ARR (see Model B) |
|
||||||
|
| **Net proceeds at $35K sale** | ~$31,500–$33,500 after legal |
|
||||||
|
|
||||||
|
### When Asset Sale Makes Sense
|
||||||
|
|
||||||
|
- Founder needs immediate liquidity
|
||||||
|
- No bandwidth to manage compliance, support, or customer success
|
||||||
|
- Buyer is a DMEPOS operator who can deploy immediately (direct ROI case)
|
||||||
|
- Regulatory risk (HIPAA compliance overhead) is not worth the SaaS upside
|
||||||
|
|
||||||
|
### When Asset Sale Does NOT Make Sense
|
||||||
|
|
||||||
|
- **Pre-proof-of-concept sale undervalues the asset.** Without a single
|
||||||
|
paying customer or pilot result, the buyer is pricing in maximum risk.
|
||||||
|
Even one supplier testimonial — "Signal CGM prevented X denials in 30 days"
|
||||||
|
— can move the negotiating floor from $25K to $45K or higher.
|
||||||
|
- When a billing system deal (Model C) is realistically achievable. A
|
||||||
|
$100K–$200K licensing fee + royalties makes a $35K asset sale look
|
||||||
|
like a distress sale in hindsight.
|
||||||
|
- When the founder has SaaS operational capacity and wants recurring income.
|
||||||
|
|
||||||
|
**Validated assumption:** The $25K–$60K range is consistent with early-stage
|
||||||
|
healthcare IT tools at pre-revenue stage. Post-pilot with documented denial
|
||||||
|
reduction data, a $60K–$100K range is defensible. The upper end ($200K+)
|
||||||
|
requires a billing system acquirer or consortium structure.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Model B — Direct SaaS Licensing to DMEPOS Suppliers
|
||||||
|
|
||||||
|
### Overview
|
||||||
|
|
||||||
|
STTIL Solutions operates Signal CGM as a hosted SaaS and licenses access
|
||||||
|
to individual DMEPOS suppliers on a monthly subscription basis.
|
||||||
|
|
||||||
|
> **HIPAA compliance note:** Operating as a SaaS with supplier ePHI contact
|
||||||
|
> makes STTIL Solutions a Business Associate under HIPAA. This triggers
|
||||||
|
> mandatory compliance obligations. See
|
||||||
|
> [hipaa-deployment-analysis-v1.md](../Compliance/hipaa-deployment-analysis-v1.md)
|
||||||
|
> for the full technical and legal analysis, including the minimum viable
|
||||||
|
> compliance stack, hosting cost comparison, and realistic launch timeline.
|
||||||
|
> The cost and timeline estimates in this section are derived from that analysis.
|
||||||
|
|
||||||
|
### Pricing Model
|
||||||
|
|
||||||
|
| Tier | Monthly Price | Annual ARR per Supplier | Assumed Supplier Size |
|
||||||
|
|------|--------------|------------------------|----------------------|
|
||||||
|
| Starter | $200/mo | $2,400 | 1–200 CGM patients |
|
||||||
|
| Growth | $350/mo | $4,200 | 200–1,000 CGM patients |
|
||||||
|
| Pro | $500/mo | $6,000 | 1,000+ CGM patients |
|
||||||
|
|
||||||
|
**Blended assumption:** $300/mo average across the mix = $3,600 ARR/supplier.
|
||||||
|
This is conservative; denial prevention ROI at even $300/mo is compelling
|
||||||
|
for a supplier losing $500–$2,000/month on avoidable denials.
|
||||||
|
|
||||||
|
**Assumption validation:** DMEPOS back-office software (Brightree, WellSky)
|
||||||
|
runs $200–$600/mo per module. Signal CGM at $200–$500/mo is within the
|
||||||
|
established price tolerance for this buyer. The ROI case is direct:
|
||||||
|
one prevented denial per month at ~$150–$400 average CGM claim value
|
||||||
|
pays for the tool. This pricing is supportable.
|
||||||
|
|
||||||
|
### Revenue Projections
|
||||||
|
|
||||||
|
```
|
||||||
|
TAM: ~7,500 Medicare-enrolled DMEPOS suppliers billing CGM
|
||||||
|
|
||||||
|
Penetration | Suppliers | MRR | ARR
|
||||||
|
────────────┼───────────┼───────────┼──────────
|
||||||
|
1% │ 75 │ $22,500 │ $270K
|
||||||
|
3% │ 225 │ $67,500 │ $810K
|
||||||
|
5% │ 375 │ $112,500 │ $1.35M
|
||||||
|
```
|
||||||
|
|
||||||
|
Realistic Year 1 ceiling (solo founder, no sales team): 10–25 suppliers = $36K–$90K ARR.
|
||||||
|
|
||||||
|
### HIPAA SaaS Compliance Requirements and Costs
|
||||||
|
|
||||||
|
Operating as a SaaS means STTIL touches supplier ePHI (patient_id mapped
|
||||||
|
against shipment records), making STTIL a Business Associate. The 2026
|
||||||
|
HIPAA Security Rule updates add mandatory requirements previously listed
|
||||||
|
as "addressable." Full detail in
|
||||||
|
[hipaa-deployment-analysis-v1.md](../Compliance/hipaa-deployment-analysis-v1.md).
|
||||||
|
|
||||||
|
**Estimated minimum compliance stack cost (Year 1):**
|
||||||
|
|
||||||
|
| Item | Annual Cost |
|
||||||
|
|------|-------------|
|
||||||
|
| HIPAA-eligible hosting with BAA (Atlantic.Net or AWS) | $1,200 – $3,600 |
|
||||||
|
| Compliance platform (Accountable HQ or similar) | $1,200 – $2,400 |
|
||||||
|
| FIDO2 MFA implementation (Duo or Authelia) | $0 – $600 |
|
||||||
|
| Legal: BAA templates per customer + policy docs | $2,000 – $4,000 |
|
||||||
|
| Annual risk assessment (internal or consultant) | $500 – $2,000 |
|
||||||
|
| Incident response planning | $500 – $1,000 |
|
||||||
|
| **Total Year 1 compliance overhead** | **$5,400 – $13,600** |
|
||||||
|
|
||||||
|
**Break-even analysis:** At $300/mo average, compliance overhead is
|
||||||
|
covered by 2–4 paying suppliers. This is achievable in Year 1 if
|
||||||
|
the pilot strategy (see Section 5 of the HIPAA analysis) generates
|
||||||
|
even one paying customer.
|
||||||
|
|
||||||
|
### BAA Obligations Per Customer
|
||||||
|
|
||||||
|
Every DMEPOS supplier customer requires:
|
||||||
|
1. A signed **Business Associate Agreement** before any ePHI is processed
|
||||||
|
2. A customer-specific **data processing addendum** covering scope
|
||||||
|
3. Documented security review in STTIL's risk assessment
|
||||||
|
|
||||||
|
The existing BAA template in the asset package is a starting point. A
|
||||||
|
healthcare attorney review ($500–$1,500) is recommended before first
|
||||||
|
customer signature.
|
||||||
|
|
||||||
|
### Minimum Viable Compliance Stack Before First Customer
|
||||||
|
|
||||||
|
1. HIPAA-eligible hosting provider with signed BAA
|
||||||
|
2. FIDO2/WebAuthn MFA on all admin and staff access paths
|
||||||
|
3. AES-256 encryption at rest; TLS 1.3 in transit
|
||||||
|
4. WORM audit logging tied to existing `audit_logger.py` (6-year retention)
|
||||||
|
5. Documented annual risk assessment
|
||||||
|
6. Signed incident response plan (72-hour ePHI restoration target)
|
||||||
|
7. BAA executed with each customer before onboarding
|
||||||
|
|
||||||
|
**The existing `audit_logger.py` already satisfies the audit log
|
||||||
|
architecture requirement.** The gap is WORM storage enforcement — PostgreSQL
|
||||||
|
must be configured with append-only log tables or exported to immutable
|
||||||
|
object storage (S3 with Object Lock, or equivalent).
|
||||||
|
|
||||||
|
### Timeline to Compliant Launch
|
||||||
|
|
||||||
|
| Milestone | Estimated Duration |
|
||||||
|
|-----------|--------------------|
|
||||||
|
| Hosting selection + BAA execution | 1–2 weeks |
|
||||||
|
| FIDO2 MFA integration | 1–2 weeks |
|
||||||
|
| Encryption audit + TLS hardening | 1 week |
|
||||||
|
| WORM audit log storage implementation | 1–2 weeks |
|
||||||
|
| Risk assessment documentation | 1 week |
|
||||||
|
| BAA template legal review | 1–2 weeks |
|
||||||
|
| **Total: compliant to first customer** | **6–11 weeks** |
|
||||||
|
|
||||||
|
**> Consult WIPA before Phase 2** (see Section 7)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Model C — Distribution Licensing to Billing System
|
||||||
|
|
||||||
|
### Overview
|
||||||
|
|
||||||
|
License Signal CGM to an existing DMEPOS billing system or software
|
||||||
|
platform (Brightree, WellSky, Niko Health, or similar) as a white-label
|
||||||
|
module or integrated feature. STTIL Solutions receives an upfront license
|
||||||
|
fee plus ongoing royalties.
|
||||||
|
|
||||||
|
### Target Companies
|
||||||
|
|
||||||
|
| Company | Why They're a Fit |
|
||||||
|
|---------|------------------|
|
||||||
|
| **Brightree** (ResMed subsidiary) | Largest DMEPOS billing platform; CGM is a growth category in their customer base |
|
||||||
|
| **WellSky** | Major post-acute and home health platform; DMEPOS billing module customers need this |
|
||||||
|
| **Niko Health** | CGM-focused billing platform — most directly aligned with Signal CGM's use case |
|
||||||
|
| **Bonafide DME** | Regional but CGM-specialized; potential pilot-to-license path |
|
||||||
|
| **Intermedix / R1 RCM** | Revenue cycle management at scale; denial prevention is core to their value prop |
|
||||||
|
|
||||||
|
### White-Label / Integration Licensing Structure
|
||||||
|
|
||||||
|
**Option 1 — White-label OEM**
|
||||||
|
- Billing system rebrands Signal CGM as their own module
|
||||||
|
- STTIL provides code + documentation + update cadence
|
||||||
|
- Billing system handles all HIPAA compliance, BAAs, customer support
|
||||||
|
- STTIL's obligations: deliver working software, maintain payer rules, provide updates
|
||||||
|
|
||||||
|
**Option 2 — API integration**
|
||||||
|
- Signal CGM runs as a STTIL-operated microservice
|
||||||
|
- Billing system calls STTIL's API per worklist calculation
|
||||||
|
- Billing system owns the customer relationship; STTIL is a BA to the billing system
|
||||||
|
- Requires STTIL to maintain HIPAA compliance posture (similar to Model B)
|
||||||
|
|
||||||
|
**Recommendation:** White-label OEM (Option 1) is cleaner for a solo
|
||||||
|
founder. STTIL delivers IP and updates; compliance burden passes to
|
||||||
|
the buyer entity.
|
||||||
|
|
||||||
|
### Fee Structure
|
||||||
|
|
||||||
|
| Component | Range |
|
||||||
|
|-----------|-------|
|
||||||
|
| Upfront license fee | $50,000 – $200,000 |
|
||||||
|
| Per-supplier royalty (ongoing) | $10 – $30/mo per supplier on platform |
|
||||||
|
| Annual maintenance fee | 15–20% of upfront fee |
|
||||||
|
|
||||||
|
**Royalty projection:**
|
||||||
|
```
|
||||||
|
Brightree has 10,000+ DMEPOS customers.
|
||||||
|
If 20% use CGM billing: 2,000 suppliers.
|
||||||
|
At $15/mo royalty: $30,000/mo = $360K ARR (royalty only)
|
||||||
|
Plus $100K upfront = strong deal economics.
|
||||||
|
```
|
||||||
|
|
||||||
|
**Assumption validation:** $50K–$200K is consistent with healthcare software
|
||||||
|
module licensing at pre-scale stage. Niko Health or a regional platform
|
||||||
|
might start at $50K–$75K. Brightree would likely start at $100K+ but
|
||||||
|
requires more proof of concept. These numbers are negotiable; the royalty
|
||||||
|
stream is the long-term value.
|
||||||
|
|
||||||
|
### IP Protection — What Transfers vs. What Stays
|
||||||
|
|
||||||
|
| What Transfers (License) | What Stays with STTIL |
|
||||||
|
|--------------------------|----------------------|
|
||||||
|
| Right to use, embed, and white-label the software | Copyright and ownership |
|
||||||
|
| Access to payer rules config updates | Right to license to other platforms |
|
||||||
|
| Integration documentation | Future research and improvements |
|
||||||
|
| 12–24 month update cadence | Right to terminate for non-payment |
|
||||||
|
|
||||||
|
**Key contract terms to require:**
|
||||||
|
- Field-of-use restriction (DMEPOS billing only — no resale to competitors)
|
||||||
|
- Source code escrow for business continuity
|
||||||
|
- Audit rights on royalty reporting
|
||||||
|
- Termination-for-cause with reversion of deployed copies
|
||||||
|
|
||||||
|
### Why This Is Strategically Superior to Individual SaaS
|
||||||
|
|
||||||
|
1. **Customer acquisition cost near zero.** Billing system already has 2,000+
|
||||||
|
supplier relationships. STTIL acquires those customers through one deal.
|
||||||
|
2. **No per-customer BAA management.** White-label shifts compliance to the
|
||||||
|
licensee. STTIL's HIPAA obligations are contained in the licensing agreement.
|
||||||
|
3. **Revenue concentration risk is real** (single large customer dependency),
|
||||||
|
but the upfront fee de-risks the first 12–18 months.
|
||||||
|
4. **Faster to scale** than signing 200 individual SaaS customers.
|
||||||
|
|
||||||
|
### What Proof-of-Concept Data Makes This Deal Easier to Close
|
||||||
|
|
||||||
|
A billing system will not pay $100K+ on a concept alone. The most useful
|
||||||
|
proof points:
|
||||||
|
|
||||||
|
| Proof Point | Impact on Deal |
|
||||||
|
|-------------|---------------|
|
||||||
|
| 1–3 pilot supplier testimonials with denial reduction data | Moves floor from concept to validated tool |
|
||||||
|
| Worklist accuracy rate (coverage flags vs. actual claim outcomes) | Demonstrates technical reliability |
|
||||||
|
| Payer rule accuracy across Medicare + 1–2 MACs | Shows maintenance commitment |
|
||||||
|
| Prior authorization flag performance (post-April 2026) | Directly relevant to 2026 urgency narrative |
|
||||||
|
|
||||||
|
**The zero-PHI pilot strategy** (see hipaa-deployment-analysis-v1.md,
|
||||||
|
Section 5) is specifically designed to generate this proof-of-concept
|
||||||
|
data before STTIL is fully HIPAA compliant — enabling early deal conversations
|
||||||
|
with billing system partners.
|
||||||
|
|
||||||
|
### Initial Approach Strategy
|
||||||
|
|
||||||
|
1. **Niko Health first** — smallest and most CGM-aligned; most likely to move quickly
|
||||||
|
2. **Request a product demo slot** at NHIA 2026 or AAHomecare meeting
|
||||||
|
3. **Lead with the denial prevention ROI story** + the April 2026 PA expansion urgency
|
||||||
|
4. **Offer a structured pilot:** 30-day free integration, shared denial data results
|
||||||
|
5. **Brightree / WellSky:** Approach through their partner/integration program after
|
||||||
|
Niko validation. These require a more established proof base.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Phased Roadmap
|
||||||
|
|
||||||
|
```
|
||||||
|
PHASE 0 — FOUNDATION (Now → Month 2)
|
||||||
|
─────────────────────────────────────────────────────────────
|
||||||
|
Goal: Zero-PHI pilot ready; compliance posture documented
|
||||||
|
□ Finalize synthetic dataset for demo/pilot
|
||||||
|
□ HIPAA compliance stack selection (hosting + BAA)
|
||||||
|
□ BAA template legal review
|
||||||
|
□ Letter of Intent template for free pilots
|
||||||
|
□ Niko Health outreach initiated
|
||||||
|
─ No ePHI touches at this phase ─
|
||||||
|
Revenue: $0
|
||||||
|
|
||||||
|
PHASE 1 — PILOT (Month 2 → Month 5)
|
||||||
|
─────────────────────────────────────────────────────────────
|
||||||
|
Goal: 1–3 supplier pilots running; proof-of-concept data collected
|
||||||
|
□ 1–3 DMEPOS suppliers on free pilot (synthetic or anonymized data)
|
||||||
|
□ Denial flag accuracy validated against real claim outcomes
|
||||||
|
□ Testimonials / case study data collected
|
||||||
|
□ Billing system introductory meetings scheduled
|
||||||
|
□ HIPAA compliance stack operational (if transitioning to live ePHI)
|
||||||
|
Revenue: $0 (pilots are free)
|
||||||
|
Key gate: At least 1 supplier can document denial reduction
|
||||||
|
|
||||||
|
PHASE 2 — FIRST LICENSE (Month 5 → Month 12)
|
||||||
|
─────────────────────────────────────────────────────────────
|
||||||
|
Goal: First paying customer(s); billing system deal in pipeline
|
||||||
|
□ 1–5 paying SaaS customers (Model B) OR
|
||||||
|
□ Letter of Intent from billing system partner (Model C)
|
||||||
|
□ Full HIPAA compliance stack operational with signed BAAs
|
||||||
|
□ Annual risk assessment documented
|
||||||
|
□ Revenue begins
|
||||||
|
⚠️ CONSULT WIPA BEFORE PHASE 2 (see Section 7)
|
||||||
|
Revenue: $3,600–$18,000 ARR (SaaS) or $50K–$200K (licensing deal)
|
||||||
|
|
||||||
|
PHASE 3 — SCALE (Month 12+)
|
||||||
|
─────────────────────────────────────────────────────────────
|
||||||
|
Goal: Distribution licensing executed; recurring revenue stable
|
||||||
|
□ Billing system white-label deal closed
|
||||||
|
□ Royalty stream established
|
||||||
|
□ Signal CGM payer rules updated for 2027 changes
|
||||||
|
□ Evaluate consortium / buying group strategy (Level 2/3)
|
||||||
|
Revenue: $100K+ ARR target
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Revenue Milestone Table
|
||||||
|
|
||||||
|
| Phase | Timeline | Model | Revenue Target | Key Milestone |
|
||||||
|
|-------|----------|-------|---------------|---------------|
|
||||||
|
| 0 — Foundation | Month 0–2 | — | $0 | Pilot ready, HIPAA posture documented |
|
||||||
|
| 1 — Pilot | Month 2–5 | Free pilot | $0 | Denial reduction data collected |
|
||||||
|
| 2A — First SaaS | Month 5–8 | Model B | $3,600–$18,000 ARR | 1–5 paying suppliers |
|
||||||
|
| 2B — Licensing LOI | Month 6–12 | Model C | $50K–$200K (one-time) | Billing system LOI signed |
|
||||||
|
| 3 — Distribution | Month 12–18 | Model C + B | $100K–$400K ARR | Royalty stream active |
|
||||||
|
| 4 — Scale | Month 18–24 | Model C primary | $360K+ ARR | 2,000+ suppliers via platform |
|
||||||
|
|
||||||
|
**Note on Model A:** Asset sale remains available at any phase. Post-pilot
|
||||||
|
(Phase 1 complete), a realistic asset sale price is $45,000–$75,000. Post-
|
||||||
|
first-license (Phase 2 complete), the range is $100,000–$200,000. Waiting
|
||||||
|
for proof of concept before selling is almost always the right decision.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. SSDI/SGA Risk Notes by Phase
|
||||||
|
|
||||||
|
> **Disclaimer:** This is general context, not legal or benefits advice.
|
||||||
|
> SSDI/SGA rules are complex and individual. Always consult a WIPA
|
||||||
|
> (Work Incentive Planning and Assistance) counselor before generating
|
||||||
|
> business income that could affect benefit status.
|
||||||
|
|
||||||
|
| Phase | SSDI/SGA Consideration |
|
||||||
|
|-------|----------------------|
|
||||||
|
| **Phase 0 — Foundation** | Research, development, and documentation activity. No earned income generated. Standard Trial Work Period rules may not yet be triggered. Low risk. |
|
||||||
|
| **Phase 1 — Pilot** | Free pilots generate no revenue. Time invested is not compensated. Monitor if consulting or advisory services emerge from pilot relationships. |
|
||||||
|
| **Phase 2 — First License** | ⚠️ **Revenue begins here. CONSULT WIPA BEFORE PHASE 2.** SaaS subscription income and one-time licensing fees may count as earned income or Unearned Income depending on structure (see SSDI vs. SSI rules). LLC structure and active vs. passive income classification matter. |
|
||||||
|
| **Phase 3 — Scale** | Ongoing royalty income classification (earned vs. unearned) depends on the degree of active management. Royalty streams from IP licensing may be treated differently than SaaS subscription income. Requires WIPA guidance. |
|
||||||
|
|
||||||
|
**Action item:** Contact a WIPA counselor before signing a first customer
|
||||||
|
or accepting any payment, regardless of structure. The Social Security
|
||||||
|
Administration's treatment of self-employment income can be counterintuitive.
|
||||||
|
WIPA counselors are free; find one at benefitsinfo.ssa.gov.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Founder Recommendation
|
||||||
|
|
||||||
|
**For a solo, pre-revenue founder in 2026 who wants to retain IP
|
||||||
|
and maximize long-term upside:**
|
||||||
|
|
||||||
|
**Pursue Model C (Distribution Licensing) as the primary path,
|
||||||
|
using Model B pilots as the proof-of-concept engine.**
|
||||||
|
|
||||||
|
The specific sequence:
|
||||||
|
|
||||||
|
1. **Do not sell the asset yet (not Model A).** A $35K asset sale before
|
||||||
|
proof of concept is a permanent exit at the worst possible valuation
|
||||||
|
moment. The upside of a billing system deal ($100K+ upfront + royalties)
|
||||||
|
is an order of magnitude larger. The option to sell always remains open —
|
||||||
|
take it off the table only when necessary.
|
||||||
|
|
||||||
|
2. **Run 1–3 free pilots using the zero-PHI path** (synthetic data, no
|
||||||
|
ePHI contact). This costs nothing in compliance overhead and generates
|
||||||
|
the denial-reduction proof points that make the billing system
|
||||||
|
conversation credible.
|
||||||
|
|
||||||
|
3. **Approach Niko Health first.** They are the most CGM-focused billing
|
||||||
|
platform and the most likely to move quickly on a licensing conversation
|
||||||
|
with a validated pilot behind it. Use AAHomecare or NHIA conferences
|
||||||
|
as access points.
|
||||||
|
|
||||||
|
4. **Build the HIPAA compliance stack in parallel** (6–11 weeks effort)
|
||||||
|
so you can convert pilot suppliers to paying SaaS customers if the
|
||||||
|
billing system deal moves slowly. Model B provides cash flow while
|
||||||
|
Model C deal terms are negotiated.
|
||||||
|
|
||||||
|
5. **Retain all IP.** License only. Structure every agreement with
|
||||||
|
field-of-use restrictions, royalty audit rights, and termination-for-
|
||||||
|
cause with software reversion. Your ongoing payer rule updates are
|
||||||
|
the stickiness mechanism — build this into the license structure.
|
||||||
|
|
||||||
|
**The single most important action in the next 30 days:** Execute one
|
||||||
|
free pilot with a real DMEPOS supplier using synthetic or anonymized data.
|
||||||
|
That pilot is the proof point that unlocks everything else.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Document version: v1 | April 2026 | STTIL Solutions LLC*
|
||||||
|
*Cross-reference: [hipaa-deployment-analysis-v1.md](../Compliance/hipaa-deployment-analysis-v1.md)*
|
||||||
Loading…
Reference in a new issue