Paradigms
In order to make FHIR interoperable, it was based on 4 paradigms:
- RESTful API
- Documents
- Messages
- Services
This is what's called an exchange framework.
REST
FHIR was primary designed to be used with Restful services which handle all requests. Restful service implies that we have a choice between using JSON or XML and it doesn't matter which one. Certain technologies (e.g. WCF) allow easy mapping between XML/JSON and objects. JSON allows built-in objects in JavaScript, hence making it incredibly easy to use in Web Applications.
There is also security to consider. REST works best when the control resides on client side and trust relationship already exists, because REST doesn't have a built-in support for digital signatures (unlike SOAP). It seems that it would create additional complexity to already encrypted system. So in order to create a trust relationship, OAuth is used. The device must first be added to the system and the system produces a key. This key is then passed along with every request. This way the server knows that this app is authenticated/authorized to perform desired operation.
FHIR is based Open Data Protocol (OData) which is Restful architectural pattern initially created by Microsoft, but released under Microsoft Open Specification Promise. OData specifies that each REST command is either:
- GET: Get a collection of entities or a single entity
- POST: Create a new entity from an entry document
- PUT: Update an existing entry with an entry document
- PATCH: Update an existing entity with a partial entry document
- DELETE: Remove the entity
Only one method can be used when making a restful call. The API in FHIR allows us to:
- Create = POST https://example.com/path/{resourceType}
- Read = GET https://example.com/path/{resourceType}/{id}
- Update = PUT https://example.com/path/{resourceType}/{id}
- Delete = DELETE https://example.com/path/{resourceType}/{id}
- Search = GET https://example.com/path/{resourceType}?search..
- History = GET https://example.com/path/{resourceType}/{id}/_history
- Transaction = POST https://example.com/path/ (POST a transaction bundle to the system)
- Operation = GET https://example.com/path/{resourceType}/{id}/${opname}
PATCH isn't used in FHIR and the remaining instructions are accessed via GET or POST methods.
Documents
FHIR syntax and working principles are fundamentally based on ATOM which originally was designed to be a universal publishing standard for blogs and other websites where content is frequently updated. ATOM is very similar to RSS, but there are slight differences. ATOM Publishing Protocol (AtomPub) was defined which specified that you should be able to do 4 things with an entry:
- Create
- Retrieve
- Update
- Delete
These 4 actions are known as CRUD (Create, Retrieve, Update, and Delete). Microsoft extended AtomPub and created OData.
There are however one key concept which remained from ATOM: documents. It seems fairly straightforward when you view, update or create elements in only one feed. But what if you wanted to mix two feeds together e.g. you might have patient records in one feed and images in another. ATOM already addressed this problem by introducing the concept of documents. This way you could mix the two collections (of feeds) together in order to display a meaningful message. The same thing applies in FHIR were document is:
"A set of coherent information that is a statement of healthcare information, particularly including clinical observations and services"
There are specific rules how to compose documents which we will describe in the next chapters. These documents can be manipulated and updated in the same way ATOM feeds are.
Messages
We've already talked about Restful approach and web feeds as the means to exchange data in FHIR. The third method are messages.
Messages in FHIR are very similar to those HL v2: "a "request message" is sent from a source application to a destination application when an event happens". They are essentially a stream of data that "will be delivered from one application to another by some delivery mechanism, and then a response will be turned to the source application".
Messages are based on the event-driven messaging design pattern. This is a service-oriented design paradigm in order to enable service consumers to get notifications about changes without resorting to the traditional inefficient polling based mechanism. We assume that the parties involved agreed on the method i.e. this can happen via: http, TCP, peer-to-peer and others.
See the FHIR/Event-Driven Messaging in WCF.pdf for an example.
Messages are event driven e.g. send lab order, get back result and can be asynchronous.
Services
FHIR was primary designed to be used with Restful services, but it is not necessary to use Restful interface when exchanging resources. Service Oriented Architecture is an architecture pattern which helps exposing different endpoints which link to the same the functionality. This way you can expose a TCP layer or only constrain is that you are passing around FHIR resources in some shape or manner. Other than this, you can have ultra-complex/simple workflows, pass individual resources or collections (ATOM or other formats). You don't even need to use HTTP.
The key thing to take from this: regardless of paradigm the content is the same. This means it is straight-forward to share content across paradigms e.g. receive a lab result in a message then package it in a discharge summary document.
This also means constraints can be shared across paradigms. If you define a profile for Blood Pressure and use it on resources in messages, documents, REST and services.