We’ve all seen that amusing poster at a local business: “You can have it Fast, Good, or Cheap – Pick Two.” Today’s landscape feels much the same to healthcare CIOs and CTOs working to modernize their IT. Many I speak to are struggling to deliver a better experience to employees and partners, manage the risk of multiple connections to their enterprise, and do it all more cost-effectively amid shrinking budgets.
In a world full of tech debt and new technologies, evolving interoperability mandates can feel like the government just asked us to fulfill all three at the same time.
But it would be a failure of imagination to only see the CMS requirement to securely expose data as HL7® FHIR® APIs as a regulatory burden. APIs have real business value and offer an opportunity to build efficiency, agility, and compliance.
Seizing the potential to scale
I described in my previous blog in this series how healthcare organizations originally attempted to “lift and shift” their processes, exposing FHIR® APIs via VPNs the way they used to do with files.
Moving into the cloud and leveraging technologies like APIs isn’t as simple as wrapping existing data and processes in an API – and it would be entirely missing out on their value for scaling operations. The goal should always be automation and re-use, not merely refreshing a stale integration.
If we only need to connect to ten partners, it may be time-consuming, but it is technically feasible to have an implementation project with ten partners and build dedicated VPNs for each of them.
New interoperability mandates in healthcare put us in an entirely different context, however. Take the requirement to support a seamless digital transfer of a person’s medical records when they change health plans. That requires dozens, even hundreds of connections at any given moment.
It’s why the Interoperability Rule requires the use of APIs – patient records need to be coded in a standardized, common language (Fast Healthcare Interoperability Resources – ®) that any partner or third party can “read.”
It will be impossible to remain compliant if we continue with a project-based mindset.
Beyond the compliance aspect, it’s easy to see how the common language of FHIR® APIs makes it infinitely easier to scale and connect to an entire ecosystem. APIs free us up to do the work of building better digital experiences because they don’t require a sit-down conversation with partners and a whole project every time.
As healthcare matures in its adoption of APIs, I challenge us to not merely take the tools of the past and use them in the future. Let’s rethink our mindset around them and create new sustainable value.
Realizing the value of your APIs
FHIR® APIs help us share health data faster and more securely. But they also give us the ability to speed development efforts. APIs are agile, allowing you to do more new things faster because they’re so reusable.
In my view, the U.S. government is building a set of foundational requirements through the Interoperability Rule, and smart leaders will use these to create new experiences.
Here’s an example of what that might look like.
Leveraging the Provider Directory API
The Centers for Medicare & Medicaid Services (CMS) now requires health plans to create a Provider Directory using the FHIR® standard. This directory needs to include essential information about healthcare providers such as names, statuses (e.g., accepting new patients, whether they are in- or out-of-network), addresses, phone numbers, and specialties.
Once a health plan’s developers have built that API, they’ve checked the compliance box. But they can do so much more with it.
Health plans can leverage the Provider Directory API to develop a cost estimation tool for their members. Knowing who is in or out of network is key to calculating the cost of a procedure, so by integrating the directory with their claims and billing systems, plans can provide cost estimates for specific medical procedures or services.
Beyond helping their own members make more informed decisions about their healthcare expenses, the payer could even open up their Provider Directory API with a tiered pricing model – API monetization. In this manner, external developers, other healthcare organizations, or tech companies can use the directory data to build their own digital products.
Now that it’s an API, it’s also now easier to leverage the data collected through the provider directory to extract valuable analytics and insights.
For example, analysis of demographic information and available providers’ specialties can help identify gaps in specific specialties or regions, enabling targeted recruitment efforts to address those gaps. It can also assist in strategic planning, such as identifying trends in the provider workforce or anticipating future healthcare needs.
This single API opens up a whole range of new opportunities to innovate, while giving IT teams more agility and headroom.
The self-service imperative
Clearly, APIs are powerful, but they’re only valuable if they’re being used. And their ROI increases every time they are reused.
Driving adoption of APIs requires two important things:
- Good APIs—clear value, well-documented, intuitive design.
- A user-friendly mechanism for finding the right APIs and easily adopting them—such as an API marketplace.
Better APIs
Organizations must highlight the clear value of an API so that it stands on its own.
It’s why we talk about API First and treating APIs as products: APIs must be designed from the start with an obvious connection to a given use case or problem to solve.
The project-to-product shift means that APIs should be well-packaged and enable self-service. This involves things like clear documentation, intuitive design, strong authentication mechanisms, and active developer support.
If APIs are a product, it follows that they must be marketed to their consumer. In this case, the consumer is a developer. And developers are tired of sifting through wikis or spreadsheets, deciphering mediocre documentation to find what they need.
More findable APIs
When you use an API marketplace, your developer community can freely find and use the APIs you choose to expose, either internally, externally, or both. An API marketplace delivers integrations in a more automated, low-code way that isn’t possible in our traditional project-based world.
Leading marketplaces will include role-based access control and policies to ensure that the APIs are exposed to the right community or group of developers, improving their experience and providing governance over the discovery and usage process. This richer developer experience is at the heart of Axway’s Amplify Enterprise Marketplace.
Because it offers a single pane of glass over all an organization’s APIs, it’s easier to manage security and compliance. This supports organizational efficiency and allows you to not only keep up with evolving mandates, but also thrive in a growing healthcare ecosystem and discover new ways to improve the patient experience.
Amplify Marketplace helps speed delivery of digital initiatives and drive API value by allowing developers to easily find and use proven API products. Developers can read documentation, choose the API they need, and then programmatically, in a self-service way, request access to this API.
The value of APIs is in their role as building blocks: the ability to exchange data clearly and quickly. These kinds of self-service integrations are the way of the future.
If we fail to grasp this fundamental strategy shift, interoperability mandates will be significantly more disruptive to our technical teams. What’s more, we risk missing out on the potential to modernize our processes and create truly innovative digital experiences that can change patient care for the better.
Discover 5 steps you can take now to drive API adoption with an API marketplace.