FHIR and APIs
The healthcare industry, like many other industries, is going through a digital transformation. The digitization of health records has made patient information and care instruction more available, discoverable, and understandable.
Implementing “The Internet of Things” when it comes to healthcare is not just a project for fun; rather, it has life-saving and life-sustaining implications. The transfer of data from facility to facility, and device to device, ultimately can factor into a patient’s health outcome.
On top of better patient care derived from digitization, this electronic initiative also comes as a result of compliance with government regulations following the Electronic Medical Records (EMR) Mandate. Compliance with this mandate created the need for managers in healthcare operations, IT, and security to rethink how to interoperate with their partners, as well as how to handle resources internally. It requires a balance of innovation and differentiation, while also keeping healthcare costs down for patients and insurance carriers.
The healthcare industry has become an example of how to open up and collaborate in order to compete on a whole new level. By working together on a standard resource and API definition, the industry has opened up resources to focus on technology and innovations that provide for better healthcare outcomes instead of proprietary integrations and data transformations for hospital technical operations.
What is FHIR?
The HL7 FHIR (Health Level 7 Fast Healthcare Interoperability Resources) specification is a standard for exchanging healthcare information. Much like how Open Banking and PSD2 create sharing within the financial services industry, FHIR creates a common set of APIs so healthcare platforms can communicate and share data across facilities in a manner that each platform can understand. FHIR is based on emerging industry approaches and stems from over 20 years of lessons learned around requirements, successes, and challenges gained through defining and implementing other HL7 standards.
The basic building block of FHIR is a resource. All exchangeable content is defined as a resource. The philosophy then is to build a base set of resources that can either be used by themselves or when combined satisfy the majority of common use cases.
The healthcare industry has embraced an Open Source philosophy to accelerate adoption of these standards. HL7 has made the FHIR specification freely available to the FHIR community with no restrictions. While the FHIR community is large and distinguished – members include the Mayo Clinic, McKesson, athenahealth, Partners Healthcare Systems, and more – you do not have to be a member to use it. This ensures broader adoption, increases interoperability, and quickens and simplifies implementation as everyone uses and contributes to the specification.
Principles of FHIR
As defined by HL7, the foundation of FHIR is grounded by the following principles:
FHIR prioritizes implementation
FHIR provides a flexible framework for interoperability
FHIR keeps complexity where it belongs
FHIR supports but does not mandate tight specifications
These guiding principles are put in place to help FHIR be strong and resilient to various technological advances that occur over time. The FHIR standard allows for different architectural approaches that are appropriate for the given circumstances, whether being used to gather information from a modern or legacy system.
FHIR and Akana
The Akana API solution focuses on the complete lifecycle of the API, starting with the design stage and continuing through deployment, consumption, and retirement. This full lifecycle API management, along with the integration capabilities of the Akana platform to work with existing and legacy data sources, make Akana well-suited to provide an end-to-end solution for API-enabled healthcare.
Learn more about Akana’s integration and mediation capabilities, or experience the platform yourself with a free 30-day trial.