How to Evaluate an EHR: Bring Your Workflow and Count the Clicks

When you sit down for an EHR demonstration, can you explain what each person in your practice needs to accomplish—and ask the presenter to show you how they will do it?

After more than ten years of implementing and customizing OpenEMR, I keep running into the same problem: people have an idea of how their practice will operate, but they have not worked out a detailed workflow.

"We're going to see patients" is a goal. It does not tell you how the patient will move through the clinic, what information each person will collect, or how that visit will become a bill that gets paid.

That missing detail makes it harder to evaluate software. You can watch an impressive presentation and still leave without knowing whether the EHR fits your practice.

Start with one patient visit

You do not need a complicated planning document. Start by describing one typical visit, from scheduling through payment.

Who schedules the appointment? What does the front desk need before the patient arrives? What happens at check-in? If a medical assistant or nurse participates, what do they collect and document? What does the provider need to see? What happens when the visit is complete?

Then follow the work beyond the exam room. Who reviews the charges? Who submits the claim or collects payment? Who handles a rejection or an unpaid balance?

Your clinic may have several people doing these jobs, or one person may handle multiple roles. Either way, the work needs an owner and a clear next step.

For each step, write down:

• Who performs the task.
• What information they need.
• What they must enter or complete.
• Who receives the work next.
• How that person knows it is ready.

That last question matters. Information can be in the chart without the next person knowing it is there.

Ask questions by role

Bring that patient journey to the demonstration. Ask the presenter to follow it.

Instead of asking, "Does your system support nursing documentation?" ask:

"Our nurse records observations before the provider enters the room. Show us where those observations go and how the provider finds them."

Instead of asking, "Do you have intake forms?" ask:

"Our front desk collects this information before the appointment. Show us how the patient completes it, who reviews it, and where it appears in the chart."

Those questions connect features to actual work.

A demonstration might walk through check-in, rooming, nursing observations, the provider's assessment, checkout, and billing. Adjust that sequence to your practice. A therapy office, a primary care clinic, and a doula service will not have identical needs.

Be specific about your patients, services, and payment arrangements. What information supports the care you provide? What additional information does your billing process require?

A self-pay visit may avoid some insurer-specific steps, but that does not remove the need for appropriate clinical documentation. Keep the care record and payment requirements clear when planning your workflow.

You may need to see it before you can describe it

Some people cannot tell you exactly what they need until they see a screen.

I have worked with clients who say, "If you show me something, I can tell you whether it is right."

That can be a useful starting point. A screen gives people something concrete to react to. They recognize missing information, unnecessary fields, or a step that does not match how they work.

The important part is what happens next.

Use that reaction to refine your plan. Have the people who will actually do the work walk through the example. Record what needs to change and why.

You do not need a perfect workflow before your first demonstration. You do need to turn what you learn into specific requirements before you commit.

Count the clicks—and watch the work

During the demonstration, pay attention to how much effort a routine task takes.

Once the user is logged in, how do they open the patient's chart? How do they reach the right note? How do they find information entered by another staff member? How do they complete the task and move on?

Make a mark each time the presenter clicks. Also notice how often they change screens, search for information, or enter something twice.

One physician I spoke with counted the clicks needed to accomplish tasks in his previous system. That is a practical way to make frustration measurable.

There is no single ideal click count for every task. Opening a chart and completing an entire encounter are different activities. Some steps also serve a useful purpose, such as reviewing information before submitting it.

Compare the same task across systems, from the same starting point to the same finished result. Consider clicks alongside time, clarity, and opportunities for mistakes.

If a task you repeat throughout the day takes fifteen or twenty clicks, ask the presenter to explain the steps and show whether there is a shorter route.

Then, if possible, try it yourself in a test environment with fictional patient information. Watching an experienced presenter is different from having to find your own way.

Ask what can actually be changed

The software you see reflects decisions made over years of development and customer requests. That includes our software.

A workflow that works well for one practice may be awkward for another.

Ask what happens when the fit is close but not quite right:

• Can we change the form, or also the steps around it?
• Can each role see the information it needs?
• Can we change how work moves between staff members?
• Which changes can we configure ourselves?
• Which changes require development, and what do they cost?
• What happens to those changes during an upgrade?

A custom form and a custom workflow are different things. Adding a field does not necessarily change how someone reaches that field or how the information gets to the next person.

Ask the vendor to identify what is available now, what needs configuration, what requires development, and what cannot be changed. Get important commitments in writing.

If you want to see how we approach this at Affordable Custom EHR, the features page walks through what we configure, what we build, and what you own when the work is done.

Follow the visit all the way to payment

Billing deserves its own walkthrough. Your biller will use these screens repeatedly, and unnecessary work can accumulate quickly.

Ask the presenter to take your sample visit through charge review, claim submission or self-pay collection, and payment posting. Then ask them to demonstrate a problem.

What happens if information is missing? Where does a rejected claim appear? Who corrects it? How does the biller know the correction went through?

Use the same method: count the clicks, watch the handoffs, and identify repeated entry.

Ask which steps are automated, what triggers each automation, and what still requires review. If routine work remains heavily manual, find out why and what that means for your staffing.

Speed matters. So does being able to see where the work stands.

Test automation when something goes wrong

Kat, who works with me, and I have helped clients untangle messy billing. Software is only part of that story. Processes, information, and human decisions all contribute.

Automation can carry a mistake forward quickly when the process does not catch it.

My experience with AI coding tools reinforces that lesson. I sometimes recognize an error that the tool continues to treat as correct. I have to make the correction myself and point out what changed before its next response reflects the issue.

For an EHR demonstration, turn that lesson into practical questions:

What errors does the system detect? What does it allow through? Who reviews exceptions? Can you stop a process, correct the information, and verify the result?

Ask the presenter to introduce a deliberate mistake into a fictional test case and show you what happens.

Before you trust it to run fast, walk it slowly once and see where it drifts.

Leave with evidence of fit

A useful demonstration should help you explain how your practice will operate in that system.

You should know what each role does, where information goes, how staff hand work to one another, how the visit reaches billing, and what happens when something goes wrong.

You will still learn things during implementation. A demonstration cannot reveal every situation your clinic will encounter.

But bringing your workflow gives you a better basis for the decision. It helps you discover gaps while you can still compare options and clarify changes.

Start with one patient. Follow the work. Count the clicks. Then ask whether your staff can get the job done.

One more consideration worth raising before you commit: if you are evaluating whether to build your own EHR rather than adopt an existing platform, read Build Your Own EHR in the Age of AI first. The same gap between a convincing demo and a production-ready system applies — and the compliance and integration responsibilities are yours to own.

If you want to see how a customizable EHR handles this in practice, request a software demo or review our pricing to understand what a tailored implementation looks like from day one.