Stream: implementers
Topic: Server-side alteration of resource
Andrew Patterson (Sep 08 2017 at 06:46):
Say we had a very opinionated server that wanted to put some rules on FHIR resources stored on it. Is it acceptable behaviour for the server to make alterations to a Resource as it is being put onto the server?
To some extent it already does this with changes to metadata like last updated. Could it also add a code to an Observation? Generate a narrative and insert it into the resource (if the narrative was empty)?
If it did make these alterations, would it be required to make the altered resource be a new version? So client saves resource at version 5, server notices that it can helpfully generate a nice narrative - can it add the narrative to version 5 on save, or does it now need to generate a version 6 with narrative?
Richard Townley-O'Neill (Sep 08 2017 at 07:11):
Pretending it is the same version sounds very nasty.
Someone could reasonably complain, "That is not what I sent".
Grahame Grieve (Sep 08 2017 at 09:38):
it's allowed - we very carefully don't say that this can't be done
Grahame Grieve (Sep 08 2017 at 09:38):
but that doesn't make it wise
Andrew Patterson (Sep 08 2017 at 09:41):
Do you mean not wise in all scenarios, or just not wise to fix up say version 5 of a resource on the server as it is being saved and still call it resource 5?
Andrew Patterson (Sep 08 2017 at 09:42):
I presume there might be lots of scenarios where a server might receive version 5 of a resource and decide for whatever business reason that something needs to change - and have the server itself create version 6
Andrew Patterson (Sep 08 2017 at 09:42):
That wouldn't be 'unwise'?
Grahame Grieve (Sep 08 2017 at 09:42):
more the first. The server can alter as it saves. it doesn't have to update the version, but that might be useful to underscore that it changed it.
Grahame Grieve (Sep 08 2017 at 09:43):
I was generally saying, the server altering the semantics as it saves the resource can be an unwise thing to do.
Jens Villadsen (Sep 08 2017 at 09:46):
the clean approach is to increment the version as you make alterations. the server alterations is just another version increment. That also makes auditing a lot more simple
Jens Villadsen (Sep 08 2017 at 09:46):
and your client will not be surprised
Andrew Patterson (Sep 08 2017 at 09:47):
Ok thanks. I think if I did do it I would definitely do a bump version and server to server POST.
Lloyd McKenzie (Sep 08 2017 at 21:28):
Altering is going to be pretty common actually - lots of servers won't be able to store all extensions received, or possibly even some of the core elements. A bigger change is adding new elements or change data values. That'll be less common, but is posisble if the system doesn't "trust" the sender for certain data, or if it has supplemental data it chooses to integrate. Doing any of these things will break any digital signatures that happen to be present though. The possibility of this occurring is one of the reasons we support echoing back the stored resource as part of the response to a 'create'.
Michael Lawley (Sep 08 2017 at 23:47):
I was pondering this question with regards to fields like CodeSystem.count which may differ from the actual number of defined concepts (and where CodeSystem.content == complete)
John Moehrke (Sep 10 2017 at 23:17):
Is the unaltered (submitted) 'version' made available as a first version, or somewhere? I would recommend a Provenance record explain this sever modification and why. (Provenance.agent = server identity)
Andrew Patterson (Sep 10 2017 at 23:21):
Yeah, I think in my head there are 2 approaches - an almost silent 'fixing' of something submitted - I'm pretty wary of that. And the 2nd approach would just be to accept the submitted version as per normal, and then the server itself submit a new version with its 'fixes' (with as you say a proper Provenance recorded with server as agent)
Last updated: Apr 12 2022 at 19:14 UTC
