Constrain prefetch to align with FHIR's DataRequirements

[kpshek]

In discussion with @brynrhodes and @isaacvetter regarding aligning Clinical Reasoning and CDS Hooks, one of the topics of discussion was around how both projects handle the concept of prefetching data.

Prefetching aims to address the following:

1. Allows the EHR to satisfy data that it may have already (eg, in memory)
2. Allows the EHR to calculate an optimal set of queries necessary to satisfy data across multiple CDS Services

In Clinical Reasoning, this concept is defined in the ServiceDefinition.dataRequirement using the DataRequirement type. Compared to our prefetch definition, DataRequirement is a much more constrained model. Based upon @brynrhodes implementation experience, the constraints of DataRequirements allow for the calculation of an optimal set of FHIR queries to satisfy multiple DataRequirements. Our current prefetch definition (any FHIR query) would not actually allow EHRs to achieve our 2nd goal above.

To help with this discussion, it would be good to take an inventory on the current prefetch FHIR queries for a variety of CDS Services that have been prototyped at Connectathons. With their feedback, we can see if constraining prefetch to the functionality of DataRequirements would still meet their needs.

[jmandel]

@kpshek can you explain a bit about what you mean by "calculation of an optimal set of FHIR queries"? Is this about generating raw/internal database queries to retrieve the data you need? In general, the more capabilities you allow the harder this gets; but for simpler search strings (e.g. Observation?patient={{Patient.id}} you could always optimize these directly (by recognizing them explicitly as having some structure that you know how to handle well).

Obviously this is more work on the EHR side, but I'd imagine a couple of common cases would handle a good fraction of the load, while still giving service developers the flexibility to pre-fetch on more expressive REST API when needed. And if you see some pre-fetch requests that are "too hard" (whatever that might mean), you can always leave them out and allow the client to fetch directly.

All that said: I agree that it would be good to take stock of what queries people are actually running. On my list so far are:

• patient (read)
• search for most recent set of bilirubin labs for a specific patient
• search for all med orders + statements for a patient
• search for most recent height + weight for a patient
• search for all allergies for a patient
• practitioner (read)

None of these is super complicated. But looking at https://www.hl7.org/fhir/metadatatypes.html#datarequirement, it's not so straightforward either. It actually appears to enable many kinds of queries that the FHIR REST API search protocol does not (e.g. arbitrary dotted-path filters like Observation.component[2].code, where the REST API enumerates a specific list of search parameters).

[niquola]

Isn't it similar to what GraphDefinition is trying to solve?

[jmandel]

In principle, yes. This is definitely worth keeping an eye on, and we can make sure to share the CDS Hooks use cases as examples for GraphDefinition. Some concerns for the moment include:

• The STU3 GraphDefintion doesn't support backwards links yet (so starting from a patient there's no way to traverse outward to allergies, labs, etc).
• There's not yet a clear story for filtering labs by code, or meds by drug, etc
• Slicing and Profiling aren't readily supported in today's EHR FHIR implementations

[kpshek]

@jmandel - Yes, that is what I meant by "calculation of an optimal set of FHIR queries". Under our current model, we allow for any FHIR search string which, as you know, can result in some very complex queries (chained parameters, reverse chaining, contained, etc). I do not think any EHR can achieve our stated goal of calculating an optimal set of of database queries given an arbitrary set of prefetch queries.

Certainly, this can be accomplished if the prefetch queries are sufficiently simple (as in the case of the Observation?patient={{Patient.id}} query you mentioned).

Obviously this is more work on the EHR side, but I'd imagine a couple of common cases would handle a good fraction of the load, while still giving service developers the flexibility to pre-fetch on more expressive REST API when needed. And if you see some pre-fetch requests that are "too hard" (whatever that might mean), you can always leave them out and allow the client to fetch directly.

I agree with this. However, if the purpose of prefetch is to allow the EHR to either return data it already holds cheaply (eg, memory) or optimally fetch it, why start with an API that allows for complex queries which I contend will always be 'left out' and on the client to fetch directly.

None of these is super complicated. But looking at https://www.hl7.org/fhir/metadatatypes.html#datarequirement, it's not so straightforward either.

Agreed. Perhaps @brynrhodes can specify some examples to help us all understand this model better?

I've created this new wiki page to solicit feedback from the community on what prefetch queries are being used today (or what plan on being used). Hopefully this will provide use with some additional context that may help us decide if/what changes are made in this space.

[jmandel]

However, if the purpose of prefetch is to allow the EHR to either return data it already holds cheaply (eg, memory) or optimally fetch it

Even if the EHR does no better than to query its own database the same way it would for a rest call, it at least saves a round trip. That was my initial motivation here.

[grahamegrieve]

GraphDefinition will need to handle backwards links. It allows for slicing/profiling, but that's not mandatory (unless the problem makes it mandatory, which is a problem anyway). One of the advantages of graphdefinition is that the EHR can define a fixed number that they implement optimally, and let the client choose one.

[jmandel]

@grahamegrieve does GraphDefinition contemplate a way to filter which links are followed (e.g. from Patient --> "all MedicationRequests from the past 12 month prescribed by Dr. Jones")? From the current design, it looks like this kind of filtering would be profile-based; is the thought to add some other constraint specification language (like FHIRPath, search params, DataRequirement-style filters, or something new)?

[brynrhodes]

DataRequirement is more about defining the leaves of a graph, where the relationships between those leaves would be specified some other way (in CQL in a measure or decision support artifact). I've been thinking about a transformation between CQL and a GraphDefinition, seems like it would be straightforward, but haven't had time to get into the details. In general, the data requirements would still be computable from the leaves, and you could probably get some economy based on the relationships as well.

[grahamegrieve]

we weren't contemplating this... but it might be a good idea. And it would be good to not only be able to do it by profile. But there has to be a limit somewhere.

[brynrhodes]

It actually appears to enable many kinds of queries that the FHIR REST API search protocol does not (e.g. arbitrary dotted-path filters like Observation.component[2].code, where the REST API enumerates a specific list of search parameters).

Yes, DataRequirements allows you to describe queries in terms of general paths, that's definitely an area that needs to be worked out. What we do right now is map the path to a search param, in the best case that works fine because it's one-to-one; anything beyond that needs to be addressed by the data access layer (either by augmenting or subsetting the search results).

GraphDefinition works the same way, but has the advantage of being behind the service API. Where CQL can execute behind the API, it can use the paths directly, but when it's in front of it, there has to be a mapping.

[brynrhodes]

As far as examples, the Library examples have quite a few, here's a typical example.

[kpshek]

However, if the purpose of prefetch is to allow the EHR to either return data it already holds cheaply (eg, memory) or optimally fetch it

Even if the EHR does no better than to query its own database the same way it would for a rest call, it at least saves a round trip. That was my initial motivation here.

While we remove the latency between the CDS Service and the FHIR server (since we're going from the EHR to FHIR Server), the performance impact to the user is actually worse in many cases. This is because the EHR is blocking on calling the CDS Services until the prefetching is finished. As such, the user is waiting longer for the initial cards to be returned.

[jmandel]

In practice, there are lots of opportunities for optimization — e.g. the EHR can preemptively compile the details required for a MedicationPrescription hook as soon as the prescribing pad is opwn, even before the user has entered a drug (so they can be ready the instant the EHR needs to otrigger the hook).

[kpshek]

Absolutely!

My apologies if my previous comments are being construed as questioning the value of prefetch as that is not my intention. I'm just trying to impress that I believe our current prefetch model is difficult to implement by EHRs in order to achieve our higher-order goals.

Conversely, our current prefetch model is very simple for CDS Service providers to implement which I love and would like to maintain with any changes that may be introduced.

[jmandel]

This discussion is spot-on @kpshek. I agree with the question, and I like the idea of constraints that enable :-) Just want to make sure they have reasonable ergonomics, too. Saying "we support search-style URLs but the only allowed parameters are patient, code, and date" might be worth considering, too.