“…next generation standards framework created by HL7. FHIR combines the best features of HL7’s v2 , HL7 v3 and CDA product lines while leveraging the latest web standards and applying a tight focus on implementability.”
To understand FHIR better, we’ll dive into what the latest web standards are, how they facilitate implementability, and what this implementability could mean.
The key point to remember is: FHIR is a RESTful API, which puts it in a class of web standards that is very widely used in the tech field to transfer all kinds of data between different applications and systems.
Say you have some app or service - in this case, a kitchen full of chefs that can create and output many exciting dishes. You also have a set of clients - very hungry restaurant patrons - who want to get at the provided services.
However, these clients might be completely ignorant of how this specific kitchen (service) operates, what food is provided, how this food is made and dispensed, and all the other intricacies of running a restaurant. Yet these clients still want access to this and other such restaurant services with minimal hassle.
That’s where the waiter (API) comes in. The waiter acts as an interface that the customers to interact with, and translates their needs to the kitchen in a way the kitchen can understand. Finally, the waiter/API devlivers the services to the clients, isolating the kitchen from individual interactions.
Ideally, the waiter/API provides the customers with an experiance they’ve come to expect from other such fine establishments. Even if this kitchen/service operates completely differently and - maybe a different cuisine, done on a different scale, at a different pricepoint - the experience as viewed by the clients using the waiter/API is not unfamiliar.
In summary, an ideal API provides a standardized, well-documented, and convenient endpoint for clients to interface with a given app or service.
Operations are highlighted here, and introduced as follows:
The RESTful API defines a set of common interactions (read, update, search, etc.) performed on a repository of typed resources. For further information concerning how operations are defined and invoked, see Extended Operations on the RESTful API.
This is a full list of the operations defined by this specification:
FHIR provides a framework for the representation of healthcare data and methods for sending and retrieving this data.
The standard has the potential to be the language that all kinds of different healthcare apps and services
- EHRs, personal health apps, fitness trackers, patient portals, clinical labs, and so on - all communicate with.
There’s a large difference between the FHIR specifications and the actual implementation of a standard.
FHIR is relatively mature as an API, and the documented features are relatively comprehensive.
However, the FHIR endpoints that have been implemented so far differ widely in the extent their implementation matches the spec.
This distinction between the (1) state of the FHIR standard itself and the (2) the adherance of different implementations to the standard is crucial for any organization exploring the use of this technology.
FHIR API Tutorial
Now, we’ll put all of this learning in action and build our own Cardiovascular Risk Calculator using FHIR resources!
Explore on your own!
Work through this tutorial on your own, and post comments with any thoughts or questions.
Sorry for the delay with posting the video for this tutorial. I had to splice together the audio with the video I managed to record, and was finally able to upload the results to YouTube. Feel free to check it out here:
Unfortunately, the video of the tutorial section of the webinar did not record =(
You can try following along with the audio, or reach out to me if you’re working through it on your own and run into any issues.
Also, if you’d like to get some other perspectives on FHIR, check out these two videos from a tutorial Viet Nguyen gave at last year’s UW FHIR Workshop: