FHIR Chat · Request Idempotency · implementers

Stream: implementers

Topic: Request Idempotency


view this post on Zulip Lonnie King (Aug 06 2020 at 01:40):

I see that the FHIR spec has recommendations for how to handle resource idempotency but I'm curious to know if there are any recommendations for handling HTTP request idempotency.

My team has some thoughts on how we might do it, but we'd like to follow precedent if there is any. Does anyone here have any experience with this or recommendations?

view this post on Zulip Grahame Grieve (Aug 06 2020 at 01:48):

that's a pretty wide open question. can you be more specific?

view this post on Zulip Lonnie King (Aug 06 2020 at 02:40):

Sure, happy to spell this out in more details. I'll also include some additional thinking in terms of solutions.

Scenario: I operate a FHIR server and one of my (external) clients accidentally sends the same HTTP POST request to my server twice.

There are cases where this might affect the patient's clinical outcomes, and I want my application to provide some functionality that will allow a client to uniquely identify a request (or possibly resources within that request) so that I can avoid the accidental creation/duplication of resources. I understand that POST is not, by default, an idempotent operation according the the HTTP spec, but in instances where it could be harmful to a patient's safety I should want to provide some functionality to protect against this.

Using Request Idempotency
Some banking APIs handle it this way. Which provides a nice clean way for my application to handle duplicate request identification at the transport layer. I will know immediately if this request has accidentally come to me twice and can respond before I even look at the request body.

Using Resource Idempotency
Another way to approach this might be to allow clients to supply their system's unique identifier as the URI in a Meta for each resource. I could store and check these URIs at creation time for any resource and only create resources that have unique URIs provided.

For a complete solution, I might choose to implement both of these to solve both problems of Resource and Request idempotency.

Would love to get some thoughts and feedback on this. Thanks!

view this post on Zulip Lloyd McKenzie (Aug 06 2020 at 03:25):

Have you looked at Conditional Create? (https://build.fhir.org/http.html#ccreate)

view this post on Zulip Grahame Grieve (Aug 06 2020 at 03:30):

one of my (external) clients accidentally sends the same HTTP POST request to my server twice

use a payload header is interesting, but implies that that the problem happens in the stack. I'm interested to know if other people have this problem or how they've solved it

view this post on Zulip Lonnie King (Aug 06 2020 at 03:40):

Lloyd McKenzie said:

Have you looked at Conditional Create? (https://build.fhir.org/http.html#ccreate)

Yes, I have looked at this, but I'm not sure how it could solve the problem described in my scenario as the client has no knowledge of the IDs for the resources when it creates the duplicate requests. Maybe there is something I'm missing?

view this post on Zulip Lloyd McKenzie (Aug 06 2020 at 03:43):

You wouldn't use the 'id' - but you might use an 'identifier' or some other element that you know to be unique.

view this post on Zulip Lonnie King (Aug 06 2020 at 03:50):

Lloyd McKenzie said:

You wouldn't use the 'id' - but you might use an 'identifier' or some other element that you know to be unique.

Oh, yes, I think I understand. That's exactly what I'm suggesting in my description for Using Request Idempotency.

I think you're suggesting that, more concretely, I use something like If-None-Exist: <requiest-identifier> to identify unique requests coming into the application and respond appropriately. Did I understand you correctly?

view this post on Zulip Lonnie King (Aug 06 2020 at 03:51):

I'm also very curious to know if anyone has opinions/thoughts on the suggested use of the Meta.uri property as a resource idempotency key.

view this post on Zulip Michael Lawley (Aug 06 2020 at 03:55):

I would suggest If-None-Exist as well. You need to have some (client side) notion of uniqueness (ie what is a key for the resource being created), and then map that into the _search_ criteria.
I'm not sure what property Meta.uri is? https://www.hl7.org/fhir/resource.html#Meta

view this post on Zulip Lonnie King (Aug 06 2020 at 04:06):

Michael Lawley said:

I would suggest If-None-Exist as well. You need to have some (client side) notion of uniqueness (ie what is a key for the resource being created), and then map that into the _search_ criteria.
I'm not sure what property Meta.uri is? https://www.hl7.org/fhir/resource.html#Meta

Sorry, I need to correct that. I meant to say the Meta.source property which is of type uri.

view this post on Zulip Lloyd McKenzie (Aug 06 2020 at 04:49):

Meta.source is not expected to be unique across instances. In fact, that would defeat its purpose which is to act as a quick flag about where a record originated.

view this post on Zulip Grahame Grieve (Aug 06 2020 at 05:36):

it might be unique in particular circumstances, and it might meet the requirement, but it feels inherently problematic compared to something more directly linked to a business identifier.

view this post on Zulip Grahame Grieve (Aug 06 2020 at 05:36):

but that assumes there is such a thing. I presume our working use case is prescribing a medication?


Last updated: Apr 12 2022 at 19:14 UTC