FHIR versioning with a non-version capable back end

As I’ve mentioned before, FHIR has the concept of versioning baked into it. Providing that the server supports versions, then any resource can be versioned, and older versions retrieved. However, particularly when using FHIR as a proxy server to a back end system, this might not always be the case – as we discovered at Orion during a project to provide FHIR interfaces to an existing product.

However, there are a number of areas where a ‘version specific’ ID is required – for example in the ‘self-link’ of a bundle containing the resource. (The self-link is optional, but desirable). It took a bit of fiddling – and a trip to Grahame via the skype implementers chat – to get this working correctly, so I thought I’d document where we got to (so I can remember next time!).

• We store the ‘last-modified’ time of the ‘resource’ in the system (eg the last time that the patient was updated). This timestamp becomes the version we expose.
• If we need to use a version specific reference (like the self-link) then we use the timestamp  – eg: /Patient/100/_history/201301011300
• In our conformance statement for this resource we set:
  • Read: supported
  • Vread: supported
  • Update: supported
  • Delete: not supported
  • History: not supported
• When we are returning a resource via a GET (read), then we set the ‘last-modified’ date to the timestamp

Now that we have that:

• An ‘ordinary’ read will return the current version of the resource
• If a client does a vread using the current version (e.g. /Patient/100/_history/201301011300) then there is no problem (and this will be what appears in any bundle we return).
• Should a client have cached an older version, and attempt to vread on that, then we return an error indicating that the older resource version is not available.

In this way our system is compatible with a version-aware client, even though the back end does not support versions.

Simple!