Health IT, MedCity Influencers

FHIR mandates are an opportunity to transform patient experiences through a consistent API strategy

There’s a real opportunity to go beyond a piecemeal, bare-minimum, “check-the-box” approach and think of FHIR mandates as an opportunity to kick-start consistency across your API landscape.

The healthcare industry is moving toward greater adoption of the Fast Healthcare Interoperability Resources (FHIR) standard.

The CMS interoperability rule mandating FHIR as a technical standard by July means a lot of healthcare organizations are scrambling to meet compliance markers, and industry heavyweights are also tipping the scale: Apple, Google, Microsoft, and Amazon all prioritize the HL7 FHIR standard for healthcare data.

But there’s a real opportunity to go beyond a piecemeal, bare-minimum, “check-the-box” approach and think of FHIR mandates as an opportunity to kick-start consistency across your API landscape. It’s possible to build truly digital, connected healthcare that gives patients better information and better outcomes.

A Common Business Language
Application Programming Interfaces, or APIs, at their technical core, are essentially a definition of an access point to a function or service.

They allow developers to create applications by accessing data and features of other applications, services, or operating systems.

More importantly, they are a way to package up a business capability to make a business highly consumable and interoperable.

FHIR can best be defined as a standardized language tailored to healthcare data, and it opens up new possibilities for collaboration and innovation, bringing real interoperability into reach.

Consumers don’t see them directly, but FHIR APIs power healthcare portals, in-hospital patient charts on iPads, connected devices – the list goes on.

Big Tech’s adoption of the FHIR standard shows a willingness to agree on a common business and technical language, and having a common standard makes it easier for the entire healthcare industry to make data more accessible and improve patient experiences.

I often hear organizations say things like, “well, that’s just an internal API, so I don’t need to use FHIR.” But designing with the idea that anything could be externalized at some point simplifies API design.

If the time comes to call on that API externally, there is less transformation required. Using FHIR for as many APIs as possible avoids private/public, internal/external discussions and reduces time and complexity.

Ultimately, focusing only on FHIR compliance is missing the mark – and could mean you are missing out on an opportunity to get a real capability map of your business.

Consistent Representation of Data
Using FHIR as the API building block throughout an organization ensures patient data is consistently represented. I’ve noticed FHIR implementation is often very focused on the clinical side of healthcare.

But a lot of API development work also needs to be done with the administrative and business end – think payments, insurance, or even patient experience. Instead of just using FHIR where it is legally required, there’s an opportunity to use FHIR’s resource definitions globally.

A patient is a patient is a patient. Whether it’s inpatient care systems or on the administrative back-end, it is extremely helpful to have the same representation of that data throughout.

You don’t want the business administration set of your APIs to have one definition and then use a completely different language in the clinical setting.

Also, standardizing APIs across your organization can give a true capability map of your business: you can catalog your APIs and know what resources are available to you, and those building blocks are readily available to use and start programming apps and tools that will improve user experience.

Using FHIR above and beyond patient data management helps you work in a cross-functional way. If you use a common building block, the entire organization is more modular. Now you can re-use APIs across the organization and shorten the time-to-market of new features and services.

What does a cohesive API strategy look like?
Thinking about a better API strategy, instead of just plugging in FHIR APIs where mandated, supports a platform vision, where your business model and your technology model converge: the technological parts come together to serve organizational goals, instead of the organization being limited by technical capabilities.

Moving from a FHIR mandate mindset to using FHIR as a common language both in and out of your organization, makes your APIs easier to work with and abstracts teams away from the complexity: it provides a common business language in your APIs so they are not such a cryptic, technical back-end to your work.

The Office of the National Coordinator for Health Information Technology (ONC) has made it clear that its goal with ongoing technical mandates is to increase transparency for consumers, creating a more competitive health IT marketplace and ultimately better patient care.

But it goes much further than just handing people’s raw data and checking the box: what healthcare consumers need is a way to do something with their data while still trusting the platforms that ultimately manage that data.

The Capability Layer
This is where you consider the patient’s experience and start building a middle layer which I like to call a capability layer: it means building a taxonomy, a catalog of capabilities ranging from claims, to care plans, building care, care delivery, patient records, doctor’s notes, hospital management… and then looking at these APIs as products that developer teams can pick and choose for what they need to accomplish.
I’m starting to talk to healthcare organizations about elevating the catalog as a way of building a true marketplace of world-class digital products and services.

You can’t really reuse your data if it’s not abstracted to a level that can apply to other use cases or capabilities.

Choosing to build on FHIR helps to standardize code and builds a resource framework for abstracting development teams away from the complexity of their specific backend systems so that every resource would have the same model in an API.

It allows you to avoid other parts of the organization not picking up on existing resources and starting from scratch on their own. Using FHIR as the basis for APIs means you can then focus on differentiators and extend those APIs as needed.

On the consumer end, this is the difference between a health plan portal that takes five minutes to load and forces you to wade through pages of information to find an answer to your question and one that pulls from a capability API and knows which tier of a health plan you’re on, therefore presenting only relevant information to you. A cohesive API strategy throughout translates into a better patient and customer experience.

Conclusion

The adoption of FHIR as an industry-wide API standard has the potential to unlock patient data – for the benefit of the patient, and the providers, plans, and organizations that serve them. It can offer a true capability map of healthcare businesses and enable reuse throughout.

But we’ll reach true interoperability only when healthcare partners see the opportunity to go beyond compliance and kick-start consistency across their API landscape, using FHIR as a building block for brilliant digital patient experiences.

Photo credit: Andrey Suslov, Getty

 


Avatar photo
Avatar photo

Brian Otten

Brian Otten is a Digital Catalyst at Axway, a hybrid integration software company that empowers customers around the world to compete and thrive in dynamic marketplaces by better connecting their people, systems, businesses and digital ecosystems. Brian has over 25 years of experience partnering with large enterprises in guiding strategy, adoption and execution of business technology transformation.

This post appears through the MedCity Influencers program. Anyone can publish their perspective on business and innovation in healthcare on MedCity News through MedCity Influencers. Click here to find out how.

Shares1
Shares1