Neutron Health / technical document

Tech Overview

The v3 clinic-system candidate: local patient records, clinical decision support, clinician review, and clinic sharing—with verification and approval still open.

Section 01 of 6

Patient records and encounter history

The v3 candidate replaces session-only custody with retained local patient records and encounter history. Earlier notes remain read-only history; adding information to a new intake is a deliberate clinician action.

Records use append-only events with their sources.
Imported patient matches and conflicting information require clinician confirmation.
Signed encounter history is preserved when analysis is repeated.

A separate clinical path

MedGemma runs locally inside Neutron Health’s clinical workflow, supervised by deterministic safeguards. It does not move into the general assistant runtime, and other models do not participate in clinical decisions.

Clinical work does not send patient information to a remote AI service.
A planned non-clinical assistant would have its own store, no patient-record access, and no role in diagnosis or prescribing.
Offline clinical work does not imply that the entire app can never connect: intended signed-update delivery may use the internet.

Clinician review, signing, and handoff

The clinical workflow moves from intake through triage, differential assessment, risk, and recommended actions to a clinician’s note, signing, and deliberate handoff. AI output remains distinct from the clinician’s conclusion.

Separate rules check missing information, vital signs, and other safety conditions; they are not clinical judgment.
Clinicians must verify outputs against examination, local protocols, and their own judgment.
Signing and key protections require validation on real Macs; a candidate signature is not evidence of clinical authorization.

Approved Macs on the clinic network

The v3 design uses a local clinic hub for encrypted shared records and backups. A clinical administrator approves each joining Mac. Access and administrative actions are recorded.

Each Mac runs its own clinical model and retains local work.
The hub is designed to store ciphertext rather than readable patient records.
Pairing, access controls, key revocation, and standby recovery still need real-Mac checks.

Outages, backup, and recovery

The candidate saves work locally when the hub is unavailable. On reconnection, a clinician confirms record merges. The design includes snapshots, a standby copy, and recorded restore checks.

Potential duplicates and conflicting clinical information require review.
Backup retention and restore behavior must be verified against clinic requirements.
Multi-Mac outages, standby switching, and recovery have not yet established field readiness.

Boundary

Checking our work

The v3 roadmap records implemented candidate components, partly delivered work, and open gates—not a certified or clinically deployed system. Build 158 identifies a development candidate, not a qualified release.

Open gates include real-Mac clinic checks, hardware performance, native workflow review, clinical and Spanish-language review, and applicable regulatory approvals.
Clinical prompt or output changes require benchmark checks and clinical review before use.
The intended direct-distribution path requires verified archives, notarization, update integrity, administrator-approved installation, and no installation during an encounter.
Later appointments, queues, patient flow, follow-ups, pharmacy, and non-clinical assistance remain planned.

End of document

Clinician control. Verified before deployment.

Clinician decision support only. The v3 candidate is not authorized for clinical deployment. Clinical review, required regulatory approvals, and field validation remain prerequisites.