Healthcare

Clinical documentation.
Not diagnosis.

Clinicians spend a substantial share of their working day writing records rather than seeing patients. That is a documentation problem with a documentation solution — and it is categorically different from putting a model near a clinical decision.

Last reviewed 4 September 2026 · Engineering guidance, not regulatory or legal advice.

All Healthcare & Pharma →

Why this is the right first use case

Documentation burden is one of the most consistently cited contributors to clinician burnout, and unlike most things AI is proposed for in healthcare it is not a clinical judgement task. The model transcribes and structures what was said; a clinician reads, corrects and signs. Accountability never moves.

That property is what makes it deployable. A system that drafts a note for a clinician to approve is a productivity tool with a human in an existing, well-understood approval loop. A system that suggests a diagnosis is a medical device in most jurisdictions, with a regulatory pathway to match. Whether a given documentation system crosses that line is jurisdiction-specific and for your regulatory function to determine; nothing here is regulatory advice. Conflating the two is how healthcare AI projects stall in legal review.

The corollary is a design constraint we hold firmly: the system must not infer clinical content that was not said. A note that includes a plausible finding nobody documented is a patient safety issue, not a quality issue, and the evaluation set has to test for it explicitly rather than measuring only fluency.

What we build

DOCUMENTATION PATH

01

Encounter audio

consented, on your infrastructure
02

Transcribe

speaker-attributed
03

Structure

into your note template
04

Clinician review

edits and signs
05

Record

written to the EHR
06 · Branch / escalation

Coding suggestions

coder-reviewed

Solid: the documentation pathDashed: coding support, reviewed separately

Nothing reaches the record unsigned. The audio and the transcript stay inside your perimeter throughout.

The constraints that decide the design

Consent and recording.

Capturing a clinical encounter has consent implications that vary by jurisdiction and by setting. This is settled before any engineering, because a system built on a recording model your legal team will not accept is a system that never launches.
No inference beyond the encounter.

The note contains what was said and observed. The evaluation set includes deliberate cases testing whether the model fabricates plausible clinical detail, and that metric gates deployment rather than being reported alongside it.
The clinician signs.

Every note is reviewed and signed by the clinician whose name is on it. The efficiency gain comes from editing rather than authoring, and any design that erodes the review step erodes the thing that makes it acceptable.
Data stays put.

Patient audio and identifiable records are among the strongest cases for on-premise or private hosting we encounter. Open-weight models handle transcription and structuring well, and this workload does not need a frontier API.

Questions

Questions about Clinical Documentation.

Is this a medical device?

Documentation support with clinician review generally is not, while anything offering diagnostic or treatment suggestions generally is. The boundary is jurisdiction-specific and it is a question for your regulatory function, not for us — but the way the system is scoped is designed to keep it clearly on the documentation side.

Can it suggest billing codes?

It can propose codes from the signed note for a coder to review, which is a genuine time saving. It should not select codes autonomously: coding accuracy carries financial and compliance consequences that need a human owner.

Where does the audio go?

Wherever you require, and for most clients that means nowhere — processed on infrastructure inside their own perimeter. This is the single most common reason healthcare clients choose on-premise deployment, and the workload does not require a hosted model.