Stream: terminology
Topic: Exception codes for terminology and other APIs
Senthil Nachimuthu (Nov 21 2017 at 19:46):
Where are the exception codes for terminology module operations defined, e.g. Unknown code system, Unknown code system version, Unknown concept code, Unknown Language, Language not supported for code system, etc.? I searched for "exceptions" through the Bing search on the FHIR website, but didn't find anything helpful about exceptions. Does the FHIR standard define exceptions and are there standard ways to extend exceptions for various APIs?
Peter Jordan (Nov 21 2017 at 22:18):
Those are all covered by the Issue Type Codes for the OperationOutcome resource... http://hl7.org/fhir/valueset-issue-type.html
Jim Steel (Nov 22 2017 at 00:46):
It might be a good idea to associate HTTP response status codes with these, e.g. as properties on the code system
Rob Hausam (Nov 22 2017 at 11:32):
I think Senthil has a good point. We haven't defined any of the terminology-specific exceptions that he mentioned, except for 'code-invalid'. At this point it's pretty much server dependent regarding what is returned as an OperationOutcome. Possibly we could consider defining some additional issue types for some of them (e.g. unknown code system and unknown code system version). And maybe it would be useful to at least allow (not necessarily require) declaring additional server-defined exception behavior in TerminologyCapabilities?
Senthil Nachimuthu (Nov 22 2017 at 16:11):
Thank you all. As a first step, we need to define what exceptions are applicable to the terminology services module. As a second steps, we need to associate specific exceptions with specific operations. This is what we did with CTS 1 and 2, but is there some documentation on how FHIR deals with exceptions - I'd like to educate myself about it please. The Bing search did not return anything useful. Thank you!
Peter Jordan (Nov 22 2017 at 21:09):
We haven't defined any of the terminology-specific exceptions that he mentioned, except for 'code-invalid'. At this point it's pretty much server dependent regarding what is returned as an OperationOutcome. Possibly we could consider defining some additional issue types for some of them (e.g. unknown code system and unknown code system version). And maybe it would be useful to at least allow (not necessarily require) declaring additional server-defined exception behavior in TerminologyCapabilities?
We need to consider this from a client developer perspective and analyse if and how they might benefit from a more granular set of TS-related exception issue type codes as opposed to viewing the text in the diagnostics value which can provide more specific information. It would also be informative to view this in the light of how developers process exceptions thrown by broader applications frameworks, such as .NET (exception.message - plus stack trace - tells me more than anything else) and it's not as if many terminology services errors are going to be thrown back to end users, other than invalid codes (in various contexts). The bulk of the remainder are more likely to be down to what's supported by the individual terminology server at the resource instance level (code system edition & version; concept map).
Rob Hausam (Nov 22 2017 at 22:13):
I agree with you, Peter. I'm not sure what would be the best approach to determine this, but I agree that we shouldn't add anything unless we have some evidence that it would be useful.
Senthil Nachimuthu (Nov 28 2017 at 16:48):
We haven't defined any of the terminology-specific exceptions that he mentioned, except for 'code-invalid'. At this point it's pretty much server dependent regarding what is returned as an OperationOutcome. Possibly we could consider defining some additional issue types for some of them (e.g. unknown code system and unknown code system version). And maybe it would be useful to at least allow (not necessarily require) declaring additional server-defined exception behavior in TerminologyCapabilities?
We need to consider this from a client developer perspective and analyse if and how they might benefit from a more granular set of TS-related exception issue type codes as opposed to viewing the text in the diagnostics value which can provide more specific information. It would also be informative to view this in the light of how developers process exceptions thrown by broader applications frameworks, such as .NET (exception.message - plus stack trace - tells me more than anything else) and it's not as if many terminology services errors are going to be thrown back to end users, other than invalid codes (in various contexts). The bulk of the remainder are more likely to be down to what's supported by the individual terminology server at the resource instance level (code system edition & version; concept map).
Peter, I agree with your concerns. Here is one real world use case that I have encountered and implemented. A lab HL7 interface keeps sending messages to a date warehouse. The datawarehouse translates the local lab codes on the fly and stores them. Now, suddenly the lab sends a new code. This throws a "No Map" or "Unknown Code" exception. There are other types of exceptions we've seen when we have centralized terminology servers - e.g. "Unknown Code System", "Unknown code system version", "Unsupported language", etc. These happen at runtime, not just configuration time. So, it's not sufficient to just send a human readable error message in the text description. There needs to be a standardized set of exceptions that the implementer can program against so that their system knows what to do or whom to alert, as opposed to getting a NullPointerException with the stacktrace or a HTTP 404 error. Thanks.
Yunwei Wang (Dec 05 2017 at 21:33):
I agree with Peter that OperationOutcome.issue.code is designed to fill the purpose.
Last updated: Apr 12 2022 at 19:14 UTC
