If your practice management system hasn’t got a proper open API, bin it.
Clinics seem oddly tolerant of bad software. If their kettle took twenty minutes to boil, or their fridge stopped being cold, they’d be on Facebook Marketplace by lunchtime. Yet people happily stick with PMSs that hold their business back for years.
The MSK world is full of practice management systems, yet very few have a genuinely open API. In 2026, that’s unacceptable.
Quick definition for anyone who needs it. An open API is an interface that lets different pieces of software talk to each other, so your patient, appointment, financial and operational data can be accessed by other tools you’ve authorised. Think of a telly and a DVD player (showing my age here). Any DVD player should work with any TV, and when a better TV comes out, you unplug the old one and connect the new one. Same goes for clinic software.
A PMS with an open API does one job exceptionally well: managing your clinic. Then you plug in the best tools for everything else, a proper email marketing platform, AI phone answering that books appointments straight into your diary, reporting platforms like ClinicSignal, AI scribes like Heidi, and whatever gets invented next year. Without an API, your data lives in a box and you’re stuck with whatever features your PMS vendor eventually decides to build.
Imagine your bank only let you use its own budgeting app, its own accounting software and its own payment platform, and refused to connect to anything else. You’d move banks. Yet plenty of clinics accept exactly that from their PMS.
Your patient data belongs to your clinic. You paid to acquire every patient, every appointment and every invoice. If your software makes it hard to get at that data, it’s limiting how you can run your business.
It matters more now than it ever has, because the next ten years of clinic software is going to be AI driven, and AI can’t deliver much value if it can’t access your data. It can’t analyse bookings, predict cancellations, automate your admin or tell you anything useful about the business without it. A closed PMS isn’t just inconvenient. It limits what your clinic can do.
The argument against is always the same. We’ve built our own ecosystem, it all talks to itself, you don’t need anything else. It’s nonsense. That thinking died in the 90s, when big corporations were told to standardise on IBM or standardise on SAP. You don’t want one company doing everything. You want best of breed, and almost no business on earth can honestly claim to be the best at everything.
It’s fine if you’re Apple. Billions in the bank, the whole thing built in-house, every part connected. Crack on. But Jane isn’t Apple. TM3 isn’t Apple. People talk about PMS companies as though they’re Microsoft-sized software businesses. They’re not. Most are small teams. When a company tries to build everything itself, everything ends up average. And they haven’t got the engineering resource to build every one of those products to the standard of companies whose entire business is focused on solving that one problem.
The irony is that an open API is good for PMS companies as well. It lets them focus on what they should be brilliant at instead of wasting years trying to build mediocre versions of products that already exist. Everyone wins. Clinics get better software. Developers get customers. PMS vendors build a better core product.
A closed system isn’t an accident either. It’s a retention strategy. If every workflow, report and integration in your clinic depends on one vendor, leaving becomes painful, and they know it. An open API cuts your switching costs, which funnily enough tends to keep vendors on their toes. Closed APIs don’t protect clinics but they do protect software vendors.
And the day-to-day stuff gets better too. Review requests going out automatically. Outstanding payments chased without anyone lifting a finger. Proper answers to proper questions, cost per patient by marketing channel, rebooking rates by clinician, lifetime patient value, instead of the crayon-level reporting most systems ship with. The PMS becomes a data source, and your reporting lives somewhere better.
If you ever sell, buyers notice this stuff as well. A clinic where the systems talk to each other is easier to diligence and worth more than one held together with manual exports and a spreadsheet someone updates on a Friday.
So here’s my advice. Your next PMS should have a documented, well-supported open API. If your current provider refuses to build one, or won’t let third-party developers use it, ask yourself why.
There are brilliant tools appearing every month, AI receptionists, AI scribes, business intelligence platforms, patient communication software, billing automation. The next breakthrough won’t come from your PMS vendor. It’ll come from somewhere else.
Your PMS shouldn’t decide which innovations your clinic gets to use. You should.
