Going paperless on day one
A discharge summary is a view of clinical data that has already been recorded, not something a person has to sit down and write. Record the data and the document comes free.
Everything below elaborates this sentence.
The reason paperless usually fails
Claims require documents: a discharge summary, a claim form, a treatment sheet, a signed consent. Most systems meet that requirement by asking a person to write the document, into a word processor or into a form that produces a PDF, and then to attach it.
That is the paper workflow with the paper taken out. It still costs a person per claim, it still happens at the end when everyone is in a hurry, and the documents it produces still disagree with the clinical record they were transcribed from.
The alternative is to render documents rather than author them. Every field a discharge summary contains, the diagnosis, the encounter dates, the medications, the results and the clinician, is already recorded at 05 · Treat. The document is a projection of that record.
| Call | What it does | What you keep |
|---|---|---|
You record clinical facts | Diagnoses, observations, orders, results and prescriptions, coded as the encounter runs. This is the work, and you were doing it anyway. | the record |
The rail renders documents | It knows which documents this claim requires, and it holds the data each of them is made of. Ask for them and it produces them. | document_id |
Nobody types a summary | A new HMIS on the rail is paperless the day it connects, without building a document editor, a template engine or a PDF pipeline. | the capability, for free |
Generate what the claim requires
Generate the documents this visit's items require, from the clinical data already recorded.
The response is per document, and the one worth reading is the document that could not be built.
Code
missing[] names clinical elements rather than form fields. The fix is to record the fact, so
close the encounter or rank the primary diagnosis instead of typing anything into a document.
A system that treats missing[] as a validation error on a form has rebuilt the thing this
replaces.
Render on demand
Render a document to show on screen, or as a PDF to hand over and sign.
| Call | What it does | What you keep |
|---|---|---|
HTML | For display inside your own UI, in a clinician's review screen, in a patient portal. It is styled to be embedded rather than printed. | the markup |
PDF | For the cases where a physical artefact is genuinely required, such as a signature, a hand-over, or a regulator who asks for one. | the file |
Deterministic from the record | Render the same visit twice and you get the same document. You never have to store a snapshot, because you can ask for the view again. | nothing |
Do not cache the rendered artefact as your source of truth. The record is the truth and the
document is derived from it, so a stored PDF goes stale the moment a result is amended. Store the
document_id that was attached to the claim, since that is the version the payer assessed, and
render fresh for everything else.
What this gives an HMIS that has never had it
- 01A small clinic connects and is paperlessIt needs no document editor, no template library and no PDF service. It records clinically, asks for documents, and attaches what comes back.
- 02The documents always match the recordNothing is transcribed between the two, so what was billed, what was recorded and what the payer reads cannot drift apart.
- 03Attachment failures move upstreamMISSING_DOCUMENTS at submission becomes DOCUMENT_DATA_INCOMPLETE while the encounter is still open, naming the clinical gap while somebody can still close it.
- 04The same data serves four purposesOne recording becomes the claim's evidence, the shared health record, the referral's payload, and the document set. You capture it once, at the point it was true.
What breaks here
| Where it surfaces | What the desk sees | What actually went wrong |
|---|---|---|
| Submit | "Generation says incomplete and we cannot see why" | Read missing[]. It names clinical elements, so record the fact rather than looking for a form field to fill. |
| Submit | "We attached a summary we wrote and it was queried" | A hand-written document disagrees with the coded record behind the claim. Generate it instead; the assessor is reading both. |
| Treat | "The PDF we stored is out of date" | A rendered document is a view rather than a record. Keep the document_id that was attached and re-render everything else. |
Errors
| HTTP | error | When |
|---|---|---|
| 422 | DOCUMENT_DATA_INCOMPLETE | The clinical data the document renders from is missing elements. |
| 422 | MISSING_DOCUMENTS | A required document was never attached. Checked at 08 · Submit. |
Back to the stop that records the data all of this is generated from.