Every working day, letters arrive at your practice — discharge summaries, outpatient letters, ambulance reports, results. Someone has to read every one, decide what it means, code it, action it, and file it. It is one of the most consequential jobs in the building, and one of the least visible.
Document workflow is where many practices first meet operational AI, because suppliers have built tools that read incoming letters, suggest clinical codes, propose actions, and route documents to the right person.
This lesson is about that category of tool. Note what that means: incoming documents are full of patient-identifiable data, so everything in this lesson concerns embedded tools — procured systems with data processing agreements and completed DPIAs. Nothing here is a job for ChatGPT.
What these tools actually do
AI document tools typically offer some combination of four functions.
Reading and summarising. The tool extracts the key content of a letter — diagnosis changes, medication changes, follow-up requests — and presents a summary so the processor can work faster.
Code suggestion. The tool proposes clinical codes for the record: a new diagnosis, a procedure, a result. A human accepts, amends, or rejects the suggestion.
Action suggestion. The tool flags what the letter seems to require — a medication change, an appointment, a task for a clinician — and routes it accordingly.
Prioritisation. The tool sorts the incoming pile so urgent items surface first rather than waiting their turn in a date-ordered queue.
Used well, these tools can meaningfully reduce the time between a letter arriving and its contents being safely reflected in the record. Used carelessly, they create a new failure mode: miscoded records and missed actions at scale, with a false sense of security on top.
The failure modes to respect
Everything you learned about AI errors in Module 2 applies to document tools, with a workflow twist.
Wrong code, plausible code. AI coding errors are rarely absurd. The tool will not code a fracture as pregnancy. It will code “query angina, for investigation” as confirmed angina — plausible, wrong, and consequential for the patient’s record, insurance, and future care. Plausible errors survive casual review.
Missed actions. A letter may contain three actions. The tool finds two. The human, reassured by the summary, does not read to the end. The third action — stop the anticoagulant, chase the scan — is lost.
Automation complacency, again. The pattern from Module 4 returns: after weeks of good suggestions, staff stop checking. The error rate has not changed. The checking rate has.
The safety question for document AI is not “how accurate is the tool?” It is “what happens to the errors?” A tool with 95% coding accuracy in a practice processing a thousand documents a week produces dozens of errors weekly. Your workflow — who reviews, what they compare against the original letter, how disagreements are logged — determines whether those errors are caught or filed.
Designing the human role properly
The practices that use document AI well have redesigned the human role rather than simply deleting it.
Review against the source. The reviewer checks suggestions against the original letter, not just against plausibility. The summary is a navigation aid, never a substitute for the document.
Clear escalation thresholds. Medication changes, new significant diagnoses, safeguarding content, and anything ambiguous go to a clinician. The tool can route; only a clinician decides.
Audit on a rhythm. A monthly sample of processed documents — checked end to end by someone senior — tells you your real error rate. This mirrors the note audits from Module 4, and it belongs on the same governance agenda.
Feedback to the supplier. Recurring error patterns should go back to the supplier as structured feedback. Good suppliers want it; a supplier who does not is telling you something.
Adopting a document tool
If your practice is considering a document management or coding tool, the process is one you already know. This is a Module 4 implementation, start to finish.
Ask the five questions from Module 3: is it approved for NHS use, is it registered where it needs to be, where does the data go, can you complete a DPIA, can your team use it well? Then Decide, Prepare, Pilot, Embed — with a pilot that measures coding accuracy and missed actions, not just speed.
In the pilot, run a parallel sample: have your experienced document processor handle a set of letters the traditional way while the tool processes the same set. Compare codes and actions. The disagreements are your training material — and your evidence for the partners’ meeting.
One more thing worth saying: document AI changes a job that someone in your practice has done, often for years, and done well. Involve them from the first conversation. They know where the bodies are buried in your document workflow, and their judgement about the tool’s suggestions will be sharper than anyone else’s.
Key Takeaway
Document and coding AI can genuinely speed up correspondence workflow, but it processes patient data and therefore belongs strictly in the embedded, governed category — procured through the Module 4 process. The safety question is what happens to the errors: review against the source document, escalate clinical decisions to clinicians, audit monthly, and involve your experienced document staff from day one.