Updating Observations in FHIR

Had an interesting question put to me yesterday. We’re developing functionality to store Observations sourced both from a User Interface and also personal devices like Blood Pressure monitors, Scales & Glucose meters; and then do interesting stuff with them – like render them as a chart in a UI, make available to mobile devices, perform analytics and so forth.

As part of the testing process, one of the developers asked (as developers do) – what should we do if we get an updated observation, and the Observation.name is different from the original? It’s not impossible that the user in a UI selected the wrong type of observation (which is Observation.name in DSTU-1) initially and then sent an update through.

Putting to one side the security aspects (are they allowed to make this kind of update) and the version history – what should the repository do?

My first reaction was simply to change the observation in the repository – it’s an error, right? But then some edge-cases were brought up. In particular, what if the original was a Blood Pressure with 3 Observations (a ‘parent’ BP Observation and related Systolic & Diastolic observations), and this was changed to a single Weight measurement – should all 3 be updated in some way?

It’s a tricky question, and part of the answer is whether the client or the server is responsible for maintaining ‘integrity’ of the data being submitted, as well as the ‘paradigm’ of exchange being used.

If this is a purely RESTful exchange, then you could argue that it’s the clients responsibility to make it right. In this scenario (however unlikely it may be) then the client should update all 3 observations (perhaps changing the status of all 3 to ‘entered in error’) and then submitting a new, correct observation.

If you’re more used to thinking in operations, or an ‘RPC’ paradigm, then you could argue that the server should be enforcing this. That there should be an ‘update’ process that occurs on the server when the update occurs that invalidates the current set of Observations before applying the update. But how far should that go? And what rules should be followed in deciding which related Observations should be invalidated?

In our case, we’re in a constrained environment (we know who is sending us stuff) and so can define ‘trading partner agreements’ that covers the behaviours expected in this sort of scenario – and it’s a fairly unlikely scenario anyway. So we decided that it was the clients responsibility to clean up their own mess.

But is something that we may need to come back and address later, especially if the number and range of clients increase.

In any case, we audit everything, so if a client doesn’t follow the rules and questions are asked later – we know who you are!