Stream: implementers
Topic: considered puristic or not
Jens Villadsen (May 13 2019 at 13:08):
I'm trying to gather some community input on the general use of the REST API that I can only imagine that most FHIR implementations contain/support. The question is this: "Whenever your application supports parts or the entire CRUD spectrum on a give resource type, how often do you choose to embed business logic and/or server side effects in that particular operation that modifies or ignores parts of the content from the request - opposed to make a FHIR custom operation instead?" - This is particularly interesting for CREATE and UPDATE operations.
René Spronk (May 13 2019 at 13:30):
IMHO any large scale implementation which processes (potentially conflicting/overlapping) data from multiple sources will have to do some server-side filtering. $process-message comes to mind (for those who use FHIR Messaging). Like Jens I'd be curious to hear what server implementers have done with this regard.
Jens Villadsen (May 13 2019 at 13:32):
In a project im currently engaged in we are trying to be puristic about it - meaning that side effects may be present, but they have no or little impact on the resource posted by clients. Instead we have favoured PATCH support (with whitelisted paths) and custom operations
Michele Mottini (May 13 2019 at 13:45):
how often do you choose to embed business logic and/or server side effects in that particular operation that modifies or ignores parts of the content from the request
All the time because we are mapping to our data model that does not support all the data that _can_ be in a FHIR resource
Lloyd McKenzie (May 13 2019 at 14:46):
Some level of filtering will be pretty typical - due to persistence limitations, permission limitations and/or other business rules. That's why the response to creates and updates can echo back what actually got stored or return an OperationOutcome with warnings.
René Spronk (May 14 2019 at 10:35):
So as a server I can choose to ignore a PUT or POST as long as I return a warning (stating that I did ignore it) ? Kind of defeats the idea of a client-driven architecture..
Vadim Peretokin (May 14 2019 at 11:26):
I don't see why. 'client-driven' shouldn't be a blank cheque to create chaos
Jens Villadsen (May 14 2019 at 12:11):
Some level of filtering will be pretty typical - due to persistence limitations, permission limitations and/or other business rules. That's why the response to creates and updates can echo back what actually got stored or return an OperationOutcome with warnings.
Right - I understand that the content posted by the client is echoed back with potential changed content according to the servers business rules - but it just not seem right in a couple of scenarios. I would say that PATCH seems pretty obvious for partial content updating for obvious reasons - it is however a bit harder to implement. AFAIK, there isn't any structured way to document what part of a resource which is entirely determined by the server - or is there?
Jens Villadsen (May 14 2019 at 12:13):
How would you for instance tell a client that you can do all the updates to a patient resource that you can think of besides altering its identifiers as they are entirely controlled by the business logic of the server
Jens Villadsen (May 14 2019 at 12:15):
Or even more complex - how will you tell a client that they can update all of the patient instance, except the official name and the official identifier as they are governed by another system/the server - and if you try to it will be entirely ignored
Jens Villadsen (May 14 2019 at 12:16):
So as a server I can choose to ignore a PUT or POST as long as I return a warning (stating that I did ignore it) ? Kind of defeats the idea of a client-driven architecture..
ignore the entirety of the request or parts of it?
Jens Villadsen (May 14 2019 at 12:18):
What Im probably searching for here as a way to tell a client that parts of a resource is governed elsewhere and cannot be changed by the client itself in a structured fashion.
Jens Villadsen (May 14 2019 at 12:18):
@Lloyd McKenzie
John Moehrke (May 14 2019 at 12:18):
I think you are describing a level of policy driven StructureDefinition Profile that might be needed, but is not expressed today. Expressing these policy based things has not been our focus till this point. I could imagine it being an extension of a StructureDefinition Profile, much like you just narrative described.
Vadim Peretokin (May 14 2019 at 12:42):
Right now, I'd just document it as part of the profile: such and such field will be ignored if you try and change it.
Vadim Peretokin (May 14 2019 at 12:42):
(I'm kind of wary of stuffing even more obscure fields into ElementDefinition...)
Jens Villadsen (May 14 2019 at 13:13):
Putting stuff in a narrative usually do not catch my attention - icons, flags and gifs however do catch my attention. I guess my suggestion is to add yet another element in the ElementDefinition that says something like "Beware, gory details could be present here"
Grahame Grieve (May 14 2019 at 13:19):
That’d be awesome; we could set it to true on every element in the base spec ;-)
David Pyke (May 14 2019 at 13:20):
And for the Infrastructure resources, "Abandon all hope, ye who enter here"
John Moehrke (May 14 2019 at 13:21):
we do have the dragon http://build.fhir.org/assets/images/dragon.png
Jens Villadsen (May 14 2019 at 14:18):
Im fine with dragons ... but less could also be useful
Jens Villadsen (May 14 2019 at 14:22):
sort of ... https://img.memecdn.com/you-cant-touch-this_o_1016714.webp
Jens Villadsen (May 14 2019 at 14:22):
every dev loves kittens
Jens Villadsen (May 14 2019 at 14:24):
or https://d2gg9evh47fn9z.cloudfront.net/800px_COLOURBOX30078417.jpg
Lloyd McKenzie (May 14 2019 at 14:38):
We can always add more into CapabilityStatement - and we will always run into use-cases where it would be useful to include "just a bit more". The key question is what can we reasonably expect clients to computably adapt to when they see what the capabilities of a given server are and what's reasonable for them to adapt to at run-time when the server simply does what it does. The rules about "can't touch this" could easily vary by time, by who last touched the record or a miriad of other factors. You'll never be able to account for (or adapt to) all of them no matter how computable we make the capability declaration. As a result, clients will always need to deal with the fact that what they asked for and what happened won't necessarily be the same. If that's the case, then the argument for increased computability above what we have now is a tough (though not necesssarily impossible) sell.
Jens Villadsen (May 14 2019 at 14:42):
its a matter of stating that the selected attributes are not editable even if you try to/if you try to manipulate part of this content it is safely ignored. Its more of a nonfunctional use case - so the meaning is not crystal clear and it shouldn't be. It it about simply stating that this may be governed by another party
Jens Villadsen (May 14 2019 at 14:48):
The rules about "can't touch this" could easily vary by time, by who last touched the record or a miriad of other factors. You'll never be able to account for (or adapt to) all of them no matter how computable we make the capability declaration. As a result, clients will always need to deal with the fact that what they asked for and what happened won't necessarily be the same. If that's the case, then the argument for increased computability above what we have now is a tough (though not necesssarily impossible) sell.
Omitting a statement that says that you cannot expect to receive what you've posted or edited doesn't make it any better.
You can hide complexity (or don't state it in any way which is the current case) but you cannot make it go away
Lloyd McKenzie (May 14 2019 at 15:16):
"you cannot expect to receive what you've posted or edited" is a generic statement that applies to all FHIR interfaces. There's a whole section devoted to it in the spec. The question is what a client's supposed to do differently if they receive a more fine-grained indicator about the locations of the bits that are more likely to be ignored. There's no point adjusting the code that writes them given that there's no need to. The client can't count on such declarations appearing, so they still have to "check and see what actually stuck". Would there be some other benefit?
Jens Villadsen (May 15 2019 at 07:58):
Besides being more explicit? no
Last updated: Apr 12 2022 at 19:14 UTC
