Your EHR Is Working. So Why Does It Still Need Maintenance?

I was having a conversation with a client recently about the future of her electronic health record system.

We had successfully implemented OpenEMR, and now the practice had a list of modifications and improvements they wanted us to make. Naturally, she wanted to know how quickly we could complete the work.

But then she asked another question.

Once we finished making those changes, would that be the end of their need for technical support?

It was a reasonable question. After all, if the software is installed, configured, and doing everything the practice needs, what else is there to do?

That question led us into a much larger conversation about software ownership, maintenance, and what it really means to operate an open-source EHR.

And it reminded me of another client who had recently contacted me after twelve years.

But I'll come back to him in a moment.

Why Should I Pay to Fix Something That's Broken?

During our conversation, my client asked why open-source software wasn't free of defects. More importantly, she wanted to understand why her organization should have to pay someone to fix those defects.

I understood her reasoning.

When someone purchases software, they naturally expect it to work. If something doesn't function correctly, they expect the company responsible for the software to fix it.

So I gave her an example.

When you purchase Microsoft software and discover a defect, you generally expect Microsoft to address that defect through its product maintenance and update process. Microsoft controls the development and maintenance of its proprietary products.

But open-source software operates under a different model.

With OpenEMR, the source code is publicly available. Developers and organizations can use it, study it, modify it, and distribute it according to its open-source license.

The original contributors retain their applicable copyrights, but no single commercial vendor is automatically obligated to maintain every installation or fix every defect for every user.

There is an entire community contributing to OpenEMR. Developers report problems, submit improvements, review code, and release updates.

But community participation is not the same as purchasing a guaranteed maintenance contract.

If a healthcare organization discovers a defect, it has several options. It can report the issue to the community, wait for an available correction, repair the problem using its own technical resources, or hire a developer to address it.

The software may have been free to acquire, but the professional labor required to investigate, repair, test, and deploy a correction is not necessarily free.

That's an important distinction.

And it led me to another example.

Think About Owning a Vehicle

I asked my client to think about the difference between owning a vehicle and having a vehicle covered by a maintenance agreement.

When a vehicle is under warranty, certain repairs may be the manufacturer's responsibility. When you have a lease or maintenance agreement, some responsibilities may be covered under that contract.

But when you own a vehicle that's no longer under warranty, the responsibility for maintaining it generally falls on you.

If the transmission fails, you don't expect the mechanic to repair it for free simply because you didn't manufacture the transmission.

You pay the mechanic for the knowledge, equipment, time, and labor required to make the vehicle operational again.

Software maintenance works much the same way.

When a healthcare practice chooses an open-source EHR, it gains considerable control over its technology. It can choose where to host the application, who maintains it, what modifications are made, and how long it continues using a particular version.

But those freedoms also mean the organization must decide how maintenance will be handled.

That doesn't necessarily mean paying a company every month.

It means understanding that someone must take responsibility for the system.

There is also a distinction between repairing a defect in the original open-source application and correcting a problem introduced by an implementation company. If we introduce a defect through our own development work, our responsibility to correct that work is governed by our agreement with the client. Open source is not an excuse for poor workmanship.

The conversation eventually moved on, but it reinforced something I've encountered repeatedly over the years.

People often think of software as something you install once and then forget.

Sometimes, remarkably, that's almost exactly what happens.

The Client Who Didn't Need Me for Twelve Years

Not long ago, I received a call from a client whose OpenEMR system I had installed twelve years earlier.

Twelve years.

When we originally implemented his EHR, we installed it on a Windows computer located in his office. The application ran using a XAMPP software stack, which included the components needed to operate OpenEMR.

It wasn't hosted in the cloud. There were no monthly hosting charges from us. The client handled his own backups.

Microsoft maintained the Windows operating system through its patching process, but the XAMPP components remained unchanged.

Nobody upgraded the PHP version. Nobody upgraded the database or web server components. Nobody modified the OpenEMR source code.

For twelve years, the application continued working.

And for twelve years, he didn't need to spend additional money with us on his EHR.

Think about that for a moment.

In an industry where recurring software subscriptions can represent a substantial operating expense, this physician operated his EHR for more than a decade without paying us another dollar for software development or maintenance.

That's one of the remarkable possibilities of open-source software.

He wasn't forced to purchase a new version every year. He wasn't required to subscribe to a new package simply because the software developer released one.

He had a system that met his needs, and he continued using it.

But eventually, he called.

The Software Was Still Working. The World Had Changed.

He wanted to upgrade his OpenEMR installation from version 5.0.0 to a much newer release.

He didn't specifically tell me that something had broken or that a particular feature had stopped working.

My impression from our conversation was that he simply recognized how far behind his installation had become.

The healthcare industry had changed. OpenEMR had continued evolving. New functionality had been introduced, technologies had advanced, and his installation was now many generations behind.

It was time to catch up.

And this is where his story becomes particularly important.

Software can continue working long after it stops being current.

The fact that his EHR had operated successfully for twelve years did not mean every component remained secure, supported, or compatible with modern technology.

The Windows operating system had received updates, but the underlying XAMPP stack had not.

Older versions of PHP, database software, and web servers can contain vulnerabilities that are corrected in later releases. They can also become incompatible with newer software.

I've personally encountered the difficulties of trying to upgrade individual XAMPP components. Changing one component can affect another. A newer PHP version may no longer support functions used by an older application. A database upgrade may require changes to existing code.

I've broken XAMPP installations attempting those upgrades myself.

That's why upgrading an EHR is not always as simple as downloading the newest version and clicking an install button.

A system that has remained unchanged for twelve years may require considerable planning, testing, and migration work to bring it forward safely. The same principle applies to any EHR migration from a legacy system — owning the data and owning a plan for moving it are two different things.

And in healthcare, where patient information and daily clinical operations are involved, that work must be approached carefully.

I don't tell this story to criticize the physician's decision to continue using his existing system.

Quite the opposite.

His experience demonstrates how much control an organization can have over its technology.

But it also demonstrates that postponing maintenance doesn't eliminate the need to eventually address it.

Installing an EHR Is a Project. Maintaining One Is an Ongoing Responsibility.

That brings me back to the conversation with my other client.

She wanted to know whether completing her requested modifications would eliminate the need for ongoing support.

The answer depends on what responsibilities the organization is prepared to handle itself.

There are several different kinds of work involved in operating an EHR, and they shouldn't be confused with one another.

Custom development involves changing the application to meet a particular organization's workflow requirements.

Release management involves evaluating new software versions, reviewing changes, testing compatibility, planning upgrades, and deploying updates without unnecessarily disrupting the practice.

Server maintenance and monitoring involve watching the environment in which the application operates. That includes reviewing security updates, checking system health, monitoring available resources, and verifying that backup and recovery procedures are working.

Completing a list of custom modifications doesn't make those other responsibilities disappear.

A clinic can certainly decide not to purchase an ongoing support agreement. It can assign maintenance to an internal IT department, contract with another provider, or manage the system itself.

That's part of the freedom open source provides.

But choosing not to purchase support is different from eliminating the need for maintenance.

And there's another consideration.

Healthcare technology doesn't operate in isolation.

An EHR may communicate with laboratories, pharmacies, clearinghouses, electronic prescribing networks, patient portals, and other external systems. Our interoperability and support services exist precisely because those connections require ongoing attention — not just at implementation, but as external systems change their requirements over time.

Those organizations also update their software, change technical requirements, and introduce new standards.

A practice may make absolutely no changes to its EHR and still find that an external integration eventually requires attention.

Regulatory requirements can change as well.

The application that satisfied a practice's needs five years ago may not support everything the organization needs today.

In other words, even when you leave your software alone, the environment around it continues to evolve.

The Real Cost of Open Source Isn't the Download

One of the reasons I have worked with OpenEMR for so many years is the flexibility it gives healthcare organizations.

A small practice can begin with a relatively modest investment. It can customize workflows, control its data, choose its hosting environment, and decide who provides technical services.

Those are meaningful advantages.

But I've also learned that organizations sometimes misunderstand what they're receiving when they choose open-source software.

They hear the word free and assume that means there will never be another expense.

The software license may be free. The ability to access and modify the source code may be free.

But servers, technical expertise, security management, integrations, backups, and development all require resources.

The same is true of proprietary software, although those expenses may be bundled into a subscription or managed-service agreement. If you want to understand how those costs compare in practice, the OpenEMR comparison walks through what independent practices are typically sold versus what they actually need.

The question isn't whether open-source software costs money.

The better question is who controls those costs, who performs the work, and who is responsible when something needs attention?

With open source, the healthcare organization has more freedom to make those decisions.

That freedom can produce substantial savings. My twelve-year client is an example.

It can also require an organization to make decisions it may never have considered when using a fully managed subscription service.

Neither approach eliminates the need for maintenance. They simply distribute the responsibility differently.

Ownership Means Having Choices

After more than a decade of implementing, customizing, and supporting OpenEMR, I've learned that every healthcare practice has different needs.

Some organizations want us involved in every aspect of their technology. They want someone monitoring their systems, managing releases, troubleshooting problems, and helping them adapt as their practice grows.

Others prefer to manage most of those responsibilities themselves and contact us only when they need specialized assistance.

Both approaches can work when the organization understands what it is taking responsibility for.

The physician who contacted me after twelve years made his choice. He operated his system independently for more than a decade and eventually decided it was time to modernize.

My other client is now considering what ongoing support should look like after her requested modifications are completed.

Two different practices. Two different situations. But the same underlying question.

Who is responsible for keeping the software useful, secure, and operational?

That's a question every healthcare organization should answer before choosing an EHR, not after something goes wrong. It connects directly to building a ten-year foundation for your practice — the decisions made at the start determine how much flexibility you have later.

Because the real advantage of open-source software isn't simply that you can download it without paying a license fee.

It's that you have the freedom to decide how your technology is operated, maintained, and improved.

And with that freedom comes the responsibility to make those decisions.

Your EHR may continue working for twelve years without a single code change.

But twelve years of operation and twelve years of maintenance are not the same thing.

---

At Affordable Custom EHR, we help healthcare organizations implement, customize, upgrade, and maintain OpenEMR-based systems. Our approach begins with understanding how your practice operates and determining which technical services you actually need.

Learn more about how we work or review our pricing to understand what ongoing support looks like from day one.