These integrations are our first leaps towards one of Halo Connect’s core goals: better PMS interoperability for integrators. They will allow integrators to query multiple PMS systems via the same API endpoints, using the same infrastructure, and to receive query results in a consistent format.
This means less overhead for integrators who want to take their integration to a new PMS, enabling easier access to whole new customer markets. It’s one less barrier to interoperability and enables faster innovation in Australian healthcare.
Expanding beyond Bp Premier did present a few technical challenges, both due to differences in the SQL engines used by different PMS providers and to support more complex configurations. This included…
Supporting more SQL flavours
Halo Link can now connect to MS SQL Server, Firebird, and Sybase databases. We had to get creative to set up the connections and handle errors correctly for each new database type. Now that it’s done, it’s a breeze to add support for other PMSs that use one of these database types.
Multi-database support
Zedmed uses a pair of databases, and connecting to them must be done explicitly. So a new field was added to our immediate and async queries - catalogue, which lets integrators specify which database to query.
This option currently only works for Zedmed, however, we intend to extend it to work with Bp Premier as well, and any PMS we add support for in the future that use multiple databases.
Multi-install support
Zedmed and D4W both allow multiple instances of the PMS software to be installed on one server but Halo Link was originally designed to only be installed once on a server and to only connect to one database. This had to change.
Our solution was to allow each Halo Link instance to connect to multiple PMS instances, routing and queuing queries appropriately based on the Halo GUIDs assigned to each PMS instance. This meant a good amount of infrastructure work and some slight changes to Halo Link’s registry, but overall was managed with little to no impact on practices or integrators.
This is also a key feature for supporting cloud-hosted PMS systems, which often have many PMS instances on one server.
API changes
While we try to minimise breaking changes to our API, new PMS types meant some slight changes to our API, and we chose to do a bit of a cleanup at the same time.
To future-proof against PMS differences causing response data to vary PMS-to-PMS, we’ve started moving some data into sub-objects. Currently, that includes the practice metadata object returned by the Site APIs into which we’re putting practice identifiers. We’ve deprecated the original fields that used this data, plus a few others that weren’t useful for integrators.
Extensive testing across all PMSs
No PMS integration is complete without a fleet of test machines running various combinations of PMS and OS software, and a few hundred tests to ensure nothing goes awry. Not to mention all of the infrastructure and automation to support running those tests frequently, of course.
New docs content
To help integrators get started with the new PMS integrations, our docs were also updated with new PMS guides for Zedmed and D4W, and various other pages were overhauled to ensure the content was up-to-date and easy to read.
All that said, practice makes perfect, and we’re now a lot faster at adding support for additional PMSs for our Passthrough API. With so much of the groundwork now laid, we’re confident future PMS integrations can be done in a few weeks.
Of course, while the SQL Passthrough API unlocks many benefits for integrators, we’re also planning to extend our recently announced FHIR API for Bp Premier to other PMSs.
If you’re a PMS vendor and are interested in lowering the barrier to integrations and rapidly expanding your third-party Partner Programs, contact us at hello@haloconnect.io.