The attestation statement: what a clinician is signing when the draft was machine-written

An attestation statement is the line by which a clinician asserts that they reviewed what is in the note and adopt it as their own. It is not a claim of authorship and it is not a disclaimer. On a machine-drafted note it does two jobs at once: it records that a human took responsibility for the content, and it records that the content did not originate with them.

That second job is why the sentence alone is not enough. "This note was drafted with the assistance of an ambient documentation system and reviewed by the signing clinician" is a reasonable sentence, and on its own it is unfalsifiable — it says nothing about which draft was reviewed, how long the review took, or whether the text stored today is the text that was on screen when the clinician signed.

What the signer is actually asserting

3 distinct claims are usually bundled into a single sentence, and separating them makes the record's shape obvious.

• Presence. That the signer conducted or supervised the encounter being documented. This is the claim that fails first when notes are drafted in bulk from recordings taken by somebody else, and it is the one an auditor asks about most directly.
• Review. That the signer read this content, in this state, before signing. Not that they read a draft of it, and not that they read the parts they were most interested in.
• Adoption. That the content is now theirs — that they stand behind the assessment and the plan as their clinical judgement, whatever produced the first draft.

Adoption is the one that carries the weight, and it is worth being blunt about its limits. A model does not become a co-author because the note says so, and no wording moves clinical responsibility off the signer. The attestation makes the arrangement legible; it does not change who is accountable for the record.

The scribe convention, and what changes when the scribe is software

Human medical scribes have documented alongside clinicians for years, and the conventions that grew up around them transfer almost intact. A scribe's entry normally carries the scribe's own identity, and the clinician adds a statement that they were present, reviewed the documentation and confirm it reflects the care they provided. 2 identities, 2 roles, 1 record.

3 things genuinely change when the scribe is software. The drafting identity is a system and a build version rather than a person, so the record needs a software identity that survives a release on a Tuesday. The volume changes: a clinician clearing 40 notes at the end of a list is doing something categorically different from one who reviews a scribe's work between patients, which is the argument behind reviewing the draft in the room rather than at the end of the list. And the failure mode changes: a human scribe who did not hear something leaves a gap, whereas a model fills it fluently, so review has to be verification rather than proofreading.

Store it as a record, not as a string in the note body

The design decision that makes an attestation verifiable is to stop treating it as prose. Rendered text at the foot of a note can be edited, copied into a template, or carried forward to a note it never applied to. A record with fields cannot.

Row 4 is the one most implementations miss, and it is the one that makes the rest meaningful. If a background job re-runs generation, applies a template change, or expands abbreviations after the clinician has signed, the stored note is no longer the note that was reviewed — and nothing in the record reveals it. Binding the signature to a hash of the reviewed text makes that divergence detectable instead of invisible. The same problem in a different guise is what makes an ambiguous abbreviation expanded after signature more than a cosmetic issue.

1. Freeze the draft when it is presented for review, and identify that frozen version by a hash of its content rather than a row identifier that can be updated in place.
2. Record the review window as two timestamps, not one. A single signed-at value cannot distinguish a careful read from a click, and the difference is the whole point of the record.
3. Store the diff between presented draft and signed text. It is small, it compresses well, and it is the only direct evidence of what the clinician contributed.
4. Make the record immutable at signature. Any subsequent change becomes an addendum with its own signer, timestamp and reason, and the original stays readable underneath.
5. Expose the attestation wherever the note is read, including exports and any patient-facing rendering — a note that leaves the system without its provenance arrives somewhere as an anonymous assertion.

What the attestation does not fix

It is a record of a decision, not a control over the decision's quality. A clinician signing 40 drafts in 6 minutes produces 40 valid attestations and 40 unreviewed notes, and the record is honest about that — which is exactly its value. Median seconds-per-note between draft presentation and signature is a blunt but genuinely diagnostic number: a median of 4 seconds on notes running to 300 words is not a reading speed anyone has. It becomes available the moment those 2 timestamps exist, and it costs nothing else to compute.

Nor does it stop the content problems the review is supposed to catch. Text carried from a previous encounter is signed just as readily as text written today, which is why provenance marking inside the note matters alongside the signature and why copy-forward makes a chart stop being readable. Attribution errors inside the note — a relative's symptom recorded as the patient's — survive a signature untouched, and are a capture problem that diarisation in a consult room addresses upstream. And a template that quietly asserts normal findings will keep doing so under any attestation wording, which is one of the reasons a general template against a specialty one is a governance question rather than a preference.

A sentence at the foot of a note is a claim. A record with a signer, a timestamp and a hash of what they saw is evidence. Only one of them survives being asked about two years later.

Most of this is unglamorous plumbing: an immutable record, two timestamps, a diff and a hash. It is also the part a documentation vendor is least likely to volunteer, so it belongs on the list in what to ask a clinical software vendor before signing — specifically, whether the signature is bound to a version, whether the record is immutable, and whether you can export it. Building that layer is the kind of work that sits in our internal tools and operations practice rather than in a model, the surrounding decisions are collected in ambient documentation and the clinical note, and the broader picture is in our healthcare and MedTech work.

• clinical documentation
• attestation
• governance
• audit trail