The healthcare community-building patient experience with API Platforms: Part 2

In Part 1 of our series, 5 roles in the healthcare community, we demonstrated how Axway’s customers span the five main areas of the healthcare value chain and how Axway delivers the best patient experience for all. In Part 2, we go even deeper; we explore the health-as-a-service platform and more.

Health-as-a-service platform

Before exploring the health-as-a-service platform, it’s worth exploring their desired objectives and how they become possible with a modern technology approach.

Often, the focus of modernization is put on API integration as the solution to improving the experience, continuously innovating, and better-managing risk and compliance.

This focus is only partially correct. It’s not about APIs as much as it is about building an API-first platform. The platform is what “decouples” the various pieces of the architecture so they can move independently and enable more discrete improvements to a complex system.

Capabilities

There are a few key capabilities that will be framed into the healthcare conversation that are important to understand:

1. Decoupling the fast-moving, innovative capabilities from back-end complexity. APIs in general, and FHIR® in specific, make integration easier than in the past. As well-defined REST and JSON messages they run on a standards-based infrastructure, through firewalls, using HTTPS, and so on. They’re well understood, and API definition files (like WSDL, Swagger, OpenAPI) that can be consumed by developer tools make integration easy.

However, creating software using APIs without a platform misses the objective. Developers will still create “brittle” integration points and complex interdependencies. They will still create “heavy” applications containing capabilities that could be shared across applications, capabilities like user authentication, or performance and usage metrics.

The magic of APIs lies in the fact that as a standards-based integration capability an abstraction layer can be put in-between API provider and API consumer opening up a world of new benefits such as the ability to innovate faster or improve security.

Improve healthcare delivery with Axway mobile app development

2. Taking security (and governance) out of the hands of developers and putting it into the hands of security (and governance) experts. One of the key capabilities of any API platform, and one you should strongly evaluate, is the breadth and depth of the security capabilities. The key point is having a rich policy language for implementing security as a policy in the platform.

The benefits accrue to developers, whether it’s making OAuth simpler to implement and reducing time to market or have a defined set of authentication flows so that authentication best practices are enforced in the platform.

Additionally, for a complex platform such as health-as-a-service, there are many complexities with identity and enterprise security integration.

An API platform deeply considered with security will make it easier to abstract away the diverse identity and authentication systems used by participants. Such abstraction makes complex health security policies, such as SMART on FHIR®, much simpler to implement and govern over time.

And, while these capabilities are about function — improving security, privacy, and compliance — they’re also about cost. When you can manage all of this “better” you manage more cost-effectively.

You enable innovation through-software to happen more quickly and in more places, a benefit that flows directly to the patients, doctors, nurses, and all the participants in the healthcare system.

Finally, Axway is also the only API Platform that is Common Criteria certified. Perhaps this level of security is “overkill” for the current proposal, the security and privacy of your patient’s health information is not something Axway takes lightly.

3. Enabling people to solve their challenges through software. One of the things that APIs have enabled but that many organizations haven’t taken advantage of is the change in who is “creating” with software. When complex back-end systems (that require specialized skills) are protected and security is built into the platform it becomes easier to allow people to solve their software problems.

As “citizen developers,” it means that with the right tools in place to govern how systems and data are used many more people can innovate than in the past.

This again means that innovation can happen anywhere and be focused on the customer (whether that customer is the patient, or the doctor or nurse helping them — the statistics show that doctor burn-out from patient records systems complexity is high).

The first step in enabling people to solve their problems is having a store or a catalog of capabilities that developers can use to innovate.

This catalog must not be system-dependent… because if it’s a reflection of the back-end complexity, there are no benefits to citizen developers. The catalog should unify the presentation of capabilities — from technical flows, like authentication, to simple integration points, like upload step count — so that developers collaborate better, are more efficient at their work, and are more effective in aligning to the desired experience.

This catalog also helps API owners encourage consumption and engagement. It helps API owners focus on results instead of activity and is critical to aligning to developers and their experiences with your healthcare platform.

4. Analytics and insight so that “the business” can encourage and anticipate developer needs. Analytics plays a role for API consumers as well as API owners. For a consumer, it’s important to understand what to expect from the performance of an API.

For an owner, it’s useful to understand how an API is being used to better plan for growth and the typical dynamic business environment. One might imagine, as COVID emerged, a different set of services became important while others became less so.

Using Axway, we’d have the insight to help your organization balance your infrastructure to deliver capacity where it’s needed and understand how the market demand changes over time.

5. A platform provides flexibility to adapt. It’s often said that the only constant is change. Change in our health needs, with the technology used to solve problems, and in the relative priorities of the moment.

Going into 2020 we didn’t know people couldn’t wait in a waiting room during a pandemic. Yet now we need a way to queue patients in the parking lot and let them into the office only in time for their appointments.

Or we need doctors to connect video conferencing into a patient record (and call it telehealth). We know things change while changing complex systems hard.

A platform enables more responsive technology adaptation to change, whether it’s the changing healthcare landscape, new capabilities, or fundamental technical capabilities (like, for example, biometric authentication).

Increasingly, each of these organizations has realized that to fulfill their mission, they not only needed to excel in the quality and price of the product/service they were delivering to their patient but also that patients were individuals experiencing the product/service of others.

Hence the journey for their patient (and employees, and partners) could not be seamless unless each participant built an open platform, not only considering their services but also considering services provided by other Healthcare Community participants to their patients.

“This need for openness is more and more apparent, with the need to regularly bring in partners — for R&D programs, for example — or as part of value-creating open innovation initiatives.” Pascal Bousquet, Global Head of Architecture at Novartis.

In Part 3, we will explore what it means to create a health-as-a-service open platform based on FHIR® in support of existing and healthcare opportunities.

Footnote:

1. An example of an activity is “how many APIs are published”… it might be interesting but it’s not as useful as understanding “how many new applications have been created” using an API; or how many new experiences have been satisfied because the IT capability exposed by the API enabled innovation around experience.