Stream: implementers
Topic: QuestionnaireResponse and OperationOutcomes?
Eric van der Zwan (May 03 2016 at 06:43):
I was wondering what a fhir server should return when it receives a QuestionnaireResponse with logical errors in the answers. For example i want to know the maximum systolic blood pressure and the minimum blood pressure of the 1ste 24hours of ad admittion. What if the answer of the maximum blood pressure is lower then the minimum blood pressure? I don't want to reject the QA but i would like to send back a response with some kind of message that a problem has been detected. Should i use the OperationOutcome resource for this?
Lloyd McKenzie (May 03 2016 at 07:40):
OperationOutcome would be the appropriate mechanism. You can use it to send both errors and warnings
Brian Postlethwaite (May 03 2016 at 07:56):
This is an interesting result.
Would this mean that I receive the OperationOutcome resource in the returned content that has the location of the actual saved QuestionnaireResponse resource in the headers?
Lloyd McKenzie (May 03 2016 at 08:00):
I think there's a header to return the OperationOutcome in, actually
Pascal Pfiffner (May 03 2016 at 16:12):
Do you know which header that is, @Lloyd McKenzie ? Haven't found it on the HTTP page. OperationOutcome otherwise should only be returned on 400+ (or within a Bundle) I think.
Grahame Grieve (May 03 2016 at 16:45):
I don't know what it is. There's a provenance header, but I think Lloyd is indudging in wish ful thinking on this one ;-)
Lloyd McKenzie (May 04 2016 at 01:14):
I remember it being talked about. It's possible it was never defined.
James Agnew (May 04 2016 at 01:16):
Yeah, this has been discussed but never turned into a thing...
I think it's risky too. I have experimented with putting validation results in a header, and it seems like a lot of servers, proxies and clients don't like very long header values. I don't know that I think it's a good idea after all that.
Brian Postlethwaite (May 04 2016 at 01:18):
My understanding was if you wanted to return warnings then you need to return the OperationOutcome resource. The header will still give the location of the actual resource that was created.
This is then consistent with error conditions.
Brian Postlethwaite (May 04 2016 at 01:18):
(I think)
Eric van der Zwan (May 04 2016 at 09:42):
I think James is right in that including a OperationOutcome in a header is dangerours since it can be large for a QR (in a bundle with other resources). Since people can fill in the QR the risk of multiple errors is very possible. I've about 600 checks on the data... Although it would be hard to fail them all, 10 or 20 issues can easily found. Can i place the operationOutcome in de body of the message? Should i use something else?
James Agnew (May 04 2016 at 10:57):
I would just go with Brian's suggestion of returning an OperationOutcome with the warnings. If you need the stored QuestionnaireResponse for some reason afterward, you could always fetch it in a separate operation, but you shouldn't need that anyhow unless your server is modifying it in some way before saving it.
Brian Postlethwaite (May 04 2016 at 11:46):
And clients should be able to handle this anyway, as that is what can occur if you use the Prefer header.
The status of the return would also have a different result (for the errors, but I guess is a 201 for where there are warnings)
Brian Postlethwaite (May 04 2016 at 11:46):
You'd just have to know to look for them.
Brian Postlethwaite (May 04 2016 at 11:47):
For our client, we actually call the $validate operation before saving which is expected to return the operationoutcome, so don't normally expect to have issues on the actual save.
Brian Postlethwaite (May 04 2016 at 11:47):
http://hl7.org/fhir/http.html#2.1.0.10.1 is the section covering the reject updates calls
Brian Postlethwaite (May 04 2016 at 11:55):
On looking at this list, the 403 is not actually Not Authorised, it is forbidden. 401 is Unauthorized. 403 is forbidden.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Will log it.
Are any of the other servers returning 401s or 403s?
(I notice grahames server happily returns 401s for unauthorised as it should)
Pascal Pfiffner (May 05 2016 at 18:00):
I'm not sure I like the proposal of returning OperationOutcome for status < 400. The _Prefer_ header helps with that, server either returns nothing or the full resource. It'd be bad to sometimes receive something entirely different.
I'm also not sure what the goal is, @Eric van der Zwan. If you detect said problem, do you still store the QR but want to let the client know that there was a problem? Then, what is the client supposed to do with that information? Fix it and update? Inform the user and let the user decide? Seems to me you could either reject the QR, and return that OperationOutcome you want, or accept as-is. Everything in between makes stuff complicated.
Brian Postlethwaite (May 05 2016 at 20:33):
The implementer needs to handle the cases where the result is the OperationOutcome anyway for the error scenarios.
Brian Postlethwaite (May 05 2016 at 20:34):
The dotnet client handles this for you and grabs stashes it away, and if you want the full resource, it goes and gets it for you.
Lloyd McKenzie (May 05 2016 at 20:54):
There are lots of situations where a create or update might have "succeeded" but not been applied exactly as the sender might have expected/desired. Getting back an OperationOutcome with warning messages explaining what happened and why is a lot more useful than having to compare the returned resource with the submitted resource on a node-for-node basis and having to guess as to why the discrepancies exist
Pascal Pfiffner (May 05 2016 at 22:59):
Brian, what I meant is that on a create with < 200, the server either returns the resource or nothing. 400+ possibly an OperationOutcome. Sure, easy for a client to implement, but it gets a bit ugly IMHO with all the possibilities.
Lloyd McKenzie (May 06 2016 at 17:14):
But how do you handle situations where a create is "successful", but perhaps not as successful as intended/expected and the server wants to communicate back the nuances of what happened? (E.g. "I created the patient, but the address didn't pass validation against our postal database" or "The encounter you were linking to couldn't be resolved" or "You don't have authorization to record phone numbers, so we dropped that information")
Grahame Grieve (May 06 2016 at 20:54):
what situations are those? Has anyone ever seen those in a real world context?
Lloyd McKenzie (May 06 2016 at 23:23):
I know of systems that pass back references to DDI on successful creation of a prescription.
Eric van der Zwan (May 09 2016 at 07:02):
My QR will contain information about Intensive Care admissions. Patients can have very extreme values, even at a level that it becomes questionable if it is real. For example we defined a domain for serum bicarbonate as >=0 <60 mmol/L. When we received a value of 67 mmol/L a report was send back to the hospital. They could confirm the measurement was correct, and they had multiple. Now we have an extra domain of >=60 <70. A value in this domain will be accepted with a warning 'the value was unussually high'. So a hospital can check it again to make sure.
In this case i will accept the QR because it has more valuable information then just the one item. A heartrate 0-300 will be accepted without warnings, a heartrate between 300-350 are accepted with a warning, >350 the value will not be accepted and will be changed to null. The QR will be accepted and saved, the response would contain warnings of values which a unussually high or values which were changed to null.
I will probably almost never reject a QR. The hospitals have the possibility to correct the issues.
Grahame Grieve (May 09 2016 at 08:38):
A bicarb of >60 mmol/L? scary. but I don't follow this generally - so what if you return a warning? the client just ignores it, and there actually was no warning... The warning has to be inline....
Eric van der Zwan (May 09 2016 at 09:05):
If the client just ignores the warnings, there is no point. The goal of sending warnings is to inform the client and hopefully correct the values, though we can not forced them. I don't know how the warnings will be shown to a user (if all) or it will be shown to a manager?
Eric van der Zwan (May 09 2016 at 09:06):
In general my question would probably be: How can you give data-quality feedback in a manner that it is possible to update?
Grahame Grieve (May 09 2016 at 09:20):
i'm not sure whether you are asking an application design question or an interoperability question
Eric van der Zwan (May 09 2016 at 09:30):
The questionnaireResponses will be created by EPR-systems. I would like the EPR-systems to handle the warning in a way that somebody can have another look at it and make sure the values send are correct or make adjustments to correct them. I think the question is both: who would you show you user the warnings (application design) and how should you return data-qualitity information if a questionnaireResponse is processed in a way an EPR can handle it in a uniform manner (interoperability).
Brian Postlethwaite (May 09 2016 at 14:36):
We are handling this in our system by performing these types of updates in the $validate operation that is called prior to saving the questionnaireresponse data.
Then users can be notified and the messages/warnings displayed to the users.
Ewout Kramer (May 11 2016 at 15:18):
That's certainly not inline, or would the $validate add this information inline in the QR?
Brian Postlethwaite (May 11 2016 at 19:35):
$validate always returns an operationOutcome, and we include the location in the QR of where the issues are.
Brian Postlethwaite (May 11 2016 at 19:36):
(by describing the llinkid of the question - I guess that's not a part of the spec at this point)
Eric van der Zwan (May 17 2016 at 06:32):
calling $validation prior to saving would make the communication more complex and there is a danger: If $validation has found problems and the QR wasn't saved, how can you be sure it will be send again? I would prefer to save it, with warnings or emptying fields in case of errors. This way i know there is a QR. In other words: If my QR contains a ICU admission, rejecting it would mean i miss a admission.
Brian Postlethwaite (May 30 2016 at 02:47):
$validate is not an instruction to save the record, its a chance for the client to see if there are issues with it, that can then be easily shown to a user.
This may also be returned from the save call too.
Last updated: Apr 12 2022 at 19:14 UTC
