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](../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 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](../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*