The Automation That Never Happened

He wanted to spend less money running his practice. Instead, he found himself spending money trying to make the technology work.

A few years ago, I was introduced to a behavioral health physician who had a problem that I've encountered many times throughout my career.

He had a busy practice, but his profit margins were thin.

He was seeing patients and generating revenue, yet a significant portion of that revenue was being consumed by the administrative work required to operate the business.

Patient intake. Scheduling. Documentation. Payments. Billing. Group therapy sessions.

Every one of those activities required someone's time.

And every hour spent on administrative work represented another expense.

The physician believed technology could help him change that.

He wasn't trying to build the next great healthcare software company. He was trying to keep more of the money his practice earned.

His idea made sense.

His expectations about what it would take to accomplish it were another matter.

The Dream of an Automated Practice

By the time I met him, the physician had already started building his own solution.

He had assembled different applications to handle different parts of his workflow.

One of those applications was JotForm.

He had created a form that collected information exactly the way he wanted. It worked well for its intended purpose.

But collecting information was only the beginning.

He wanted the information from that form to populate the patient's medical record automatically.

He wanted patients to pay for their sessions upfront.

He wanted the system to determine which group therapy session a patient should attend based on where the intake originated.

Then he wanted the system to schedule that patient, send the appropriate telehealth meeting information, and manage the responses.

After a group session, he wanted the documentation handled automatically for the patients who attended, with the appropriate billing generated as part of the workflow.

And that was only part of his vision.

He wanted to bring the various tools he had assembled into one coordinated system.

Imagine what that could mean for a busy behavioral health practice.

Instead of having someone repeatedly transfer information between applications, check payments, schedule appointments, and prepare documentation, much of that work could happen automatically.

Fewer repetitive tasks.

Less administrative overhead.

More time available for patient care.

Potentially, better profit margins.

I understood exactly what he was trying to accomplish.

The problem was that he wasn't simply asking for a few forms to be connected.

He was describing a substantial software development project involving several interconnected healthcare workflows.

And he had already hired developers to build it.

When the Developers Couldn't Keep Up

The physician had been working with offshore developers before someone recommended me.

He was frustrated with how long the project was taking.

He wanted me to step in, manage the developers, and get things moving.

From his perspective, he already had people writing code. What he needed was someone who understood OpenEMR well enough to direct their efforts and bring the project across the finish line.

But there was an immediate problem.

He had dramatically underestimated the amount of work involved.

He expected to pay me approximately $500 to manage a small development team and help complete the project.

What he was asking for was far more than a little project supervision.

It involved understanding his business processes, evaluating what had already been built, coordinating developers, and making multiple applications work together inside a healthcare environment.

Before I could help him finish anything, I needed to understand what was already there.

That's when I discovered the real problem.

It Worked. That Wasn't the Problem.

When I began reviewing the code, I found something that concerned me far more than the project's slow progress.

The previous developers had exposed the database connection and hard-coded credentials into their modifications to make the application perform the functions they wanted.

The application worked.

That was the dangerous part.

To someone using the system, everything might appear perfectly normal. A form could submit information. A button could perform its intended action. Data could move from one place to another.

But underneath those working features was a serious security problem.

Depending on how those credentials were exposed, an attacker discovering them could potentially gain unauthorized access to the database.

And this wasn't a database containing someone's grocery list.

This was healthcare software.

Patient information could be at risk.

I explained the seriousness of what I'd discovered to the physician.

He listened, but his reaction left me with the impression that the security problem wasn't his immediate priority.

He wanted his automation completed.

I understood his frustration. He had already spent money and time trying to get the project working.

But I couldn't responsibly continue building on top of code with vulnerabilities like those.

So I began correcting them.

Three Weeks of Work Nobody Could See

I spent approximately three weeks fixing the security problems left behind in the existing code.

Think about that from the physician's perspective.

He had hired me because the developers were taking too long.

Now another three weeks had passed, and he still wasn't seeing the automation he had envisioned.

At our meetings, he wanted to know when the project would be finished.

He wanted me to hurry.

He wanted the additional expense to stop.

And I was trying to explain why the work I was doing had to be completed before we could safely move forward.

This is one of the most difficult things about software development.

People naturally measure progress by what they can see.

A new screen.

A working form.

An automated message.

A report that didn't exist yesterday.

But some of the most important work happens where the customer can't see it.

Correcting security vulnerabilities doesn't necessarily make the application look any different.

Neither does fixing a poorly designed database interaction or correcting code that bypasses the application's established architecture.

Yet those changes can be essential to making the software reliable and safe.

A feature that works isn't necessarily a feature that's ready for production.

I completed the security corrections.

But the larger automation project was still unfinished.

And the physician was running out of patience with the cost.

I Remember When I Was That Developer

I want to make something clear about the developers who worked on this project before me.

The problem wasn't that they were offshore.

I've worked with developers in different places, and geography doesn't determine whether someone understands an application.

The problem was that they didn't appear to understand OpenEMR's underlying architecture well enough to modify it safely.

And I can say that without pretending I've always known everything about the software myself.

I remember when I first started developing for OpenEMR.

I knew how to write code.

I could find a section of the application, make a change, and get the result I wanted.

Then something would break.

Sometimes it was something that seemed completely unrelated to what I had changed.

I'd find myself wondering how modifying one part of the program could affect another.

It took time for me to understand that the application wasn't just a collection of independent pages and functions.

It had an architecture.

Different components depended on one another. There were established ways the application handled data, security, and workflows.

Once I began understanding those relationships, my approach to development changed.

I stopped looking only at the immediate result I wanted and started considering how a modification affected the rest of the application.

I stopped breaking things the way I had in the beginning.

That's a lesson experience teaches you.

Someone can be a capable programmer and still be unfamiliar with the architecture of the application they're modifying.

And when that application manages healthcare information, the consequences of that unfamiliarity can be much more serious than a broken button.

The physician had hired developers to build functionality.

What he also needed was development experience specific to the system they were changing.

That difference had become expensive.

The Money Problem Never Went Away

The physician's original motivation was to reduce expenses.

He wanted automation because he believed it could reduce the administrative labor required to run his practice.

But building the automation required an investment of its own.

The developers had to be paid.

The existing work had to be evaluated.

Security problems had to be corrected.

The separate applications had to communicate with one another.

And the resulting workflows needed to function reliably.

None of that work disappeared simply because the physician needed the project to cost less.

I cost more than the developers he'd originally hired.

I understood that.

But I also knew that making the system work correctly would require more time and money than he had anticipated.

After approximately a month, the funding stopped.

Without continued funding, I couldn't continue the development work.

So my involvement ended.

I had corrected the security issues I discovered, but we hadn't completed the automation he wanted.

I went on to other projects.

And for a long time, I didn't know what happened to his.

Two Years Later

About two years passed.

Every so often, a former customer comes to mind.

Sometimes I wonder whether they ever solved the problem they were facing when we first met.

This physician was one of those people.

I remembered his practice.

I remembered the collection of tools he had assembled.

And I remembered how determined he had been to automate the administrative work that was eating into his profits.

I wondered whether he had finally brought everything together.

Had he completed the integrations?

Had he found a way to make the scheduling, payments, group sessions, documentation, and billing operate as one workflow?

Had the system finally become what he'd imagined?

So I reached out to him.

I asked how things had turned out.

He hadn't hired any additional developers after we parted ways.

And his answer about the project was simple.

"I just couldn't get it to work."

That was it.

He didn't describe a new system that had replaced the old one.

He didn't tell me he'd found another way to connect everything.

He didn't explain exactly which parts of the project had failed or which pieces might still have been useful.

I wasn't going to fill in those gaps for him.

All I knew was that the automation he had envisioned hadn't come together.

He had given up on the project.

The Cost of Trying to Save Money

I've thought about that experience more than once.

Here was a physician with a legitimate business problem.

His practice was busy, but the administrative expenses were consuming too much of what he earned.

He believed that connecting his software tools and automating his workflows would help him improve his profitability.

And he may well have been right about the potential benefits.

But there's a difference between understanding what you want software to accomplish and understanding what it will cost to build it.

A form that collects information is one thing.

A system that takes that information, creates or updates medical records, collects payments, schedules the appropriate group session, distributes telehealth invitations, documents attendance, and generates billing is something else entirely.

Every connection introduces requirements.

Every workflow needs to account for exceptions.

Every modification must coexist with the rest of the application.

And when patient information is involved, security cannot be treated as an optional expense.

The physician saw the finished automation as a way to reduce his operating costs.

But the cost of building that automation was greater than he expected or was willing to continue funding.

In the end, he spent money pursuing a system he never got to use as intended.

I don't know whether the project would have succeeded with a larger budget. Software development has no guarantees, and a larger budget alone doesn't solve poor planning.

But I do know that the scope of the work and the financial expectations were never aligned.

And without that alignment, even a worthwhile idea can become an unfinished project.

This story has something in common with the physician who paid for an EHR for eighteen months without entering a single patient. The circumstances were different, but the underlying pattern was the same: the gap between purchasing technology and actually using it can be wider than it appears from the outside.

What I Wish More Practice Owners Understood

I've spent years helping healthcare organizations implement, customize, and maintain OpenEMR.

One thing I've learned is that software projects often begin with someone describing what they want the application to do.

That's a necessary starting point.

But it's only the beginning.

Before committing to development, someone needs to examine how the existing software works, what can be configured without custom code, which integrations are required, what security obligations apply, and how much work is realistically involved.

Sometimes the right solution is custom development.

Sometimes it's an existing feature that hasn't been configured properly.

Sometimes it's an integration with another application.

And sometimes the best decision is to reduce the scope of the project and automate one manageable workflow at a time.

Not every good idea needs to be built all at once.

A physician trying to reduce administrative expenses shouldn't have to become an expert in software architecture.

But someone involved in planning the project needs to understand it.

Otherwise, the physician may find himself managing a software development operation instead of enjoying the efficiencies he hoped the software would create.

That's exactly the kind of burden this doctor was trying to escape.

If you're a small practice looking for a starting point that doesn't require a custom development project, Tarevo is a fully configured, hosted OpenEMR system built for independent practices — the workflows are already there, without the build-it-yourself risk.

The Automation That Never Happened

When I think back on this experience, I don't remember the physician as someone with a bad idea.

I remember someone who understood his business well enough to recognize that administrative costs were limiting his profitability.

He could see a better way to operate.

He had even begun assembling the tools to make it possible.

What he underestimated was the complexity of turning those tools into one reliable system.

I also remember the uncomfortable position I found myself in.

I had been brought in to accelerate the project, but the first thing I had to do was slow it down long enough to correct serious security problems.

I completed that work.

But I couldn't finish the larger project without the resources to continue.

Two years later, when I asked how things had turned out, the physician didn't have a success story to share.

He had only those six words.

"I just couldn't get it to work."

He had started the project hoping to reduce the cost of running his practice.

Instead, he spent time and money trying to make the automation itself work.

And that's the part of the story I hope other practice owners remember.

Sometimes the most expensive software project isn't the one with the highest development quote.

It's the one you spend money on but never get to use.

---

Affordable Custom EHR helps healthcare organizations implement, customize, and maintain OpenEMR-based systems. Our approach begins with understanding the practice's workflows and the existing software before determining what needs to be built.

Learn more about how we work or contact us if you're planning a project and want an honest assessment of what it will take.