Stream: implementers
Topic: Functional ACK?
Jose Costa Teixeira (Sep 05 2017 at 14:09):
Hi. What is the way to provide a "functional" ACK using REST? Example: I POST a record of a medicationAdministration with a medication as a contained resource. If the product code is not known in the receiving system, how should we say "We received this record, but this product does not exist in our formulary and we have no way to figure it out"?
John Moehrke (Sep 05 2017 at 14:10):
Use of OperationOutcome
Jose Costa Teixeira (Sep 05 2017 at 14:11):
That's it, thanks!
Jose Costa Teixeira (Sep 05 2017 at 14:24):
ah wait... in terms of communication how does that work?
There are two times: 1. immediate response, saying "OK, i got this" and another one - may not be at the same time - that says "well, remember i said it was ok?.. Well, here's the thing..."
Jose Costa Teixeira (Sep 05 2017 at 14:25):
pretty much like this chat - i asked a question and you replied, it computes, so I say OK. Then I see that in some cases it may not be sufficient.
Lloyd McKenzie (Sep 05 2017 at 15:06):
From a RESTful perspective, once you say "create successful" or "update successful", etc., there's no take-backs. The expectation is that the processsing of the create/update/delete is done synchronously. If you're talking about a request for fulfillment, then you can have Task and you can update the state of the Task to say "cancelled" if you had previously accepted
John Moehrke (Sep 05 2017 at 15:19):
Yes, what Lloyd said... The exception is HTTP 202 "Accepted"; which is well defined as having no good and perfect solution. But 202 is a choice the server can make, and isn't all that unusual when servers are under-load. As Lloyd points out , http REST is intended to be a synchronous protocol. This is where much of the 'simplicity' comes from. Thus, recommend the server do all the validation it needs to do before it returns a 2xx; using 202 only when it is a server overloaded condition that it knows it will recover from and ultimately persist.
Jose Costa Teixeira (Sep 05 2017 at 15:27):
Ok, so I would use a task. If i get it right:
1. I POST and I get a 201. I go about my other business.
2. Later, if the server sees an issue, the server can decide to create a Task for that administration. It's up to the client to check if there are any issues with any Tasks associated with one of the administrations the client previously POSTed
Jose Costa Teixeira (Sep 05 2017 at 15:27):
is that it?
Lloyd McKenzie (Sep 05 2017 at 16:15):
FHIR doesn't allow 202 as a response
Abbie Watson (Sep 06 2017 at 15:18):
Take a look at the Touchstone tests. They provide the proper HTTP response codes for all the FHIR endpoints. They vary depending on failure, error, success, authorization, and other circumstances. It's often the case that a 201 response is used, but not always... Bundle responses sometimes get a 200 code; and a successful query that just happens to return 0 matches will sometimes serve up a 204.
Here is an example file that conforms to Touchstone tests that will give you a sense of what the ACK responses should look like:
https://github.com/clinical-meteor/hl7-resource-patient/blob/master/server/rest.js
Igor Sirkovich (Sep 06 2017 at 20:05):
@Jose Costa Teixeira , you might consider using Messaging if you need to support asynchronous operation: http://www.hl7.org/fhir/STU3/messaging.html#2.24.3.2
Jose Costa Teixeira (Sep 06 2017 at 20:09):
Thanks @Igor Sirkovich . I would not look at that because we are looking for simple / straightforward communications but actually it does seem interesting. Thanks for pointing out.
Last updated: Apr 12 2022 at 19:14 UTC
