Stream: cds hooks/github
Topic: docs / Issue #366 Prefetch does not distinguish between a...
Github Notifications (Jul 13 2018 at 18:57):
euvitudo opened Issue #366
In the prefetch response discussion, the spec says:
Note that the missing u key indicates that either the EHR has decided not to satisfy this particular prefetch template or it was not able to retrieve this prefetched data. The CDS Service is responsible for retrieving this Practitioner data from the FHIR server (if required).
I was part of the discussion in #157, but my main complaint in that discussion was about the Bundle.entry being the standard method for communicating the prefetch result.
At this point, I think a clarification is needed, as I think it would benefit CDS Service implementers to provide some guidance to clients (namely EHRs) as to what should be provided in the prefetch result.
For instance, when the EHR executes the prefetch query against its FHIR server and no results are returned or an error occurred, it seems relevant to provide the response from the server (e.g., an empty Bundle or an OperationOutcome) to the CDS Service to more clearly indicate why the response was such from the FHIR server (versus simply passing a null).
(As a side note, it seems to me that requiring the EHR to check the response and send null instead of sending the response, is more work on the EHR's part.)
We (Claude Nanjo and I) see several use cases to consider from the CDS Service implementer's viewpoint (though these may not be all-:
- EHR does not put a prefetch key in the prefetch response (or provides a null as the response); when the CDS Service asks for the prefetch resource/response, it is null. The use case presented in the spec discussion indicates that the EHR refused or was not able to retrieve the resource. Thus, if the reason is the EHR decides not to honor the prefetch, such an indication would be beneficial to the CDS Service. If we expect something back, and there is no way to distinguish whether a result was not included or empty, what should the CDS Service assume? Therefore, the CDS Service should know why a resource was not included.
- The prefetch is a search; results are returned; when you ask for the prefetch resource/response, you get a Bundle with entries.
- The prefetch is a search; no results are returned; when you ask for the prefetch resource/response, you get an empty Bundle; would be beneficial to the CDS Service to obtain this empty Bundle (e.g., to assert the result set is empty).
- The prefetch is a read; a resource is returned; when you ask for the prefetch resource/response, you get the specified resource.
- The prefetch is a read; no resource exists; you get an OperationOutcome with a 404, 410, etc. Would be beneficial to the CDS Service to obtain the OperationOutcome from the prefetch response in order to take appropriate action (e.g., the CDS Service knows to search elsewhere for the information it needs).
- The FHIR server encountered an error; an OperationOutcome is returned from the FHIR server; this communication would be beneficial to the CDS Service; e.g.,:
- we wanted to retrieve information about the Patient's HIV diagnosis:
- if this is null, then is it that they have a record and the EHR refused via some other mechanism than null (possibly due to security/no consent, though the reason should likely not be disclosed), by way of, e.g., an OperationOutcome with a 403
- the guidance back to the EHR might be to indicate that, e.g., permissions need to be provided (consent or BTG), or the clinician will have make the determination manually
- the patient doesn't have a record but the FHIR Server responded with a 500, in which case you know that it's indeterminate whether they have an HIV diagnosis (whether the patient has a record or not)
Last updated: Apr 12 2022 at 19:14 UTC
