FHIR Chat · Patch operation · implementers

Stream: implementers

Topic: Patch operation


view this post on Zulip Shlomy Reinstein (Nov 17 2016 at 12:25):

In DSTU2, an update operation creates a new version of the resource with the contents that were provided in the update, without looking at the previous version. For example, if I want to update the name of a patient, I can't send an update operation with just the name - I must first read the current version, then modify the name and send the update request with all the contents. Is there Patch functionality planned for STU3, so I don't need the entire transaction of read-modify-write? (i.e. tell the server exactly what changes I want to make, and it will apply the "patch" on its own)

view this post on Zulip Patrick Werner (Nov 17 2016 at 14:53):

Hi @Shlomy Reinstein
yes this is part of STU3: http://build.fhir.org/http.html#patch

view this post on Zulip Shlomy Reinstein (Nov 17 2016 at 15:42):

Thanks!

view this post on Zulip Thomas Herchenroeder (Nov 21 2016 at 20:13):

It's sort of sad that the FHIR designers left this more functional approach where you wouldn't change a resource, but rather create a new version of it. Yes, it puts a bit more load on the client, but it would bring us a step further away from "place-oriented programming" (which looks like a pervasive issue in our industry).

view this post on Zulip Grahame Grieve (Nov 22 2016 at 04:24):

so I think he's wrong; if you go to a non-place orientated programming approach, you move the core problem from 'managing the space' to 'identifying the fact', given that you can no longer identify the fact by it's location. And I say this as someone who built a very large commercially successful insert only database

view this post on Zulip Grahame Grieve (Nov 22 2016 at 04:26):

and in fact my server is almost an insert database. And FHIR is almost an insert only database, where the resource id (http://fhir3.healthintersections.com.au/open/Patient/1) is a partial identity, and the specific versions of the resource are the real identities, and resource versions are immutable facts.

view this post on Zulip Grahame Grieve (Nov 22 2016 at 04:26):

and my server PATCH operation is a facade over that fact

view this post on Zulip Grahame Grieve (Nov 22 2016 at 04:27):

this works just like a version control system. Though maybe if that's all he's saying... that's what we did, and PATCH is just a facade method on it. Which is useful

view this post on Zulip Thomas Herchenroeder (Nov 22 2016 at 09:43):

So PATCH is returning a new version of the resource? That would be nice. But like with version control systems, you might run into merge issues when you are not patching the latest version of the resource.

view this post on Zulip Grahame Grieve (Nov 22 2016 at 10:05):

you can only patch on the latest version

view this post on Zulip Grahame Grieve (Nov 22 2016 at 10:06):

FHIR lets you look at things either way - a version control/insert only sequence, or a record operation. We could never commit to supporting the first only until everyone rewrites their systems...


Last updated: Apr 12 2022 at 19:14 UTC