Does My Practice Need AI?

A longtime client recently asked me a question that deserves more attention than another demonstration of what AI can do.

Would any of it actually help her practice?

She runs a child therapy practice and has been working with me for about four years. I recently approached her about upgrading her OpenEMR system and showed her some AI features I had been developing.

She appreciated the work. But when she considered those features against the work her therapists do every day, she had questions.

Her existing billing process already helped identify claim problems. Her therapists had tried AI assistance with progress notes and weren't using it. Her practice treats clinically complex children, and she didn't see generic treatment suggestions being useful for those cases.

She also had concerns about accuracy. Her own experiences with AI had not given her much confidence, and having to make repeated requests for software fixes had colored how she viewed my use of it.

These were specific observations from someone who knew her practice.

We Were Building Automation Before AI

Years ago, I built a voice-operated system to automate documentation for a home health care clinic.

This was before the current wave of AI tools. We used the programming tools available at the time to make a computer respond to voice commands and help with documentation.

The software did not gain traction because that part of the industry did not have the margins to pay for it.

That experience stayed with me. You can build something that performs a useful function and still find that the economics do not work for the people who would use it. Development takes time. Support takes time. The customer has to receive enough value to justify the expense.

Those questions existed long before AI.

Today, AI gives us more ways to build and automate. But a practice owner still has to ask: What would this do for us? Would anyone use it? Would the benefit justify the cost and effort?

I Remember the Bugs Before AI, Too

One part of my client's email brought back our earlier years working together.

Before I used AI in development, she would ask for a change. At the time, we had an intermediary who helped communicate those requests. I would interpret the instructions and write the code.

Sometimes I got it right. Sometimes part of the change worked while another part needed adjustment. Sometimes we discovered a bug or a flaw in the logic after trying it.

That was software development before AI entered the conversation.

I reminded her of that shared history because I remember doing the work. Understanding a request, translating it into code, and getting the result to match what someone needs has always involved testing and revision.

AI can help me write code. It can also get things wrong. I still have to understand the request, review the work, and help bring it to the result the client needs.

From her side, she needs the feature to work. The tools I use do not erase the time she spends identifying a problem or explaining it again.

Both experiences belong in the conversation.

The Clinician Knows What Fits

My client's concerns about treatment suggestions were especially useful.

I can build a tool that produces a treatment plan. But she knows the children her practice serves, the complexity of their cases, and what her therapists need from a useful plan.

That knowledge cannot be supplied by a software demonstration.

I had previously built a treatment planning tool for an earlier version of OpenEMR. What I did not have was a clinician with her depth of experience guiding the development closely enough to tell me where the output helped and where it fell short.

So I offered her an invitation: if she thought of a tool that would be truly useful, we could collaborate to build it.

She would bring the clinical knowledge. I would bring the ability to turn that knowledge into working software. Together, we could determine where automation belonged and whether AI had a useful role.

We have not agreed to build anything yet. That is simply where the conversation opened a door.

Start With the Work You Need Done

Does your practice need AI?

It depends on the work you need help doing.

Perhaps your staff repeatedly enters the same information. Perhaps a documentation task consumes time that could be spent with patients. Perhaps the feature you need is a straightforward software change that could have been built years ago.

It is also possible that the tools being offered do not address a meaningful problem in your practice.

A clinician should be able to say that. Their experience gives a developer information that a feature list cannot.

After years of customizing EHR systems, I still need the people doing the work to help me understand what useful looks like in their setting.

That is what made this exchange valuable. My client looked at what I had built and explained why it did not fit her work. I could listen, draw on our shared history, and invite her to help shape something that might.

The next useful tool for her practice could begin with that conversation.

---

If you want to think through how your current EHR handles your actual workflow, this earlier piece on evaluating an EHR by counting the clicks is a good place to start.

Have a workflow you wish your EHR handled better? Let's talk about what would help your practice.