A prominent and growing concern in today’s healthcare ecosystem is the interoperability of numerous, increasingly complex systems that the industry relies on. These include, but are not limited to, administrative systems such as for billing and scheduling, and clinical systems including laboratory services and Electronic Health Records (EHR). These systems need to interact seamlessly with one another across different regions, used by different types of clinicians in different contexts (human care, public health, research, etc.).
In addition, the same information may be represented inconsistently with different levels of detail, granularity, and nesting by various parties across the systems. As healthcare records are becoming increasingly digitized, healthcare providers and their patients are negatively impacted by the ever increasing amount of data and its variability caused by non-standard healthcare processes and business practices.
Canada is not exempt from these limitations, but the digitization of its healthcare industry is still in its early stages, only starting within the past 2 decades. As developers of healthcare-centric applications at Evenset in Toronto, we are interested in a method of standardization that allows us to create applications which provide just the right information to healthcare providers and practitioners as well as their patients, while keeping relevant information accessible and secure.
Background
Fast Healthcare Interoperability Resources, or FHIR (pronounced “fire”) is a next-generation standards framework published by Health Level Seven International (HL7) aiming to make EHRs be available, discoverable, and understandable as well as have the data be structured and standardized across systems.
FHIR at its core contains two primary components: Resources and API. Resources are a modular set of components – a collection of models of different types of clinical and administrative data. They are the common building blocks for all information exchange, acting as a representation of any healthcare related entity such as a patient, medication, or concepts such as allergies, laboratory results, etc.
The API is designed as a RESTful specification which allows for interoperating between two applications. They are designed to enable an exchange of healthcare-related information in a wide variety of settings across a wide range of teams and organizations.
FHIR’s philosophy is to build a base generic set of resources that, either by themselves or when combined, satisfy the majority of common use cases. As well, there is a built-in extension mechanism defined as Profiles that extend existing resources to provide richer and more specific content and data. Resources are designed in a way that changes to their data can be made without altering how the system passes them around. They are interoperable out of the box, and are suitable for use in a wide variety of contexts:
- Mobile/Web apps
- Cloud communications
- EHR-based data sharing
- Server communication in large institutional healthcare providers
- In-patient care
- Ambulatory care
- Acute care
- Long-term care
- Community care
Why we want to build custom software based on this framework
Current standards for healthcare information exchange are based on C-CDA (consolidated clinical document architecture), designed to exchange entire documents full of static, hard to extract data. FHIR allows for greater control of the information exchanged through their resources and any extensions required. With the boom of the healthcare Internet of Things with, for example, devices that collect patient-generated health data, now is a great time to standardize how all this information should be exchanged to make them useful.
FHIR provides a platform on which our applications can collect and filter the information we need into meaningful sets. We can build situation-specific apps that are extensible to meet different needs and use their API to communicate between different applications to share data. These applications can range from scheduling appointments to dealing with the finances involved in the healthcare industry, to sharing patient results and consultation notes through the patient’s mobile device, among many other innovative health-related software.
The FHIR framework gives us the tools to develop a more unified EHR system, in a way. For patients, there might no longer be a need to worry about using various patient portals or applications depending on the different health systems they are exposed to or are using. Instead, we can create one portal application that integrates data from different formats created by different healthcare provider systems for anyone to use.
Because of its simple API design, our custom software can easily be created as plug-and-play applications that can interface with any EHR to boost provider workflow and efficiency. A current issue with non-standardized methods of EHR sharing is decreased patient-provider interaction due to the tedious nature of obtaining patient data from a complex system. This is easily resolved with FHIR based applications, as the information is provided in a more straightforward and succinctly.
In addition to all that, integrated health data, opens door to an increasing number of Artificial Intelligence (AI) and Business Intelligence (BI) applications, where access to integrated data pieces is more valuable than all pieces combined.
We believe that Canadian healthcare providers can greatly benefit from adapting FHIR based applications into their workflow. Canada is an open market for EHR applications which will undoubtedly save time, costs, and headaches for many of our healthcare providers and their patients. As a country, there is already an established foundation for digital health technologies and applications, and FHIR is poised to lead the standardization of healthcare information exchange.
Available Libraries
- FHIR.js – https://github.com/lantanagroup/FHIR.js
- Node.JS library for serializing/deserializing FHIR resources between JS and XML, and validating FHIR resources by Lantanagroup.
- FHIR.js – https://github.com/lantanagroup/FHIR.js
- fhir.js – https://github.com/FHIR/fhir.js
- Older JavaScript client for FHIR
- fhir.js – https://github.com/FHIR/fhir.js
- Node FHIR Server – https://github.com/Asymmetrik/node-fhir-server-core
- A Secure Rest implementation for the HL7 FHIR Specification by Asymmetrik.
- Node FHIR Server – https://github.com/Asymmetrik/node-fhir-server-core
- FHIRBase – PostGres https://github.com/fhirbase/fhirbase
- A command-line utility which enables you to easily import FHIR data into a PostgreSQL database and work with it in a relational way.
- FHIRBase – PostGres https://github.com/fhirbase/fhirbase
- HAPI FHIR – https://github.com/jamesagnew/hapi-fhir
- An active, open-source implementation of the FHIR specification in Java
- HAPI FHIR – https://github.com/jamesagnew/hapi-fhir
- Python SMART on FHIR client – https://github.com/smart-on-fhir/client-py
- A flexible Python client for FHIR servers supporting the SMART on FHIR protocol.
- Python SMART on FHIR client – https://github.com/smart-on-fhir/client-py
- SMART on FHIR – https://github.com/smart-on-fhir/client-js
- JavaScript Client for FHIR
- For more information: https://dev.smarthealthit.org/
Further Reading
Digital Health in Canada – https://betterhealthtogether.ca/digital-health-in-canada/what-is-digital-health
Foundational Programs in Canada – https://www.infoway-inforoute.ca/en/what-we-do/progress-in-canada/foundational-programs
FHIR Overview – https://www.hl7.org/fhir/overview.html
Why FHIR, Why Now? – https://infocentral.infoway-inforoute.ca/en/resources/docs/2351-why-fhir-why-now-canada/view-document
What is SMART on FHIR? – https://www.redoxengine.com/blog/what-is-smart-on-fhir/