The Doctor Who Paid for an EHR He Never Used
A physician paid for an electronic health record system for eighteen months without entering a single patient. Then, just when it appeared he might finally begin using it, he asked us to shut it down. This is the story of an EHR implementation that left me with more questions than answers.
Eighteen months, an empty patient database, and a decision I never saw coming.
I've been implementing and supporting electronic health record systems for more than a decade. During that time, I've worked with physicians opening their first practices, established clinics replacing outdated systems, and healthcare organizations trying to solve problems their existing software couldn't handle.
I've seen projects go remarkably well. I've also seen projects struggle.
But every now and then, something happens that leaves me with more questions than answers.
This is one of those stories.
Everything Was Ready. Nobody Came.
A physician contacted us to set up an electronic health record system.
We did what we were hired to do. We provisioned the environment, installed and configured OpenEMR, and made the application available for his practice.
From our side of the equation, the system was ready.
Then we waited.
As part of operating our hosted systems, we can observe certain application activity. We can tell whether the system is being used, whether patients are being entered, and whether staff members are working in the application.
What we cannot see is what is happening inside the physician's business.
We don't know how many patients are calling for appointments, whether a practice has secured its office space, whether employees have been hired, or whether the physician has encountered some unexpected obstacle.
Unless the client tells us, we simply don't know.
During the first 90 days, I watched for signs that the physician was beginning to use the EHR.
There were none.
No patients had been entered.
No additional staff members had been added.
Not a single clinical note had been completed.
The application was available, but it wasn't being used.
At first, I didn't think much of it. Opening a medical practice involves far more than installing software. There are countless moving parts, and I know from experience that things don't always happen according to schedule. I've written before about why clinics lose money before they ever open — the gap between signing a lease and seeing a first patient is longer and more expensive than most physicians anticipate.
But three months passed, and the system remained empty.
I Tried to Find Out What Was Happening
I reached out to the physician.
I wanted to understand whether he needed assistance or whether something was preventing him from moving forward.
I didn't receive a response.
The subscription continued, and we continued providing the hosted service.
More time passed.
Still no patients. No staff. No completed clinical notes.
Eventually, the months began adding up.
I couldn't tell whether he was still planning to use the application, had postponed opening his practice, or had simply changed his mind.
And I wasn't going to invent an explanation.
He had purchased a service, and we continued making that service available.
There is an important distinction between providing someone with a functioning tool and knowing whether that person is using it to accomplish their goals.
We were responsible for the technology we provided.
But we had very little visibility into the business the technology was supposed to support.
Then Something Unexpected Happened
After a long period of inactivity, the physician contacted us with a request.
He wanted us to execute a Business Associate Agreement, commonly called a BAA.
He also wanted a compliance and security audit.
For anyone unfamiliar with healthcare technology, a BAA is an important agreement that establishes responsibilities for protecting patient information when a service provider handles protected health information on behalf of a healthcare organization.
Security and compliance reviews are also important parts of operating healthcare technology responsibly.
These weren't unusual requests in themselves.
What made them unusual was their timing.
Here was a physician whose EHR had shown no meaningful clinical activity for an extended period, suddenly requesting documentation and security-related work.
From my perspective, it looked like something might finally be happening.
Perhaps he was preparing to begin using the system.
Perhaps someone had asked him to demonstrate that his technology arrangements met certain requirements.
I didn't know.
He never explained his plans to me.
But after all those months, the request certainly caught my attention.
Then, the following month, another message arrived.
The Email I Didn't Expect
The physician had decided to move in a different direction with his EHR setup.
He wanted to end our support arrangement.
That was it.
After approximately eighteen months of paying for a hosted electronic health record system, he was ready to shut it down.
During that entire period, he had never entered a patient into the application.
He had never added another staff member.
He had never completed a clinical note.
And just one month after requesting compliance and security documentation, he was leaving.
I read his message and wondered what had happened.
Had he found another EHR that better suited his needs?
Had his business plans changed?
Was there something about the application he didn't like?
I couldn't answer any of those questions.
He didn't express dissatisfaction with our service. He simply told us he was moving in another direction.
And I respected that decision.
But the experience stayed with me.
The Part of an EHR Implementation We Can't See
When people think about implementing an electronic health record system, they tend to focus on the technology.
Which software should we use?
How much will it cost?
Does it support electronic prescribing?
Can it schedule appointments, generate claims, collect payments, and document patient encounters?
Those are all important questions.
But an EHR is only one component of operating a medical practice.
A physician may have the right software and still face challenges involving staffing, financing, credentialing, patient acquisition, office space, or the countless other responsibilities of running a healthcare business. The real cost of opening a small medical practice goes well beyond the technology budget — and those costs don't pause while the EHR sits waiting.
And sometimes the technology provider has no idea those challenges exist.
I can install an EHR.
I can configure it to support a practice's workflows.
I can maintain the server, manage software updates, and help troubleshoot technical problems.
But I cannot operate the physician's business for him.
More importantly, I cannot know what assistance he needs if he never tells me.
That is what made this experience so unusual.
For eighteen months, we had a window into the technology but almost no window into the business it was intended to serve.
We knew the application wasn't being used.
We didn't know why.
A Subscription Isn't the Same as Adoption
This experience also taught me something about the way we measure success in the software business.
From a purely financial perspective, we had a paying customer for approximately eighteen months.
The subscription was active. The service was available. The customer continued paying.
If I looked only at recurring revenue, I might have considered that account successful.
But I don't build healthcare software simply to collect subscription payments.
I want the applications we provide to become useful tools in the daily operation of a medical practice.
I want physicians to schedule patients, document encounters, manage their workflows, and get value from the technology they've purchased.
In this case, that never happened.
And it illustrates an important distinction.
A customer can purchase software without ever adopting it.
Those two events are not the same.
Signing up for an EHR doesn't mean a practice is ready to use it.
Completing an implementation doesn't mean the application has become part of daily operations.
And continuing to pay a subscription doesn't necessarily mean the customer is receiving the business value they originally hoped to achieve.
That doesn't automatically mean the software failed.
It doesn't automatically mean the customer failed, either.
It means that somewhere between purchasing the technology and putting it to work, something didn't happen.
In this particular case, I never learned what that something was.
What I Would Tell a Physician Preparing to Open a Practice
If you're preparing to open a medical practice, I would encourage you to think about your EHR as part of a larger business plan.
Don't just ask whether the software has the features you need.
Ask yourself when you expect to begin using those features.
Who will enter your patients?
Who will manage your schedule?
Who will document encounters?
Who will handle payments and billing?
Have you established the workflows that the software is supposed to support? The workflow-first approach to EHR implementation addresses exactly this — the clinical and operational decisions that need to be made before the technology is ever configured.
And if your opening date changes, what does that mean for the technology services you're already paying for?
You don't necessarily need to have every answer before selecting an EHR.
But you should have a reasonable plan for moving from installation to actual use.
And if that plan changes, communicate with your technology provider.
Sometimes a conversation can reveal options that weren't obvious before.
Perhaps an implementation schedule can be adjusted. Perhaps training should be postponed. Perhaps a different configuration would better support the practice's needs.
There may be solutions, but it's difficult to explore them when nobody knows what problem needs to be solved.
Eighteen Months Later, I Still Don't Know
I've thought about that physician from time to time.
I don't know whether he opened his practice.
I don't know whether he chose another EHR.
I don't know whether his plans changed for reasons that had nothing to do with technology.
And I don't know what prompted the compliance and security requests just before he decided to leave.
All I know is what happened on our side.
We installed the system.
We kept it available.
We watched for signs of adoption.
We reached out.
And eventually, we shut it down at his request.
There was no dramatic technical failure. No angry confrontation. No complicated dispute over software functionality.
Just a physician who purchased an EHR and never used it.
After years of working with healthcare organizations, I've learned that not every project gives you a clear explanation of what went right or wrong.
Sometimes the lesson comes from recognizing the limits of what you know.
And this experience left me with a thought that applies to far more than healthcare software:
You can provide someone with the tools to build something, but that doesn't mean you'll ever know what happened to the dream they were building.
Affordable Custom EHR shares real-world experiences from implementing, customizing, and supporting healthcare technology. These stories are intended to help physicians and healthcare organizations make more informed decisions about the systems they choose and the businesses they are building.
Learn more about how we work or contact us if you're planning an implementation and want to talk through the timeline.
Written by
Sherwin Gaddis
Sherwin Gaddis has spent more than a decade implementing, customizing, and supporting OpenEMR for independent practices, tribal health programs, and community health organizations. He founded Affordable Custom EHR to give small practices access to a fully configured, clinician-owned EHR without the enterprise price tag.
