Stream: cds hooks/github
Topic: docs / Issue #82 Add mandatory prefetch information
Github Notifications (Sep 08 2017 at 16:26):
bvdh opened Issue #82
In the current specification, including prefetch information is optional.
I suggest that we have optional and required prefetched data.
Optional prefetch indicates that the CDS Service would appreciate the data.
Mandatory prefetch indicates that the CDS Service depends on the data.This would make simple CDS Services that do not require FHIR repository access possible.
Github Notifications (Sep 09 2017 at 10:03):
rongchen commented on Issue #82
Agree, having mandatory prefetch will make EHR/CDS integration easier.
Github Notifications (Sep 09 2017 at 14:24):
I can see your point for simple CDS services, but it also forces that complexity on the caller. Generally I think it is good to have an indicator that the data is mandatory for the CDS service to run successfully. However, if the caller does not want to provide this data as part of the request, the service should pull it via FHIR calls.
Github Notifications (Sep 09 2017 at 15:05):
olbrich commented on Issue #82
I thought the goal of the prefetch was to provide a performance optimization and as such it would only be optional. Defining the contract of what is required to actually make use of a CDS service can be described in an implementation guide and the service itself could check for required resources in the Capability statement at the time the service is registered with the EHR.
Github Notifications (Sep 09 2017 at 16:59):
grahamegrieve commented on Issue #82
There are cases where there's no prospect of contacting the EHR server - the CDS hooks provider is outside the trust boundary. So in this case, prefetch is more than a performance optimization
Github Notifications (Sep 09 2017 at 18:24):
bdoolittle commented on Issue #82
Prefetch can enable the use of CDS-Hooks for an EHR service that may not have a FHIR server.
Github Notifications (Sep 09 2017 at 18:38):
rongchen commented on Issue #82
That's exactly what I have in mind, to use CDS-Hooks for EHRs that have no FHIR server.
Github Notifications (Sep 09 2017 at 19:22):
olbrich commented on Issue #82
@rongchen as I understand this, you are trying to cover the case where a cds-service requires certain data and it is incapable of querying a FHIR server for the data (either because of networking/connectivity issues or because the cds-service just doesn't implement the logic to go get the data).
If the cds service is capable of getting the data, then the prefetch would not be 'required', but might be 'optional'. In any case, what would be the point of having the standard define the prefetch data as 'required'? Would something on the EHR side process the requests differently, or is this just something you would need to consider when you are configuring installing the cds hook the first time around with each EHR?
Github Notifications (Sep 10 2017 at 07:54):
rongchen commented on Issue #82
@olbrich our usecase here is to integrate our cds services with EHR that has no FHIR server. So there is no querying a FHIR server for the data in our scenario. The initial cds request has to be complete with all required data. That's why prefetched data is mandatory in our case.
As I described in issue 78, we found CDS-Hooks to be interesting and generic enough to be used in any EHR/CDS integration even when FHIR is not used (there are lots of these legacy EHRs in the market). The common building blocks of Cards, Suggestions and Decisions are useful in CDS regardless which kind of clinical models (FHIR, CIMI or openEHR) are used.
Github Notifications (Sep 10 2017 at 12:43):
@rongchen you convinced me. I have often used requests in testing without a FHIR server explicitly to ensure that the test is not impacted by external data. I can see the value in supporting this generally. So if you have a prefetch marked mandatory and a FHIR server, but the prefetch data is not provided, should the service attempt to retrieve that data or should it assume it is null?
Github Notifications (Sep 10 2017 at 19:02):
kensaku-kawamoto commented on Issue #82
I agree this would be a useful feature, in particular around Graham's comment: "There are cases where there's no prospect of contacting the EHR server - the CDS hooks provider is outside the trust boundary. So in this case, prefetch is more than a performance optimization." From a healthcare provider system perspective, we would feel much more comfortable doing an interaction with an external CDS service that we "push" data to, rather than giving it access to our FHIR server.
Github Notifications (Sep 11 2017 at 19:15):
rongchen commented on Issue #82
@robs16 Thanks!
If prefetch marked mandatory and a FHIR server, but the prefetch data is not provided..
I think the service should return error pointing at missing data. That's what mandatory means to me.
Github Notifications (Sep 12 2017 at 10:22):
There is the case where the data doesn't exist, but is mandatory - for example maybe you want some particular vital observations that occurred in the last 24 hours. In this case the caller could fill in essentially an empty prefetch (bundle with no entries), so I guess that would satisfy the prefetch having a value, vs a null or missing mandatory prefetch item which should result in a 400.
Github Notifications (Sep 12 2017 at 11:34):
rongchen commented on Issue #82
In such case, I would think the EHR should not make the cds request with empty prefetch, say for a MEWS score calculation when the vital signs are required. The cds service will surely not be able to cope with the missing data, and return an error.
This requires some extra work on the EHR side makes sure cds requests are not made when there are missing data.
Github Notifications (Sep 12 2017 at 18:01):
brynrhodes labeled Issue #82
Github Notifications (Sep 12 2017 at 18:59):
TODO - Summarize WGM Q2 discussion
Proposal: Leave as-is (explain reasoning). Discussion around strengthening prefetch documentation either in the spec or in a future IG (desire to keep spec simple/concise and balance with understanding these complexities)
(Kevin will update this comment later)
Github Notifications (Sep 12 2017 at 19:30):
isaacvetter commented on Issue #82
Hey Everybody,
We talked about this issue during the CDS/CQI working group joint session today (Tues at Q2).
Pre-fetch is clearly valuable for more than performance optimization. There are real-world cases where the cds service doesn't have access to the FHIR server for "callback" queries. This lack of access may be due to health system security policies or even a scenario where the clinical workflow system doesn't have a FHIR server at all.
In these cases, a specific implementation requires that the content to be pre-fetch'd, but the actual service should be able to accept the desired pre-fetch'd resource or alternatively query for that same resource against the clinical system's FHIR server.
To the same point, the access to data, granted to a cds service is not and should not be governed by the cds service's discovery endpoint. Rather, that data access is governed by its OAuth2 scopes and the permissions of the current user.
Ultimately, whether a pre-fetch'd resource is required by a specific implementation, can only be determined during the specific implementation. CDS Services should be capable of querying the FHIR Server if the data needed is not provided in the prefetch.
Github Notifications (Sep 12 2017 at 20:22):
grahamegrieve commented on Issue #82
Issac: I'm having trouble parsing this:
"There are real-world cases where the cds service doesn't have access to the FHIR server for "callback" queries" then "In these cases .. the actual service should be able to ... query for that same resource against the clinical system's FHIR server."
Github Notifications (Sep 12 2017 at 22:14):
isaacvetter commented on Issue #82
@grahamegrieve - yes, I can see now why that would be confusing. I added more words in the hope that it will be clearer.
Github Notifications (Sep 12 2017 at 23:11):
grahamegrieve commented on Issue #82
ok that made much more sense. I can go with that - if we agree to add it as documentation to the spec
Github Notifications (Sep 13 2017 at 03:56):
olbrich commented on Issue #82
There is another scenario to consider. A CDS service that is unwilling or unable to make FHIR requests to the caller under any circumstances. I would expect that such a service would simply document that the prefetch is require in an implementation guide and return an error code if it was invoked without the required prefetch data.
Github Notifications (Sep 13 2017 at 15:32):
isaacvetter commented on Issue #82
Hey @olbrich ,
A CDS service that is unwilling or unable to make FHIR requests to the caller under any circumstances
Ultimately, access to the FHIR server is the big win, compared to other in-production, external CDS specs. Enabling the cds service to access additional data without modifying EHR configuration or settings, perhaps even dynamically based upon details about the patient/user/clinical scenario, etc, is a boon to the cds service.
I think that a "A CDS service that is unwilling or unable to make FHIR requests" is not really a CDS Hooks service or at least is definitely not fully implementing the specification and is not a scenario that we should encourage.
Assuming such a service does occur in production, I agree that the approach you've outlined would be natural.
Isaac
Github Notifications (Sep 13 2017 at 16:04):
bdoolittle commented on Issue #82
hey @olbrich and @Isaac Vetter, I agree that "a CDS service [or EHR] that is unwilling or unable to make FHIR requests is not really a CDS Hooks service." This would be a partial implementation of the 1.0 specification. However, the discussion touches on a deeper (out of 1.0 scope) issue, __#78__, regarding CDS Hooks' ability to be flexible in the clinical data model it uses.
Github Notifications (Sep 14 2017 at 08:08):
isaacvetter commented on Issue #82
Hey @brian doolittle - I think that you concern is actually better represented in #76, not #78. Concerns?
Hey @bvdh , @rongchen , @olbrich - with the above discussion/resolution are you okay with this issue being closed upon adding some documentation to the spec around expectations of clients, per Grahame?
Github Notifications (Sep 14 2017 at 10:29):
olbrich commented on Issue #82
@Isaac Vetter yes.
Github Notifications (Sep 15 2017 at 07:27):
rongchen commented on Issue #82
@Isaac Vetter yes.
Github Notifications (Oct 10 2017 at 16:22):
isaacvetter assigned Issue #82
Github Notifications (Oct 30 2017 at 20:39):
isaacvetter closed Issue #82
Last updated: Apr 12 2022 at 19:14 UTC
