FHIR Chat · conditional updates · implementers

Stream: implementers

Topic: conditional updates


view this post on Zulip Brian Reinhold (Sep 13 2016 at 12:41):

How much can one specify in a conditional update?
Can I specify a conditional update with a path and if the resource does not exist will the path be maintained?
For example
PUT https://baseURL/PCHA/Patient/patientId_authCode/Device/systemId/Observation?identifier=Observation.identifier.value
Note that there is no resource at https://baseURL/PCHA/Patient/patientId_authCode/Device/systemId/. In fact the entire path may not exist.
Will the resource be created such that
GET https://baseURL/PCHA/Patient/patientId_authCode/Device/systemId/Observation?identifier=Observation.identifier.value
will return the resource?

view this post on Zulip Simone Heckmann (Sep 17 2016 at 21:45):

I don't think so. The condition's purpose is to determine whether a matching resource already exists on the server, if yes -> update, if no -> create a new one. I don't think that the condition is supposed to have any effects beyond that. It's just a PRE-condition...
I wonder: what's your use case?

view this post on Zulip Jonas Toft (Apr 20 2021 at 07:52):

I would like to do an update on a Task resource based on a criteria. From the docs I can see that the resource is created if there is no match on the criteria. https://www.hl7.org/fhir/http.html#cond-update. I want to do the update if the criteria is matched or not do the update at all. Any suggestions?

view this post on Zulip Lloyd McKenzie (Apr 20 2021 at 13:15):

In general, you wouldn't want to do an update without querying first - and if you do that, you'll know if it exists or not.

view this post on Zulip Lloyd McKenzie (Apr 20 2021 at 13:15):

What's your use-case for updating without querying?

view this post on Zulip cristi mihailescu (Apr 21 2021 at 07:23):

Hi Llloyd,

This is the scenario the I and Jonas have:

  1. We're accessing the FHIR Repository from 2 clients
  2. On client 1, we choose a PractitionerRole ( let's say it has the version "1" )
  3. On client 2, we're updating the PractitionerRole data ( it goes to version "2" )
  4. We're updating the Task's owner to the PractitionerRole that we've selected on step 2

We are looking for a constraint ( as "conditional update", or by specifying a ifMatch etag inside a bundle transaction (?) ) that can fail the update of the Task if its owner PractitionerRole was changed meanwhile. Without doing an extra query, if possible.

view this post on Zulip Lloyd McKenzie (Apr 21 2021 at 16:33):

I don't understand why changing the PractitionerRole should impact updating the Task. You could have the reference in the Task be version-specific, but if it was, the fact it had been subsequently updated wouldn't interfere with the ability to update a resource that references it.

view this post on Zulip cristi mihailescu (Apr 22 2021 at 04:00):

We can mark, by a Boolean extension, that the PractitionerRole cannot be assigned to a Task. If this occurs while we are changing Task's owner, it should somehow fail / signal the client - at least this is our scenario.

view this post on Zulip Lloyd McKenzie (Apr 22 2021 at 20:14):

My leaning would be to handle that as business rule processing on the server side. I.e. when you receive the request to update the Task, query at that point whether the Practitioner is 'available'. Collision detection, as defined with in the FHIR spec, only works on the resource being changed, not on resources being referenced.

view this post on Zulip cristi mihailescu (Apr 23 2021 at 09:07):

Thank you for your reply, Lloyd. You've enforced our findings.

We're accessing the FHIR server directly, so a way to do collision detection for the referenced resource could be on the FHIR server, or on a middle layer .

view this post on Zulip Luke Smith (Nov 08 2021 at 19:06):

Hello all -- I think it makes sense that only the resource in question is updated conditionally. On the point, though, of "updating without querying" I think it's key to realize that conditional update solves a problem that querying beforehand cannot -- specifically, concurrent access to the resource. Querying first doesn't guarantee that the resource won't change before your next request to write something; conditional update does (or at least it should).

view this post on Zulip Luke Smith (Nov 08 2021 at 19:08):

Does anyone know who's working on the process of formalizing/adopting conditional update as part of the spec? @Daniel Tam and I are interested on behalf of One Medical Group

view this post on Zulip Lloyd McKenzie (Nov 15 2021 at 03:17):

Actually, what most systems that support update do is leverage the If-Match header, as described here. That's distinct from conditional updates.

view this post on Zulip Luke Smith (Dec 06 2021 at 20:30):

If-Match seems good if you know the ID of an existing the resource, but there are cases where you don't and still want to avoid inserting a logical duplicate

view this post on Zulip Paul Church (Dec 06 2021 at 20:32):

Could this be satisfied by a conditional update using If-Match: *, if we expanded the functionality of If-Match to support that?

view this post on Zulip Luke Smith (Dec 06 2021 at 21:25):

not sure exactly what If-Match * would be, but basically what's required is "don't insert this if anything matches specified search"

view this post on Zulip Luke Smith (Dec 06 2021 at 21:25):

where converting to and update of the found matching resource is OK

view this post on Zulip Luke Smith (Dec 06 2021 at 21:29):

otherwise you're limited to resolving conditions where you know the singular ID of the resource, not logical duplicates that happen to have different IDs you're trying to reconcile ... admittedly this is an border case

view this post on Zulip Luke Smith (Dec 06 2021 at 21:29):

however it's something that has come up for us

view this post on Zulip Lloyd McKenzie (Dec 07 2021 at 03:14):

I'm not really following. You shouldn't be performing an update unless you've previously queried from that system - which means you'll know both the id and the version.

view this post on Zulip Luke Smith (Dec 13 2021 at 22:17):

What if what I am trying to verify is that nothing matching a search exists

view this post on Zulip Luke Smith (Dec 13 2021 at 22:18):

that's the thing

view this post on Zulip Luke Smith (Dec 13 2021 at 22:19):

I think that is basically the key differentiator / motivation for conditional update

view this post on Zulip Lloyd McKenzie (Dec 13 2021 at 23:07):

Ok. So you have a copy of the current version of the existing record, and you'll check that the record being updated hasn't changed. However, you're also wanting to ensure that some other query returns no results before the update proceeds? If that's correct, can you provide an example of the sort of situation where you'd want to do that?


Last updated: Apr 12 2022 at 19:14 UTC