sttil/Signal
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update Signal brand language and add pitch/build artifacts

Browse source 
- Remove 'coverage' from worklist description across all docs
- Add whitepaper v2, documentation gap whitepaper, gate demo, sample
- Add TERAX.md, Claude Code settings, test-data generator
- Add settings.local.json to .gitignore

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Kisa 2026-05-28 10:14:16 -04:00
parent a424ac9d13
commit c2141a127a
12 changed files with 1308 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
.claude/settings.json Normal file
View file

@ -0,0 +1,16 @@
{
"permissions": {
"allow": [
"mcp__mempalace__mempalace_kg_query",
"mcp__mempalace__mempalace_search",
"mcp__trilane__trilane_search",
"mcp__mempalace__mempalace_status",
"mcp__mempalace__mempalace_diary_read",
"mcp__granola__get_account_info",
"mcp__trilane__trilane_list_workspaces",
"Bash(launchctl list *)",
"Bash(launchctl print *)",
"Bash(brew list *)"
]
}
}

1
.gitignore vendored
View file

@ -8,3 +8,4 @@ data/
node_modules/
.DS_Store
.vercel
.claude/settings.local.json

2
README.md
View file

@ -1,6 +1,6 @@
# Signal CGM powered by STTIL Solutions
B2B CGM coverage worklist tool for DMEPOS suppliers. Ingests CSV shipment data
B2B CGM documentation worklist tool for DMEPOS suppliers. Ingests CSV shipment data
(Brightree/WellSky exports), calculates coverage expiration per patient using
device wear-day rules, and produces a prioritized worklist for proactive outreach
— so small DME teams act before claims deny, not after.

127
TERAX.md Normal file
View file

@ -0,0 +1,127 @@
# Signal — Terax AI Context
> Dev and terminal work only. Strategy, brand, and pilot decisions stay in Claude Code.
> Use @path references in the AI Composer to pull in specific files before asking questions.
---
## What Signal Does
Signal is a B2B CGM documentation readiness tracker for DMEPOS suppliers. A supplier exports their order data as a CSV (from Brightree or similar), Signal evaluates each patient against documentation requirements (6-month qualifying visit, PECOS enrollment, SWO, resupply eligibility), and produces a stoplight report so staff can prioritize outreach before claims are submitted.
Signal identifies gaps. It does not contact anyone.
**Core value:** Shifts supplier staff time from reactive (denial appeals after the fact) to proactive (preventing denial conditions before supplies ship).
---
## PHI Architecture — Non-Negotiable
- STTIL never stores patient names, SSNs, DOBs, or contact info
- Sole crosswalk key: `patient_id` (the DME's internal MRN or account number)
- AI/calculation layer sees: `patient_id`, `device_type`, `shipment_date`, `quantity`, `payer` — nothing else
- All logs hash `patient_id` before storing — never raw
- If a proposed change would require storing additional PHI fields, stop and flag it
---
## Level 1 Stack (Active)
| Layer | Tool |
|-------|------|
| Hosting | Hostinger VPS — data never leaves VPS |
| Language | Python (FastAPI) |
| Database | PostgreSQL (encrypted at rest, audit logs) |
| Orchestration | n8n self-hosted (24-hr batch trigger) |
| Notifications | Self-hosted Mailcow — encrypted email to DME staff only |
| Frontend | signal-ui/ |
---
## Active Files — Start Here
```
python-backend/core/coverage_calculator.py # main eligibility logic
python-backend/core/audit_logger.py # hashed logging
python-backend/config/payer_rules.json # wear days and payer rules — reference for all calculations
signal-ui/ # frontend
research/dmepos-research-v3.md # full market context + verified stat index (updated May 2026)
research/cgm-market-research-synthesis-v1.md # stat verification summary (May 2026)
docs/hipaa-deployment-analysis-v1.md # compliance reference
docs/sttil-brand-system-v1.md # brand (read-only reference)
pitch/ # pitch assets and whitepaper
```
---
## Market Context — Key Verified Stats (May 2026)
Use these. Do not invent or derive alternatives.
| Stat | Source | Use For |
|------|--------|---------|
| 30.86% pre-pay error rate | CGS MAC Jurisdiction B Q2 2024 | Denial prevention pitch — measures near-submission risk |
| 32.8% error rate / 68.6% from docs | CERT 2019 | LinkedIn and public copy — "nearly 1 in 3", "over two-thirds from docs" |
| 67.6% absent documentation | CMS 2024 MLN | Whitepaper / gate framing — post-payment audit |
| $1.9B DMEPOS improper payments | OIG FY2024 | Market context only |
**Do not use:** "94.2%" (derived, not citable), "63% write-off" (modeled, not citable).
Full verified stat table: `research/dmepos-research-v3.md` Section 14.
---
## Urgency Anchors (Active)
- Synapse Health mandatory for Medicare CGM: August 1, 2026
- PA exemption cycle (90% affirmation rate): June 1, 2026 first cycle
- 7 new HCPCS codes added to Required PA List: April 13, 2026
- DMEPOS enrollment moratorium in effect: February 27, 2026
- CGM competitive bidding: January 1, 2028
---
## What Is Tabled — Do Not Build
| Item | Why |
|------|-----|
| Dexcom OAuth API | Requires vendor agreement + PHI scope expansion |
| Prescriber fax automation | Phase 2 — Level 1 manual outreach sufficient |
| Patient-facing SMS | PHI to third party — needs BAA + consent layer |
| Consortium / Level 2-3 features | Needs 15+ paying Level 1 suppliers first |
| Convex | Not needed until real-time sync requirements emerge |
---
## VPS — Common Terax Commands
```bash
# Connect
ssh root@72.62.134.75
# Check running Signal services
ssh root@72.62.134.75 "docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'"
# View Signal API logs (live)
ssh root@72.62.134.75 "docker logs signal-api --tail 50 -f"
# Restart Signal API
ssh root@72.62.134.75 "docker compose -f /opt/signal/docker-compose.yml restart signal-api"
# Check Caddy (reverse proxy)
ssh root@72.62.134.75 "docker logs caddy --tail 30"
# Run local tests before deploy
cd python-backend && pytest core/ -v
```
---
## Dev Rules
- Work Level 1 scope only
- Reference `payer_rules.json` for all wear-day calculations — do not hardcode
- Use "resupply" not "refill" (CGM supply allowances are exempt from Medicare refill rules)
- Never suggest adding PHI fields beyond `patient_id`
- Flag any vendor integration that would require a new BAA
- If asked about Phase 2/3 scope, acknowledge and defer — do not spec or build

4
docs/hipaa-deployment-analysis-v1.md
View file

@ -512,7 +512,7 @@ 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.
Signal CGM, a documentation worklist tool for DMEPOS suppliers.
PILOT SCOPE
- Historical shipment data for approximately [N] CGM patients
@ -531,7 +531,7 @@ Supplier will:
STTIL Solutions will:
1. Process the anonymized file using Signal CGM's coverage calculator
2. Return a coverage worklist with synthetic patient IDs
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

2
docs/sttil-brand-system-v1.md
View file

@ -42,7 +42,7 @@ The brand earns trust through specificity. It does not perform warmth. It demons
Not a generic software company. A specialist that understands CMS coding, PA workflows, and the cash flow math of competitive bidding.
**Signal** (Signal Powered by STTIL Solutions):
> The CGM coverage worklist that prevents denials before they happen.
> The CGM worklist that prevents denials before they happen.
See full product brand extension: `signal-cgm-brand-extension-v1.md`

2
pitch/signal-asset-package-v1.md
View file

@ -34,7 +34,7 @@ CMS projects CGM beneficiaries to exceed 3.2 million by 2028.
## What Signal Does
Signal is a B2B coverage worklist tool built for DMEPOS supplier back-office
Signal is a B2B documentation worklist tool built for DMEPOS supplier back-office
teams. It replaces manual spreadsheet tracking with an automated, rule-driven
coverage clock.

118
pitch/signal-whitepaper-v2.md Normal file
View file

@ -0,0 +1,118 @@
# The Documentation Gap
## Why Continuous Glucose Monitoring (CGM) Claim Performance Is Decided Before Claims Submission
_Published by STTIL Solutions_
_A reference for CGM suppliers, Revenue Cycle Management teams, and other billing professionals_
---
## The Core Problem
Clean claim performance in CGM is not primarily a billing problem. It is a documentation problem, and the gap opens upstream, not at claims submission.
Centers for Medicare & Medicaid Services (CMS) compliance reporting is clear: 67.6% of improper payments for glucose monitoring supplies during the 2024 reporting period were attributed to missing documentation. Not insufficient. Absent. The documentation records were unable to be created, collected, or verified before the CGM claim was filed.
By the time a denial, write-off, or audit flag appears in your billing queue, capital exposure is already at risk. The window to address it closed before the supplies left the building.
This paper maps five checkpoints in the CGM documentation chain where that window is open, what tends to go wrong at each one, and why resupply is where the most preventable risk lives.
---
## The Resupply Context
The majority of CGM claim volume is not first-time dispensing. It's at resupply. And resupply introduces a documentation dynamic that first-time workflows often miss: the documentation is never static.
Provider Enrollment, Chain, and Ownership System (PECOS) enrollment changes. Prior authorizations expire. The qualifying visit requirement creates a recurring window that runs on the patient's care calendar, not the billing calendar. SWO currency must be confirmed against the order being fulfilled now, not the file from the original onboarding.
For resupply, documentation review is not a one-time event. It is a recurring checkpoint for every shipment. Each resupply cycle carries its own exposure, and that exposure is determined before any CGM supplies goes out the door.
---
## The Five Checkpoints
The CGM documentation chain minimally has five distinct points where gaps form. Each one precedes billing and likely outside the control of the supplier. Each one shapes the outcome of a claim that has yet to be filed.
### 1. The Qualifying Visit
Coverage eligibility for CGM rests on clinical documentation from a qualifying physician encounter. The treating physician's notes must reflect the coverage criteria: insulin treatment type, frequency of adjustment, and medical necessity. Not inferred from the order. In the chart.
For resupply, the qualifying visit anchors the entire downstream timeline. If the encounter is not documented before the resupply window opens, the chain is already misaligned before a single order is processed.
### 2. The Standard Written Order
The SWO must be current, complete, and field-matched to the claim before supplies ship. A prescriber change not reflected in the SWO, an outdated quantity, or a mismatch between the order and the claim creates an exception the claim cannot survive on its own.
For resupply, this means confirming the SWO against the specific order being fulfilled now, not the record on file from the original dispensing.
### 3. PECOS Enrollment
The prescriber on record must have active PECOS enrollment at the time supplies ship, not when they were added to your system. Physicians move practices, change enrollment categories, or allow enrollment to lapse.
Supplies shipped against an order from a prescriber with a lapsed enrollment carry that exposure from the moment they go out the door. It is one of the most common and most preventable sources of capital risk in the resupply documentation chain.
### 4. Prior Authorization Currency
PA must be active and aligned with the specific HCPCS codes on the current shipment. Not just present; aligned. Authorization windows expire, and code list requirements can shift mid-coverage-period without direct notice to the supplier.
For resupply, confirming PA currency before anything ships is the only point in the workflow where this exposure can be addressed without financial consequence.
### 5. Proof of Delivery (POD)
POD documentation must be complete and consistent with the claim before the claim is filed. For mail-order and ship-and-service delivery, the shipment invoice and carrier tracking record must be linked. For in-person, the signed delivery slip must match the claim on description, quantity, and date.
One mismatch is enough to change the outcome on an otherwise clean claim. By the time it surfaces as a denial, the product has long since left the building.
---
## What the Data Shows
CMS compliance reporting on glucose monitoring supplies is unambiguous:
67.6% of improper payments during the 2024 reporting period were attributed to absent documentation. Records that were not available, collected, or in place at the time of audit.
Documentation-related causes consistently account for the majority of DMEPOS improper payments across audit cycles, outpacing billing errors and coverage determinations as the primary driver.
These are not billing errors caught after the fact. They are upstream documentation gaps. Documentation that was not generated or verified before the supplies were delivered or a claim was filed.
---
## What This Means Operationally
The teams with the strongest clean claim rates are not faster at denial management. They have upstream documentation visibility.
For resupply workflows specifically, that means the ability to confirm, per patient, per shipment:
- Whether the qualifying visit is documented before the resupply window opens
- Whether the SWO is current and field-matched to this order, not the original file
- Whether PECOS enrollment is active for the prescriber on record right now
- Whether the PA on file covers the codes on this specific shipment
- Whether POD documentation will be complete and linked before the claim is filed
Most RCM platforms surface claim status at the payer response stage. The denial work queue is a lagging indicator. The exposure it reflects was created before the resupply was ever initiated.
The question is whether your documentation chain is visible before anything ships, or only after the remittance comes back.
---
## A Note on Payer Variation
The SWO framework governs Medicare DMEPOS, but suppliers working across Medicare, Medicaid, and commercial payers face variation in documentation requirements. That variation is not always communicated when requirements change.
| Requirement | Medicare DMEPOS | Medicaid | Commercial Payers |
| ------------------- | ------------------------------------- | ------------------------------ | -------------------------------- |
| Order standard | SWO (eff. Jan 1, 2020) | Varies by state | Varies; some still reference CMN |
| Face-to-face | Required for designated items | Varies | Varies |
| PECOS enrollment | Required | Provider enrollment equivalent | Credentialing varies |
| Prior authorization | Required for PA-designated codes | Varies | Varies by plan and product |
| Proof of delivery | Required; specific field requirements | Required; varies | Required; varies |
A current, payer-specific documentation matrix is a working operational tool, not a one-time setup.
---
_The documentation gap is real, measurable, and addressable before the supplies ever leave the building._
_STTIL Solutions builds tools for CGM suppliers and care teams that surface documentation status upstream. Learn more at sttilsolutions.com_
_CMS data references: CMS Glucose Monitoring Supplies compliance tip (updated February 2026); CMS Standard Documentation Requirements (Article ID 55426); CGS Medicare Final Rule CMS-1713-F SWO FAQ; LCD L33822 Glucose Monitors._

118
pitch/the-documentation-gap-whitepaper.md Normal file
View file

@ -0,0 +1,118 @@
# The Documentation Gap
## Why Continuous Glucose Monitoring (CGM) Claim Performance Is Decided Before Claims Submission
_Published by STTIL Solutions_
_A reference for CGM suppliers, Revenue Cycle Management (RCM) teams, and other billing professionals_
---
## The Core Problem
Clean claim performance in CGM is not primarily a billing problem. It is a documentation problem, and the gap opens upstream, not at claims submission.
Centers for Medicare & Medicaid Services (CMS) compliance reporting is clear: 67.6% of improper payments for glucose monitoring supplies during the 2024 reporting period were attributed to missing documentation. Not insufficient. Absent. The documentation records were unable to be created, collected, or verified before the CGM claim was filed.
By the time a denial, write-off, or audit flag appears in your billing queue, capital exposure is already at risk. The window to address it closed before the supplies left the building.
This paper maps five checkpoints in the CGM documentation chain where that window is open, what tends to go wrong at each one, and why resupply is where the most preventable risk lives.
---
## The Resupply Context
The majority of CGM claim volume is not first-time dispensing. It's at resupply. And resupply introduces a documentation dynamic that first-time workflows often miss: the documentation is never static.
Provider Enrollment, Chain, and Ownership System (PECOS) enrollment changes. Prior authorizations expire. The qualifying visit requirement creates a recurring window that runs on the patient's care calendar, not the billing calendar. Standard Written Order (SWO) status must be confirmed against the order being fulfilled now, not the file from the original onboarding.
For resupply, documentation review is not a one-time event. It is a recurring checkpoint for every shipment. Each resupply cycle carries its own exposure, and that exposure is determined before any CGM supplies go out the door.
---
## The Five Checkpoints
The CGM documentation chain minimally has five distinct points where gaps form. Each one precedes billing and is likely outside the direct control of the supplier. Each one shapes the outcome of a claim that has yet to be filed.
### 1. The Qualifying Visit
Coverage eligibility for CGM rests on clinical documentation from a qualifying physician encounter. The treating physician's notes must reflect the coverage criteria: insulin treatment type, frequency of adjustment, and medical necessity. Not inferred from the order. In the chart.
For resupply, the qualifying visit anchors the entire downstream timeline. If the encounter is not documented before the resupply window opens, the chain is already misaligned before a single order is processed.
### 2. The Standard Written Order
The SWO must be current, complete, and field-matched to the claim before supplies ship. A prescriber change not reflected in the SWO, an outdated quantity, or a mismatch between the order and the claim creates an exception the claim cannot survive on its own.
For resupply, this means confirming the SWO against the specific order being fulfilled now, not the record on file from the original dispensing.
### 3. PECOS Enrollment
The prescriber on record must have active PECOS enrollment at the time supplies ship, not when they were added to your system. Physicians move practices, change enrollment categories, or allow enrollment to lapse.
Supplies shipped against an order from a prescriber with a lapsed enrollment carry that exposure from the moment they go out the door. It is one of the most common and most preventable sources of capital risk in the resupply documentation chain.
### 4. Prior Authorization (PA) Status
PA must be active and aligned with the specific Healthcare Common Procedure Coding System (HCPCS) codes on the current shipment. Not just present; aligned. Authorization windows expire, and code list requirements can shift mid-coverage-period without direct notice to the supplier.
For resupply, confirming PA status before anything ships is the only point in the workflow where this exposure can be addressed without financial consequence.
### 5. Proof of Delivery (POD)
POD documentation must be complete and consistent with the claim before the claim is filed. For mail-order and ship-and-service delivery, the shipment invoice and carrier tracking record must be linked. For in-person, the signed delivery slip must match the claim on description, quantity, and date.
One mismatch is enough to change the outcome on an otherwise clean claim. By the time it surfaces as a denial, the product has long since left the building.
---
## What the Data Shows
CMS compliance reporting on glucose monitoring supplies is unambiguous:
67.6% of improper payments during the 2024 reporting period were attributed to absent documentation. Records that were not available, collected, or in place at the time of audit.
Documentation-related causes consistently account for the majority of Durable Medical Equipment, Prosthetics, Orthotics and Supplies (DMEPOS) improper payments across audit cycles, outpacing billing errors and coverage determinations as the primary driver.
These are not billing errors caught after the fact. They are upstream documentation gaps. Documentation that was not generated or verified before the supplies were delivered or a claim was filed.
---
## What This Means Operationally
The teams with the strongest clean claim rates are not faster at denial management. They have upstream documentation visibility.
For resupply workflows specifically, that means the ability to confirm, per patient, per shipment:
- Whether the qualifying visit is documented before the resupply window opens
- Whether the SWO is current and field-matched to this order, not the original file
- Whether PECOS enrollment is active for the prescriber on record right now
- Whether the PA on file covers the codes on this specific shipment
- Whether POD documentation will be complete and linked before the claim is filed
Most RCM platforms surface claim status at the payer response stage. The denial work queue is a lagging indicator. The exposure it reflects was created before the resupply was ever initiated.
The question is whether your documentation chain is visible before anything ships, or only after the remittance comes back.
---
## A Note on Payer Variation
The SWO framework governs Medicare DMEPOS, but suppliers working across Medicare, Medicaid, and commercial payers face variation in documentation requirements. That variation is not always communicated when requirements change.
| Requirement | Medicare DMEPOS | Medicaid | Commercial Payers |
| ------------------- | ------------------------------------- | ------------------------------ | -------------------------------- |
| Order standard | SWO (eff. Jan 1, 2020) | Varies by state | Varies; some still reference Certificate of Medical Necessity (CMN) |
| Face-to-face | Required for designated items | Varies | Varies |
| PECOS enrollment | Required | Provider enrollment equivalent | Credentialing varies |
| Prior authorization | Required for PA-designated codes | Varies | Varies by plan and product |
| Proof of delivery | Required; specific field requirements | Required; varies | Required; varies |
A current, payer-specific documentation matrix is a working operational tool, not a one-time setup.
---
_The documentation gap is real, measurable, and addressable before the supplies ever leave the building._
_STTIL Solutions builds tools for CGM suppliers and care teams that surface documentation status upstream. Learn more at sttilsolutions.com_
_CMS data references: CMS Glucose Monitoring Supplies compliance tip (updated February 2026); CMS Standard Documentation Requirements (Article ID 55426); CGS Medicare Final Rule CMS-1713-F SWO FAQ; LCD L33822 Glucose Monitors._

307
pitch/whitepaper-gate-demo.html Normal file
View file

@ -0,0 +1,307 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Whitepaper Gate — Demo</title>
<link href="https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@400;500;600;700;800&display=swap" rel="stylesheet">
<style>
*, *::before, *::after { margin: 0; padding: 0; box-sizing: border-box; }
body {
font-family: 'Plus Jakarta Sans', sans-serif;
background: #D6CFC6;
min-height: 100vh;
padding: 40px 16px;
}
.page {
max-width: 680px;
margin: 0 auto;
background: #F0EAE1;
box-shadow: 0 4px 32px rgba(0,0,0,0.12);
}
.top-bar { height: 5px; background: #2EA3A3; }
/* Nav */
.nav {
display: flex;
align-items: center;
justify-content: space-between;
padding: 18px 40px;
border-bottom: 1px solid rgba(4,26,26,0.08);
}
.nav-brand { font-size: 11px; font-weight: 700; color: #8AABAB; letter-spacing: 0.18em; text-transform: uppercase; text-decoration: none; }
.nav-back { font-size: 13px; color: #3A5E5E; text-decoration: none; }
.nav-back:hover { color: #2EA3A3; }
/* ── STATE 1: Teaser ── */
#state-teaser { padding: 52px 48px 56px; }
.eyebrow {
font-size: 11px; font-weight: 700; color: #2EA3A3;
letter-spacing: 0.20em; text-transform: uppercase; margin-bottom: 16px;
}
.title {
font-size: 36px; font-weight: 800; color: #041A1A;
line-height: 1.15; letter-spacing: -0.02em; margin-bottom: 16px;
}
.subtitle {
font-size: 16px; color: #3A5E5E; line-height: 1.65;
max-width: 520px; margin-bottom: 36px;
}
.stat-row {
display: grid; grid-template-columns: 1fr 1fr;
gap: 12px; margin-bottom: 44px;
}
.stat-card {
background: rgba(26,80,80,0.06);
border: 1px solid rgba(26,80,80,0.12);
border-radius: 6px; padding: 18px 20px;
}
.stat-n { font-size: 28px; font-weight: 800; color: #1A5050; line-height: 1; margin-bottom: 6px; }
.stat-l { font-size: 13px; color: #3A5E5E; line-height: 1.4; }
.stat-s { font-size: 11px; color: #8AABAB; margin-top: 4px; font-style: italic; }
/* THE button */
.btn-read {
display: inline-flex; align-items: center; gap: 10px;
background: #1A5050; color: #F0EAE1;
font-family: 'Plus Jakarta Sans', sans-serif;
font-size: 15px; font-weight: 700; letter-spacing: 0.03em;
padding: 16px 32px; border-radius: 4px; border: none;
cursor: pointer; transition: background 0.15s;
}
.btn-read:hover { background: #041A1A; }
.btn-read svg { transition: transform 0.15s; }
.btn-read:hover svg { transform: translateX(3px); }
.btn-note {
margin-top: 12px; font-size: 12px; color: #8AABAB; letter-spacing: 0.02em;
}
/* ── STATE 2: Form ── */
#state-form { display: none; padding: 52px 48px 56px; }
.form-eyebrow { font-size: 11px; font-weight: 700; color: #2EA3A3; letter-spacing: 0.20em; text-transform: uppercase; margin-bottom: 14px; }
.form-title { font-size: 24px; font-weight: 700; color: #041A1A; margin-bottom: 8px; }
.form-sub { font-size: 15px; color: #3A5E5E; line-height: 1.6; margin-bottom: 32px; }
.form-grid { display: grid; grid-template-columns: 1fr 1fr; gap: 14px; margin-bottom: 14px; }
.form-field { display: flex; flex-direction: column; gap: 6px; }
.form-field.full { grid-column: 1 / -1; }
label { font-size: 12px; font-weight: 600; color: #1A5050; letter-spacing: 0.06em; text-transform: uppercase; }
input, select {
font-family: 'Plus Jakarta Sans', sans-serif;
font-size: 15px; padding: 11px 14px;
border: 1px solid rgba(4,26,26,0.18); border-radius: 4px;
background: #F8F4EE; color: #1A1A1A; outline: none;
transition: border-color 0.15s;
}
input:focus, select:focus { border-color: #2EA3A3; }
select { cursor: pointer; }
.btn-submit {
display: inline-flex; align-items: center; gap: 10px;
background: #1A5050; color: #F0EAE1;
font-family: 'Plus Jakarta Sans', sans-serif;
font-size: 15px; font-weight: 700; letter-spacing: 0.03em;
padding: 16px 32px; border-radius: 4px; border: none;
cursor: pointer; margin-top: 8px; transition: background 0.15s;
width: 100%; justify-content: center;
}
.btn-submit:hover { background: #041A1A; }
.privacy-note { font-size: 12px; color: #8AABAB; margin-top: 12px; text-align: center; line-height: 1.5; }
/* ── STATE 3: Whitepaper revealed ── */
#state-whitepaper { display: none; }
.wp-confirmed {
background: #1A5050; padding: 20px 48px;
display: flex; align-items: center; gap: 14px;
}
.wp-confirmed-text { font-size: 14px; font-weight: 600; color: #F0EAE1; }
.wp-confirmed-name { color: #8AABAB; font-weight: 400; }
.check-circle {
width: 28px; height: 28px; border-radius: 50%;
background: rgba(240,234,225,0.15);
display: flex; align-items: center; justify-content: center; flex-shrink: 0;
}
/* Whitepaper content — abbreviated for demo */
.wp-content { padding: 48px 48px 56px; }
.wp-content h2 {
font-size: 11px; font-weight: 700; color: #2EA3A3;
letter-spacing: 0.20em; text-transform: uppercase; margin-bottom: 12px;
}
.wp-section-title { font-size: 24px; font-weight: 700; color: #1A5050; margin-bottom: 16px; }
.wp-content p { font-size: 15px; color: #2D2D2D; line-height: 1.75; margin-bottom: 14px; }
.stat-callout {
background: #1A5050; border-radius: 4px; padding: 28px 36px;
margin: 28px 0; position: relative;
}
.stat-callout::before {
content: ''; position: absolute; left: 0; top: 0; bottom: 0;
width: 4px; background: #CB6B20; border-radius: 4px 0 0 4px;
}
.sc-num { font-size: 56px; font-weight: 800; color: #F0EAE1; line-height: 1; margin-bottom: 8px; }
.sc-label { font-size: 14px; font-weight: 500; color: rgba(240,234,225,0.85); line-height: 1.6; max-width: 420px; margin-bottom: 10px; }
.sc-source { font-size: 11px; font-weight: 600; color: #8AABAB; letter-spacing: 0.12em; text-transform: uppercase; }
.demo-note {
background: rgba(203,107,32,0.08); border: 1px dashed rgba(203,107,32,0.35);
border-radius: 4px; padding: 14px 18px; margin-top: 36px;
font-size: 13px; color: #CB6B20; line-height: 1.5; text-align: center;
}
/* Footer */
footer {
border-top: 1px solid rgba(4,26,26,0.08);
padding: 20px 40px;
display: flex; align-items: center; justify-content: space-between;
}
.footer-brand { font-size: 11px; font-weight: 700; color: #8AABAB; letter-spacing: 0.16em; text-transform: uppercase; }
.footer-url { font-size: 11px; color: #8AABAB; }
</style>
</head>
<body>
<div class="page">
<div class="top-bar"></div>
<nav class="nav">
<a class="nav-brand" href="#">STTIL Solutions</a>
<a class="nav-back" href="#">← Back to Signal</a>
</nav>
<!-- ═══════════════════════════════════════════
STATE 1 — Teaser + "Read the Whitepaper" button
(This is what every visitor sees first)
══════════════════════════════════════════════ -->
<div id="state-teaser">
<div class="eyebrow">Whitepaper</div>
<h1 class="title">The Documentation Gap</h1>
<p class="subtitle">Why CGM claim performance is decided before claims submission. A reference guide for CGM suppliers, RCM teams, and billing professionals.</p>
<div class="stat-row">
<div class="stat-card">
<div class="stat-n">67.6%</div>
<div class="stat-l">of improper payments attributed to absent documentation</div>
<div class="stat-s">CMS, 2024</div>
</div>
<div class="stat-card">
<div class="stat-n">5</div>
<div class="stat-l">upstream checkpoints where documentation gaps form before billing</div>
<div class="stat-s">Signal framework</div>
</div>
</div>
<button class="btn-read" onclick="showForm()">
Read the Whitepaper
<svg width="16" height="16" viewBox="0 0 16 16" fill="none">
<path d="M3 8h10M9 4l4 4-4 4" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/>
</svg>
</button>
<div class="btn-note">Free. Takes 30 seconds to access.</div>
</div>
<!-- ═══════════════════════════════════════════
STATE 2 — Short form
(Appears after clicking "Read the Whitepaper")
══════════════════════════════════════════════ -->
<div id="state-form">
<div class="form-eyebrow">One quick step</div>
<h2 class="form-title">Who should we address this to?</h2>
<p class="form-sub">Enter your details below and the whitepaper opens immediately.</p>
<form onsubmit="showWhitepaper(event)">
<div class="form-grid">
<div class="form-field">
<label for="name">Name</label>
<input type="text" id="name" placeholder="Your name" required>
</div>
<div class="form-field">
<label for="email">Work Email</label>
<input type="email" id="email" placeholder="you@yourcompany.com" required>
</div>
<div class="form-field">
<label for="org">Organization</label>
<input type="text" id="org" placeholder="Company name" required>
</div>
<div class="form-field">
<label for="role">Role</label>
<select id="role" required>
<option value="" disabled selected>Select your role</option>
<option>Supplier Owner / Operator</option>
<option>Billing Manager</option>
<option>RCM Director / Lead</option>
<option>Billing Company</option>
<option>Compliance Officer</option>
<option>Other</option>
</select>
</div>
</div>
<button type="submit" class="btn-submit">
Open the Whitepaper
<svg width="16" height="16" viewBox="0 0 16 16" fill="none">
<path d="M3 8h10M9 4l4 4-4 4" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/>
</svg>
</button>
<p class="privacy-note">Your information is used only to share relevant Signal updates. No spam.</p>
</form>
</div>
<!-- ═══════════════════════════════════════════
STATE 3 — Whitepaper revealed inline
(Appears after form submit)
══════════════════════════════════════════════ -->
<div id="state-whitepaper">
<div class="wp-confirmed">
<div class="check-circle">
<svg width="14" height="11" viewBox="0 0 14 11" fill="none">
<path d="M1 5.5l4 4L13 1" stroke="#F0EAE1" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
</svg>
</div>
<div class="wp-confirmed-text">
Sent to <span class="wp-confirmed-name" id="confirmed-email"></span> — the whitepaper is below.
</div>
</div>
<div class="wp-content">
<h2>Overview</h2>
<div class="wp-section-title">The Core Problem</div>
<p>Clean claim performance in CGM is not primarily a billing problem. It is a documentation problem, and the gap opens upstream, not at claims submission.</p>
<p>Centers for Medicare &amp; Medicaid Services (CMS) compliance reporting is clear:</p>
<div class="stat-callout">
<div class="sc-num">67.6%</div>
<div class="sc-label">of improper payments for glucose monitoring supplies during the 2024 reporting period were attributed to missing documentation. Not insufficient. Absent. The documentation records were unable to be created, collected, or verified before the CGM claim was filed.</div>
<div class="sc-source">CMS Glucose Monitoring Supplies Compliance Tip, February 2026</div>
</div>
<p>By the time a denial, write-off, or audit flag appears in your billing queue, capital exposure is already at risk. The window to address it closed before the supplies left the building.</p>
<div class="demo-note">
Demo shows first section only. Full whitepaper renders here after form submit.
</div>
</div>
</div>
<footer>
<span class="footer-brand">STTIL Solutions</span>
<span class="footer-url">sttilsolutions.com</span>
</footer>
</div>
<script>
function showForm() {
document.getElementById('state-teaser').style.display = 'none';
document.getElementById('state-form').style.display = 'block';
window.scrollTo({ top: 0, behavior: 'smooth' });
}
function showWhitepaper(e) {
e.preventDefault();
const email = document.getElementById('email').value;
document.getElementById('confirmed-email').textContent = email;
document.getElementById('state-form').style.display = 'none';
document.getElementById('state-whitepaper').style.display = 'block';
window.scrollTo({ top: 0, behavior: 'smooth' });
}
</script>
</body>
</html>

566
pitch/whitepaper-sample.html Normal file
View file

@ -0,0 +1,566 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>The Documentation Gap — STTIL Solutions</title>
<link href="https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@300;400;500;600;700;800&display=swap" rel="stylesheet">
<style>
/* ── Reset ── */
*, *::before, *::after { margin: 0; padding: 0; box-sizing: border-box; }
/* ── Page ── */
html { background: #D6CFC6; }
body {
font-family: 'Plus Jakarta Sans', sans-serif;
background: #F0EAE1;
color: #1A1A1A;
max-width: 800px;
margin: 40px auto;
padding: 0;
box-shadow: 0 4px 40px rgba(0,0,0,0.14);
}
/* ── Top accent bar ── */
.top-bar {
height: 5px;
background: #2EA3A3;
width: 100%;
}
/* ── Header ── */
header {
padding: 56px 72px 48px;
border-bottom: 1px solid rgba(4,26,26,0.10);
}
.brand-row {
display: flex;
align-items: center;
gap: 12px;
margin-bottom: 36px;
}
.brand-name {
font-size: 11px;
font-weight: 700;
color: #8AABAB;
letter-spacing: 0.18em;
text-transform: uppercase;
}
.product-tag {
font-size: 11px;
font-weight: 700;
color: #CB6B20;
letter-spacing: 0.14em;
text-transform: uppercase;
border: 1px solid rgba(203,107,32,0.35);
padding: 2px 8px;
border-radius: 2px;
}
.doc-title {
font-size: 52px;
font-weight: 800;
color: #041A1A;
line-height: 1.05;
letter-spacing: -0.02em;
margin-bottom: 16px;
}
.doc-subtitle {
font-size: 17px;
font-weight: 400;
color: #3A5E5E;
line-height: 1.55;
max-width: 600px;
margin-bottom: 28px;
}
.doc-meta-row {
display: flex;
align-items: center;
gap: 20px;
}
.doc-meta {
font-size: 12px;
font-weight: 500;
color: #8AABAB;
letter-spacing: 0.08em;
}
.doc-tag {
font-size: 11px;
font-weight: 600;
color: #1A5050;
letter-spacing: 0.10em;
text-transform: uppercase;
background: rgba(26,80,80,0.08);
padding: 3px 10px;
border-radius: 2px;
}
/* ── Document body ── */
.doc-body {
padding: 0 72px;
}
/* ── Sections ── */
section {
padding: 48px 0;
border-bottom: 1px solid rgba(4,26,26,0.08);
}
section:last-of-type { border-bottom: none; }
h2 {
font-size: 11px;
font-weight: 700;
color: #2EA3A3;
letter-spacing: 0.20em;
text-transform: uppercase;
margin-bottom: 18px;
}
.section-title {
font-size: 26px;
font-weight: 700;
color: #1A5050;
line-height: 1.25;
margin-bottom: 20px;
}
p {
font-size: 16px;
font-weight: 400;
color: #2D2D2D;
line-height: 1.75;
margin-bottom: 16px;
}
p:last-child { margin-bottom: 0; }
/* ── Stat callout ── */
.stat-callout {
background: #1A5050;
border-radius: 4px;
padding: 36px 44px;
margin: 36px 0;
position: relative;
}
.stat-callout::before {
content: '';
position: absolute;
left: 0; top: 0; bottom: 0;
width: 4px;
background: #CB6B20;
border-radius: 4px 0 0 4px;
}
.stat-number {
font-size: 72px;
font-weight: 800;
color: #F0EAE1;
line-height: 1.0;
letter-spacing: -0.03em;
margin-bottom: 10px;
}
.stat-label {
font-size: 16px;
font-weight: 500;
color: rgba(240,234,225,0.85);
line-height: 1.6;
max-width: 480px;
margin-bottom: 14px;
}
.stat-source {
font-size: 11px;
font-weight: 600;
color: #8AABAB;
letter-spacing: 0.12em;
text-transform: uppercase;
}
/* ── Pull quote ── */
.pull-quote {
border-left: 3px solid #CB6B20;
padding: 20px 28px;
margin: 36px 0;
background: rgba(203,107,32,0.05);
border-radius: 0 3px 3px 0;
}
.pull-quote p {
font-size: 18px;
font-weight: 600;
color: #1A5050;
line-height: 1.6;
font-style: italic;
margin: 0;
}
/* ── Checkpoints ── */
.checkpoint {
display: flex;
gap: 24px;
margin-bottom: 36px;
align-items: flex-start;
}
.checkpoint:last-child { margin-bottom: 0; }
.checkpoint-num {
width: 36px;
height: 36px;
border-radius: 50%;
background: #1A5050;
color: #F0EAE1;
font-size: 14px;
font-weight: 700;
display: flex;
align-items: center;
justify-content: center;
flex-shrink: 0;
margin-top: 2px;
}
.checkpoint-body h3 {
font-size: 17px;
font-weight: 700;
color: #041A1A;
margin-bottom: 10px;
}
.checkpoint-body p {
font-size: 15px;
color: #3A3A3A;
line-height: 1.70;
margin-bottom: 10px;
}
.checkpoint-resupply {
font-size: 14px;
font-weight: 500;
color: #1A5050;
background: rgba(26,80,80,0.07);
border-left: 3px solid #2EA3A3;
padding: 10px 14px;
border-radius: 0 3px 3px 0;
line-height: 1.6;
margin-top: 6px;
}
/* ── Checklist ── */
.checklist {
list-style: none;
margin: 20px 0;
}
.checklist li {
display: flex;
align-items: flex-start;
gap: 12px;
font-size: 15px;
color: #2D2D2D;
line-height: 1.65;
padding: 8px 0;
border-bottom: 1px solid rgba(4,26,26,0.06);
}
.checklist li:last-child { border-bottom: none; }
.check-icon {
width: 18px;
height: 18px;
border-radius: 50%;
background: #2EA3A3;
display: flex;
align-items: center;
justify-content: center;
flex-shrink: 0;
margin-top: 3px;
}
.check-icon svg { display: block; }
/* ── Table ── */
.doc-table {
width: 100%;
border-collapse: collapse;
font-size: 14px;
margin: 24px 0;
border-radius: 4px;
overflow: hidden;
}
.doc-table th {
background: #1A5050;
color: #F0EAE1;
font-weight: 600;
font-size: 12px;
letter-spacing: 0.06em;
text-align: left;
padding: 12px 16px;
}
.doc-table td {
padding: 11px 16px;
color: #2D2D2D;
line-height: 1.5;
border-bottom: 1px solid rgba(4,26,26,0.07);
}
.doc-table tr:nth-child(even) td { background: rgba(46,163,163,0.05); }
.doc-table tr:last-child td { border-bottom: none; }
.doc-table td:first-child { font-weight: 600; color: #1A5050; }
/* ── Footer ── */
footer {
border-top: 1px solid rgba(4,26,26,0.10);
padding: 24px 72px;
display: flex;
align-items: center;
justify-content: space-between;
}
.footer-brand {
font-size: 11px;
font-weight: 700;
color: #8AABAB;
letter-spacing: 0.16em;
text-transform: uppercase;
}
.footer-url {
font-size: 11px;
color: #8AABAB;
letter-spacing: 0.06em;
}
.footer-cite {
font-size: 11px;
color: #AAAAAA;
line-height: 1.6;
padding: 0 72px 32px;
}
/* ── Print ── */
@media print {
@page { margin: 1.8cm 2.2cm; size: letter; }
html { background: white; }
body { box-shadow: none; margin: 0; max-width: 100%; }
.top-bar, .stat-callout, .doc-table th, .checkpoint-num {
-webkit-print-color-adjust: exact;
print-color-adjust: exact;
}
section { page-break-inside: avoid; }
h2, .section-title, h3 { page-break-after: avoid; }
.stat-callout { page-break-inside: avoid; }
.checkpoint { page-break-inside: avoid; }
}
</style>
</head>
<body>
<div class="top-bar"></div>
<header>
<div class="brand-row">
<span class="brand-name">STTIL Solutions</span>
<span class="product-tag">Signal</span>
</div>
<h1 class="doc-title">The Documentation Gap</h1>
<p class="doc-subtitle">Why Continuous Glucose Monitoring (CGM) Claim Performance Is Decided Before Claims Submission</p>
<div class="doc-meta-row">
<span class="doc-meta">Published May 2026</span>
<span class="doc-tag">Reference Guide</span>
<span class="doc-meta">sttilsolutions.com</span>
</div>
</header>
<div class="doc-body">
<!-- The Core Problem -->
<section>
<h2>Overview</h2>
<div class="section-title">The Core Problem</div>
<p>Clean claim performance in CGM is not primarily a billing problem. It is a documentation problem, and the gap opens upstream, not at claims submission.</p>
<p>Centers for Medicare &amp; Medicaid Services (CMS) compliance reporting is clear:</p>
<div class="stat-callout">
<div class="stat-number">67.6%</div>
<div class="stat-label">of improper payments for glucose monitoring supplies during the 2024 reporting period were attributed to missing documentation. Not insufficient. Absent. The documentation records were unable to be created, collected, or verified before the CGM claim was filed.</div>
<div class="stat-source">CMS Glucose Monitoring Supplies Compliance Tip, February 2026</div>
</div>
<p>By the time a denial, write-off, or audit flag appears in your billing queue, capital exposure is already at risk. The window to address it closed before the supplies left the building.</p>
<p>This paper maps five checkpoints in the CGM documentation chain where that window is open, what tends to go wrong at each one, and why resupply is where the most preventable risk lives.</p>
</section>
<!-- The Resupply Context -->
<section>
<h2>Context</h2>
<div class="section-title">The Resupply Context</div>
<p>The majority of CGM claim volume is not first-time dispensing. It is at resupply. And resupply introduces a documentation dynamic that first-time workflows often miss: the documentation is never static.</p>
<p>Provider Enrollment, Chain, and Ownership System (PECOS) enrollment changes. Prior authorizations expire. The qualifying visit requirement creates a recurring window that runs on the patient's care calendar, not the billing calendar. Standard Written Order (SWO) status must be confirmed against the order being fulfilled now, not the file from the original onboarding.</p>
<p>For resupply, documentation review is not a one-time event. It is a recurring checkpoint for every shipment. Each resupply cycle carries its own exposure, and that exposure is determined before any CGM supplies go out the door.</p>
</section>
<!-- The Five Checkpoints -->
<section>
<h2>Framework</h2>
<div class="section-title">The Five Checkpoints</div>
<p>The CGM documentation chain minimally has five distinct points where gaps form. Each one precedes billing and is likely outside the direct control of the supplier. Each one shapes the outcome of a claim that has yet to be filed.</p>
<div style="margin-top: 32px;">
<div class="checkpoint">
<div class="checkpoint-num">1</div>
<div class="checkpoint-body">
<h3>The Qualifying Visit</h3>
<p>Coverage eligibility for CGM rests on clinical documentation from a qualifying physician encounter. The treating physician's notes must reflect the coverage criteria: insulin treatment type, frequency of adjustment, and medical necessity. Not inferred from the order. In the chart.</p>
<div class="checkpoint-resupply">For resupply: the qualifying visit anchors the entire downstream timeline. If the encounter is not documented before the resupply window opens, the chain is already misaligned before a single order is processed.</div>
</div>
</div>
<div class="checkpoint">
<div class="checkpoint-num">2</div>
<div class="checkpoint-body">
<h3>The Standard Written Order</h3>
<p>The SWO must be current, complete, and field-matched to the claim before supplies ship. A prescriber change not reflected in the SWO, an outdated quantity, or a mismatch between the order and the claim creates an exception the claim cannot survive on its own.</p>
<div class="checkpoint-resupply">For resupply: this means confirming the SWO against the specific order being fulfilled now, not the record on file from the original dispensing.</div>
</div>
</div>
<div class="checkpoint">
<div class="checkpoint-num">3</div>
<div class="checkpoint-body">
<h3>PECOS Enrollment</h3>
<p>The prescriber on record must have active PECOS enrollment at the time supplies ship, not when they were added to your system. Physicians move practices, change enrollment categories, or allow enrollment to lapse.</p>
<div class="checkpoint-resupply">For resupply: supplies shipped against an order from a prescriber with a lapsed enrollment carry that exposure from the moment they go out the door. It is one of the most common and most preventable sources of capital risk.</div>
</div>
</div>
<div class="checkpoint">
<div class="checkpoint-num">4</div>
<div class="checkpoint-body">
<h3>Prior Authorization (PA) Status</h3>
<p>PA must be active and aligned with the specific Healthcare Common Procedure Coding System (HCPCS) codes on the current shipment. Not just present; aligned. Authorization windows expire, and code list requirements can shift mid-coverage-period without direct notice to the supplier.</p>
<div class="checkpoint-resupply">For resupply: confirming PA currency before anything ships is the only point in the workflow where this exposure can be addressed without financial consequence.</div>
</div>
</div>
<div class="checkpoint">
<div class="checkpoint-num">5</div>
<div class="checkpoint-body">
<h3>Proof of Delivery (POD)</h3>
<p>POD documentation must be complete and consistent with the claim before the claim is filed. For mail-order and ship-and-service delivery, the shipment invoice and carrier tracking record must be linked. For in-person, the signed delivery slip must match the claim on description, quantity, and date.</p>
<div class="checkpoint-resupply">For resupply: one mismatch is enough to change the outcome on an otherwise clean claim. By the time it surfaces as a denial, the product has long since left the building.</div>
</div>
</div>
</div>
</section>
<!-- What the Data Shows -->
<section>
<h2>Data</h2>
<div class="section-title">What the Data Shows</div>
<p>CMS compliance reporting on glucose monitoring supplies is unambiguous: 67.6% of improper payments during the 2024 reporting period were attributed to absent documentation. Records that were not available, collected, or in place at the time of audit.</p>
<p>Documentation-related causes consistently account for the majority of Durable Medical Equipment, Prosthetics, Orthotics and Supplies (DMEPOS) improper payments across audit cycles, outpacing billing errors and coverage determinations as the primary driver.</p>
<p>These are not billing errors caught after the fact. They are upstream documentation gaps. Documentation that was not generated or verified before the supplies were delivered or a claim was filed.</p>
</section>
<!-- What This Means Operationally -->
<section>
<h2>Operations</h2>
<div class="section-title">What This Means Operationally</div>
<div class="pull-quote">
<p>The teams with the strongest clean claim rates are not faster at denial management. They have upstream documentation visibility.</p>
</div>
<p>For resupply workflows specifically, that means the ability to confirm, per patient, per shipment:</p>
<ul class="checklist">
<li>
<span class="check-icon">
<svg width="10" height="8" viewBox="0 0 10 8" fill="none"><path d="M1 4l3 3 5-6" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/></svg>
</span>
Whether the qualifying visit is documented before the resupply window opens
</li>
<li>
<span class="check-icon">
<svg width="10" height="8" viewBox="0 0 10 8" fill="none"><path d="M1 4l3 3 5-6" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/></svg>
</span>
Whether the SWO is current and field-matched to this order, not the original file
</li>
<li>
<span class="check-icon">
<svg width="10" height="8" viewBox="0 0 10 8" fill="none"><path d="M1 4l3 3 5-6" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/></svg>
</span>
Whether PECOS enrollment is active for the prescriber on record right now
</li>
<li>
<span class="check-icon">
<svg width="10" height="8" viewBox="0 0 10 8" fill="none"><path d="M1 4l3 3 5-6" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/></svg>
</span>
Whether the PA on file covers the codes on this specific shipment
</li>
<li>
<span class="check-icon">
<svg width="10" height="8" viewBox="0 0 10 8" fill="none"><path d="M1 4l3 3 5-6" stroke="#F0EAE1" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round"/></svg>
</span>
Whether POD documentation will be complete and linked before the claim is filed
</li>
</ul>
<p>Most Revenue Cycle Management (RCM) platforms surface claim status at the payer response stage. The denial work queue is a lagging indicator. The exposure it reflects was created before the resupply was ever initiated.</p>
<p>The question is whether your documentation chain is visible before anything ships, or only after the remittance comes back.</p>
</section>
<!-- Payer Variation -->
<section>
<h2>Reference</h2>
<div class="section-title">A Note on Payer Variation</div>
<p>The SWO framework governs Medicare DMEPOS, but suppliers working across Medicare, Medicaid, and commercial payers face variation in documentation requirements. That variation is not always communicated when requirements change.</p>
<table class="doc-table">
<thead>
<tr>
<th>Requirement</th>
<th>Medicare DMEPOS</th>
<th>Medicaid</th>
<th>Commercial Payers</th>
</tr>
</thead>
<tbody>
<tr>
<td>Order standard</td>
<td>SWO (eff. Jan 1, 2020)</td>
<td>Varies by state</td>
<td>Varies; some still reference Certificate of Medical Necessity (CMN)</td>
</tr>
<tr>
<td>Face-to-face</td>
<td>Required for designated items</td>
<td>Varies</td>
<td>Varies</td>
</tr>
<tr>
<td>PECOS enrollment</td>
<td>Required</td>
<td>Provider enrollment equivalent</td>
<td>Credentialing varies</td>
</tr>
<tr>
<td>Prior authorization</td>
<td>Required for PA-designated codes</td>
<td>Varies</td>
<td>Varies by plan and product</td>
</tr>
<tr>
<td>Proof of delivery</td>
<td>Required; specific field requirements</td>
<td>Required; varies</td>
<td>Required; varies</td>
</tr>
</tbody>
</table>
<p>A current, payer-specific documentation matrix is a working operational tool, not a one-time setup.</p>
</section>
<!-- Closing -->
<section style="text-align: center; padding: 52px 0 40px;">
<p style="font-size: 20px; font-weight: 600; color: #1A5050; line-height: 1.6; max-width: 560px; margin: 0 auto 24px;">The documentation gap is real, measurable, and addressable before the supplies ever leave the building.</p>
<p style="font-size: 15px; color: #3A5E5E; margin: 0 auto;">STTIL Solutions builds tools for CGM suppliers and care teams that surface documentation status upstream.</p>
<p style="font-size: 14px; font-weight: 600; color: #2EA3A3; margin-top: 10px; letter-spacing: 0.04em;">sttilsolutions.com</p>
</section>
</div><!-- /doc-body -->
<p class="footer-cite">CMS data references: CMS Glucose Monitoring Supplies compliance tip (updated February 2026); CMS Standard Documentation Requirements (Article ID 55426); CGS Medicare Final Rule CMS-1713-F SWO FAQ; LCD L33822 Glucose Monitors.</p>
<footer>
<span class="footer-brand">STTIL Solutions</span>
<span class="footer-url">sttilsolutions.com</span>
</footer>
</body>
</html>

50
test-data/generate_samples.py Normal file
View file

@ -0,0 +1,50 @@
"""Generate 25 CSV test files covering all flag states."""
import csv
import random
import os
from datetime import date, timedelta
random.seed(42)
DEVICE_TYPES = ["dexcom_g7", "dexcom_g6", "freestyle_libre_3", "omnipod_5"]
PAYERS = ["Medicare Part B", "Medicaid - GA", "BCBS - FL", "Aetna", "UnitedHealth", "Cigna", "Humana"]
COMPONENTS = {"dexcom_g7": "sensor", "dexcom_g6": "sensor", "freestyle_libre_3": "sensor", "omnipod_5": "pod"}
# Shipment date ranges to trigger different flag states
TODAY = date.today()
DATE_BUCKETS = {
"OK": (TODAY - timedelta(days=10), TODAY - timedelta(days=1)),
"VISIT_DUE": (TODAY - timedelta(days=400), TODAY - timedelta(days=250)), # old visit, no recent qualifier
"OUT_OF_COVERAGE": (TODAY - timedelta(days=600), TODAY - timedelta(days=500)), # way too old
"REFILL_WINDOW": (TODAY - timedelta(days=30), TODAY - timedelta(days=25)), # inside resupply window
}
OUTPUT_DIR = os.path.dirname(os.path.abspath(__file__))
for i in range(1, 26):
flag = random.choice(list(DATE_BUCKETS.keys()))
bucket = DATE_BUCKETS[flag]
delta = (bucket[1] - bucket[0]).days
ship_date = bucket[0] + timedelta(days=random.randint(0, max(delta, 1)))
device = random.choice(DEVICE_TYPES)
component = COMPONENTS[device]
payer = random.choice(PAYERS)
quantity = random.choice([1, 2, 3, 6, 9, 14])
filename = f"sample-batch-{i:02d}-{flag.lower()}.csv"
filepath = os.path.join(OUTPUT_DIR, filename)
with open(filepath, "w", newline="") as f:
writer = csv.writer(f)
writer.writerow(["patient_id", "device_type", "shipment_date", "quantity", "payer", "component"])
# 3-8 rows per file
num_rows = random.randint(3, 8)
for j in range(num_rows):
pid = f"PT-{1001 + (i-1) * 10 + j}"
row_ship = ship_date + timedelta(days=random.randint(-5, 5))
writer.writerow([pid, device, row_ship.isoformat(), random.choice([1, 2, 3, 6, 9]), payer, component])
print(f"Wrote {filename} ({num_rows} rows, flag={flag})")
print(f"\nDone — 25 files in {OUTPUT_DIR}")