Consider that the service definition can change dynamically

[olbrich]

We have a use case where some aspects of a service may change over time. In particular the prefetch may be updated as new guidance becomes available. Consumers of this service would need to update their cache of the service definition before invoking the service to ensure they are providing the proper data.

One possible approach to this would be for the EHR to cache the /cds-services endpoint with ETags and and then try to reload it on every invocation of the hook.

[robs16]

Is this a change that needs to apply immediately? I would guess many implementations might look at the service definition during dev, but not actively at run-time, so it might be difficult for them to handle. Like you, our prefetch will change over time, but we assume the caller is not dynamic and their dev lifecycle does not match ours.

[olbrich]

In our case we ship content updates a couple of times a week and we would prefer that our customers got that change immediately. It's also possible that changes to the rules may exclude or include patients that are in fact not eligible for our service.

One possible way to do this is to do a GET against the service definition before invoking the service and using ETags or other HTTP caching mechanisms to keep the overhead low.

[robs16]

I'm still having trouble understanding the need for the change in prefetch definition. Am I correct in assuming you need all data provided in the prefetch, because the service will not auto-query it from the FHIR server where it is not provided? Does the prefetch supply a set of patient identifiers or characteristic? What is the workflow that drives this hook?

The Stanson CDS content may change hourly but has nothing to do with hooks per-se. The interface doesn't change, just the CDS rules that use that content. If a patient is not eligible, that is actually part of the CDS rules, not something that would impact the prefetch.

[olbrich]

@robs16 in our case we are using the prefetch to check and see if the patient has a Condition that matches a list of code systems and codes. These codes can change over time (usually on the order of every few days at most), but we wouldn't want to have false positives (or worse false negatives). We only return a card and do additional processing if the patient is eligible. We could theoretically skip the prefetch completely, but then we would have to run a fairly complicated set of queries for each patient, every time the chart is viewed.

[robs16]

ok - that does explain it. The Stanson CDS tends to look at such data but queries large swaths, so we are currently not subject to the same issue. In this case it is not the resource types or entirely new prefetch fields that are changing, but the search criteria for a standard prefetch field/resource type. I do see the need for this type of capability in order to limit the scope of the data which the service needs. I wonder if this gets rather dicy when dealing with different code systems and large sets of codes (we have some similar uses that may hit 1000 codes between various code systems - especially where the EMR augments existing terminology). In any case, to support this type of functionality it would be better to have a flag or similar associated with the particular prefetch field which tells the calling EMR to re-reference the definition before pulling the prefetch data. I would guess most prefetch fields do not need this for most hooks, and checking it each time would be a latency issue if this functionality is not needed.

[olbrich]

@robs16 I'm ok with having to flag my service as needing a refresh before use. FYI, we also run into issues where the length of the query (because there are so many codes) can exceed some limit (at least in the sandbox), which results in the prefetch failing. We've actually had to break up our prefetch into several sub keys and then iterate through them looking for one that matched. The chunks we break it down into could also change.

I'd love to hear feedback from an EHR vendor about how they would address this problem when implementing a hook.

[jmandel]

That's interesting -- it'd be good to understand where it's breaking down in the sandbox, at least. HTTP doesn't specify a limit, but many clients and servers do have limits (e.g. https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers is a good overview). That said: this issue wouldn't be unique to CDS Hooks; it'd apply to any FHIR client (or possibly: any browser-based FHIR client).

The "right solution" is to support valuesets, and to search by valueset -- but honestly, the chunking scheme you've come up with might scale OK for this, if it's an unusual case.

[kpshek]

@jmandel - The Sandbox error @olbrich mentioned was actually the HSPC FHIR server erroring out on the very large prefetch request that was attempted.

[jmandel]

OK -- and is the error due to total query length, or something about the semantics of this particular query?

[olbrich]

@kpshek I think that's true, not sure if the sandbox does POSTs for searches or not.

@jmandel I'll investigate the valueset searching, that might work for us.

[kpshek]

OK -- and is the error due to total query length, or something about the semantics of this particular query?

Not sure what the root cause was (I saw the error over @olbrich's shoulder while at the Connectathon).

[olbrich]

@jmandel if I take the query and break it into smaller parts, it works fine. I think this is a length limit somewhere in the prefetch logic.

[olbrich]

See cds-hooks/sandbox#47 for the length limit problem in the sandbox.

[jmandel]

I wouldn't rely on valuesets, because most FHIR servers won't support allowing a client to create its own valuesets. (Sorry for the confusions -- that's why I put "right solution" in quotes.)

[kpshek]

I'd love to hear feedback from an EHR vendor about how they would address this problem when implementing a hook.

To add more problems here, one that hasn't been discussed is that if the prefetch templates change in a material way, or if new prefetch templates are added that request additional data types. Part of the undefined, assumed pre-negotiated setup between the EHR and CDS Service is to ensure that the CDS Service is authorized to access the prefetch data they request. So, changing the prefetch templates potentially affect this such that prefetch updates may not be able to be automatically honored by the EHR.

Our EHR is not going to support many prefetch templates (at least initially). Given the problems with dynamic prefetch templates being discussed here, I don't see these being applied/recognized without some manual oversight.

As an aside, an analog exists with SMART apps and the scopes they request from the authorization server. In my EHR, if a SMART app requests additional scopes from the AS (in a provider setting), the healthcare organization must be involved (manually) to grant these additional scopes -- they are not authorization "on the fly".