Stream: implementers
Topic: Response to Create Interaction
Ken Sinn (Oct 08 2019 at 20:14):
I just noticed that from FHIR v1.6.0 to FHIR v1.8.0, there was a change in conformance language for the expected response to a Create Interaction:
The server returns a 201 Created HTTP status code, and SHOULD also return a Location header which contains the new Logical Id and Version Id of the created resource version (http://hl7.org/fhir/2016Sep/http.html#create)
The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version (http://hl7.org/fhir/2017Jan/http.html#create)
Does this imply that a FHIR Server's Create Interaction:
1) Must persist a copy of the FHIR Resource (e.g. that "Create" cannot by transient, and be used as transmission)?
2) Must support/enable the retrieval of that FHIR Resource after its creation (since the location must be available)?
Just noticed this change, and wondering if those implications are correct.
Thanks!
Grahame Grieve (Oct 08 2019 at 22:52):
I don't believe it implies either of those 2 things. But it does imply that the system understands that the location it returned thereafter refers to that resource, and it won't re-use the location for another resource, and it will understand future references to that location as being references to that resource.
None of that requires that the resource exist or be available, but it does imply that some record of the transaction needs to be retained (unless the location is a random UUID and you regard references to resources by UUID as likely a reference to a past resource and you don't care about integrity)
Ken Sinn (Oct 09 2019 at 00:00):
Thank you Grahame. Returning a copy of the newly created FHIR resource in the response body is only optional/situation, correct? For some reason, I had it in my head that a Create Interaction should always return a copy of the new resource, but I may be conflating it with a different conformance rule.
Lloyd McKenzie (Oct 09 2019 at 02:16):
The client has the ability to indicate whether it wants back a copy of the created record or not using the Prefer:return header, but that's a preference, not a requirement. In the end, the server can choose what to return - be that just the headers, or headers + OperationOutcome (if warnings) or headers + content. The latter is most important if the server has persisted something other than what was sent (e.g. dropped or transformed content in some way) to allow subsequent update without re-query.
Lloyd McKenzie (Oct 09 2019 at 02:17):
@Grahame Grieve Do we have language that says that a client needs to pay attention to the content echoed back on a create (or an update for that matter) when planning subsequent updates?
Grahame Grieve (Oct 09 2019 at 02:20):
no i don't think so. We couldn't make it a SHALL and it's self evident that it's probably a good thing to do
Lloyd McKenzie (Oct 09 2019 at 02:29):
I don't think it's self-evident. I suspect most clients don't twig to the fact that the stored content could be different from the submitted content. Most probably blindly assume that whatever's returned just echos what they submitted in the first place.
Grahame Grieve (Oct 09 2019 at 02:34):
We do have a whole page about that
Lloyd McKenzie (Oct 09 2019 at 02:38):
Is it pointed to by the HTTP spec?
Lloyd McKenzie (Oct 09 2019 at 02:46):
What I currently see is "The second asks to return the full resource. " - there's no explanation of why this could or should happen (independent of whether the client asks for it). We do point to the "varations between submitted and stored data" section a few places, but we don't have anywhere that specifically says:
a) if you've changed the content of the resource, you SHOULD return it;
b) if you receive the content of the stored source in a response and want to be able to do updates, you SHALL drive your update from the returned content, not the originally submitted content.
If we can't do a SHALL for the latter, then we should at least make it a SHOULD and note the danger involved in failing to do so (and perhaps suggest that servers that change data and don't trust clients to drive off the version in the response shouldn't include the etag and instead require systems to query for it)
Grahame Grieve (Oct 09 2019 at 03:58):
what's the danger? but sure, make a task to link to it from the appropriate place
Lloyd McKenzie (Oct 09 2019 at 04:35):
Danger is that data gets changed by the EHR, the client then sends an update and the changes aren't taken into account. For example, a clients submits a patient with an email address and two phone numbers. The server dumps the email address because it can't store emails. The client subsequently uses PATCH to correct the first phone number. If the client received an etag in response to the initial create and based their PATCH off the submitted record rather than the returned record, the PATCH would end up replacing the second phone number rather than the first .
Lloyd McKenzie (Oct 09 2019 at 04:43):
Yunwei Wang (Oct 09 2019 at 13:29):
GF#22770 also indicate that "a server MAY determine that create request matches an existing record with high confidence, and MAY return a 201, effectively making it look to the client as though a new resource had been created, even though the the "created" resource is actually a pre-existing resource."
Ken Sinn (Oct 09 2019 at 14:05):
The HTTP page https://www.hl7.org/fhir/http.html#create section points to Variations between Submitted data and Retrieved data
(http://hl7.org/fhir//updates.html) and transactional integrity (https://www.hl7.org/fhir/http.html#transactional-integrity)
Lloyd McKenzie (Oct 09 2019 at 15:47):
Yes - it points to those pages. But there's no normative wording in those pages. And there's no specific warning in the HTTP page that highlights the fact that paying attention to what comes back is important.
Lloyd McKenzie (Oct 09 2019 at 15:47):
(and why)
Ken Sinn (Nov 14 2019 at 16:07):
unless the location is a random UUID
Reading over the Create section https://www.hl7.org/fhir/http.html#create, it doesn't seem like a random UUID is allowed for the location header -- "the location SHALL contain logical id", in the format Location: [base]/[type]/[id]/_history/[vid].
Grahame Grieve (Nov 14 2019 at 19:59):
the id can be a random UUID
Last updated: Apr 12 2022 at 19:14 UTC
