Who Answers When Two Vendors Point at Each Other

The treatment coordinator is holding on two lines. The practice management vendor is on line one, the patient communication vendor is on line two. Both companies have looked at the logs on their side and told her the same thing. Everything is fine here. Whatever is wrong is not us. She takes them both off hold, tries to connect them so they can talk to each other, and gets told by both parties that the other side has to open the ticket. The doctor walks by twice. The morning huddle is over and nobody knows why the treatment plan the front desk sent last night is not showing up in the schedule this morning.

Every practice that runs more than one piece of software has had this hour. It does not get discussed openly, and when it does get discussed it gets framed as a support-culture problem: the vendors should just be better about this. Better vendors help. But the finger-pointing is not, in the main, a behavior problem. It is a contract problem. And the practice owns it by default, not because the practice deserves to, but because the boundary between two companies' software was not written into either company's contract at the time it was signed.

Why the boundary belongs to nobody

Two vendors, two agreements, two service-level commitments. Each one describes what its own software does and how it will be supported. Neither describes what happens when the two systems have to talk to each other. That is not an accident. It is how software contracts are written across every industry, and it is how they are written in dentistry. A vendor's obligation is to its own product. The interface between two products is a third thing, and a third thing that nobody has contracted to own goes to the party with the least ability to say no. That party is the practice.

Support agents at both vendors are not being difficult when they say the log shows nothing wrong on their side. From their point of view the log does look fine. The bug is not inside either system. The bug is in the sentence one system said to the other, in a format both systems technically understand, but with an assumption about the shape of the data that only one of them makes. Nobody is going to volunteer to own that bug when their support-ticket queue is measured on time-to-close on tickets that fall inside their software.

What the ADA already said about this

In October 2024, the ADA sent a ten-page comment letter to the Department of Health and Human Services about the HTI-2 proposed rule on health IT interoperability. The letter is public, signed by the ADA president and executive director, and it says two things about dental software vendors that no dental content site has written the sentence for.

The first is that most dental practices use practice management systems that are not certified under the federal health IT certification program, and that connecting standards changes to that program will therefore not benefit most dental providers. That is not a criticism the ADA made in passing. It is stated as an argument for a different regulatory approach for dentistry, and it is repeated across the letter.

The second is more direct. The ADA told HHS, in writing, that there are "financial advantages for vendors in dental technology who only support proprietary APIs." That sentence, from the ADA to the federal government, is the honest answer to the finger-pointing question. Vendors do not build to open standards because their business model does not reward it. Keeping the interface proprietary keeps the customer where they are.

This is the ADA's characterization, not a marketing claim. And it reframes the front-desk moment we started with. What looks like two support teams being unhelpful is the practice discovering, in real time, that the interface between two proprietary systems is not anyone's contracted responsibility.

Why the federal enforcement teeth do not reach dentistry

In September 2025, the HHS Office of Inspector General and the Assistant Secretary for Technology Policy issued a joint enforcement alert. Health IT developers and certain other actors can now face civil monetary penalties of up to one million dollars per violation of the information blocking rule. Enforcement targets, in the alert's own priority order, practices that cause patient harm, significantly impair a provider's ability to deliver care, are of long duration, or cause financial loss.

That regime has meaningful teeth in medicine, where most electronic health record vendors are certified under the ONC program and are therefore in scope. In dentistry, the same regime largely does not reach. Most dental practice management software is not certified health IT, and being a business associate does not put a vendor in scope on its own. The million-dollar penalty exists on paper and does not apply to most of the software running in a dental practice. This is not an interpretation. It is what the ADA told HHS in writing, and it is what the CFR structure actually does.

The practical reading for an owner-dentist is that the federal answer to bad vendor behavior in medicine has not arrived in dentistry, and there is no timeline for its arrival. Waiting for it is not a plan. The plan has to be different, and it has to start earlier than the finger-pointing hour.

The move is before signing, not after

The moment to define who owns the boundary between two vendors is when the second vendor's contract is being negotiated. Not after. Every practice signs the first vendor's agreement without thinking about the second one because there is no second vendor yet. The second vendor, though, is being asked to talk to the first vendor's software, and their agreement is where the interface question can actually be answered.

A short section in the second contract naming what the vendor will support at the interface, what data formats they will accept, what timelines they will respond to for interface-specific issues, and who at the vendor owns escalation when the other side is unresponsive: that section changes the finger-pointing hour into a resolvable ticket. It also gives the practice something to point at when the two support teams stop talking. Practices with real bargaining power ask for it. Practices without leverage often cannot get it. Both cases benefit from having asked, because the vendor's answer is data about how the boundary will actually be handled after the sale.

Where we sit on this

We built AiroDental as a modular platform on purpose, and part of the reason is that the boundary between modules is inside our own code, not between two vendor agreements. When Saige and Laine both touch the same patient record, we own the debug on both sides. We integrate directly with Dentrix, Dentrix Ascend, Open Dental, and CareStack, and where a boundary exists between our software and a practice's PMS, we will tell you exactly what we handle and what we do not, in writing, before you sign. We are month to month, with no long-term contract and no onboarding fee, and the shortest version of our sales pitch is that we prefer to earn a renewal than to hold you to one. If you want to see what that means in practice, we can walk you through it. See how AiroDental works →

Deren Flesher, DDS. Founder, AiroDental.