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. In a monitored service, the clinically interesting object is the shape of the change, not the current value.
A prescriber deciding whether to continue treatment is asking four things. Is this patient responding? Has the response plateaued? Did a side effect appear after a particular escalation? Do the last three reviews say the same thing? A current-state record can answer none of those questions, 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. It 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 |
What makes it useful is that these sit in one sequence, not 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. These differ by service. A weight management service captures weight and BMI, a TRT service testosterone and haematocrit, a travel clinic 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, not the general practice.
The kind of data you choose determines what can be done with the value afterwards. That is why it deserves more thought than it usually gets 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. A service that 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. The artefact is the evidence; a note recording that somebody looked at it is not. That 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 a checkbox that records a box was ticked and nothing about what the wording said at the time. That is adequate until the wording changes. Then 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. 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, the element almost always missing. And immutability: 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 — where a reviewer expects to find it.
Three consent types recur across private services. They are withdrawn independently, so they warrant separate fields, not one combined agreement. Consent to treatment is clinical and specific to the service. Agreement to service terms is contractual. And permissions cover data sharing with a GP, photography where a service uses it, and marketing — the one governed by the consent rules our PECR guide sets out, 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, release the revision as a new version with an effective date. Existing signatures continue to reference the version actually shown. The alternative — amending the wording in place — retrospectively changes what every previously consenting patient appears to have agreed to. That is a records failure, not a tidy-up.
Designing your data capture set
Services monitor different things. 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 that sometimes holds a number and sometimes 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. A service that cannot distinguish them cannot demonstrate independent verification — the requirement the verification duties article sets out.
Keep the set small. Every additional field is something a team must complete at every consultation. Fields nobody completes are worse than absent ones: 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 that 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. It can be compared against the previous one, charted across a treatment, filtered on to find 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: the measurement as a field, the explanation as a note. 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. The ordinary way it gets consumed is collecting information that could have been collected earlier. A patient arrives, and the first eight minutes go on their weight, their medical history, their current medicines, what they have tried before and who their GP is, while 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 instead of 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. 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: a refusal at the appointment is an appointment that produced nothing.
Verification can be requested and chased in advance. Where the category requires an artefact rather than a self-report, asking at booking gives the patient days to obtain it and the service time to follow up. Nobody discovers on the day that the review cannot proceed. This is the difference between a verification requirement that functions and one that 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. 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. The appointment opens with the agreement already on the record instead of spending its first minutes obtaining one.
Three honest limits belong alongside that. Pre-capture does not replace the clinical conversation; anything requiring the clinician's judgement about how an answer was given still belongs in the appointment. A pre-booking form that 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, not assumed — a patient who completed the 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.
At month nine, that record answers five questions from one screen. Did the patient respond? When did the response slow? Did a dose change precede or follow that? Did reviews happen at the intervals the protocol requires? 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. 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: how many patients are within a BMI band, how many recorded a given side effect, how many are overdue. Audit preparation: when the values are structured, producing the evidence for a sample of patients is a filter rather than a fortnight. And service review: the clinical governance obligation the April 2026 themed review asks to be regularly reviewed, far easier to discharge when the supporting data can be produced as a table.
Captured patient data is personal and often special category data. An export therefore needs 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 that can be changed without trace is not evidence. So every recorded value carries who entered it and when. 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 the reason a patient became eligible. Only the audit trail distinguishes them. A service that 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 — the reason shared logins defeat the entire mechanism, as the security article notes. And the audit entries export with the data, because 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, take a fresh signature against the current version rather than editing the previous one. Both stay on the timeline, so a reader can see what was agreed and when it was superseded.
The test: for a value that matters, can the system answer what it was originally, who changed it, when, and what it became? A service that can answer that has records. A service that 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. 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. It should be visible on the timeline, not merely absent from it — which is why 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, not why. The why 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; together they mean no timeline exists. That 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. Monitored services need the trajectory — 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; a value in a note is prose. Ask whether you would ever want it as a column or a chart.
- Field type determines what a value can be used for afterwards: numbers for measurements, selects rather than free text for finite answers, file uploads for verification artefacts.
- Consent captured as an e-signature field holds the signature, the timestamp and the version of the wording shown — the element almost always missing. 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. Cohort reporting, audit preparation and the regular service review all depend on it.
- Field changes are attributed and traced, with the previous value retained. 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. That is why recalls belong on the same record.
- Avoid too many fields, inconsistent entry, decisions without reasoning, and history split across systems. Each is invisible while a service is small.
Sources and further reading
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