We Didn't Just Replace Their EHR. We Built a Better Way to Work.

How collaboration, custom development, and an experienced billing team helped a rural medical practice move from Tebra to OpenEMR—and reduce claim reconciliation time by approximately 70%.

When a medical practice decides to change its electronic health record system, the conversation usually starts with software.

What features does the new system have? How much will it cost? Can we migrate the patient records? Will the providers have to learn a completely different way of working?

Those are reasonable questions. But after more than a decade of implementing and customizing OpenEMR, I've learned that there's another question we should be asking.

Can we make the work easier than it was before?

I want to share a story about a project involving the Morton family, a group of medical providers serving rural communities, and three people who helped make this implementation successful: Louis Morton, Jana Smith, and Mike Hoang.

It's a story about moving away from Tebra, but more importantly, it's about what can happen when the people who actually perform the work participate in designing the software they use.

Five Providers, 80 Patients a Day

The Morton family operated a busy medical practice serving patients in rural communities.

Five providers were seeing approximately 80 patients per day. Their work included traveling to facilities in their service area to provide medical care, along with making hospital rounds.

This wasn't a practice where every patient walked through the same office door and followed the same appointment process.

Different facilities, different types of encounters, and different billing requirements were all part of their daily operations.

The practice was using Tebra and wanted to move to OpenEMR.

Mike Hoang was driving the project. He and Jana Smith, an experienced medical biller, approached me about developing the functionality the Morton practice needed to make that transition.

Louis Morton was the person who could explain the existing billing workflows and what the new system needed to accomplish.

Our initial objective was straightforward: build the features they were using in Tebra so they could move their billing operations to OpenEMR.

But that's not where the project ended.

A Screenshot Is Not a Workflow

One of the first things the team provided was screenshots of the interfaces they were using in Tebra.

They explained what each screen did, how they used it, and what they needed the new system to do.

Screenshots are useful. They show you what someone is accustomed to seeing. But they don't necessarily tell you everything about how a person performs their job.

To understand that, you have to talk to the people doing the work.

Louis knew his billing process. He understood the information he needed, the steps he was taking, and the things that slowed him down.

Rather than simply duplicating what was on the screen, we worked through the features and functions necessary to accomplish what Louis described.

And as we worked, the requirements went beyond what Tebra had been doing for them.

That's where custom software development becomes valuable.

You aren't limited to reproducing someone else's idea of how your practice should operate. You can build around the way your practice actually works.

This is the same principle behind workflow-first EHR evaluation — understanding how your practice operates before selecting or customizing the software, not after.

Why I Meet With Clients Every Week

My standard practice when developing software is to work closely with the client throughout the project.

We hold weekly meetings to review what has been completed, discuss changes, and approve the work as we move forward.

Louis, Mike, and Jana were involved throughout this development process.

As features were completed, they could see them working. They could tell us what was right, what needed to change, and what they hadn't thought about when we first discussed the requirements.

I prefer this approach because people don't always know everything they need until they see something working.

A client may describe a process one way during our first meeting. Two weeks later, after using a working version of the feature, they may realize there's a better way to accomplish the same task.

I don't see that as a problem.

That's part of development.

In more rigid projects, those discoveries can turn into change orders, additional costs, and disagreements about what was originally requested.

I prefer to incorporate those discoveries as we go, provided we're still working toward the agreed objective.

We review, revise, and approve the work week after week.

By the time we reach the end, the client has already participated in building the finished product.

My philosophy is simple:

When we're done, we're done.

The goal isn't to check off a list of features and declare victory. The goal is to deliver a working solution that the people using it have helped develop and approve.

Building Billing Features Around the Practice

Two important pieces of functionality we developed specifically for the Morton practice were rapid-charge entry and hospital billing.

These weren't generic features we simply turned on in OpenEMR. They were built around the practice's particular needs.

For example, hospital billing required handling services delivered across multiple days.

Louis needed to enter charges for seven days of hospital care, retain the appropriate provider and facility information, and avoid repeatedly searching for diagnoses and other information already available in the system.

He also wanted hospital charges categorized separately to make auditing easier.

These details may sound small to someone who doesn't work in medical billing.

But imagine entering claims throughout the day and repeatedly having to select the same provider, search for the same diagnosis, or reenter information the software already knows.

One unnecessary step might take only a few seconds.

Multiply that by hundreds of claims, and those seconds become hours.

That's why I pay attention to workflow.

An EHR can have every feature listed on a comparison chart and still make someone work harder than necessary. The real cost of evaluating EHR software by clicks rather than workflows is something billing staff feel every day, even when it's invisible to the people who selected the system.

Moving Away From Tebra Without Disrupting Billing

We didn't approach the migration by selecting a date, turning off Tebra, and hoping everything would work in OpenEMR.

We phased the transition.

As we completed each part of the project, the Morton practice began processing the corresponding types of claims through OpenEMR.

The team could verify that the new functionality worked before moving more billing activity into the system.

In October 2025, Louis reported that a claim submitted through the new workflow had been paid by Medicaid.

That was an important milestone.

It demonstrated that the process was doing more than generating a screen or preparing information. Claims were successfully moving through the billing process.

With that success, Louis wanted to begin entering hospital charges in OpenEMR so the practice could discontinue billing those services through Tebra.

There were still details to work through, including hospital admission information, service dates, and payment posting.

Those issues became part of our ongoing development and review process.

We addressed the requirements as the team encountered them.

As each phase was completed, more billing activity moved to OpenEMR.

Eventually, all the required features and functions were in place, and the practice came off Tebra.

The transition was smooth because we didn't require the practice to change everything at once.

We allowed the new system to prove itself while the practice continued operating.

The Email That Put a Number on Our Work

In January 2026, Louis sent an email to the project team.

He had been working with the improvements we made to the claims reconciliation process and wanted to share the results.

He reported reconciling more than 750 claims in under two hours.

Previously, that same work had taken him six to eight hours.

Think about that for a moment.

A task that consumed most of a working day was now being completed in less than two hours.

Depending on whether we compare against six or eight hours, that represents a reduction of more than two-thirds to three-quarters of the time previously required.

Approximately 70%.

And that improvement wasn't something I calculated from a theoretical model or included in a sales presentation.

It came from Louis, the person actually doing the work.

There were still refinements to make. In the same email exchange, Louis identified an issue with secondary insurance claims being transmitted to Waystar. We continued reviewing those kinds of problems as part of the process.

But the larger accomplishment was already clear.

We hadn't merely recreated the old workflow.

We had improved it.

A Pretty Interface Doesn't Tell the Whole Story

One of the things I've noticed over the years is how differently people evaluate software.

Someone who is new to medical billing may look at a system and think it's wonderful. The screens are attractive, the menus are organized, and everything appears easy to use.

An experienced biller may look at that same system and notice something entirely different.

They notice how many times they have to click to complete a task.

They notice information that must be entered repeatedly.

They notice the extra steps required to correct a claim, post a payment, or reconcile an account.

Neither person is necessarily being dishonest about their experience. They simply have different expectations and different levels of experience.

I can't speak for every practice using Tebra, and I wouldn't suggest that everyone has the same experience.

What I can speak about is what happened with the Morton practice.

They showed us what they were using, explained what they needed, and participated in developing a system that worked better for them.

The results were measurable.

The People Who Do the Work Need a Seat at the Table

This project succeeded because the right people were involved.

Mike drove the project. Jana contributed her medical billing knowledge. Louis brought firsthand experience with the practice's daily billing operations.

My responsibility was to take what they knew and translate it into working software.

No single person had to know everything.

And nobody had to pretend that the original requirements were perfect.

We learned as we went, made adjustments, tested the results, and continued until the system accomplished what the practice needed.

That's the value of collaboration in software development.

Too often, technology decisions are made without enough involvement from the people who will spend their days using the system.

Then, after implementation, everyone wonders why the staff is frustrated or why productivity has fallen.

I believe the people performing the work should help determine how the software performs that work.

That doesn't mean every suggestion automatically becomes a feature. It means we listen, understand the problem, and work together to find a practical solution.

What Other Practices Can Learn From This Migration

If you're considering changing your EHR, I would encourage you to think beyond the software demonstration.

Don't just ask whether the new system has the features you're using today.

Ask whether those features can be improved.

Look at how your staff performs its daily work. Pay attention to repetitive tasks, unnecessary steps, and processes that take longer than they should.

Bring your experienced billers, clinical staff, and other key employees into the conversation early.

And when possible, consider a phased migration that allows the new system to demonstrate that it works before you move your entire operation.

The Morton practice didn't simply replace one EHR with another.

They participated in building a system around their actual operations. They transitioned their billing in phases. And they achieved a substantial improvement in a critical administrative workflow.

For me, those aren't three separate accomplishments.

They're all part of doing the job correctly.

If your practice is considering a similar transition, learn more about how we approach OpenEMR implementation. If you're a smaller practice looking for a ready-to-use starting point, Tarevo is a fully configured, hosted OpenEMR system built around the workflows independent practices actually use.

The goal was never to replace Tebra. The goal was to build a better way for the Morton family to work. Replacing Tebra was simply the result.

---

At Affordable Custom EHR, we help medical practices implement, customize, and improve OpenEMR-based systems, including Tarevo. Our approach begins with understanding how your practice operates and what your software needs to accomplish—not simply installing a system and expecting your staff to adapt to it.

If you'd like to discuss your practice's workflow challenges, contact us or view the software demo.