1. It’s about time – but why is it taking so long for the API to be released to market?
What we are trying to do is hard. We are putting a single, coherent, secure, cloud-hosted API layer over the top of a federated data-set spanning 900+ practices – each with varying Medtech versions, configurations and network infrastructure. The work being done now lays the foundations for an ongoing programme of extended and improved interoperability. We want to get those foundations – the fundamentals of how we address that heterogeneous practice environment – as strong and robust as they can be. To do that takes time to deliver the work program that covers planning, development, integration, performance, security, permissions, monitoring, documentation, testing and ultimately deployment.
[More details can be found in the answer to 3 below]
2. Why is it harder to do in Medtech32 – what are the technical constraints? Is this Medtech forcing us to upgrade to Evolution (to get enhanced API functionality)?
Medtech32 is a 20+ year-old piece of software delivered by a single, monolithic, code-base deployed on technologies from that era – Interbase and Delphi – and even on old versions of those old technologies. Medtech Evolution, in contrast, is built on modern versions of standard Microsoft tools in an up-to-date, decoupled architecture. Our Medtech APIs are also built with native Microsoft technologies – this time the cloud services that run in Microsoft Azure. Microsoft have deliberately made those Azure services work best with other, leading-edge Microsoft technologies so inevitably it is easier to build the Medtech APIs over Evolution.
That said, for our APIs to be useful they need to allow access to records in every practice and that means supporting Medtech32 in the first cut of the APIs and for the foreseeable future. Part of the purpose of the APIs is to ensure that integrators do not need to be concerned with the differences between MT32 and Evolution and we are working hard to ensure that is the case. Most likely we will end up delivering the APIs for both platforms but seeing some constraints when the APIs are used on MT32 sites – for example, slower performance or less rich data.
So, we are certainly not using the APIs to drive upgrades to Evolution. We are working hard to support MT32 in the APIs but we are battling with old technology, old code and old architectures and that means compromises must be made somewhere. For all that, there are many good reasons to upgrade to Evolution that are entirely independent of the APIs. We do want to get practices onto Evolution because we believe it will provide a better overall PMS experience and it will be our main focus for new PMS features going forward. However, the APIs are not any kind of driver towards this – they are necessarily neutral when it comes to MT32 and Evolution. They need to be able to span both.
3. What is so complicated about this project? Isn’t it relatively standard/straightforward?
The external-facing aspects of the Medtech API are standard and straightforward – these include the use of RESTful APIs returning JSON payloads, adherence to the HL7 FHIR standard for those APIs and the hosting of the APIs in Azure cloud supported by standard Azure services.
However, Medtech – as a point of principle – has chosen to offer those APIs as a single, secure, coherent layer that spans the diverse, heterogeneous and complex world of 900+ individual NZ GP practices. We have consciously chosen this approach – in preference to maintaining a centralised dataset that aggregates the data of all of those practices. We made that decision because we consider that the right home for clinical data is in the care of individual GP practices with a strong interest in the quality and maintenance of that information. We also want to ensure that the data that our APIs return is as current and reliable as it can possibly be and that is done by drawing on the ‘source-of-truth’ – the data that resides out there in all of those practices. We also know that to be useful the APIs need to be able to return the data from any practice in the country so while we can more easily draw on data in our public cloud versions we know that we need to embrace every practice in every remote location around New Zealand.
By choosing to let the Medtech clinical data remain as a disparate, federated data-set we have taken a harder path. It is harder because it means that for every API call we are having to negotiate – in real-time – across that wide set of practice environments. This means accounting for the practices using MT32 vs Evolution, for practices using older versions, for different network speeds and different levels of network quality, for customized coding-systems within the practice data and unusual server and database configurations within the practices. This challenge of bridging between our cloud-hosted APIs and the complexity of practice environments will be common to all FHIR clinical resources. Once we have a reliable way of providing API access to one FHIR resource across all practices (e.g. the Patient Summary) then that problem is largely solved for all resources. That’s why we are prepared to do the hard yards now in addressing that fundamental challenge of the ‘Hybrid Cloud’ that spans Microsoft’s Azure data-centres and these many, different practices. We are embracing the workload pain now so that we can take advantage of the many gains in the future.
4. Why are you moving away from bespoke development work if third parties are willing to pay?
We consider that bespoke development of 3rd party integrations does not scale, limits innovation and stifles competition. It also blurs the boundaries between Medtech and the 3rd parties that thrive on access to Medtech data and functionality.
We prefer APIs because they provide a clear, standard and re-usable point of entry to Medtech capabilities. That standard interface can be available to competing interests and to innovators who have a great idea but don’t have the capital to invest in bespoke development. Our intent is that through the APIs Medtech, and its partners, can become part of a wider eco-system of securely and seamlessly interoperating digital health services.
Finally, bespoke integrations may solve specific, individual problems but they don’t facilitate wider, patient-centric end-to-end health processes. We know that Medtech is just one player in a wider world of digital health services and that the patient journey will usually span many of those services. We know that those other services are moving to APIs and standard interoperability and we want to be part of that.
5. I have an agreement with you already – and we are happy with the way things are, we don’t want to be involved in this way forward – will we be forced to?
Medtech will honour any existing agreements already out there. However, we will work with all those parties so that over time they align with the Principles of the Partnering Program and are migrated to the API program. Overtime existing agreements will not be renewed or will run the natural course of the agreement until termination effect. We believe that most partners will see the new way of working is better for common users, with better SLAs for customer support being a key advantage. Furthermore, the newer technical solutions will give all our partners greater longevity with innovation and fewer constraints on how they wish to deliver their services in the future.
6. How will this create value for our mutual customers?
Let us take as a given that the 3rd party offerings are already delivering value to our mutual customers. If they were not then these offerings would not exist or GP practices would not pay for them. The question then becomes – what additional value is created for our mutual customers by integrating by way of a single, standard API rather than integrating in any other way?
The use of a standard interface creates value in many ways. Many existing integrations – particularly those that have not been co-developed, agreed or authorised by Medtech – significantly degrade the performance of core Medtech functionality. By providing a standard interface we can eliminate or minimize that performance impact by tuning the interface and managing throughput. Similarly, by integrating through a standard interface, Medtech can ensure that critical business logic is enforced in the integration. A good example of this application of business logic is the addition of important audit logging information when writes are done to Medtech records. When 3rd party integrations are done through other interfaces it becomes easy for them to bypass or incorrectly apply this kind of business logic.
The use of a standard interface can also ensure that the behaviour of integrated solutions is sensibly aligned with the enhancement and extension of Medtech itself. New versions of Medtech and new Medtech features need not cause any issues in the delivery of those 3rd party integrations. The use of a standards-based interface, HL7 FHIR, means that existing offerings that are already designed to make use of that interface are immediately available (with minimal extra coding) to be used in a Medtech context. The use of the standard APIs also lowers the barrier of entry for new, innovative integration partners because they do not need to significantly customize their offering to work with Medtech (or get Medtech to significantly customize our interfaces to work with their offering).
The Partnering Program and the use of a standard interface also ensures we are all better able to collaboratively provide better customer support. In the past, the lack of transparency between organisations made it difficult to provide responsive and timely assistance when a practice was having problems. A lot of finger pointing occurred. Our SLAs ensure that we work effectively together to get practices back on track as our interests for success are clearly aligned.
Perhaps the biggest value for our mutual customers, though, is the opportunity that it provides Vendors, and practices, to participate in new and innovative ways of delivering healthcare. We consider that patient journeys span the many tiers and sectors of the health system and that the digital services that underpin those patient journeys need to similarly span. The patient should have a single, coherent experience of being treated within the healthcare system and the digital systems that support that need to be thought of as a similar, holistic system that just happens to be made up of a disparate set of applications and software in use at each location. The use of a standard interface – one that the sector as a whole, both internationally and in a New Zealand context, is adhering around will allow those practices to be part of that holistic healthcare experience.
7. Is this the beginning of sunsetting Medtech32?
We have not determined the date to sunset Medtech32. Many people are happy with their Medtech32 experience and see no reason to want to change. However, we are looking to remove all the reasons why people have not chosen to migrate to Medtech Evolution. Some of the barriers are clearly innovation, functionality differences and trust that they will be better off moving to Medtech Evolution. The API and Partnering Program will certainly assist in showing that they can have better access to a number of innovative applications that they would not have otherwise, but we will also be spending considerable more on development for Medtech Evolution over Medtech32. We also expect the API performance and capabilities will be better with Medtech Evolution.
8. Don’t you already have an API? Why can’t we just use that instead of waiting for the new one?
As discussed above – we see value in a standards-based API interface – FHIR. An interface based on this standard allows us to be a good citizen in a wider New Zealand health sector eco-system. It also provides a mechanism that has been tested internationally and proven in many other jurisdictions to satisfy most or even all common health sector use-cases. We would argue this will allow our partners to go offshore into other jurisdictions. We will for example, establish an API over Australian products in the near future leading the way for partners to enter easier into the Australian market. In addition, we want to offer an interface that is built on cloud technologies – specifically Microsoft Azure. The use of cloud allows us to make an interface that isolates the consumers of the API from the idiosyncrasies and challenges of individual practices. The cloud hosting also allows us to deliver more reliable quality of service and coherent support. Cloud also allows us to extend the API more rapidly and scale up (to the extent the practices at the end can support it) for increased volumes of API calls.
9. How do you choose who you’re partnering with? Or is it anyone willing to pay?
We choose our partners on a case-by-case basis using a combination of good-faith and due-diligence. The good-faith part means that we are open to having a partnering conversation with any potential partner who considers that they have a contribution to make to New Zealand healthcare and a viable business model to make that contribution. The due-diligence part means that we have a set of onboarding processes that allow us to scrutinise that offering and how it works so that we can be confident that the partner is reliable and trustworthy and will not abuse the special access to health information and services that our API will provide. The Partnering Principles are also contracted terms and partners in breach will need to ameliorate the behaviour or will cease to be a partner.
Willingness to pay is not a factor in our choice of partners because we have aligned our business model to the viability and success of those partners. If they make money we make money. If they do not succeed then we do not make money off the partnership.
10. How do you choose how and when resources are included in your API roadmap? And how long they take to develop?
The prioritisation of specific FHIR resources and other new features in the API roadmap is done by the Product Management Team. The Product Management Team makes those decisions based on a mix of factors including:
- Commonality of need (i.e. those features that are needed by the most partners and practices)
- Commercial imperatives (i.e. what features will deliver best commercial returns for our partners)
- Ease of delivery (i.e. when a feature is easy to deliver then why not provide it)
We are still getting a feel for the speed with which we can deliver new resources. There are a number of design principles that we are applying specifically to try and make the delivery of new resources and features as quick as possible. These include “cloud-first” (with only very generic capabilities being implemented at the edge – i.e. in the PMS itself), automation built-in (CI/CD pipelines for resources), use of auto-scaling Azure services, standardized permissions models (OAuth2 scopes) and others. There are other aspects that may speed up the delivery of new resources that we are still investigating. An example of this kind of investigation is we are considering the use of an Integration Platform as a Service (IPaaS) for data-mapping and transformation. In theory the use of a tool could make many parts of providing a new resource a “drag-and-drop” exercise but we still need to test the “in theory” part of that assertion.
Regardless, the time it takes to deliver new resources will vary significantly depending on both the complexity of the resource and the clinical significance of what the resource might enable. This will mean that the most important question will not be “how quickly can we deliver <generic> resources?” but instead will be “when can we expect to see <specific> resource X?”. As our understanding of the time taken to develop matures and as that priority exercise described above takes place we will be sure to make that information available to the interested parties. We fully intend to make our Product Roadmap for APIs highly and publicly visible. That roadmap will be to the level of describing expected delivery dates of committed resources and features. The dates will be subject to change but when we know a timeframe we want you to know it as well.