Stream: implementers
Topic: Error Handling
René Spronk (Feb 17 2020 at 12:59):
Are you interested in Error Handling? :boom:
I've offered to speak to the topic of "Error Handling and Error Mitigation" at the upcoming DevDays in Cleveland OH. (For me personally this is a new subject, as a challenge to look at an issue in more detail then I'd normally do). Focus will be on HTTP status codes and OperationOutcome, plus mitigation (how could one have prevented these issues from occuring? any workarounds/solutions?). The talk won't be about server/client/software specific glitches, but tries to describe the common ground. I've seen a few FHIR implementation guides that also speak to this.
Question: what in your personal opinion, should be the URLs, concepts, issues covered by such a talk?
Medi Harsini (Feb 17 2020 at 13:25):
Isnt preventaion part of validation... I can understand they are very much inter related and perhaps finding such relationship and a way to systematically define that would the key
Lee Surprenant (Feb 17 2020 at 17:00):
You might already be planning it, but maybe you could cover the use of the Prefer header (for client-specified return and handling preferences) and the tradeoffs between being lenient or strict on the server.
For example, when a query comes in with unknown search parameters and/or unknown JSON fields.
For example, the spec recommends servers to drop unknown or unsupported parameters by default, but we've found that (in development at least) this leads to confusing results for newer clients who don't know to check the self link or look for warning in the search results.
René Spronk (Feb 18 2020 at 07:45):
@Medi Harsini Sure, prevention is part of it as well. Any mature error message should inform one as to how the error could have been prevented, or how the error can be mitigated once it has happened. Validation errors can be avoided by validating the resource itself before submitting it. But that's just one category of errors.
René Spronk (Feb 18 2020 at 07:47):
@Lee Surprenant Hadn't thought of it, but I'll definitely add it to the slide deck
Lloyd McKenzie (Feb 18 2020 at 14:40):
Possible topics in no particular order: Trade-off of validation strategies (XML schema vs. schematron vs. JSON schema vs. full validator; role of terminology services in error detection; trade-off of runtime validation vs. conformance testing; language translation of errors; error vs. warning vs. best practice invariants; validating profile declarations (or not); strategies for detecting instances to validate against profiles; relaying errors from legacy (including converting locations); returning operation outcomes on success (i.e. with warnings);
Lee Surprenant (Feb 19 2020 at 15:41):
just read your post at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Vonk.20-.20API.20Function.20Validations/near/188429501 and thought it worth mentioning in this thread too...whether to check the references or not seems to be an area of difference for servers.
Multiple parts
- whether it exists or not
- whether it is of the right resource type or not
- whether it conforms to the profile (for profiles that further constraint reference targets)
René Spronk (Feb 24 2020 at 13:51):
from a clients perspective, there's client side validation (as an error prevention measure) prior to calling the server (which does server side validation) which in case of errors leads to error mitigation on the side of the client. As Lloyd points out there's a ton of different approaches a client and/or server could take when validation FHIR content.
The validation of references is one of such things, and not an uncontroversial one at that, a reference that doesn't work at some point in time may be valid at some later point in time, or may have been valid at some point in the past. It's a server-side design choice..
René Spronk (Feb 24 2020 at 14:09):
@Lloyd McKenzie
- XML schema vs. schematron vs. JSON schema vs. full validator: I'm aware of the considerations when it comes to v3/CDA, this is probably no different in the case of FHIR. From what I'm reading on this chat JSON schema is not a terribly reliable/stable method for validation.
- role of terminology servers: IMHO should be part of 'full validation' testing. Fallback is to at least validate the system (but not the code)
- language translation of errors: would be no different than any other translation issues in FHIR, although it'd be both text as well as the display name associated with an error code
- strategies for detecting instances to validate against profiles: with that you probably mean scanning the persistence layer to get hold of potential resources which would match a given profile? What would the most likely strategy be? Each and every change to a resource could cause it to become conformant to a profile, or cause it to be no longer conformant to a profile. But it'd be a lot of overhead to keep validating all resources after any changes that were made, so probably one would try to assess the situation if and when the situation arises that one needs to collect/return resources that conform to a certain profile. Interesting question, but not that closely related to error handling IMHO.
Lloyd McKenzie (Feb 24 2020 at 15:09):
JSON schema is more thorough than XML schema, but the tooling isn't terribly stable yet.
Terminology servers - key thing is that checking the validity of terminology can be very complex, so outsourcing to a terminology service is often necessary/appropriate
Translation - key thing is that errors may propagate from a variety of locations, so translation is trickier
strategies to validate - also about receiving an instance that doesn't declare a profile but you want to know if it's valid against a profile. Kicking off full validation against all profiles is kind of nuts. Filtering just by resource type isn't much better. You probably want some sort of discriminator approach to decide what profiles are worth trying to validate against. (Dealing with stuff already persisted would also be relevant.)
Grahame Grieve (Feb 24 2020 at 19:57):
I'm going to post something about the last soon.
René Spronk (Mar 03 2020 at 15:06):
A draft description of my DevDays tutorial, please feel free to comment, or suggest additional stuff:
"Error Handling"
To err is human, errors are part of life. In the context of FHIR the main indicators that an error has occured are HTTP result codes, and the OperationOutcome resource. The main reason for errors include Validation issues and the use of API features by a client that are not actually supported by a FHIR server.
This talk will explore the various ways an error can be identified, discuss whether validation should take place on a client and/or a server, discuss the relative validation strength of schema versus object model based validation, cover the use of terminology servers for validation, show how best to relay errors from legacy applications, cover error mitigation strategies once errors have happened, and provide examples as to how FHIR implementation guides provide guidance around error handling.
Jason Walonoski (Mar 03 2020 at 21:54):
@René Spronk "One man's warning might be another man's error." (not trying to be gender specific, just figure of speech) Or vice versa.
Last updated: Apr 12 2022 at 19:14 UTC
