What an electronic health record really is, and which parts your clinic needs

Plenty of practices believe they already have electronic records because the paper charts were scanned and the files sit in a folder on a computer. That is a digital archive, not an electronic health record. The distinction comes down to one question: can the system search, filter and calculate on what it holds?

If answering "which of my patients have diabetes and have not had an HbA1c in six months" means opening files one by one, the data is not structured — whatever format it is stored in.

Three things that get confused with each other

The third column is not a luxury tier. It is the difference between owning your patients’ records and merely having access to them.

What a complete record actually contains

• Demographics with a unique identifier — not a name and surname, which two patients will eventually share.
• An allergy and intolerance list that is checked automatically at the moment of prescribing, not one that has to be remembered.
• Visit history with coded diagnoses (ICD), not free text. Free text is unreportable, and a report you cannot run is a question you stop asking.
• Active and discontinued medication, each with its dates and the reason it stopped.
• Vital signs as a time series, so a trend can be drawn rather than inferred from a stack of readings.
• Lab results as numbers with units and reference ranges — not as images of a lab report.
• Imaging, ideally with DICOM support rather than exported screenshots.
• Structured clinical notes, such as SOAP, so the parts of a note stay distinguishable.
• Consent and document attachments, dated and attributable.

Why structure turns into money

Structured data does three things a scanned archive can never do, and each has a number attached to it.

1. It warns. Interaction and allergy checks only fire when the medication list and the allergy list are both machine-readable. One prevented prescribing error pays for a year of most systems.
2. It reports. Patients overdue for follow-up, revenue by service, no-show rate by day of the week, which doctor’s clinic overruns. None of these are answerable from scans.
3. It moves. When you change system — and eventually you will — structured data transfers and unstructured data is retyped or abandoned.

The third point is the one that belongs in the contract, and it is the first criterion in our guide to choosing clinic software. If a system cannot hand your data back in a format something else understands, you do not own your records; you rent them.

FHIR, and why to ask about it by name

FHIR is the HL7 standard for exchanging health data. Its importance to a single clinic is practical rather than theoretical: when a system can produce a FHIR export, your records have a shape other systems already understand. Without it, "you can export your data" usually means a file only that vendor can read.

Ask it in exactly these words — can I export one patient’s full record as FHIR? — and ask to watch it happen on a real record during the trial. A yes that cannot be demonstrated is a roadmap item.

From paper to structured, without stopping the clinic

The migration that fails is the one that tries to digitise the past before starting on the present. Reverse it.

1. Start today, not with the archive. Every new patient and every new visit goes straight into the system, from the first day.
2. Bring a patient’s history across the first time they come back — not everyone at once.
3. For each returning patient, enter the minimum that makes the record safe: allergies, active medication, chronic diagnoses.
4. Keep the scan of the paper chart as an attachment, but do not treat it as the record. It is evidence, not data.
5. Run a report after three months. If it comes back empty, the data is being typed into free-text boxes and the structure is not being captured — a training problem, not a software one.

That is the real design constraint, and it is worth judging software by it: structured capture has to be the fast path, not the diligent one. Dictating a visit and having the note come back already divided into sections, with the diagnosis coded and the medication list updated, is the only version of this that holds up on a busy day.

Frequently asked

What is the difference between an EHR and an EMR?

In common use, an EMR is the record a patient has at one organisation, and an EHR is a record designed to be exchanged between organisations. The practical difference for a clinic is that an EHR has to produce standard output, so the record is still readable at the next clinic the patient attends. If a vendor uses the terms interchangeably, judge the export, not the acronym.

Is scanning our paper charts enough?

No. Scanning produces a digital archive, not an electronic record: you cannot search an image, report on it, or check a prescription against it. Scans are worth keeping as attachments, but they do not replace entering allergies, medication and diagnoses as structured data.

Where should patient data be stored?

Ask every vendor and get the answer in writing. There are three common answers — a server in the clinic, a data centre in a named jurisdiction, or a cloud service — and all three can be acceptable depending on the rules you work under. What is not acceptable is a vendor who cannot tell you which one applies to you.

If we change software, what happens to the records?

That depends entirely on what the current system exports. Structured output such as FHIR or a complete CSV set can be imported elsewhere; a folder of PDFs effectively cannot, and becomes an archive you keep for legal reasons and never read. Settle this clause before signing, not when you are leaving.

How long do we have to keep patient records?

Retention periods are set by the rules of the country and the profession you practise in, and they differ for adults, children and imaging. Your record system should make retention a setting rather than a manual clean-up, and should be able to produce a complete, dated copy of one patient’s file when it is formally requested.