Every vendor in this category shows you a polished example. Almost none show you what arrives before a clinician edits it. That's the version worth seeing, because the gap between those two documents is the work you'll actually be doing.
I build one of these, so I'm describing our output rather than the category's. But the shape generalises, and knowing what to expect makes a trial far more informative than watching a demo.
The demo shows the finished version. The trial shows you this one.
What usually arrives in good shape
The structural sections. Referral question, procedures, the scaffolding of the document. These are mechanical and they come out clean.
Descriptive passages. Background written up from what you supplied, observations rendered into prose. Usually serviceable on the first pass, sometimes with phrasing that isn't quite yours.
Consistency. Terminology holding steady across twenty pages, headings in the right order, nothing contradicting itself six sections later. Software is genuinely better at this than a tired person at 10pm.
What usually arrives thin
Anything requiring selection. A summary has to decide what matters, and the software deliberately doesn't decide. What arrives lays the findings out with similar weight — a starting point for you to prioritise, because which finding changes the picture is a call only you can make.
Transitions between findings. The sentence that connects two results and says why the connection matters is exactly the sentence that requires judgment, so it isn't the draft's to write. What arrives there is a placeholder at most — a suggested shape you can react to, with the connective claim itself left for you to make.
Recommendations. The shape can be scaffolded, but the substance — the thing, the setting, the amount, whether the recommendation belongs there at all — comes from you. That's consistent with what the research says makes recommendations land, which I've covered in what the recommendations section is for.
The two things to expect to rewrite every time
The integration section. Not because the drafting is poor, but because that section is the professional judgment. What arrives should be a scaffold — the questions the section needs to answer — not an answer. If a tool hands you a confident integration you didn't reason your way to, that's a problem dressed as a feature.
Your own idiom. Every clinician has phrases they always use and phrases they never would. A draft gets close and then says something in a way you wouldn't. That's a five-minute pass, not a rewrite, but it's real and nobody mentions it in a demo.
Expect to rewrite the integration section. That's the design working, not failing.
What should never arrive
A finding you didn't supply.
If your material was missing something and the output contains a confident sentence covering it, that's the failure mode that matters — because it reads exactly like the true sentences around it. In a proofread you'd catch a garbled line instantly; a fluent invented one hides.
Which is why I'd deliberately leave a gap in any trial material and check. A tool that fills silently on a test case will fill silently on a real one.
How to read the raw draft when you get one
Three passes, in this order.
Provenance first. Pick three sentences at random and try to point at what they came from. If you can, the review is a genuine check. If you can't, everything else is moot.
Then completeness. What's missing that should be there, and did the draft say so.
Then voice. Last, because it's the cheapest to fix and the easiest to be distracted by. A draft that sounds slightly off but is accurate and traceable is far better than one that sounds perfect and can't be verified.
If you want to see ours on your own material rather than a sample, that's the trial — and the protocol for running it without exposing a real client file is in trialling an AI report tool without risking a client file.
— Ian
