Almost every practice is running on configuration decisions made during implementation, by whoever was available, under time pressure, and never examined since.
Defaults become workflow
An electronic record arrives with choices already made. Templates, order sets, how results route, what appears on which screen, which fields are required. During implementation those get configured quickly, because there is a go-live date and a hundred other decisions competing for the same week.
What happens next is that people build their working habits on top of those choices. Within a few months the configuration is no longer a setting, it is how the practice does things, and the two become very hard to tell apart.
Why nobody goes back
The configuration does not fail. It produces friction, and friction gets absorbed by people rather than reported as a defect. A template that asks for something nobody needs becomes a field everyone tabs past. A result that routes to the wrong place becomes a task someone has quietly taken on.
Changing any of it means touching something that currently works, in a system where the consequences of a change are not always obvious. Given a choice between an annoyance everybody has learned to live with and a change nobody can fully predict, practices reliably choose the annoyance.
The cheapest improvement on the table
The reason this is worth revisiting is that the software already does the thing. There is no purchase, no migration, no vendor selection and no implementation. The capability is present and configured to do something else.
That makes it unusual among operational improvements, most of which require either money or people. The cost here is mainly attention, plus somebody with enough system knowledge to make changes deliberately.
Where to look first
The places that tend to repay attention are the ones people complain about casually rather than formally. Fields that are required and always filled with the same value. Templates that were built for a visit type the practice no longer runs the same way. Results routing to an inbox somebody is manually forwarding. Reports that get produced on a schedule and opened by nobody.
Each of those is small. What makes them worth collecting is that they recur every single day, which is a different arithmetic from a problem that happens occasionally.
The part that is not technical
The harder half of this is not configuration, it is getting agreement about how a task should be done, since a shared template requires a shared answer. That conversation tends to surface differences people had been managing by quietly working around each other.
It is worth expecting that, and worth deciding in advance who settles it, because a configuration project that stalls on an unresolved workflow disagreement usually gets described afterwards as a technology problem.
What the vendor will and will not do
Implementation support and ongoing optimization are usually separate arrangements, and the second is often billable in a way the first was not. That is worth establishing before a conversation starts, because it changes whether the practical route is a support ticket or an internal person who learns the build tools properly.
The other thing worth knowing is that a vendor can say what the system is capable of and cannot say what this practice should do with it. That second question needs somebody who knows how the day actually runs, and it is not answerable from outside.
About the author. Marina Davar has managed a private medical practice of about fifty people since 2020. She writes here about how the operational side of an independent practice fits together. More about Marina Davar, or her work in healthcare education.