Your software vendor's AI is not your AI strategy

Every practice management company and every EHR is shipping AI features right now. Your account rep has mentioned it. There's a webinar. Some of it is genuinely good.

The reasonable question that follows is: do I need anybody else, or should I just wait?

Sometimes the answer really is "just wait," and I'll tell you when. But the answer turns on a distinction most people haven't been given, so here it is.

Vendors solve inside their own walls

A software company builds features that work inside its own product, using its own data, for its average customer. All three of those constraints matter.

Inside its own product. Your PMS vendor will make scheduling smarter. They will not make your phone system talk to your billing company, because they own neither.

Using its own data. They can act on what's in their database. They cannot act on the PDF your referring physician faxed over, the voicemail from Tuesday, or the spreadsheet your office manager maintains because the software doesn't do the thing she needs.

For its average customer. This is the big one. If you have four locations and an unusual specialty mix, you are not their average customer, and the thing costing you the most money is specific to you. It will never be near the top of a roadmap that has to serve twelve thousand practices.

None of that is a criticism. It is the correct way to build software for a large market. It does mean the shape of what you will get is predictable, and so is the shape of what you will not.

The money is in the seams

Think about where work actually stalls in your practice. Almost every time, it's between two systems, not inside one.

A patient calls; the call lives in the phone system. Their appointment lives in the PMS. Their insurance sits with a clearinghouse. Their intake form arrives as a PDF. Their balance is in the billing system. The referral came in by fax. Someone's personal spreadsheet tracks the thing none of those systems track.

Every one of those handoffs is a human retyping something a computer already knew. That's where the labor goes. And no vendor owns the seam — by definition, a seam is the place where two vendors stop.

This is the whole argument for doing work outside your software vendor, and it has nothing to do with quality. Their AI is fine. It is also confined to their own walls, by design.

A test you can run in one meeting

Take the three things that annoy you most about how the practice runs. For each, ask: does fixing this require touching more than one system?

If no — it's entirely inside your PMS, or entirely inside your phone system — put it on a list and ask that vendor when they're shipping it. There's a reasonable chance it's coming, and paying someone else to build it is money you didn't have to spend.

If yes, and most will be yes, nobody is coming. It's yours to solve or yours to keep paying for.

Ask your vendor these four things

Before you decide anything, get answers in writing from your account rep. This costs you one email.

"What AI features ship in the next two quarters, and are they on my plan tier?" The second half matters more than the first. A lot of announced AI is on a higher tier.

"Does it cost extra?" Frequently yes, and frequently per-user or per-provider, which changes the arithmetic completely for a multi-provider practice.

"Do you have an API, and what does it cost to get access?" This is the most consequential question on the list and it has nothing to do with AI. Whether your PMS has a usable, affordable API determines what anybody — us, a freelancer, your own IT person — can ever build for you. Some vendors are open. Some charge meaningfully for access. Some are closed and there's no route in except screen automation, which is fragile and should be a last resort.

"Will you sign a BAA covering the AI features specifically?" Usually yes, since they're already a business associate, but get it in writing for the AI functionality rather than assuming the existing agreement stretches.

The answers give you a real map. In particular, that third answer tells you the ceiling on everything you could ever do.

When waiting is genuinely right

I'd tell you to wait if:

• The thing you want is squarely inside one product and that vendor has publicly committed to shipping it soon.
• You're mid-migration to a new system. Never build against software you're leaving.
• The feature is on a higher tier and upgrading costs less than building. Do the boring comparison; sometimes upgrading a plan is a tenth the price of a custom build.
• You genuinely have nobody internally who can own a project right now. A system with no owner decays.

When it isn't

• The problem crosses systems. This is most problems.
• Your vendor is closed and slow, and the cost of waiting is measurable in months.
• The thing costing you the most is unique to how your practice works. That will never be on anyone's roadmap.
• You've been told "it's coming" for more than a year.

The unglamorous conclusion

The right answer is usually a mix: use your vendor's AI for the things inside their walls, since you're already paying for it, and get someone to build the two or three cross-system things that are actually costing you money.

That's a much smaller and cheaper project than "an AI strategy," which is a thing nobody needs and several people will happily sell you.

---

Part of what the audit produces is exactly this map — what your existing software already does or will do, what it can never do, and what's genuinely worth building. Sometimes the finding is "upgrade your plan tier and keep the rest of your money," and that's a fine outcome.