FHIR API
FHIR (opens in a new tab) is a community-maintained healthcare-specific data model and API specification. Oystehr's FHIR API is our implementation of the many rules and guidelines in the FHIR specification.
Why Build on FHIR?
Interoperability — The more systems adopt FHIR, the more opportunities you have to share data to improve outcomes. The FHIR standard was created to give disparate healthcare systems with proprietary data models a common language for communicating healthcare data to improve interoperability. In order to use FHIR, legacy monolithic EHRs have to maintain their proprietary data models as well as a mapping to and from FHIR. With Oystehr, FHIR is your data model from the start, removing the entire cost center of mapping into and out of FHIR.
Future-proofing — Proprietary data models rarely see the future from the beginning. Instead, engineers have to do expensive refactors to accommodate new requirements. The FHIR model is designed to support future requirements from square-one.
Building on FHIR
Working with the FHIR API is in many ways similar other APIs you may have used. You can create, read, update, and delete resources. You can also search for resources using a variety of parameters.
But the FHIR API specification goes well beyond the basics. The Oystehr FHIR API implements resource history and resource-provenance which enable valuable analytics and auditing functions.
The Oystehr FHIR API also implements batch / transaction, the ability to perform many FHIR queries in a single API request.
FHIR Modeling
As of FHIR R5, there are 157 different resources.
The challenge with building on FHIR is learning how the FHIR model fits together so you can see how best to achieve your use case. Our "Building Your Workflows on Oystehr" guides include FHIR modeling examples to help you get familiar.
We love this stuff, so if you have a FHIR modeling question, reach out in the Oystehr Slack Workspace (opens in a new tab) and we will help you out. Another great resource for FHIR modeling is FHIR chat (opens in a new tab) where you can often search and find good modeling advice.
FHIR Versions
Although there are many published versions of FHIR (opens in a new tab), and new versions in the works, four FHIR versions are especially relevant to builders today,
| FHIR Version | Release Date | Oystehr Support |
|---|---|---|
| R4 | 2019-10-30 | |
| R4B | 2022-05-28 | ✅ |
| R5 | 2023-03-26 | ✅ |
| R6 | WIP |
- R4 refers to version R4.0.1 — R4 is specified in the ONC Certification Criteria for §170.315(g)(10) Standardized API for patient and population services (opens in a new tab). In particular, the US Core implementation guide (opens in a new tab), is based on R4. This rule led to the widespread but very shallow adoption of FHIR across legacy monolithic EHRs. Because many EHRs do support R4.0.1, if only partially, it is the most popular version of FHIR today.
- R4B — Adds several new FHIR Resources, with very minimal breaking changes relative to R4.0.1. Importantly, there are no breaking changes in R4B which impact the ability to support the US Core profile.
- R5 — The current latest release, R5 has 55 new FHIR resources and many resources from R4B are now "normative" which means they are no longer likely to have breaking changes in a newer version of FHIR.
- R6 — This release is expected to bring most FHIR Resources to "normative" maturity.
We recommend you use R4B for your project. The benefits of R4B over R5 include:
- Other R4 or R4B FHIR services integrate more easily with your project.
- Your project can become ONC Certified (opens in a new tab).
- You will have access to Oystehr's Telemed, Messaging, or RCM services.