What makes weight management software different?
Three requirements arrive together which most systems handle separately, and the combination is what defeats assembled stacks.
Eligibility rests on verified facts rather than reported ones. The category's defining regulatory failure is accepting self-reported measurements, so the record must hold what was independently confirmed, from what source, on what date, accepted by whom. A field recording that eligibility was confirmed is an assertion. The artefact behind it is evidence.
The dose moves on a schedule. Titration means the clinically relevant object is a sequence rather than a current value, and a system which shows only the present dose cannot answer why the patient is on it, who decided, or whether the escalation followed the protocol.
The review cannot be allowed to slip. This is simultaneously the safety mechanism and the commercial one, and it fails silently, since nobody notices a review which did not happen until something else goes wrong.
The regulator has now specified what this means. Its themed review of 24 April 2026 found inconsistent verification sitting alongside incomplete consultation records and limited follow up, and the inspection framework of 13 January 2026 makes failure to verify weight, height or BMI an inspection failure. A system is therefore being asked to evidence six things rather than store four, which is why the criteria below are written around evidence rather than around fields.
Underneath all three sits the arithmetic set out in the clinic build guide. The cohort matures, and by roughly the second year reviews and dose adjustments exceed new consultations. Software chosen on how smoothly it onboards will be the wrong software precisely when the service is largest.
What are the criteria for weight management clinic software?
Score any vendor against these, including this one. They are stated so that a competitor could answer them, because a criteria list which only one product satisfies is a specification rather than an evaluation.
| Criterion | What good looks like |
|---|---|
| Verification as evidence | The artefact stored against the patient with source, date and accepting user, rather than a confirmation flag |
| Dose history as a sequence | Every dose with its prescribing decision, reasoning and author, readable as a timeline |
| Review intervals driven by the system | Recalls fired against the interval, with overdue patients visible as a worklist rather than discoverable on request |
| Refusals recorded as first-class events | A decline captured with its reasoning, so refusal rate can be reported as a quality measure |
| One record end to end | Assessment, verification, prescribing, dispensing and delivery on a single patient journey with no rekeying |
| Questionnaire version control | The version applied to each consultation recorded, so a cohort can be identified when guidance changes |
| Prescriber workload visibility | Decision times, approval rates and caseload visible to the superintendent |
| Maintenance-cohort reporting | Retention, overdue reviews and discontinuations reportable, not just new starts |
| Data protection posture | Per-user accounts with multi-factor authentication, exportable access lists, defined retention |
| Exit | Full patient data export in a usable format, on documented terms, priced in advance |
The last criterion is the one most often omitted and the one a purchaser regrets omitting. A system which cannot be left is a dependency rather than a supplier.
How does Dataforge PMR answer each criterion?
Honestly, including where the answer is a workflow rather than a feature, and including where the answer is no.
Verification as evidence. Verification artefacts are stored against the patient record with the source, the date and the accepting user, so the evidence pack is the record rather than a reconstruction. Dose history. Doses are held as a sequence with each prescribing decision, its reasoning and its author attributed and dated. Review intervals. Recalls fire against intervals the service configures, and overdue patients surface as a worklist. Whether a supply is hard-blocked pending review is a configuration decision for the service rather than an enforced product behaviour, which we state plainly because it determines who carries the responsibility.
Refusals. Declines are recorded with reasoning and are reportable, so refusal rate can be read as the quality signal the playbook describes. One record. Assessment through to delivery runs on one patient journey, which is the design premise of the product. Questionnaire versioning. Supported through the service's own configuration and recorded per consultation.
Prescriber visibility. Decision attribution and caseload are available to the superintendent. Maintenance reporting. Retention and overdue-review views are the reporting we regard as the category's actual requirement. Data protection. Per-user accounts with multi-factor authentication and exportable access lists, matching what the DSPT declaration already assumes. Exit. Full patient data export on documented terms.
What we do not do. Verification and measurement data are entered as a workflow step the service owns rather than pulled through automated third-party feeds, and titration ladders are configured rather than shipped as fixed protocols. Both are deliberate, both belong in a process design, and an operator for whom either is a genuine constraint should weigh it now rather than discover it at implementation.
What should the decision process look like?
Four steps, in order.
Score the criteria before seeing demonstrations, weighting them for your own service, since a demonstration is designed to make its own strengths feel like your requirements.
Test with the maintenance case. Ask each vendor to show a patient eighteen months into treatment with a dose change, a missed review and a discontinuation, rather than a new patient onboarding. Most demonstrations are built around the second.
Ask what it cannot do, and treat a vendor without a clear answer as a vendor who has not been asked or will not say.
Confirm the exit before signing, comprising what is exported, in what format, on what notice and at what cost.
Key takeaways
- Weight management combines verified eligibility, tracked titration and enforced review intervals, which is why assembled stacks fail on the question an inspector actually asks.
- Verification must be stored as an artefact with source, date and accepting user, since a confirmation flag is an assertion rather than evidence.
- Dose history is a sequence with attributed decisions, not a current value, and reviews fail silently unless the system drives them.
- Score the ten criteria against every vendor including this one, and weight the maintenance case, since the cohort inverts by roughly the second year.
- Dataforge PMR holds verification artefacts, attributed dose sequences, interval-driven recalls, recorded refusals and one end-to-end record, with per-user authentication and full export.
- It does not pull automated verification or lab feeds and does not ship fixed titration ladders, both of which are workflow decisions the service owns.
- Test with an eighteen-month patient rather than an onboarding, ask what the system cannot do, and confirm the exit terms before signing.
FAQs
Test it with a month-eighteen patient.
Ask any vendor to show you a patient eighteen months into treatment with a dose change, a missed review and a discontinuation, rather than a new patient onboarding. See it working, then bring us your own case and we will run exactly that, and show you where Dataforge PMR ends and your own workflow begins.
See Dataforge PMR