I want to start this post by stating that I like FHIR – I like it a lot. It’s widely used and accepted as a health care data exchange standard. I like it because it’s modern, well documented, easy to work with (implementable) and supported by high-quality open source frameworks and a great community (which greatly helps to speed up high-quality implementation). However, there’s a couple of things that have bothered me for a while about FHIR. The first of which is FHIR and REST. I’ve dedicated this post to describe what I think the problem is and to make a start on a proposed solution. Please let me know your thoughts in the comments below.
REST (REpresentation State Transfer) is an architectural style which can be used to create web services. The style was defined in 2000 by Roy Fielding as part of his Ph.D. dissertation [1]. It is a style which has become very popular amongst software developers, but also the subject of misunderstanding and misuse. See this article from Roy on this subject [2].
The REST style offers may properties, including scale, evolvability, and reliability. REST’s properties can be used to better support web service integration, in the context of new device types (e.g. smartphones, connected cars, fridges, watches, connected everything!), cloud-scale computing and heterogeneity (interoperating independently of programming language and platform).
At this stage, I think it’s worth a look at what I think is meant by “state transfer”. Have a look at this state machine diagram for a bank ATM machine (otherwise known as a behavioral diagram).
The diagram depicts the ATM in a number of states (idle, active, and out of service). The states can transition, for example when an account holder enters their card or an engineer starts to service the ATM.
As Fielding ‘s paper was intended as his Ph.D. dissertation, it’s a bit of a read! To help summarise, the Richardson (REST) Maturity Model [3] defines four levels of REST maturity (0, 1, 2, and 3). The higher the level achieved, the more mature the web service can be considered. The highest level, level three, is needed for a web service to be considered RESTful. The third level involves using hypermedia as a means of self-documentation, in order that clients (of the web service) can discover how the service can be used. This is an important factor, as it decouples the client and the web service. The web service can change (evolve) independently of the client, so long as the client is able to support reading and interpreting updates to the self-documenting hypermedia. In practice, the hypermedia is typically used to show what state transitions can be performed on a resource at any given time. For example, if an ATM machine (the ATM machine can be considered a “resource” in this context) is in the idle state, the web service may present hypermedia to the client, showing that the ATM can be transitioned to either the “active” or “out of service” states. Later, the web service can publish a “decommissioned” without having to force clients to update their software. The clients will be able to make transfers to the “decommissioned” state, in the way described in the hypermedia.
But, how does all of this relate to healthcare!? Have a look at this NICE pathway for Caesarean sections [4]. The diagram shows a number of scenarios under which a pregnant woman may transition through the Caesarean section pathway. The other pathways are the same – there are hundreds of them in use across the NHS. The REST architectural style is a good fit for this, as it is designed to help model state transfer – in other words where a patient is in a particular pathway. Furthermore, REST allows the client and service to be decoupled, which means the pathways can change in the future, without having to update all client software at the same time.
Although FHIR is not exclusively a RESTful specification, one of it’s supported paradigms is REST [5]. While FHIR servers are required to publish a capability statement, which provides some information to clients about what the web service can do, there is no hypermedia. This is because the FHIR standard doesn’t really facilitate state transition in this sense. FHIR resources can be sent to their own dedicated endpoint, and the HTTP verbs can be used to denote CREATE, READ, UPDATE and DELETE operations (amongst other operations for search and history, for example).
In FHIR’s defense, it would be difficult to try to standardise all health care pathways, internationally. This is because, so far as I understand it, healthcare isn’t standardised internationally. I recall conversations in my family, a few decades ago, about a family member who had moved to the US and was receiving treatment for breast cancer. Some of my family members in the UK, who are clinicians, were surprised about how early in the pathway the US system suggested mastectomy.
I suggest an extension to the REST part of the FHIR standard, in order that pathway’s and their states can be modeled. The following pattern of placeholders could be used;
https://{base}/fhir/{pathway}/{state}/{identifier}
While it would still be possible to do the following;
PUT https://{base}/fhir/Patient/12345
It would also be possible to send some hypermedia with the patient resource, to show that they could be transitioned to (for example);
PUT https://{base}/fhir/c-section/operation-performed/12345
To clarify, I’m proposing that the patient resource, or prehaps a bundle containing the patient and other resources relating to this pathway transition (e.g. procedure, observation, …) is PUT.
1.https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
2.https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
3.https://restfulapi.net/richardson-maturity-model/
4.https://pathways.nice.org.uk/pathways/caesarean-section
5.https://www.hl7.org/fhir
Hi,
Thanks for this – an interesting article. I’m wondering if maybe you might be confusing a business workflow state with the states of the FHIR resources used to represent the data underpinning that workflow? I would have thought the business workflow states would be represented by changes to attributes within those FHIR resources (eg updating the status of an appointment slot from available to booked) rather than trying to explicitly model business state transitions directly into operations on the FHIR resource? That way the same resources can safely participate in multiple business work flows simultaneously without having to have explicit knowledge of any of them? So the “ReST” in FHIR is all about managing states of the resources, with business workflows acting as a layer on-top (effectively separating the concerns). Of course I may have missed the point entirely, so happy to be corrected!
Hi Adam,
I think that the whole REST style is based on modelling business workflows states in an addressable way (e.g. by URLs). Modelling in this allows hypermedia as the engine of application state (HATEOAS), which in turn allows loose coupling between client and service. It’s true to say that in some context, a patient may be in multiple states simultaneously (e.g. complete on hearing checkup, but scheduled for eye operation). However, at a lower level, each of the encounters that the patient has may only be in one state at any given time (for example).
Representing workflows states as attributes of a resource is just another way of doing things – e.g. a non-RESTful way of doing things.
There’s a bit more info. on HATEOAS here;
https://restfulapi.net/hateoas/