Security

Security & data architecture

This page is written to be forwarded — to your office manager, your IT consultant, or your compliance reviewer. It describes what the system does, at the level a buyer needs.

Built and working — all data synthetic today. Pilot practices onboarding fall 2026.

Three isolated data planes

Patient records, cross-practice learning, and clinical terminology live in three separate databases — 168 tables in total. Your patients' data never mixes with the network's learning.

Plane 1

Your practice's records

Patient data is isolated per practice at the database layer and again at the application layer. Cross-practice access isn't a permission that can be granted — the isolation is structural.

Plane 2

De-identified learning

Only de-identified, non-identifying samples ever cross into the shared learning store, and they are validated automatically before they land. Insights surface only when backed by 3+ samples from 2+ practices — enforced in code — and practices can opt out, with hard deletion of their contributions.

Plane 3

Clinical terminology

A 107,862-code terminology engine (ICD-10-CM, HCPCS, openFDA, with licensed-source connectors). Licensed code sets are guarded fail-closed: without a recorded license, they refuse to load.

Controls

Role-based access control

14 roles and 54 discrete permissions. Staff see what their job requires — including corporate roles, which see aggregates by default and need a justified, time-boxed, audited elevation to read an individual record.

Multi-factor authentication

MFA with one-time codes and trusted-device management, with enforced enrollment for privileged roles at go-live.

Append-only audit trail

Every authenticated request is logged, and every chart change is appended to the record's history with a source tag — manual, voice, file, or AI. Audit entries cannot be edited or deleted.

Encryption

Data is encrypted in transit (TLS 1.2+) and at rest. Secrets are held in a managed vault, not in code or configuration files.

AI data handling

Patient identifiers are minimized before AI processing. AI output lands as a proposal a clinician must confirm; suggested codes are validated server-side against the catalog, and out-of-catalog answers are rejected. There is no AI reading of radiographs in v1 — by design.

Clearinghouse infrastructure

Eligibility and claims run on HITRUST r2-certified clearinghouse infrastructure (Stedi). Eligibility (270/271) has been verified end-to-end against Stedi's live sandbox.

Safety-gated releases

Production deploys are blocked unless all backend tests and a browser-run patient-safety suite pass — 1,536 automated tests in total. Invariants like "signed notes are immutable" and "missing history raises an alert" are tested in a real browser before every release.

Data status & BAA path

All data in the product today is synthetic; no real patient data has been processed. Go-live for a real practice is gated on executed BAAs with our cloud and AI providers and on commercial code-set licenses — a checklist we complete with each pilot practice.

Questions a reviewer would ask that aren't answered here? Email zastavnyuk@gmail.com and we'll answer in writing.