Stream: cds hooks/github
Topic: docs / Issue #14 How should a cds-service let an EHR know...
Github Notifications (May 10 2017 at 11:07):
At the Madrid Connectathon this past weekend (2017-05-07), a large group of us participating in the CDS Hooks track discussed this issue in an offline discussion. This group of ~12 represented a broad set of stakeholders, from multiple EHR vendors, several CDS Service providers, and a healthcare organization. What follows is the summary of our discussion and the consensus of the group.
Our documentation should provide specific guidance for CDS Services to return appropriate HTTP status codes in cases of errors. Since we already leverage RESTful conventions, it makes most sense for us to make use of standard HTTP status codes.
Our documentation should provide guidance for CDS Services to return error information in the response body as it sees fit. However, we should not prescribe a particular error response structure. This does not preclude CDS Services from returning an OperationOutcome.
Our documentation should provide guidance for EHRs to log errors from CDS Service calls as it sees fit. As EHRs are bound by their own technical and operational practices, as well as that of the healthcare organization, the manner in which they address such errors will be unique. The group agreed that our documentation should note the importance of logging such errors, especially when debugging integration between a CDS Service and the EHR.
Github Notifications (Jul 25 2017 at 06:47):
grahamegrieve commented on Issue #14
As an outcome, this leads a client hanging. What should the client be prepared to receive and process so that it can display a coherent message to the user? This matters. This nothing users - and trouble shooting progammers - hate more than a blank screen when there could be some useful information presented. I'd prefer OperationOutcome, but if we can settle on that, can we nail it down to very short list of formats, so that the client can know how to display errors it gets?
Here's some possibilities for a CDS service to return:
- OperationOutcome
- Text in the body
- a valid CDS-hooks response with a single card labelled as an error
- an full html page with a lovely stack dump that no one can read in text - or a lovely haiku. ;-(
- an empty body with minimally useful message on the status code
- a json object that describes the error
- markdown that describes the errorI've seen all these from generic web applications.... please can we make this a bounded problem for clients
Github Notifications (Jan 26 2018 at 17:44):
hongyan99 commented on Issue #14
From a REST perspective, every time when one invokes a service of this type, he is requesting to create a new unique resource (the calculation of evaluation result).
When there is a service error, it is of course 500 error. When the rule evaluation cannot be performed due to authentication or authorization failure it can be either 404 or 403 (see https://httpstatuses.com/403). Note that 403 does not have to mean that there is a security access related issue, it could also mean that there is bad data so that the service cannot perform the requested operation.
One catch here is that what if there is a partial failure? For example, I have a request for evaluation on a rule that contains a set of sub-rules. Only part of that failed due to data validation. In this case, I suppose that the service implementer can choose to either fail the whole request and return 403 with detail of the failure in the response body, or fail only partially. If the later, it would be a status code 200 but include the status of each sub-rule in the response body, so that the invoking system can take proper action precisely on the failed part(s).
Either implementation of using 403 or include error in response has advantages and disadvantages. The 403 is simpler but the 200 with detail in response gives more control.
One site that I found that might be helpful is the google doubleclick-search API reference: https://developers.google.com/doubleclick-search/v2/standard-error-responses. Can we copy what they are doing?
Just my 2 cents :).
Last updated: Apr 12 2022 at 19:14 UTC
