How do reminders and recalls work in Dataforge PMR?

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. It stops working at exactly the point the service becomes commercially significant.

The interval lives in a spreadsheet. Better, and it degrades quietly. A spreadsheet records who was due but does not notice who was missed. It does not attach the outcome to the clinical record, and it 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, including TRT monitoring, ADHD titration and contraception continuation. 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: what was decided, and by whom, is recorded against the same patient journey as the assessment and the supply.

That third property is what turns the mechanism from an operational convenience into evidence — the requirement the buyer's guide criteria describe.

What the interval counts from

Configuring a recall

Four decisions. Each should come from the clinical protocol, not 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. Allow enough time to contact, book and complete the review before the interval expires, not on the day it does.

The outcome set. What closing a recall can record: review completed, treatment continued, dose changed, treatment stopped, patient declined, or unable to contact. A recall that can only be marked done has recorded that somebody clicked something.

Overdue patients as a worklist

The reporting requirement is simple and frequently absent: 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 that reports what is due this week, but not what was missed last month, has built a to-do list rather than a monitoring system. 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. It belongs next to the commercial figures, not in a separate clinical report. A growing overdue count and a growing revenue line in the same week is the pattern worth catching.

Patients who stop responding

A patient who has stopped responding while holding an active treatment is a clinical question. The software's job is to keep them visible, not 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 lets the service demonstrate what it did. And disengaged patients remain a category rather than expiring. Stopping pursuit of someone should be a decision, not a default.

What follows clinically is the prescriber's judgement. It may include declining further supply until a review occurs — a service design question addressed in the clinic build guide, not 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. In practice those are one requirement, because follow up that is not recorded cannot be evidenced.

A defensible recall record carries four things: 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. 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 that are too short. The patient surfaces on the day the interval expires, and every review is guaranteed to be marginally late.

Recalls used as marketing. The distinction is legal as well as clinical: a clinical recall is a service message, while 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. That is arguably worse than not having it.

Key takeaways

FAQs