Architecture & national scale

InvisibleSignal is intentionally Lyme-only. No other condition is implemented. What makes it reusable is that 8 of its 12 layers carry no condition-specific assumptions — and that the 4 that do are named rather than glossed over.

National scale of the Lyme implementation

Scalability is not only about other conditions. A Lyme product that works in Connecticut and breaks in Texas is not nationally deployable, and handling the places with no data is the harder half.

States + DC covered

688

Counties county-coded

548

With a 2-year pair

States county-coding none

50 states plus DC are covered by the state series. 688 counties are county-coded by CDC; 16 states report Lyme cases but county-code none of them, and those states resolve to a labelled state fallback rather than to zero.

Shared infrastructure — 8 layers

A layer is listed here only when the Lyme implementation calls it through an interface carrying no Lyme assumptions — not because it could be generalised with work.

Lyme implementation today

CDC NNDSS county-coded Lyme, 2022-2023. 152,018 source cases reconcile exactly: 148,156 county-assigned, 3,694 state residual, 168 national residual.

What a future condition supplies

The reconciliation and suppression logic makes no reference to Lyme. A new dataset supplies its own Socrata resource and denominator vintage.

data/scripts/ingest_cdc_nndss_county.py

Lyme-specific logic — 4 layers

Ecosystem fit — CMS Interoperability Framework

CMS’s Health Technology Ecosystem initiative published a voluntary Interoperability Framework with criteria for networks, EHRs, payers, and patient-facing apps. InvisibleSignal is a patient-facing tool, not a network, and has not pledged. But the framework’s patient-side criteria describe the properties this platform was already built around, so we track them in the open. This self-assessment is ours, not CMS’s — listing a criterion here is not a CMS endorsement or a CMS-Aligned designation.

In the product today

FHIR R4 document export. Every screener report downloads as a FHIR R4 document bundle (Composition, Patient, Observations, RiskAssessment, DocumentReference, Provenance) coded in SNOMED CT, ICD‑10‑CM and LOINC — the terminology families the framework’s USCDI v3 criterion names.lib/fhir/screen-report-bundle.ts
LOINC-coded lab results. Extracted lab values are matched to LOINC before they are stored (Lyme IgG EIA → 16912‑0).lib/labs/extraction.ts
Versioned consent ledger. Upload and extraction routes refuse to run without active consent, and revocation applies immediately — the consent-sharing and access-control criteria (5, 24) in miniature.lib/labs/consent.ts
Append-only PHI audit log. Every upload, extraction, view, correction and deletion is recorded, and erase-everything is self-serve — the audit-transparency criterion (4).supabase/migrations/005_lab_records_and_consent.sql
Patient-mediated sharing. Data leaves the device only by the user’s choice; the clinician handoff is a document the patient carries — criterion 1’s “apps of the patient’s choice”, with the patient as the transport.

Not built — and what it would take

CMS-Aligned Network participation. The network criteria (record location, cross-network query) apply to networks. A patient app connects through one; it does not join as one.
IAL2/AAL2 digital-credential sign-in. Mobile driver’s licenses and passkeys are the framework’s identity bar. Sign-in today is email via Supabase Auth.
A hosted FHIR API. We emit bundles; we do not run a FHIR server with a US Core capability statement or FHIR Subscriptions.
SMART on FHIR app registration. The EHR handoff is a file the patient carries, not an app embedded in the EHR.

CMS Interoperability Framework — voluntary criteria under the CMS Health Technology Ecosystem initiative.

Why we did not ship a second condition

It would score worse and be less honest. The layers that generalise cleanly are the ones handling provenance, geography, evidence and export. The risk index does not: its weights were chosen for county incidence and Ixodes seasonality and validated against Lyme case data. Pointed at another condition’s data the engine would still return a number, and that number would mean nothing. Shipping it to claim breadth would undo the reason the Lyme index is defensible.

The current product is intentionally Lyme-focused. The underlying intelligence infrastructure is modular and standards-based, which is what makes future reuse possible without changing the core platform.