The Consultation Is the Data

In 2012 my team built software for clinics that operated from more than one location. The requirements were clear and sensible: appointments, patient registration, visit records, prescriptions, billing and a way for branches to see each other's information. We built it, it worked, and it solved real operational problems.

Nearly a decade later I entered medical college, and later clinical internship. I began to see clinical records from the other side of the desk, not as a database design but as the place where a consultation is supposed to be remembered. That second view changed how I think about the first.

This essay is about the gap between the two views, and what it suggests for anyone designing healthcare technology.

What software captures easily

Clinic software is very good at structured facts. Name, age, contact number. Date and time of visit. Blood pressure, weight, temperature. Diagnosis code. Medicine, dose, duration. Amount billed and paid.

These fields matter. They make appointments run on time, keep billing accurate, allow a branch to see a patient's previous visit and give managers a view of the practice. Any clinic that has moved from paper registers to a reasonable system knows how much time that saves.

The trouble begins when the system's easy fields quietly become the definition of the consultation.

What the consultation actually contains

A consultation is a conversation, an examination and a series of judgements. Much of its most important content does not fit into fixed fields.

• The way a patient describes a symptom, in their own words, which may carry meaning that a standard term flattens.
• What the patient seemed worried about but did not say directly.
• The detail that did not match the rest of the picture and made the clinician look again.
• The reason one option was chosen over another, including the patient's preferences.
• What the clinician plans to watch for at the next visit.

In homoeopathic practice this is especially visible, because individualised case taking depends on precisely those qualitative details. But every good clinician, in every system of medicine, relies on information of this kind.

How good intentions produce poor records

Nobody sets out to build a system that loses clinical meaning. It happens through a series of reasonable decisions.

A form is designed to be quick, so free text boxes are made small. Reports are needed, so fields become mandatory and drop-down lists replace descriptions. A busy clinic wants shorter visits, so the screen is optimised for clicks rather than for thinking. Each decision makes sense locally. Together they turn the record into a billing and scheduling artefact with a clinical label.

The result is familiar to anyone who has read through a year of visit records and found little more than a diagnosis and a prescription repeated each time, with none of the reasoning that would help the next clinician, or the same clinician six months later.

Designing for the consultation

What would healthcare software look like if the consultation, rather than the invoice, were treated as the primary data? A few principles follow.

Make narrative first class

Free text should be easy to write, easy to read and easy to search. Structure can be added around it, for example by tagging key symptoms, without forcing the clinician to translate everything into codes during the conversation.

Capture reasoning, not only conclusions

A short field for "why this decision" and "what to watch for" costs seconds and can transform follow up. It also helps with handover between clinicians and branches.

Keep the screen out of the conversation

A consultation where the clinician faces a monitor is a worse consultation. Systems should allow quick notes during the visit and fuller documentation afterwards, and should never demand data entry before the clinician can move on with the patient.

Show history in a way that tells a story

Previous visits presented as a list of dates and codes are hard to use. A readable timeline of complaints, changes and responses helps a clinician see the course of a case at a glance.

Automate the administrative, not the clinical

Reminders, appointment confirmations, stock of medicines and billing are strong candidates for automation. Clinical conclusions are not. I discuss where AI fits in a separate checklist for responsible AI in healthcare.

Where AI could help, carefully

Language models make one thing newly possible: turning a clinician's narrative into structured information after the fact, without forcing structure during the consultation. A tool could suggest tags for symptoms mentioned in a note, draft a summary of the last five visits, or flag that a previously recorded allergy is relevant to today's prescription.

Each of these must be designed with the same caution. The clinician should see exactly what the tool extracted and from which sentence, correct it easily, and remain responsible for the record. A summary that silently omits the one unusual detail is worse than no summary, because it creates false confidence.

What I would tell my 2012 self

If I could return to that first clinic software project, I would change less of the technology than of the process. I would spend a week sitting in consultations before designing a single screen. I would ask clinicians what they wished they had known at a patient's previous visit, and design for that. I would measure success not only by faster billing but by whether records became more useful for care.

Those are, in the end, questions for engineers and clinicians to answer together. That is what convergence means in practice.

Questions

Frequently asked questions

Why are electronic health records often frustrating for clinicians?

Many records systems are designed primarily around administrative needs such as billing, reporting and scheduling. When structured fields are easy and narrative notes are awkward, clinicians spend more time on data entry and the record captures less of the clinical reasoning that matters for care.

Should clinical notes be structured or free text?

Both have value. Structured data supports search, reporting and safety checks. Free text preserves clinical nuance and reasoning. Good systems make narrative easy to record and add structure around it rather than forcing every observation into predefined fields during the consultation.