IImplementing application programming interfaces (APIs) makes healthcare data more transparent and easily discoverable. It also introduces several challenges. The main issue is striking a balance between enabling accessibility and seamless sharing and healthcare interoperability across various platforms while ensuring the utmost security and protection of sensitive PHI (Protected Health Information).
The Health Level 7 Initiative (HL7) recently introduced a new standard to address these challenges. This specification, known as the Fast Healthcare Interoperability Resources (FHIR®) specification, establishes a uniform format for health data to facilitate seamless electronic sharing while keeping the data secure. This is why it is essential to understand how to ensure that your APIs adhere to the FHIR implementation requirements.
Our experts share some valuable tips for working with FHIR API, the vital tools for its creation, notable FHIR API examples, and the main challenges to consider.
Are you ready to master healthcare interoperability? Contact SPsoft today to learn how our experts can help you build a robust, scalable FHIR API that transforms your data exchange capabilities!
Table of Contents
“Finding the most efficient way to adjust the existing system to the new standard is the key to fast and cost-efficient adoption of FHIR. Our approach includes thoroughly analyzing the existing model to match it with the new standard. That way, we find a balanced solution that respects your needs, timeline constraints, and budget.”
Mike Lazor
CEO, SPsoft
“Working smart is the key to our team’s performance. If there are tools that can make our work more consistent and efficient, we use those tools. If there are no such tools, we make our own. In the case of the FHIR API, we have access to some truly amazing open-source tools and put them to good use.”
Romaniya Mykyta
Head of Product Management, SPSoft
What Is FHIR API, and What Should You Use It For?
FHIR is a data exchange standard created by HL7, an international organization established in 1987. It primarily focuses on developing data model standards for sharing electronic health information. If you have previous experience in the healthcare industry, you may have encountered or heard about the challenges associated with working with v2 or v3 standards.
Common complaints revolved around the proprietary TCP-based message protocol and inconsistencies in the interpretation of the semantics. These issues hindered smooth data exchange across different platforms and necessitated additional translation layers. Thus, FHIR emerged as a response to these problems, benefiting from the knowledge and experience accumulated over decades in the field. FHIR is designed to be modular and easy to configure, leveraging modern web technologies like JSON and XML.
APIs enhance data transparency and facilitate its discovery. The challenge lies in making healthcare information accessible and easily shareable across diverse healthcare systems while safeguarding sensitive patient information.
So, the fundamental question arises: How can we achieve efficient data sharing while protecting patient confidentiality? Fortunately, FHIR enables that by using a consistent FHIR format for every FHIR resource.
FHIR Healthcare API Specifications
APIs must adhere to certain specification details in terms of compliance and general usability.
REST or RESTful?
FHIR is commonly called a “RESTful” specification, aligning with the industry’s general understanding of REST. However, in practice, a RESTful API based on FHIR supports only Level 2 of the REST Maturity Model as part of its core specification. Achieving Level 3 is possible through using custom extensions. It is worth noting that while FHIR uses standardized resource structures, its reliance on a consistent interface is crucial for ensuring data exchange.
SMART on FHIR API
The Substitutable Medical Applications Reusable Technologies or SMART on FHIR API specification is very popular because it provides a standardized approach to addressing security and clinical data requirements. It defines a workflow applications can securely follow to request, receive, and utilize healthcare information.
In essence, SMART on FHIR API encompasses three key aspects.
Identity and Access Management
SMART utilizes the OpenID Connect identity management protocol, enabling applications to request access to clinical data. The level of access can vary, ranging from read-only access to specific records, comprehensive read/write access to an entire electronic health record (EHR), or any other level in between. The SMART on FHIR authentication outlines a customized version of OpenID Connect tailored for healthcare contexts.
Data Access
SMART utilizes the FHIR standard for effectively reading and updating healthcare data. In a SMART on FHIR authorization architecture, FHIR defines a set of interoperability resources that are made available for use by SMART applications. These services are secured using the Identity and Access Management layer mentioned earlier.
Launch Capability
FHIR specifies a consistent URL and base URL scheme for web-based applications that EHR systems can use to launch apps while passing relevant context to the application.
This context may include details about:
- Selected patient
- Clinical encounter
- Styling preferences
Tools For Creating FHIR-Compliant APIs
Here are a few tools that can assist you in developing your FHIR-compliant healthcare APIs and provide the basis to configure your healthcare services. At SPsoft, we take full advantage of the following tools and adapt them to the unique needs of truly custom solutions.
HAPI FHIR
HAPI-FHIR is an open-source Java library that offers a range of functionalities. The HAPI website includes a FHIR server for testing, allowing you to witness FHIR-compliant healthcare APIs in action. Working with HAPI serves as a crash course in FHIR API implementation. Their detailed documentation provides detailed guidance on various aspects, including working with resources, building FHIR servers, and managing the dataset.
Simplify.net FHIR Test Server
Public test servers mentioned in popular lists and roundups are often unavailable. That makes Simplify.net’s FHIR Test Server a basic FHIR API server you can use as a common data model for your own project. It offers a clear visual representation of the exchange of healthcare data. The server also offers a service base URL and endpoint, allowing you to experiment and try out search parameter logic firsthand.
Tips For Working With FHIR API
There are several tips to remember when working with the FHIR API. Apart from understanding the FHIR standard, you also need to know how it relates to your case. Here are some valuable tips we have derived from SPsoft’s years of experience with FHIR.
Visualize Resources
For individuals with limited knowledge of data architecture, understanding FHIR can be often overwhelming. To simplify how a FHIR resource functions, consider each one an interconnected spreadsheet. FHIR defines resources like Patient, Practitioner, and Observation as the building blocks. In this data model, individual data elements (Name, LOINC codes, Gender) are the columns within a specific spreadsheet.
Gain Knowledge of HTTP Commands
Although FHIR does not explicitly require HTTP, it is strongly recommended. The FHIR API operates based on interactions involving the Instance, the Type, and the System. They align with the familiar Create, Read, Update, and Delete (CRUD) patterns but with slightly more comprehensive controls. The API uses RESTful interactions at the endpoint level, supporting:
- Complex FHIR batch transactions
- Vread (addressing a specific version of the resource)
- Patch operations
Expand and Restrict the API
FHIR-compliant APIs offer the flexibility to be extended or restricted based on specific needs. That is achieved using the Capability Statement Resource, which outlines the available REST interactions on a particular base URL. While supporting the Capabilities statement is obvious for servers, an implementer can support extra use cases beyond the standard FHIR specification.
Include Human-Readable Text
Every FHIR resource is required to include a human-readable narrative. This human-readable text representation ensures that a clinician can understand the data even if the automated interface fails to process the JSON or XML correctly.
Learn through Examples
Understanding the FHIR specification’s depth and layers may be simple and easy for those familiar with APIs. However, having a concrete FHIR API example as a reference for building your APIs can significantly simplify the process.
Challenges to Keep in Mind When Working with FHIR
For large and established organizations, the challenge lies in aligning their existing data or native FHIR structures with the concepts defined by the FHIR standard. Over the years, an organization’s domain model may have evolved independently through guided and deliberate efforts or in a more ad-hoc manner.
Regardless of the approach, even a well-designed internal data model will inevitably differ from the newly-established core specification. These differences can range from minor semantics variations to complex issues like:
- A lack of one-to-one mapping between a dataset and a set of resources
- The standard does not cover certain custom internal concepts that hold significance for the organization
When evaluating the trade-off between the challenges of FHIR in healthcare adoption and the benefits it can bring, consider several factors.
- Popularity and community support: Is the FHIR version widely adopted within the industry, ensuring access to community support, available tooling, and the availability of experts in the job market?
- Degree of differences: How much does your dataset pre-exist the standard? Knowing the extent of the differences determine the level of effort required for alignment.
- The necessity of differences: Consider whether the organization needs to deviate from the standard or if the differences can be minimized by adapting internal processes to align more closely with the standard.
- Domain expertise: Do healthcare providers have the talent to manage the FHIR implementation? Assess whether your organization has enough domain experts who can effectively maintain and manage your domain model.
Weighing the costs of adoption against the potential future pros can be challenging. However, the effort invested in the long-term typically pays off, considering the potential benefits such as community support, standardization, interoperability, and scalability. You can address the issues of working with FHIR APIs with a reliable and experienced vendor like SPsoft. We are a trusted tech partner that can help you develop industry-compliant healthcare solutions.
Final Thoughts
The healthcare industry has recognized the urgent need for reliable data management. There has also been a growing demand for transparency, encompassing aspects such as pricing and patient records. The lessons learned from the COVID-19 pandemic have further emphasized the crucial role APIs play in the global healthcare sector.
Adhering to the FHIR specification ensures patient safety and PHI protection during the exchange of healthcare data. By using the FHIR standard, you future-proof your health system. It is the ideal time to partner with an experienced developer like SPsoft to configure these mobile solutions and APIs effectively.
Are you considering future-proofing your clinical data? Message SPsoft’s experts to learn how we can modernize your infrastructure with a native FHIR approach that scales with your organization!
FAQ
Is SMART on FHIR open source and how does it relate to the FHIR standard?
Yes, SMART on FHIR is an open-source project. It provides an open and collaborative framework for developing healthcare applications that can seamlessly integrate with electronic health records using the FHIR® standard. By using the FHIR specification for data and OAuth2 for security, it allows a developer to build an app once and have it run across different EHRs without significant integration changes. This standardized URL and launch capability are what make FHIR in healthcare so revolutionary for healthcare providers.
What is an FHIR-based API and Is It Free?
An FHIR-based API is an application programming interface that follows the specifications and principles outlined in the FHIR standard. FHIR is a data exchange standard developed by HL7 for the healthcare industry. An FHIR-based API allows for the exchange and interoperability of healthcare data in a standardized format.
The FHIR standard itself is free and open for use. However, the cost of implementing an FHIR API can vary depending on various factors. The development, adoption, and maintenance of an FHIR-based API may involve costs such as software development, infrastructure, security measures, and ongoing support.
What are the main differences between HL7 v2 and the FHIR specification?
Common complaints about v2 revolved around the proprietary TCP-based message protocol and inconsistencies in format. In contrast, the FHIR specification is built on modern RESTful principles. FHIR uses a modular set of resources that can be easily accessed via a URL or endpoint. While v2 sends a massive, rigid blob of data, FHIR enables a developer to request only the specific FHIR resource they need, such as a patient’s LOINC lab results, making data exchange across platforms much more efficient and human-readable.
How does a FHIR search parameter work when querying a FHIR server?
A FHIR search is performed by sending a GET request to a service base URL. The query uses a specific search parameter (like name or birthdate) appended to the URL. For example, a request to a FHIR server might look like [base]/Patient?name=smith. The server then filters its dataset and returns a bundle of resources in JSON or XML format. This standardized format ensures that healthcare interoperability is maintained, as any implementer will know exactly how to structure their query to exchange data with the server.
What is the role of human-readable text representation in a FHIR resource?
FHIR specifies that every resource should contain a human-readable text representation (the “Narrative”). This is a fragment of XHTML that summarizes the content of the FHIR resource for a human user. This is crucial for use cases where the automated system might not fully support the specific semantics of a resource. It ensures that a healthcare provider can always see the clinical intent of the health information, maintaining safety even if the technical interface between different healthcare systems is partially incompatible.
Why is a Capability Statement mandatory for every FHIR server?
The Capability Statement is a specific FHIR resource that describes exactly what a particular FHIR implementation can do. It lists which interoperability resources the server supports, which search parameter options are available, and the service base URL. It is mandatory because it serves as the “handshake” for healthcare interoperability. Before an app tries to exchange data, it queries the Capability Statement to configure its requests. This ensures that the data model remains consistent and the API uses the correct format for that specific health system.
