Why the current record is not enough
Most systems are built to answer what is true now. What dose is this patient on, when is the next supply due, what was ordered. That is the right design for dispensing and the wrong design for monitoring, because the clinically interesting object in a monitored service is the shape of the change rather than the current value.
A prescriber deciding whether to continue treatment is asking whether this patient is responding, whether the response has plateaued, whether a side effect appeared after a particular escalation, and whether the last three reviews say the same thing. None of those questions can be answered by a current-state record, and all of them are ordinary.
The regulator described the same gap from the other direction. Its themed review of 24 April 2026 identified incomplete or insufficient patient consultation records among the recurring weaknesses in weight management services, and asked for all consultations and clinical decision making to be thoroughly documented. A longitudinal record is what that expectation looks like once it reaches a system.
What the patient record should hold
One chronological view, on the patient rather than split across modules, carrying seven things.
| Entry | What it carries |
|---|---|
| Consultation | The questionnaire as answered, with the version applied |
| Verification | The artefact, its source, the date and who accepted it |
| Clinical decision | What was decided, the reasoning, and the prescriber who decided it |
| Custom field values | Measurements captured at that point, as structured values |
| Supply | What was dispensed, when, and against which decision |
| Recall | The due date, contact attempts and the outcome |
| Notes and attachments | Narrative context and documents, attributed and dated |
The property which makes it useful is that these sit in one sequence rather than in seven places. A reader following a patient down the timeline sees the assessment, then the measurement it produced, then the decision that measurement supported, then the supply that decision authorised, then the review that followed. That ordering is the record.
What kinds of patient data can you capture?
Patient data capture means the questions a service asks and the clinical values it records against a patient, which differ by service. A weight management service captures weight and BMI, a TRT service captures testosterone and haematocrit, a travel clinic captures destinations and dates. In Dataforge PMR these capture points are called custom fields, and the rest of this article uses that term where it means the specific thing rather than the general practice.
The kind of data chosen determines what can be done with the value afterwards, which is why it deserves more thought than it usually receives at setup.
| Type | Use it for | What it enables |
|---|---|---|
| Number | Weight, height, blood pressure, laboratory values, doses | Comparison across entries, thresholds, charting, cohort reporting |
| Single select | Anything with a fixed set of answers, comprising indication, product, injection site, outcome | Clean filtering and counting, since free text cannot be counted reliably |
| Multi select | Comorbidities, concurrent medicines, reported side effects | Identifying every patient with a given flag without reading each record |
| Yes or no | Contraindication checks, consent confirmations, eligibility gates | Unambiguous screening logic and rapid audit |
| Date | Last review, treatment start, date a measurement was taken | Interval calculation, which is what recalls depend upon |
| Short text | Identifiers, GP practice, batch references | Retrieval and matching, though not analysis |
| Long text | Narrative context which belongs to the entry rather than to a note | Human reading only, and it should not hold measurements |
| File upload | Verification artefacts, photographs, correspondence, results | Evidence attached to the entry it supports rather than sitting in an inbox |
| E-signature | Consent to treatment, service terms, data sharing, photography and marketing permissions | Consent held as dated, attributed, versioned evidence rather than as a tick |
Two choices repay particular attention. Prefer a single select over short text wherever the answers are genuinely finite, because a service which records indication as free text will discover it has eleven spellings of the same thing when it first tries to count them. And use the file upload type for verification rather than a note saying evidence seen, since the artefact is the evidence and a note recording that somebody looked at it is not, which is the distinction our verification duties article turns on.
Consent as recorded data, not a tick
Consent is the field most services treat least carefully, usually as a checkbox on a form which records that a box was ticked and nothing about what the wording said at the time. That is adequate until the wording changes, at which point the service has a population of patients who consented to something it can no longer identify. Capturing consent as an e-signature field changes what is stored. The record holds who signed, the date and time, and, critically, the version of the wording they were shown, so that a reader two years later can establish not merely that consent was given but what was consented to. Four elements make a consent record evidential rather than decorative. The signature itself, attributed to a named patient. The timestamp. The version identifier of the consent text, which is the element almost always missing. And immutability, meaning a signed consent is not editable afterwards, because a signature which can be amended is not a signature. Held that way, consent sits on the same timeline as the assessment, the decision and the supply, which is where a reviewer expects to find it.
Three consent types recur across private services and warrant separate fields rather than one combined agreement, since they are withdrawn independently. Consent to treatment, which is clinical and specific to the service. Agreement to service terms, which is contractual. And permissions, covering data sharing with a GP, photography where a service uses it, and marketing, which is the one governed by the consent rules our PECR guide sets out and which must be separately given and separately revocable.
Version control deserves the same discipline as the questionnaire versioning described elsewhere in this library. When consent wording is revised, the revision is released as a new version with an effective date, and existing signatures continue to reference the version actually shown. The alternative, which is amending the wording in place, retrospectively changes what every previously consenting patient appears to have agreed to, and that is a records failure rather than a tidy-up.
Designing your data capture set
Services monitor different things, and the design decision is which values a particular service needs as structured data rather than as prose.
Four principles produce a capture set which remains useful.
Derive them from the clinical protocol. If the protocol says review haematocrit at each interval, haematocrit is a field. If nothing in the protocol references a value, it probably does not need to be one.
One field, one meaning. A field called weight should hold weight, in one unit, always. A field which sometimes holds a number and sometimes holds a sentence is a note wearing a field's name.
Capture the unit and the method where they vary. A measurement taken in clinic and one reported by the patient are different pieces of evidence, and a service which cannot distinguish them cannot demonstrate independent verification, which is the requirement the verification duties article sets out.
Keep the set small. Every additional field is something a team must complete at every consultation, and fields nobody completes are worse than absent ones, because they create the appearance of a record without the substance.
When to record a value and when to write a note
This is the single decision which determines whether a service can analyse its own records, and it is usually made by accident. A weight typed into a consultation note is retrievable by a human reading that note and invisible to everything else. The same weight entered as a field becomes a point in a series, which can be compared against the previous one, charted across a treatment, filtered on when identifying patients who have plateaued, and produced as a column when an auditor asks for the cohort. The test is simple and worth applying to every value a service captures. Would you ever want to see this as a column or a chart? If yes, it is a field. If it is context, nuance, or the sentence explaining why the number is what it is, it is a note. Most services need both on the same entry, being the measurement as a field and the explanation as a note, and the mistake is not choosing wrongly between them but collapsing the two into free text because it was quicker on the day.
Asking before the appointment
Consultation time is the scarcest and most expensive resource a clinical service has, and the ordinary way it gets consumed is collecting information which could have been collected earlier. A patient arrives, and the first eight minutes are spent asking their weight, their medical history, their current medicines, whether they have tried anything before and who their GP is, whilst a clinician types. What remains is the part the patient came for. Attaching the custom fields to the booking rather than to the appointment inverts that. The patient completes them when they book, in their own time and at home, where they can check a packet, weigh themselves properly and look up a dose rather than estimating under the mild pressure of being watched. The clinician opens the appointment with the record already populated, and spends the time reading, questioning and deciding rather than gathering. In our own observation the effect is not marginal, since it converts a substantial share of a consultation from administration into clinical work without extending the appointment or shortening the care.
Four second-order benefits follow, and they matter as much as the time saved.
Flags surface before the day. A contraindication, an interaction or an answer requiring discussion appears while the appointment can still be lengthened, reassigned to a different clinician, or converted into a different conversation. Discovering it at the start of a ten-minute slot means the slot was the wrong slot.
Ineligible patients are identified before an appointment is consumed. Where a person plainly does not meet the criteria, that is better established at booking, courteously and with signposting, than after they have taken time off work and paid. It is also better for the service, since a refusal at the appointment is an appointment which produced nothing.
Verification can be requested and chased in advance. Where the category requires an artefact rather than a self-report, asking for it at booking gives the patient days to obtain it and the service time to follow up, rather than discovering on the day that the review cannot proceed. This is the difference between a verification requirement which functions and one which becomes a reason to make exceptions.
Answers are better. A person answering at home consults the packet, the previous letter and the bathroom scales. The same person answering across a desk estimates. The clinical quality of a pre-completed history is generally higher, not merely more convenient.
Consent is given properly rather than at a counter. This is the benefit most worth having and the one least often designed for. A patient signing consent at booking has the opportunity to read it, which a patient signing at the start of an appointment, with a clinician waiting, does not. Capturing the e-signature at booking therefore improves the quality of the consent as well as its convenience, and it means the appointment opens with the agreement already on the record rather than spending its first minutes obtaining one.
Three honest limits belong alongside that. Pre-capture does not replace the clinical conversation, and anything requiring the clinician's judgement about how an answer was given still belongs in the appointment. A pre-booking form which is too long reduces completion, so the set should be the minimum the appointment genuinely needs in advance. And answers given at booking must still be confirmed rather than assumed, since a patient completing a form a week ago may have changed medicine since.
A worked example: a weight management patient
What the timeline should contain at month nine, expressed as what a reader can establish.
At initial consultation, the questionnaire as answered with its version, the verified height and starting weight with the source of that verification and who accepted it, the calculated BMI, the prescriber's decision to initiate with reasoning, and the first supply. At each subsequent review, the current weight as a field, the change since the previous entry visible because both are fields, any side effects recorded, the decision to continue, escalate or hold with its reasoning, and the supply that followed.
What that produces at month nine is the ability to answer, from one screen, whether the patient responded, when the response slowed, whether a dose change preceded or followed that, whether reviews occurred at the intervals the protocol requires, and who made each decision. Those are precisely the questions the themed review's documentation expectation exists to make answerable.
Exporting patient data for reporting and audit
Captured values export alongside the rest of the patient record as CSV, per our data export guide, and one structural point determines whether the export is analysable.
A record can be exported one row per patient, with the latest value of each field in its own column, or one row per entry, with each measurement carrying its own date. The first is convenient for a current-state list and destroys the series. The second is what a longitudinal service needs, because it preserves the trajectory the whole record exists to hold. Where a service intends to analyse response, plateau or interval compliance, it wants the entry-level export.
Three practical uses justify taking one periodically rather than only at migration. Cohort reporting, comprising how many patients are within a BMI band, how many recorded a given side effect, how many are overdue. Audit preparation, since producing the evidence for a sample of patients is a filter rather than a fortnight when the values are structured. And service review, which is the clinical governance obligation the April 2026 themed review asks to be regularly reviewed, and which is considerably easier to discharge when the data supporting it can be produced as a table.
Captured patient data is personal and frequently special category data, so an export is subject to the same handling as any other patient extract, encrypted and access-controlled on the reasoning in the security baseline.
How changes to patient data are audited
A value which can be changed without trace is not evidence, so every recorded value carries who entered it and when, and every subsequent change carries who changed it, when, and what it was before.
That matters more than it sounds, because a corrected value and an original value are different clinical objects. A weight amended the day after a consultation may be an honest transcription fix or may be the reason a patient became eligible, and only the audit trail distinguishes them. A service which cannot show the difference is asking a reviewer to take the current value on trust.
Three properties are worth confirming in any system, including this one. Changes are recorded rather than overwritten, so the prior value survives. Attribution is to a named individual account, which is the reason shared logins defeat the entire mechanism, as the security article notes. And the audit entries export with the data, since an audit trail visible only inside the system cannot be produced to anyone who is not sitting at it.
Signed consent is the exception to that pattern and should behave differently. A consent e-signature is not amended, because the point of a signature is that it captures a moment. Where circumstances change, the correct action is a fresh signature against the current version rather than an edit to the previous one, leaving both on the timeline so that a reader can see what was agreed and when it was superseded.
The test to apply is whether the system can answer, for a value which matters, what it was originally, who changed it, when, and what it became. A service which can answer that has records. A service which can only show the current figure has a database.
Reading a patient record as a prescriber
The design serves the clinician before it serves the auditor, and three reading patterns should be easy.
The trajectory. Values as a series rather than as the latest entry, so a plateau is visible as a shape rather than inferred by scrolling.
The decision chain. Each decision beside the values it was based on, so a prescriber reviewing a colleague's decision can see what they were looking at rather than reconstructing it.
The gaps. A missing review is as clinically significant as a completed one, and it should be visible on the timeline rather than only absent from it, which is the reason recalls belong on the same record as described in the recalls article.
Data capture mistakes that ruin a record
Four, all common, all cheap to avoid and expensive to correct once patients are enrolled.
Capturing too much. A comprehensive set designed at launch, half of which is left blank in practice, produces a record which looks thorough and is patchy. Fewer questions, answered consistently, make a better record.
Inconsistent entry. Weight recorded sometimes in kilograms and sometimes in stones and pounds, or dates entered as text, destroys the series without anyone noticing until it is analysed.
Decisions without reasoning. A decision recorded as approved answers what happened and not why, which is the half an auditor actually asks about and the half a covering prescriber needs.
History split across systems. Consultations in one tool, supplies in another, notes in an inbox. Each may be adequate alone and together they mean no timeline exists, which is the architecture the buyer's guide describes as failing the question an inspector actually asks.
Key takeaways
- Current-state records answer what dose a patient is on, whilst monitored services need the trajectory, which is what a prescriber and a reviewer are both actually reading.
- The timeline holds consultations, verification, decisions with reasoning and author, field values, supplies, recalls and notes in one sequence on the patient.
- Derive custom fields from the clinical protocol, give each one meaning, capture unit and method where they vary, and keep the set small enough to be completed every time.
- A value in a field is a series and a value in a note is prose, so ask whether you would ever want it as a column or a chart.
- Field type determines what a value can be used for afterwards, so numbers for measurements, selects rather than free text for finite answers, and file uploads for verification artefacts.
- Consent captured as an e-signature field holds the signature, the timestamp and the version of the wording shown, which is the element almost always missing, and it is not editable afterwards.
- Capturing fields at booking rather than at the appointment converts administration into clinical time, surfaces flags before the day, avoids consuming slots on ineligible patients and produces better answers.
- Export one row per entry rather than per patient to preserve the series, which is what cohort reporting, audit preparation and the regular service review depend upon.
- Field changes are attributed and traced with the previous value retained, since a corrected value and an original value are different clinical objects.
- A well-built timeline lets a reader establish response, plateau, dose changes, review intervals and decision authorship from one screen.
- Missing reviews should be visible on the timeline rather than merely absent, which is why recalls belong on the same record.
- Avoid too many fields, inconsistent entry, decisions without reasoning, and history split across systems, since each is invisible while a service is small.
FAQs
The record that answers the question.
Bring a service you run and we will build its data capture set live. See it working, then bring us your own case and we will configure the fields, show a patient record at month nine and run an export you could hand to an auditor.
See Dataforge PMR