Stream: cds hooks
Topic: docs / Issue #14 How should a cds-service let an EHR know...
Github Notifications (May 06 2017 at 18:25):
seanmsmith23 commented on Issue #14
Agree with @kpshek regarding just using/returning standard HTTP error codes.
It seems unnecessary to return additional FHIR objects related to possible 500s - if there are recurring issues it's the CDS service's responsibility to fix their app or communicate possible issues to the EHR (they will surely be very noisy if there are issues as long as they have a publicly available contact). Doesn't feel like there is a strong need to add anything to the standard to cover this.
In regards to EHR responsibility for possibly tracking errors/timeouts SLA levels. I think it's okay to trust that the client and the CDS vendor can manage this as per their existing contractual obligations without needing to address it in the standard.
During scheduled downtime, I don't think the standard needs to define how the EHRs handle a resulting 503. Perhaps some suggestions or a best practice guide would be okay, but it's up to the EHR's discretion on what gracefully handling a 503 looks like. The CDS vendor should be communicating with the client well ahead of time to minimize the impact of any major workflow disruptions anyways.
Github Notifications (May 06 2017 at 21:46):
michelemottini commented on Issue #14
+1 for OperationOutcome
Having details about the errors help with troubleshooting. If you get back a 500 without any additional info the only recourse to try to figure out what's wrong is to ask the server owners to check their logs. If there are some details about what's going wrong maybe it is possible to fix it directly, or at least not having to start the troubleshooting from square zero.
Github Notifications (May 06 2017 at 21:48):
Why should the CDS Service return an
OperationOutcome? I've not known 500 errors to be parsed by the caller as due to their nature ('Internal Server Error'), they are opaque. To that, I don't see the EHR parsing the 500 error response and doing anything with it.So, why define/constrain the CDS Service to return any particular data in the body of a 500 response?
Github Notifications (May 06 2017 at 21:58):
michelemottini commented on Issue #14
Not that much experience with CDS - but when we act as a FHIR client we (try to) parse and log the error messages we got back from the servers - and that's very valuable in tracking down and solving problems. I would imagine that the same would apply for CDS calls.
Github Notifications (May 06 2017 at 22:02):
I agree that having the EHR log errors from CDS Services would be valuable. I have no problems if a CDS Service wants to log an OperationOutcome on on their own, but I don't see a need to prescribe this in the spec.
Last updated: Apr 12 2022 at 19:14 UTC
