Interoperability, while not a medical term, is currently tightly intertwined with the healthcare industry. No wonder. It’s been a hot topic since at least the 1980s, when the growing number of health IT systems started raising questions -- how are we going to share information not only between hospitals and labs, but also between different departments in the same clinic?
Many data sharing standards were introduced since then; some (like CDA) are still in use. But in 2021, we have even more requirements. With the rise of telehealth, Internet-of-Medical-Things, and the hundreds of healthcare devices and apps on the market, clinicians and patients felt the need for an easy and modern way to share newly available health data.
So, in 2020, the U.S. Centers for Medicare & Medicaid Services (CMS) announced the final health IT interoperability rules requiring all CMS-regulated payers to adopt a new standard and reach the ultimate clinical interoperability. If you’re a healthcare provider, a developer of healthcare apps, or even a curious patient, here’s all you need to know about FHIR.
What is FHIR and how will it change healthcare?
FHIR (Fast Healthcare Interoperability Resources) is a standard for healthcare data exchange created to drive clinical interoperability. FHIR (pronounced fire) was published in 2014 by HL7, a standards developing organization positioned at the origins of interoperability.
FHIR offers a common set of APIs (pieces of code enabling data transmission) for healthcare systems to communicate with each other. FHIR specifications are free to use and employ technologies and web standards commonly used in other industries, specifically the REST architectural style of API. Developers can combine different components of FHIR (called resources) to target specific clinical use cases or create extensions upon the core specifications. We will explain how it works in more detail in the next section.
So, FHIR is our best chance of achieving seamless data exchange. But what does it mean in practice for each party concerned?
FHIR for healthcare providers. FHIR creates a smooth pathway for connecting to third-party applications directly from your EHR. Basically, you’re not locked into your specific system and the integrations it provides. You can also launch your own apps by contracting development to a vendor -- with FHIR standards, this won’t be as expensive or time-consuming. FHIR also makes sure that data will always be maintained in a consistent manner in all its sources.
FHIR for healthcare software developers. Devs can focus on the value their products bring, not the implementation. HL7 provides clear and detailed documentation, the community shares numerous free tools and support, and the ability to use common web standards like XML, JSON, HTTP, and OAuth, allows programmers to build apps quickly and painlessly even if they’re not familiar with the healthcare domain.
FHIR for patients. FHIR delivers to patients a full overview over their clinical data. One handy example is the Apple’s Health app on iOS. It uses FHIR to pull patient data from EHRs and other health institutions, combines with data generated on the patient’s phone, and creates a holistic visualization of their health. The seamless access to this information drives patient engagement and updates them on lab results, allergies, medications, procedures, and more.
In this article, we will
- cover three main components of FHIR data models,
- describe the benefits of the SMART on FHIR platform,
- explain two main FHIR implementation types and
- list FHIR adoption challenges and solutions.
FHIR components: resources, references, profiles
FHIR's main purpose is to provide a core set of data elements called resources, which, when combined through references, should cover most clinical use cases. Other scenarios appearing in specific health domains are supported by the extension mechanism called profiling. These three components (resources, references, profiles) are the main aspects of FHIR development. Let’s go through them.
FHIR resources
The main structural element of FHIR solutions are resources. Resources are packets of information used to exchange or store data that satisfy most use cases in the clinical setting.
For example, a resource Patient covers demographic and administrative data about a person or animal receiving care. There are dozens of resources covering different aspects of the healthcare domain from scheduling and patient management to medical billing and information tracking.
Resources can be represented in multiple formats (UML, XML, JSON) and define what data will be shared using this resource. They can also contain normal text with explanations.
See the full resource index to learn more about the possibilities they provide. Developers can customize use cases for resources even further by using references and profiles.
FHIR references
Resources are rarely used independently and most resources have references to other resources. By linking Patient to Observation (which stores assertions made about a patient), Condition (problem or diagnosis) and Medication (ingredients, amount, strength of medications), you can implement and tailor specific scenarios. References are provided either as a URL, via an explicit identifier, or in text description.
FHIR profiles
A profile defines the use of a resource in specific circumstances. Developers describe how their FHIR-based APIs can be used and publish these adaptations in Implementation Guides, which are also standardized by FHIR.
Here’s an example. Blue Button is a Centers for Medicare & Medicaid Services' FHIR API that supports data exchange for Medicare beneficiaries. Their Implementation Guide (IG) lists the profiles for different scenarios: Carrier Claim Profile, Coverage Profile, Inpatient Profile, etc. Under each profile, you can see what elements and value sets you must include in the resource to use this profile.
Important to mention that there are tools and templates for creating an Implementation Guide as this standardized process can be technically challenging and is required for the interoperability compliance. There are just as many workshops and training courses for IG creators as for FHIR adopters alone.
Profiling is one of the most challenging tasks of FHIR adoption: It requires an intimate understanding of all FHIR resources and the technical aspects of implementation. So, to facilitate interoperability, a tool with built-in profiles was created. Let’s learn about SMART on FHIR and why you may want to use it.
SMART on FHIR
SMART (Substitutable Medical Applications, Reusable Technologies) was a standard initially developed to solve the interoperability problem similar to what FHIR did. But FHIR gained the healthcare community’s support first. So instead, SMART shifted the focus towards helping with FHIR implementations, namely creating tools and guidelines for developers building FHIR-based apps.
Today, SMART on FHIR is a project providing two products:
- a framework for building FHIR-based applications with supporting documentation, sandbox environments, software libraries, and other tools, and
- a platform to publish and access FHIR apps.
The main idea behind SMART is creating a marketplace for healthcare providers and patients where they can choose what apps they want to use on EHRs and easily switch between them. For this to work, apps should have a high level of security and interoperability that FHIR alone doesn’t provide.
So, SMART on FHIR delivers double value.
For physicians, hospital CTOs, and patients, it provides a seamless and low-cost way to integrate with hundreds of products on a marketplace. This ability to easily replace apps should drive the innovation process and create a competitive market similar to travel industry or financial mobile apps.
For developers, it gives a tech stack of concrete open specifications and profiles used to express specific types of data: medications, allergies, prescriptions, and conditions. Basically, SMART makes choices about data representations (usually based on standard codes like SNOMED) leaving less work for developers.
SMART on FHIR also has a built-in authorization and authentication mechanism. It uses OAuth for approving third-party apps and giving them access to EHR data. And OpenID Connect technology provides safe sign-in to those apps.
Many FHIR applications were built using the SMART on FHIR platform, including Apple’s Health app, which we mentioned earlier, and Microsoft Azure FHIR API.
FHIR implementation types
The FHIR specification was created for the broad selection of use cases. Still, many organizations will do the minimum effort and implement a FHIR API only to comply with the interoperability rules. But if a clinic has more far-reaching plans to build an entire data management process and make use of analytical and decision support integrations, it needs a more complex architecture as well.
There are two scenarios to implementing a FHIR API.
FHIR API on top of an existing system
This might be the most common route an EHR or other healthcare system will follow. The implementation architecture roughly consists of four layers: proprietary database, data access layer, FHIR adapter or facade, and finally FHIR API.
Your system uses its own data model, which must be converted into FHIR resources, so the layer in front of a FHIR API. This conversion is done using third-party middleware, called a FHIR adapter or facade. Some popular solutions include ones by CureLogix and Firely.
With this approach, you can also integrate the SMART on FHIR ecosystem.
Native FHIR system
This method is for those who are creating a new system and want it to be FHIR compatible from the beginning. This means that the platform will use FHIR in its design -- resources, profiles, and extensions will dictate the proprietary data model that can be used to build tons of compatible interfaces and implementations.
Of course, this approach would work for a few specific use cases.
For prototypes and new products. FHIR can create a shortcut for healthcare startups by allowing them to skip the stage of describing data and apply already existing data models.
As an alternative storage. You can also use FHIR as a data storage. Instead of investing in or building an adapter, you can readily store data in the format you require. This also applies to cases when you need temporary storage while your development team is working on an adapter.
Note that while the native approach future-proofs your system and eliminates many mistakes involved in data translation, it’s better to go native with a technology partner.
Preparing for FHIR adoption: challenges and solutions
Despite its many benefits, FHIR adoption today is mostly driven by the need for compliance with interoperability rules. For healthcare providers, this means several steps of preparation before being fully FHIR-ready. This includes the following tasks.
Patient matching
Patient matching (also called identity matching) is the process of linking a patient’s data across different healthcare systems to create a holistic health record. One of the prerequisites of interoperability, if done poorly, it can lead to catastrophic events, from million dollar HIPAA violations to fatal medical errors.
There’s currently no official tooling to quickly locate duplicates and errors and then combine them in a single record, so most of the patient matching is done manually or not done at all. A quick implementation timeline and lack of clear guidelines for patient matching may result in creating even lower quality data after FHIR is implemented.
Solution: a Master Patient Index. MPI or EMPI (for enterprise) is a database aggregating patient data from different systems. It uses algorithms to find relations between data elements. MPIs are usually sold by EHR providers, although they’re needed in laboratory or CPOE systems as well. Review what options are available to you or consider custom MPI development, which can ensure higher accuracy and the match engine that best covers your needs.
Security
FHIR wasn’t built to support security-related functionality. So to stay HIPAA-compliant, you need to build your own safeguards. That includes setting up your own authentication and access control, input validation processes, digital signatures, as well as writing data management policies.
Solution: SMART on FHIR. One of the greatest benefits of SMART on FHIR is its support of authorization and authentication protocols out of the box. If you’re not sure you can supply security processes on your own, this is the quickest solution.
Lack of infrastructure
FHIR offers an opportunity to take part in the app economy, but no technical toolkit to enable system architecture. This stalls the standard adoption, creating another set of complications healthcare providers and vendors have to deal with.
Solution: fully managed FHIR cloud platforms. In recent years, tech companies have created FHIR-focused tools to streamline healthcare app development and solve implementation challenges. Amazon, Google, Microsoft, IBM, and more companies like Salesforce and Apigee created enterprise-grade cloud platforms for managing APIs, storing data in FHIR format, securing Protected Health Information (PHI), and more.
These API for FHIR frameworks allow developers to deploy FHIR services in the cloud, basically by taking over all operations, maintenance, and compliance tasks. And they solve other challenges as well: access control and audit, legacy data conversion into FHIR, and even connectivity to analytics platforms. Cloud FHIR solutions are the easiest way to create and manage FHIR-based applications if you’re familiar with cloud platforms or have a partner who can set it up for you.