FHIR Chat · docs / Issue #37 Use Parameters as the data type for the ... · cds hooks

Stream: cds hooks

Topic: docs / Issue #37 Use Parameters as the data type for the ...


view this post on Zulip Github Notifications (May 05 2017 at 18:50):

kpshek labeled Issue #37

view this post on Zulip Github Notifications (May 05 2017 at 18:51):

euvitudo commented on Issue #37

Thanks. I look forward to the write-up.

view this post on Zulip Github Notifications (May 05 2017 at 18:52):

kpshek commented on Issue #37

For reference, here are a few Google Group posts on the design changes from last year:

view this post on Zulip Github Notifications (May 05 2017 at 19:01):

euvitudo commented on Issue #37

For clarification, I am in no way advocating the use of Parameters for the CDS Hooks data model--just the prefetch element.

view this post on Zulip Github Notifications (May 07 2017 at 00:35):

euvitudo commented on Issue #37

Below is a use case to consider in this context:

This gist (fhir.cygni.cc.500.json) is a call to the the service on fhir.cygni.cc that has been failing--returning a 500--to the caller. It's caused by the resource turning out to be null (I believe we catch the HAPI-FHIR parse exception and this yields a null resource--arguably a bug in our code that may need to more properly addressed--or at minimum-level effort, an error indicating the issue instead of a sending back the raw 500).

However, if the calling code has created an OperationOutcome instead of putting the raw HTML into the resource, this could have been more easily handled.

view this post on Zulip Github Notifications (May 07 2017 at 08:42):

jmandel commented on Issue #37

Ah -- so obviously we want to be clear that "resource" is only for FHIR resources. We wouldn't expect to see an EHR populate a prefetch resource body with an HTML document showing an error page :-) "resource": null might be the right thing there.

view this post on Zulip Github Notifications (May 07 2017 at 08:48):

euvitudo commented on Issue #37

Interesting. So instead of providing information as to why the response.status is 404 (as can be provided in an OperationOutcome) you'd rather have a null resource? The CDS Service would then need to either re-request the data from the FHIR server (getting the OperationOutcome itself) or simply ignore the null and give an unexpected result (e.g., no result).

view this post on Zulip Github Notifications (May 07 2017 at 08:52):

kpshek commented on Issue #37

We certainly should document the expected behavior for this edge case identified in the aforementioned gist..

"resource": null is one way. Another would be for the EHR to not include that particular prefetch key/value at all. In the case of the gist, that means the prefetch object would not contain the medicationOrders and patient keys at all.


Last updated: Apr 12 2022 at 19:14 UTC