What a small clinical team gets wrong about EHR workflows the first time

A small practice does not run on its process. It runs on the compensations built around the process: the sticky note on the monitor, the pile on the corner of the front desk that means "not finished", and the coordinator who knows that one particular patient always needs the later slot. None of that is written down anywhere and all of it is load-bearing. It works, and it works well, right up until the practice buys clinical software and finds it has digitised the form and deleted the compensations.

That is the shape of most difficult first rollouts, and it is why the difficulty is so rarely about features. The software generally does what it said it would. What it does not do is the eleven small things nobody had noticed were being done by hand.

1. Modelling the software on the paper process

The instinct is to make the new system resemble the old one, on the reasonable grounds that staff already know the old one. It backfires in a specific way: the paper process was shaped around paper's limitations, and a good half of its steps exist to compensate for the fact that a sheet of paper can only be in one place at a time. Recreating those steps in software preserves the cost while removing the cause.

The more useful exercise before configuration is to write down what each step was for rather than what it was. "The front desk copies the details onto the top of the form" is a step; "the clinician must not have to ask the patient for their details again" is the purpose. On a shared record the purpose is met by a different mechanism — demographics captured at check-in are already attached to the chart the clinician opens — and the step disappears instead of being rebuilt in a new medium.

2. Treating the chart template as a documentation problem

Templates get delegated, usually to whoever has the most patience for forms, and they get built to satisfy the billing and compliance requirements because those are the requirements that exist in writing. What comes out is a template a clinician cannot finish inside a visit. The consequence is not that documentation gets worse. It is that documentation moves: the clinician types the minimum into the structured fields, puts the real note in free text, or leaves the whole thing to the evening.

Once the substance lives in free text, the record has stopped being queryable, which removes most of the reason to have bought a clinical system in the first place. You can no longer ask which patients are on a given medication, or which encounters of a type produced a particular finding, because the answer is in prose and prose does not answer questions in bulk.

The test worth running before you commit

Chart your most common encounter type, live, at the pace a real visit runs, with the clinician who will actually be using it. Not a routine physical chosen because it demonstrates well — the one that fills your Tuesday. If the template cannot keep up with the visit it will be worked around, and no amount of training changes that. This is the single evaluation step we would keep if a practice only had time for one.

3. Nobody owns the open loops

A lab order that has been sent and not yet come back is an open loop. So is a referral, a prior authorisation, and a result that returned abnormal and needs somebody to act on it. On paper these lived in the pile, and the pile had an owner even if nobody had ever said so out loud — usually whoever tidied it.

In a new system they live in the record, which feels safer and is in one respect worse: a record is passive. Unless a specific person opens a specific queue on a specific rhythm, a pending result is now visible to everybody and watched by nobody. So the configuration question is not "does the system track lab results", because most of them do. It is whose screen shows the ones that have not come back, and when that person looks at it.

4. Permissions set for go-live convenience

During the first fortnight everyone needs access to everything, because nobody yet knows who needs what and there is no appetite for a permissions problem in the middle of a clinic. So access is opened up with an honest intention to tighten it later, and later never arrives, because nothing ever breaks in a way that reminds anybody.

The reason this matters is not abstract policy compliance. It is that role-based access is what makes an audit log mean anything. A log showing that fourteen people who all had full access viewed a record answers no question anyone would ask of it. Set the roles before go-live, accept that the first week will generate a handful of access requests, and treat those requests as the useful information they are — they are telling you what your roles actually are, which is something no configuration workshop discovers in advance.

5. Migration treated as an IT task

Getting the data across looks technical and is therefore assumed to be somebody else's problem. It is a clinical validation problem with a technical component. What can move is determined less by the new system's import than by what your incumbent will actually export — demographics, problem lists, medications, and appointment history come across far more cleanly than anything held as a scan or as free text, and that division is worth establishing before you agree a timeline around it.

The part to insist on is sampling. Take a set of charts chosen to include your awkward cases rather than your tidy ones, and check them field by field against the source after import. Clinical data that arrives subtly wrong is considerably worse than clinical data that arrives late, and the distance between those two outcomes is a validation step somebody has to be given the hours for.

What the small team is actually good at

It is worth ending on the advantage, because the list above reads as a warning and is not meant as one. The thing a small practice has that a large one does not is that everybody knows everything: the coordinator knows which results are outstanding, the clinician knows which patients are worrying, and none of it needs a system in order to work.

The point of the software is not to replace that. It is to make it survive one person being on leave. Every configuration decision gets easier when it is judged against that question rather than against a feature list — does this still work on the week the person who holds it in their head is not here?