Stream: implementers
Topic: RESTful create and processing differences
Alexander Henket (Nov 29 2021 at 09:06):
We have situations where BloodPressure is sent as 1 Observation with systolic/diastolic components to a system that cannot handle that this way and needs to split that up into 1 systolic and 1 diastolic Observation. How would such a system respond to a create request? Can you respond with 2 HTTP 201 statuses each carrying the Location/ETag of the thing that is created? If the create came in a Bundle you could do that.
Or is this a clear sign that RESTful is not the answer?
René Spronk (Nov 29 2021 at 09:20):
REST is client driven orchestration, so IMHO the server should refuse the create (422), the Observation being submitted is not conformant to its profiles. The server could expose an operation to do the conversion, this could then be used by a client. Or the client would have to convert before doing (a bundled) create.
Note that a server could just store the bloodpressure observation (or fake that it is storing), respond with one single 201 created, and subsequently split that observation into two other observations (and delete the non-splitted/original version of the observation). A server doesn't have to guarantee the availability of resources for which it has sent a 201. Not a very nice solution, but IMHO technically correct given the specs.
Alexander Henket (Nov 29 2021 at 09:22):
So how would a server that responds with 201 but then not actually stores it that way, deal with the SHALL on sending Location/ETag in the FHIR http spec for create?
Alexander Henket (Nov 29 2021 at 09:24):
Would it be accepted send just 'something', as long as you guarantee it does not lead to anything else, but just dead-ends in a 404 if you were ever to do a read on that Location?
Alexander Henket (Nov 29 2021 at 09:27):
Note that on this infrastructure we mostly do query, not read. So having to support a read here, is not the first requirement.
Grahame Grieve (Nov 29 2021 at 09:38):
contained resources?
Alexander Henket (Nov 29 2021 at 09:55):
Not sure what you ask, but the create is done with an Observation with 2 components. One systolic, one diastolic. The persistence happens in a non-FHIR store in what could be retrieved through query as 2 separate Observations.
Are you asking about Observation.contained in the initial Observation or are you suggesting a pseudo Observation as response to the create that holds the the two actual Observations as contained resources?
René Spronk (Nov 29 2021 at 10:18):
"Would it be accepted send just 'something', as long as you guarantee it does not lead to anything else, but just dead-ends in a 404 if you were ever to do a read on that Location?" - to me, a server could indeed do this. In such cases a client would have to assume that although a resource may have existed at that location, that such a resource no longer exists. What business rules a server have for deleting a resource is up to the server, and when that server executes that business logic (after a millisecond, or a year) is also up to a server.
Alexander Henket (Nov 29 2021 at 10:42):
I think I can work with that. Somehow though, I feel we need to rewrite future creation requests towards operations or messaging. The RESTful paradigm and the last 30 years of messaging + over 15 years of V3 does not compute too well.
Vassil Peytchev (Nov 29 2021 at 18:38):
Can you send an OperationOutcome with the 201 to show the resources as they were actually created?
Alexander Henket (Nov 29 2021 at 23:14):
Is your question whether or not the spec allows that or if the server potentially could?
Rik Smithies (Mar 18 2022 at 15:48):
@Alexander Henket @Vassil Peytchev I don't believe an OperationOutcome can accompany a 201, but would be interested to hear otherwise.
Old thread, but I have a somewhat similar issue:
Client sends an Encounter as a POST. This is saved and also triggers business logic that causes the sever to reflexively create an EpisodeOfCare. The EpisodeOfCare is not directly related to the Encounter however, but some other care that will happen later (by someone else).
The issue is how to notify the client of the id of that new EpisodeOfCare. OperationOutcome does not seem to be possible. The likely solution is to put a reference to the EpisodeOfCare into the newly saved Encounter (probably as an extension, since it is "an" EpisodeOfCare and not "the" EpisodeOfCare for that encounter).
This id is a like a second return value, and not a permanent feature of the Encounter (and would likely be erased if the client PUT the Encounter again).
Alternatively the client could just do a search for the new EpisodeOfCare, but I would prefer a positive statement of the id to be returned from the Create.
Kevin Mayfield (Mar 18 2022 at 16:02):
an event? via a subscription
René Spronk (Mar 18 2022 at 16:19):
The HTTP response contains 'what the server has done' - if it creates 2 resources as a result of a post of 1 resource, shouldn't the response then be a Bundle with 2 resources in it? This stretches REST to its limits, but kind of fits with FHIR. Question to the REST pundits whether this is a no-go in principle.
If the Encounter (if it's the only thing in the response) in the response has populated a reference to the newly created EpisodeOfCare, that minimalistically serves as a notification. The client could also subscribe to new EpisodeOfCares (where the client e.g. is part of the associated careTeam), to have a more explicit notification.
David Pyke (Mar 18 2022 at 16:57):
You can request that the create returns OperationOutcome but getting the actual resource in return is not supported behaviour. To get an OperationOutcome, just specify it as per: https://www.hl7.org/fhir/http.html#ops
That's a preference, not a hard requirement, though.
Rik Smithies (Mar 18 2022 at 17:01):
but I think that is instead of the created Encounter resource not as well as it. Ideal behaviour is to receive the original created resource, plus something else.
Rik Smithies (Mar 18 2022 at 17:03):
An OperationOutcome with 2 resource references would work, but it makes the first part of the create work differently, which is not ideal.
Vassil Peytchev (Mar 18 2022 at 19:13):
Rik Smithies said:
An OperationOutcome with 2 resource references would work, but it makes the first part of the create work differently, which is not ideal.
Which first part of the create?
In general, for presented use case (a create of Encounter also creates an EpisodeOfCare not linked to the created Encounter) I see three possible paths:
- In the case where the server always executes this business logic, the IG specifies that the client must always add the preference of getting an OperationOutcome as the response of the Encounter create, and the OperationOutcome contains the references to both the Encounter and the EpisodeOfCare
- In the case where you want to describe the business logic as a service, so that it can be implemented by various servers in addition to a simple Encounter create, then you define an operation.
- In the case where the business logic is part of multi-step workflow where the state is represented via a Task resource, the output of the Task can point to the two resources
Rik Smithies (Mar 19 2022 at 15:13):
@Vassil Peytchev ~Which first part of the create?
The part where the client directly causes an Encounter to be created.
If on most systems that gives 201 and echoes back a created resource with an id filled in (and headers), it would be unhelpful if that changed just because some other additional process happens on one server, some or all of the time.
The convenience of being told about that should ideally not come with inconvenience of having to work in some special mode.
This makes 1 and 2 less attractive. For 3 there is no Task anticipated.
Last updated: Apr 12 2022 at 19:14 UTC
