Modifier Extensions in versioning (maybe)

So I think I’ve come across my first real place where using a modifier extension makes sense. (actually, not quite – see the note at the bottom of the post, but the discussion is hopefully still interesting)

Before we get into that, a short recap on what a modifier extension is. As most people working with FHIR will be aware, the specification aims to keep the individual ‘packets’ of data (Resources) as small and simple as possible, by providing a fixed core of elements that ‘most’ people are currently sharing and an extension mechanism that allows individual implementers to add the extra elements that they may need for specific Use Cases – a process called Profiling.

Now, when you add a new element you can’t expect that a recipient will understand what it means. You can provide a definition of the extension (in fact you have to) but that still doesn’t mean that the recipient will know to do with the extra information you are adding. Most of the time that doesn’t really matter – if you add an extension for ‘eye colour’ to Patient, and the recipient doesn’t store eye colour then no harm is done.

But sometimes you can’t be that sanguine about it. Suppose you wanted to assert that a patient did not have a given Condition and created a ‘hasNotGot’ extension to use, then a recipient MUST understand what you are trying to say – otherwise they may think you are saying that the patient does have the condition. To cover this scenario, FHIR has the concept of modifier extensions – extensions that potentially change the meaning to the resource and which a recipient must have a strategy to deal with.

The spec states:

Implementations processing the data in resources SHALL check for modifiers anywhere they may appear, and if a modifier extension is present, SHALL do one of these things:

• understand the impact of the extension when using the data
• refuse to process the data
• carry a warning concerning the data along with any action or output that results from processing the data to inform users that it has not fully understood the source information

It also states:

Implementers should avoid the use of modifier extensions where possible. Any use should be carefully considered against its possible downstream consequences. However, implementers are often forced into these situations by the business arrangements around the use of resources, so this specification creates a framework for handling these cases. If modifier extensions are present, an application cannot safely process the resource unless it knows what the extension means for its own use of the data.

So, on to our Use Case.

The application that we’re developing acts as an ‘aggregator’ of information – it collects information from a number of sources (in this case Allergies) both inside and outside the Enterprise and makes that available to users.

What we want to be able to do is to support versioning of resources – the ability to record changes to a resource instance and to make that available to the user. This is optional in FHIR (though recommended) and is declared by a server in its conformance statement on a ‘per type’ basis – so a server declares that it supports version for some resource types – and potentially not for others.

This creates a particular problem for us as not all of the source systems are able to support versioning – and it’s really an ‘all or none’ – the client consuming our service doesn’t care about our internal architecture and if we say we support versioning, then they will expect that all resources we expose across that interface can have a history and that they can retrieve that history and any specific version

We bounced this around a few times and looked at a number of options. We could:

• Require that all sources support versioning – but then we could potentially cut ourselves from useful data
• Do the versioning ourselves – but that could be quite a lot of work, and potentially incorrect as we won’t know every change that occurred
• Only support versioning on the resources that have a version – but that could be just plain wrong! You can easily envisage scenarios where a clinician acted on information that subsequently changes and needs to be aware of that change.

So in the end we decided that best solution was a variant of the last option – we’ll add a modifier extension to those resources that cannot be versioned to indicate that any history is not available through the API– at least we can be explicit to the user that there is data that may have changed – we just can’t tell them through the interface – they’ll have to go to the logs (or the System Administrator will) if a history of changes is important to them.

If a client asks for a version history or a specific version then we’ll return a 404

It does add an extra burden on to the client – but it does mean that we can offer versioning over most of the resources.

So not the most satisfactory solution – but one that should work… Oh, and if you have a better alternative (or a problem with this approach) then we’re happy to hear it!

As an addendum to the post, both Grahame & Mark commented (thanks!) – Grahame suggesting that simply returning a 404 in the case of an unavailable version would be sufficient to alert the user to the possibility of a missing version – ie go look elsewhere if this is important to you. So no Modifier extension needed in this case – which is actually kind of nice – and great to get the feedback!