Add mandatory prefetch information

[bvdh]

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.

[rongchen]

Agree, having mandatory prefetch will make EHR/CDS integration easier.

[robs16]

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.

[olbrich]

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.

[grahamegrieve]

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

[bdoolittle]

Prefetch can enable the use of CDS-Hooks for an EHR service that may not have a FHIR server.

[rongchen]

That's exactly what I have in mind, to use CDS-Hooks for EHRs that have no FHIR server.

[olbrich]

@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?

[rongchen]

@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.

[robs16]

@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?

[kensaku-kawamoto]

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.

[rongchen]

@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.

[robs16]

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.

[rongchen]

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.

[kpshek]

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)

[isaacvetter]

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 -- not the cds service. The functional capabilities of the actual service should not dictate the method in which the system seeking guidance provides FHIR data. Functionally, this means that the cds service should always be capable of accepting the desired pre-fetch'd resource or alternatively querying for that same resource against the clinical system's FHIR server. This means that the same cds service, deployed across multiple health systems could likely require pre-fetch in one integration, but not another -- even when the same instance of cds service is being used.

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.

[grahamegrieve]

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."

[isaacvetter]

@grahamegrieve - yes, I can see now why that would be confusing. I added more words in the hope that it will be clearer.

[grahamegrieve]

ok that made much more sense. I can go with that - if we agree to add it as documentation to the spec

[olbrich]

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.

[isaacvetter]

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

[bdoolittle]

hey @olbrich and @isaacvetter, 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.

[isaacvetter]

Hey @bdoolittle - 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?

[olbrich]

@isaacvetter yes.

[rongchen]

@isaacvetter yes.