Why review dates fail
Not through negligence, and almost never through a decision. Review intervals fail because they are held in the wrong place, and three failure modes account for most of it.
The interval lives in someone's head. The protocol says three months, the team knows it says three months, and nothing in the system knows it. This works while the cohort is small and the founder is watching, and stops working at exactly the point the service becomes commercially significant.
The interval lives in a spreadsheet. Better, and it degrades quietly, because a spreadsheet records who was due and does not notice who was missed, does not attach the outcome to the clinical record, and is maintained by whoever remembers to maintain it.
The reminder fires and nothing follows. The most common of the three. A message is sent, the patient does not respond, and the obligation quietly disappears because nothing was tracking whether it was discharged.
The regulator's themed review of 24 April 2026 identified limited arrangements for ongoing clinical follow up among the recurring weaknesses in weight management services, alongside incomplete consultation records. The same gap appears wherever an interval matters, comprising TRT monitoring, ADHD titration and contraception continuation, and it is the mechanism this article exists to close.
What a recall is in Dataforge PMR
A dated clinical obligation attached to a patient record, generated from an interval the service configures.
Three properties distinguish it from a reminder. It surfaces the patient on a worklist when due, rather than only sending a message outward. It remains open until actioned or explicitly closed, so an unanswered recall is visible rather than absent. And it carries its outcome, meaning what was decided and by whom is recorded against the same patient journey as the assessment and the supply.
That third property is what converts the mechanism from an operational convenience into evidence, which is the requirement the buyer's guide criteria describe.
What the interval counts from
This is the configuration decision which quietly determines whether a service's intervals are accurate, and it is usually made without being noticed. A three-month review can be counted from the prescribing decision, from the date of supply, from the date of dispatch, or from the patient's last completed review, and these are not the same date. A patient whose supply was delayed by a shortage, who held stock across a gap, or who ordered late has a supply date which has drifted from the clinical decision the protocol actually measures. Anchor to dispatch and the interval stretches every time logistics slip. Anchor to the prescribing decision and it holds. The failure is invisible day to day, because each individual case looks reasonable, and it becomes visible in an audit which compares clinical decision dates against review dates across a cohort and finds intervals which have quietly extended. The rule is to anchor the recall to the event the clinical protocol names, then confirm it by checking a mature patient whose journey included a delay.
Configuring a recall
Four decisions, each of which should come from the clinical protocol rather than from what the software makes easy.
The trigger. Which event starts the clock, per the section above.
The interval. The period the protocol specifies, configured per service rather than globally, since a titration review and an annual check are different obligations.
The lead time. How far in advance the patient surfaces, which should allow enough time to contact, book and complete the review before the interval expires rather than on the day it does.
The outcome set. What closing a recall can record, comprising review completed, treatment continued, dose changed, treatment stopped, patient declined, or unable to contact. A recall which can only be marked done has recorded that somebody clicked something.
Overdue patients as a worklist
The reporting requirement is simple and frequently absent, being that someone can see, on any given morning, which patients are due and which are overdue.
Overdue is the more important of the two. A service which reports what is due this week and not what was missed last month has built a to-do list rather than a monitoring system, and the patients who most need attention are precisely those who have already slipped past their interval.
This is one of the lines our weekly scorecard recommends watching, and it belongs next to the commercial figures rather than in a separate clinical report, because a growing overdue count and a growing revenue line appearing in the same week is the pattern worth catching.
Patients who stop responding
A patient who has stopped responding whilst holding an active treatment is a clinical question, and the software's job is to keep them visible rather than to tidy them away.
Three things make this work in practice. Contact attempts are recorded, so the difference between a patient who was never contacted and one contacted three times is visible. Unable to contact is a valid outcome rather than an absence, which permits the service to demonstrate what it did. And disengaged patients remain a category rather than expiring, since the decision to stop pursuing someone should be a decision rather than a default.
What follows clinically is the prescriber's judgement, and it may include declining further supply until a review occurs, which is a service design question addressed in the clinic build guide rather than a software setting.
Evidencing that follow up happened
The themed review asked for ongoing clinical follow up to be arranged and for consultations and clinical decision making to be thoroughly documented. Those are one requirement in practice, because follow up which is not recorded cannot be evidenced.
A defensible recall record carries the due date and what it was anchored to, the contact attempts with their dates, the outcome and its reasoning, and the person who actioned it. Read together across a patient's journey, that produces the sequence a reviewer needs, being that the interval was set correctly, the patient was contacted, a clinical decision was made and the treatment continued or did not on that basis.
The test worth applying to any system is whether a colleague could reconstruct that sequence for a randomly chosen patient without asking anyone what happened.
Common configuration mistakes
Four, all recoverable, all cheaper to avoid.
Too many recall types, producing a worklist nobody can triage. Derive them from the protocol, not from the software's flexibility.
Lead times which are too short, surfacing the patient on the day the interval expires and guaranteeing that every review is marginally late.
Recalls used as marketing, which is a legal distinction as well as a clinical one, since a clinical recall is a service message whilst an offer attached to it becomes marketing subject to consent, as the email guide sets out.
Nobody owning the worklist. A recall system with no named person reviewing overdue patients weekly produces excellent data about a problem nobody is addressing, which is arguably worse than not having it.
Key takeaways
- Review intervals fail because they live in someone's head, in a spreadsheet, or in a reminder which fires and is never followed up, and the April 2026 themed review named limited follow up among recurring weaknesses.
- A recall is a dated clinical obligation which surfaces on a worklist, stays open until actioned or closed, and carries its outcome on the patient journey.
- Anchor the interval to the event the clinical protocol names rather than to dispatch, since supply dates drift and the resulting extension is invisible until an audit.
- Configure the trigger, interval, lead time and outcome set from the protocol, and give lead time enough room to complete the review before the interval expires.
- Report overdue as well as due, and keep that line next to the commercial figures rather than in a separate clinical report.
- Keep disengaged patients visible with contact attempts recorded and unable to contact as a valid outcome, since ceasing to pursue someone should be a decision.
- Test any system by asking whether a colleague could reconstruct a random patient's follow-up sequence without asking anyone what happened.
FAQs
Reviews that actually happen.
Bring your own review protocol and we will configure it live. See it working, then bring us your own case and we will set up your intervals, show the overdue worklist and walk through what a patient who stops responding looks like in the system.
See Dataforge PMR