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!

About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

2 Responses to Updating Observations in FHIR

  1. Rene Spronk says:

    Brings back memories of discussions we had years ago about objects graphs (where the objects are SMIRFS, basically a v3-based-precursor of the Resource concept), e.g. http://wiki.hl7.org/index.php?title=Object_nets_and_object_trees (directly related to the subject of this post) and http://wiki.hl7.org/index.php?title=Safe_querying_of_a_RIM-based_data_model (which will probably needs to be addressed someday in the context of FHIR as well).

  2. DamonX says:

    Regarding “So we decided that it was the clients responsibility to clean up their own mess.”, I reckon it would be more user-friendly if the server sends an warning message when the client is trying to undermine his/her own data by sending illogical observation data.

Leave a Reply