What a discharge summary is actually for

It has more than one reader

A general practitioner needs to know what changed and what they are now responsible for. A community team needs the practical detail of what happens next. The patient, who increasingly does read it, needs to understand what happened to them.

A future clinician, possibly years later and in a different organisation, needs the narrative that explains a decision that will otherwise look inexplicable.

One document, four readers, different needs. Most templates are designed as though there is one.

That does not mean writing four documents. It means ordering the single one so the parts each reader needs are findable without reading the whole thing, and not burying the actionable content under the narrative.

It is written under the worst conditions in the admission

It gets written at the end, under time pressure, frequently by the team member with the least longitudinal knowledge of the patient, because that is who is available when the bed is needed.

That is not a discipline problem to be solved with reminders. It is a structural feature of how discharge works, and software that assumes an unhurried author is designing for a situation that does not occur.

What the software should already know

Anything the system recorded during the admission should not need to be retyped. Diagnoses, procedures, medications started and stopped, and results that materially changed the plan are all in the record already.

Retyping is not merely slow. It is where errors enter, because a summary typed from memory at the end of a shift is a reconstruction, and reconstructions drift.

The author's job should be the part only a human can do: what actually happened, what we think it means, and what we are asking somebody else to do next.

Medication changes are the payload

If a summary communicates one thing successfully, it should be the medication delta: what was started, what was stopped, what was changed and why, and which of those are time-limited.

'Continue as before' next to a list that differs from what the patient was actually taking before is one of the most consequential ambiguities in the document, and it is usually a formatting problem rather than a clinical one.

Say what is outstanding

Results pending at discharge are a well-known source of harm, and they are structurally awkward: the person best placed to interpret them is no longer involved by the time they arrive.

So the summary has to be explicit about what is outstanding, who is expected to look at it, and what should happen if it is abnormal. A system that knows an order is unresolved can surface that, which is considerably more reliable than expecting a tired author to remember.

Timeliness beats completeness

A thorough summary that arrives after the patient has been seen in the community has failed at its only job. A shorter one that arrives before the handover is worth more.

That is an uncomfortable trade to design for, and pretending otherwise produces documents that are excellent and late.

The design consequence is that the summary should be assembled continuously rather than composed at the end. If most of it exists by the time discharge is decided, the author is editing rather than writing, and editing under time pressure produces far better results than composition does.