FHIR for Developers: Part 3
FHIR Exchange Module and RESTful API
FHIR Exchange Module
FHIR is designed as an interface specification — it specifies the content of the data exchanged between healthcare applications, and how the exchange is implemented and managed. FHIR defines the following methods for exchanging data between systems. Each of the methods is meant for a specific use case and has both pros and cons. The method one might use will depend on the use case.
- RESTful API: Most implementers focus on RESTful API. This is a client/server API designed to follow the principles of RESTful design for Create, Read, Update and Delete operations, along with Search and Execute (Operations) support.
- Messaging: Supports exchange between systems by sending routed messages from system to system. This exchange can be implemented on the RESTful API or using some other messaging technology.
- Documents: In this content to be exchanged is wrapped by a Composition that provides the context of the content, and that has a fixed presentation for a human reader. The document framework is provided to help with computer-assisted human-to-human communication uses — which are not uncommon in healthcare.
- Database/Persistent store: Another way to make use of the resources defined by FHIR is to store them natively in a database or persistent store, where different applications or modules write and read the resources as part of their implementation.
FHIR RESTful API
A REST API (also known as RESTful API) is an application programming interface (API or web API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services.FHIR is described as a ‘RESTful’ specification based on common industry-level use of the term REST.
FHIR provides different APIs for different types of transactions with the resources. Before we get there and start looking at the different operations we look at the structure of the URL.
[base]/[type]/[id]Base: The Service Base URL is the address where all of the resources defined by this interface are found. The Service Base URL takes the form of
http{s}://server{/path}Type: It is the Resource that you want to Access or on which you want to perform the operation.
Create: It is used for the creation of new resources at the FHIR server. It is the HTTP Post request. It will accept the RequestBody and in return, it creates a new resource. The response will contain the newly generated id for the resource.
eg: https://myserver.com/Patient (HTTP Post)
Read: It is used for getting the resource for the FHIR server. It is an HTTP Get request. We need to pass the type and id of the resource we want to retrieve we will get the complete resource as a response if it exists. Following API will return Patient resource with example as id.
eg: https://myserver.com/Patient/example (HTTP Get)
Update: It is used for updating the existing resource in FHIR. It is the HTTP Put request. We will need to pass a resource with the id and the server will return the updated resource if it exists and if it does not exist server will create a new resource with the given id. This operation may also be used to create a resource with the custom id instead of a server-generated id.
eg: https://myserver.com/Patient (HTTP Put)
Delete: It is used to delete the resource from the FHIR Server. The call for delete is similar to the get only difference is that it is an HTTP Delete request. One thing that we need to understand here is the delete performed here is a logical delete, not an actual delete. What it means the resource will not appear in the search results.
eg: https://myserver.com/Patient/example (HTTP Delete)
Search Operations
Developing any healthcare application search is one of the important operations we need to perform on our health records. FHIR provides extensive search API functionality to get the exact data from the FHIR server. We will further look into some of the search functionality provided by the FHIR.
[base]/[type]/[parameter]Parameters: These are the search parameter based on which we want to search. eg :
https://myserver.com/Patient (Return All the Patient)
https://myserver.com/Patient?name=smith
https://myserver.com/Patient?birthdate=1970–01–01
Other examples:
- Search the resource with the identifier of the given System (https:foo.com) and the value (1234).
https://myserver.com/Patient?identifier=https:foo.com|1234 (Both)
https://myserver.com/Patient?identifier=1234 (Only Value)
https://myserver.com/Patient?identifier=https:foo.com| (Only System)
2. Date as parameter and prefixes: gt (Greater Than), ge (Greater Than and Equal To), etc.
https://myserver.com/Patient?birthdate=ge1970–01–01
https://myserver.com/Patient?birthdate=gt1970–01–01
3. Chaining of Parameters:
https://myserver.com/Encounter?Patient.name=smith
https://myserver.com/Encounter?Patient.birthdate=1970–01–01
Here we have just scratched the surface of what FHIR provides in the search functionality. I would definitely recommend looking more into different search parameters provided by FHIR here.
If you loved my work please like and share this article( it’s free :)). Also, do follow me for more articles like these.
Also, check out my other articles:
