How Dataforge PMR screens orders: identity verification, duplicate detection and prescriber review

How does Dataforge PMR screen orders before a prescriber sees them?

Every order arrives at the prescriber's dashboard already verified and assembled: the patient's identity has been confirmed by live verification at the point they submitted their clinical assessment, their responses, history and any uploaded documents sit together as one case file, and any resemblance to a previous order is flagged with a match score for the prescriber to check. The prescriber then makes the clinical decision, approve, request more information or reject, and only an approved order moves on to prescription generation, labelling and dispatch.

The division of labour is the point of the design. The platform does the work machines do reliably: proving who submitted the form, assembling every piece of information into one place and pattern-matching against order history. The prescriber does the work only a clinician can do: judging whether this treatment is appropriate for this patient on this evidence. That split maps directly onto what the General Pharmaceutical Council (GPhC) has spent two years enforcing, individual clinical review of every supply, verification evidenced on the record, no transactional auto-approval, which is why this page doubles as the due diligence answer for any prescriber or superintendent evaluating the platform.

Live identity verification at the point of submission

Dataforge PMR verifies identity with a live ID document and a live selfie captured at the moment the patient submits their assessment form, which is the strongest position available for a distance service: the platform confirms in real time that the person completing the clinical assessment is the person on the document, rather than checking a name against an uploaded file after the fact. Liveness matters because static images can be edited, and the GPhC's April 2026 review documented exactly that failure in the wider market, including an investigation in which people obtained weight loss injections using manipulated photographs. Point-of-submission live verification is the gold standard the regulator's verification expectations point towards, and it means the identity evidence lands on the patient record before any clinical review begins.

What the prescriber's case file contains

By the time a case reaches the review dashboard it is complete, which is the platform's answer to the thin-consultation-record problem the regulator keeps finding. The file holds the clinical assessment responses, structured patient data capture and information gathering configured per service, the medical history as gathered, any documents uploaded against the patient, such as prior results, referral letters or identity evidence, and the free-type notes clinicians add before, during and after consultations. The verification result and any duplicate flag sit alongside.

The principle is that the platform assembles and the prescriber judges. A prescriber working from a complete file makes better decisions and leaves better records, and the consultation record the GPhC expects, one detailed enough to demonstrate a safe, clinically appropriate decision on its own, is generated by the act of working through the case rather than written up separately afterwards. The assessment configuration itself, what each service asks and captures, is covered in the Bookings and getting started guides.

How duplicate detection works

Duplicate detection matches each new order against order history using four identifiers, first name, last name, date of birth and email address, and presents the prescriber with a percentage risk score indicating how closely the new order resembles a previous one. A high score might be the same patient reordering appropriately, the same patient reordering too soon, or an attempt to obtain a second supply through a lightly varied identity; a lower score might be a family member sharing an email address. The system does not decide which, and that is deliberate: the flag warns the prescriber to check manually, with the score as the guide, rather than auto-blocking or auto-clearing.

Warn-and-check is the defensible design for exactly the reason auto-decisions fail audits: a hard block punishes the legitimate patient whose circumstances look unusual, and an auto-clear waves through the determined misuser, while a scored flag plus a human check handles both and leaves a record of the judgement. Over-ordering and multiple-account behaviour is a documented pattern in the GPhC's concerns data, and the flag, the score and the prescriber's conclusion are all on the record, which is the answer to the inspector's question.

The three outcomes: approve, request more information, reject

Every case ends in one of three recorded outcomes. Approve moves the order into prescription generation, labelling and dispensing. Request more information opens a dialogue with the patient, which is the route that separates a clinical service from a checkout: borderline cases get questions rather than a coin-flip decision, and the exchange becomes part of the case file. Reject closes the order with the reason recorded, and a service's refusals are as much a part of its governance evidence as its approvals, because a pharmacy that cannot show who it declined cannot show that its gateway works.

Each outcome writes the decision, the decider and the rationale to the record, which is the audit trail's clinical core: months later, for any patient, the pharmacy can show what was known, who judged it and why the supply happened or did not.

What Dataforge PMR deliberately does not automate

Dataforge PMR does not currently include an automated drug interaction checker or an automated contraindication checker, and the honest framing of that boundary matters more than a feature list. Every clinical judgement, including whether the patient's declared medication and history make a treatment safe, sits with the prescriber reviewing the complete case file; the platform's job is to make sure that file is complete, verified and in front of them. Prescribers using Dataforge PMR apply their own clinical references and judgement to the assembled information, exactly as they would in any consultation.

Stated as service design rather than apology: the failure mode the GPhC has spent two years acting against is not the absence of automated checkers, it is transactional prescribing where no clinician meaningfully reviewed anything. A platform that auto-approved on green flags would be building that failure mode with extra steps. The regulatory principle that decision support never substitutes for the professional's judgement holds here in its strongest form, because the professional's judgement is the decision layer, on every order, with no path around it.

After approval: straight to fulfilment

Approved orders move to fulfilment without re-keying: the Royal Mail Click and Drop integration sends approved orders directly to Click and Drop for despatch, and tracking numbers come back onto the order record automatically. Between approval and despatch sit the dispensing steps covered in the getting started guide, prescription generation, label printing and the dispensing queue's verification and scanning states, so the handoff to the courier happens only after the pharmacy's own checks are done.

Tracking on the record is worth more than convenience. The GPhC's April 2026 review received more concerns about deliveries than about dispensing errors, parcels left insecure, cold chain failures, patients unable to find out where their medicine was, and a pharmacy whose tracking lives on the patient record can answer the where-is-it question instantly and evidence the despatch trail at inspection. Delivery is part of the supply, and the record should run to the doorstep.

The audit trail across the whole journey

Every action across the journey is logged as it happens: the verification result, the assessment submission, each note and document, the duplicate flag and its resolution, the prescriber's decision and rationale, the prescription, the label, each dispensing state and the tracking number. Nothing is written up afterwards, because the log is a by-product of the work rather than a task on top of it. For a superintendent this is the practical difference between producing a patient journey on demand and reconstructing one under pressure, and it is the standard our private prescription workflow guide sets for any service: one record, from identity to doorstep, assembled by the system that did the work.

Key takeaways

FAQs