How to design data capture that clinicians complete properly, so the information is right the first time and useful long after it is entered.
Ask anyone who works with health data where the problems come from and you will often hear the same answer: the people entering it. Fields left blank, free text typed where a code belongs, "N/A" in every box, the same allergy recorded three different ways.
In our experience, this is rarely about carelessness. Clinicians are working under time pressure, often in the middle of a conversation with a patient, using forms that were designed around a database rather than around them. When a form asks for too much, at the wrong moment, with no room for the real answer, people find the quickest way through. The data reflects the design.
This guide is for hospital and clinic digital leads, vendors of electronic health records and clinic management systems, health app teams, laboratories designing request forms, and pharma and research teams collecting data from sites. It sets out ten principles for data capture that people complete properly. In the language of our piece The Toilet in the Bathroom, trustworthy data is a basic expectation. This is where it starts.
The reason data capture matters so much is that a single entry rarely stays where it was typed. A smoking status recorded at a consultation may later inform the patient's care, support an insurance claim, count towards a quality report, feed a research dataset and be read by an AI tool summarising the patient's history. Each of those uses depends on the entry being complete, consistent and correctly coded.
A field entered once may be relied on five times over. Its quality is set at the moment of entry.
Group 1
Forms tend to grow. Every stakeholder adds a field, few are ever removed, and before long a routine visit involves dozens of boxes. The more a form asks for, the less care each field receives.
Do: Give every field a named purpose and owner. If nobody can say who uses a field and for what, remove it or make it optional.
Avoid: Adding fields "in case we need it later", or keeping fields nobody has looked at in years.
Retyping information that exists elsewhere wastes time and introduces errors. Demographics, previous diagnoses, current medications, laboratory results and device readings can often be brought in rather than keyed in.
Do: Prefill from existing records and connected sources, show where each prefilled value came from, and ask the clinician to confirm or correct it.
Avoid: Asking staff to copy numbers from a laboratory report or a device screen into a form by hand.
Group 2
Databases are organised by tables. Clinical work is organised by moments: triage, history taking, examination, results review, discharge. A form that follows the database forces clinicians to jump around; a form that follows the moment lets them record as they go.
Do: Shadow real sessions, map the order in which information is actually gathered, and build separate, short forms for each moment.
Avoid: One long form covering every possible field in database order, completed at the end of the day from memory.
People choose what is quickest, so design the quickest path to be the correct one. Sensible ordering, frequently used options near the top, and personal favourites all help. Defaults need care, though: a pre-selected answer that is accepted without thought produces data that looks complete and is quietly wrong.
Do: Order options by how often they are used in that setting, allow favourites, and use defaults only where they are genuinely safe.
Avoid: Long alphabetical lists, or clinical answers such as "no allergies" pre-selected for every patient.
Structured fields make data searchable and reusable. Free text captures the clinical story, nuance and reasoning. Forcing everything into boxes loses meaning; leaving everything as narrative makes the data hard to use.
Do: Structure the items that are used later, such as diagnoses, medications, allergies and key measurements, and keep space for narrative alongside them.
Avoid: Either extreme: a form with no room for the clinical story, or a single free-text box expected to hold everything.
The same field redesigned: prefilled with its source, coded when something is added, and explicit when there is nothing to add.
Group 3
The easiest time to make data consistent is before it exists. When a clinician chooses from a list mapped to medical coding standards, and units are built into the field, there is nothing to clean up later.
Do: Use searchable pick lists mapped to medical coding standards, with everyday synonyms so clinicians find terms quickly, and fixed units on every measurement field.
Avoid: Free-text fields for items that will be counted or analysed, or number fields that accept a value without a unit.
Checks catch real mistakes, such as a weight entered in the wrong unit or a date in the future. But when every field is mandatory and every check blocks progress, people learn to get around them: typing "99999", "N/A" or a full stop simply to move on. The data then looks complete and means nothing.
Do: Use soft warnings for unusual values with a clear explanation, reserve hard stops for true safety issues, and make mandatory only what is genuinely essential at that moment.
Avoid: Blanket mandatory fields and error messages that block the clinician without explaining what is wrong.
An empty box can mean many things: the answer is no, the question was not asked, the patient was unsure, or they chose not to answer. Downstream, these differences matter a great deal. A blank allergy field treated as "no allergies" is a safety risk; a blank result treated as "normal" distorts research and reporting.
Do: Give explicit options for "no", "not done", "unknown" and "declined", and keep them distinct in the stored data.
Avoid: Using a blank field to mean "no", or collapsing every reason for missing information into a single empty value.
Four different situations that a blank field hides. Each deserves its own value.
Group 4
Data entry feels like a chore when it disappears into a system and never comes back. When clinicians can see their entries at work, in a clearer patient summary, a useful dashboard or a report that helped secure funding, the effort feels worthwhile and quality tends to follow.
Do: Feed captured data back to the people who entered it in forms that help their own work, and share how it has been used.
Avoid: Collecting data solely for people outside the clinic, with nothing returned to the team doing the work.
A form is never finished. The data it produces shows exactly where it is struggling: fields that are always skipped, an "other" option chosen far too often, free text typed into structured fields, or values that cluster suspiciously around a default.
Do: Review these signals regularly, talk to the people using the form about why, and treat the form as a product that improves over time.
Avoid: Blaming users for poor data without looking at what the form is asking them to do.
These principles improve what is captured from now on. Most organisations also hold years of records captured before them: free-text allergies, results typed in by hand, blank fields with no explanation, local codes and scanned documents. That history still matters for care, research and AI, and discarding it is rarely an option.
Historical data can be made usable, but it takes deliberate work: extracting information from documents, resolving the many ways the same thing was recorded, distinguishing genuine negatives from gaps where possible, and mapping everything to consistent standards with clinical review. Improving capture going forward and making historical data usable are two halves of the same effort.
The ten principles on one page.
Better capture and usable historical data go together, and we support both.
