Stream: cds hooks
Topic: DataRequirement dateFilter.path or .searchParam?
John Silva (Aug 18 2020 at 14:57):
In the DataRequirement dataType there are, what appears to be 2 ways to specify the search/filtering mechanism, the codeFilter and dateFilter. What is not clear, especially for the dateFilter, is how and when to use .path vs .searchParam.
For example, if I'm trying to create a DR dataFilter for "patient > 65 yrs old" how would that be encoded in dateFilter?
dateFilter.path = "birthdate=gt1955-01-01". (using this because a FHIR server might not implement the age search extension)
or
dateFilter.serarchParam = "birthdate=gt1955-01-01"
or
something else?
[Should I be asking this in the Implementers stream rather than here? ]
Josh Mandel (Aug 18 2020 at 15:03):
Yeah, it's not specifically CDS Hooks question -- though I don't think there's a dedicated area for broader CDS discussion (maybe #cql would be worth trying, or @Bryn Rhodes could probably answer directly). Where/how are you trying to use a dataFilter?
John Silva (Aug 18 2020 at 15:21):
@Josh Mandel thanks! Yes, I was debating to ask here or #cql or #implementers -- but didn't want to 'incur the wrath' of double.triple posting ;-)
As my example shows, if the CQL logic was trying to filter on patients greater than a certain age, I want to have a DR that essentially does the same FHIR search filtering as what would happen in the CQL logic. (even though ?age isn't a standard Patient search parameter)
Josh Mandel (Aug 18 2020 at 16:27):
No worries! But are you actually issuing a FHIR search? Or... what are you doing with the DR snippet you're creating? That's what I'm confused about.
John Silva (Aug 18 2020 at 17:22):
@Josh Mandel - this FHIR Clinical Reasoning page shows how the dataRequirement is supposed to be mapped to FHIR URL:
https://www.hl7.org/fhir/clinicalreasoning-cds-on-fhir.html#14.5.2.3
`The concept of prefetch data is represented within Clinical Reasoning as a DataRequirement, which can be transformed to an instance level read or type level search interaction as follows:
DataRequirement Element Mapping to FHIR URL
type [type]{[id] | ?[parameters]}
subject subject={{patientId}}
codeFilter [path]{=|:in}[code|valueSet]
dateFilter [path]{eq|lt|gt|ge|le}[valueDateTime|valuePeriod|valueDuration]
sort _sort=[sort]
limit _limit=[limit]
This prefetch data can be automatically determined from the data requirements of the PlanDefinition and provided as part of the service definition to the CDS Hooks discovery response.`
John Silva (Aug 18 2020 at 17:26):
Maybe, reading 'between the lines' here, the 'transformed to instance-level read' implies 'path' and 'type level search interaction' implies searchParam. If this is true then I suppose I should use serachParam and then the value has to be a RESTful GET search string?
Josh Mandel (Aug 18 2020 at 17:53):
Hmm, are you building a CDS Hooks client, or CDS Hooks services, or something else? The excerpt you cited seems more like an analogy/mapping exercise, but if you're doing CDS Hooks you'd want to create the actual templated prefetch URL rather than a DataRequirement structure.
Bryn Rhodes (Aug 18 2020 at 22:11):
The path is used to specify a path in terms of actual elements in the resource, whereas searchParam is used to specify the name of a search parameter to use for the filtering. The data requirements mapping can be used to construct prefetch declarations, we do this for clinical reasoning modules that we expose as CDS Hooks services.
John Silva (Aug 19 2020 at 14:51):
Brian, yes, this is what we're trying to do -- use the DR as a way to construct the prefetch searches (if you will). One thing about this approach that has me wondering though, how can you pre-create the prefetch rules before a possible CQL rule has been 'fired'? Is this a system setup phase where all the possible PlanDefinitions in the system pre-computed the prefetch searches and store them so they are available when (i.e. before0 the CDS Hook actually fires?
Bryn Rhodes (Aug 19 2020 at 18:01):
Yes, exactly, the Library resource has a DataRequirements element, and as part of packaging a CQL library, the DataRequirements for the logic are inferred and persisted in the Library so they can be processed for exactly that type of use case. See this library for example
John Silva (Aug 19 2020 at 22:11):
Thanks! That library example helps show the correlation between the CQL rules and the dataRequirements. The only one that is missing a DataRequirement is the "age between 2 and 17"; I would assume that would be done using the Patient resource and a searchParam for age, but, of course, age is not a standard Patient search operator (e.g. HAPI doesn't implement it and probably others).
I still have to think about how all these Library (or PlanDefinitions) would be retrieved to create the prefetch criteria before any rule is fired. There could be many of these on a FHIR server, how would the CDS Hook code (service) know which ones to use (or all?)
Josh Mandel (Aug 19 2020 at 23:06):
@Bryn Rhodes can you help me understand what this is about? Who implements the mapping described in https://www.hl7.org/fhir/clinicalreasoning-cds-on-fhir.html#surfacing-clinical-decision-support, and when/why?
Josh Mandel (Aug 19 2020 at 23:06):
Like, who turns DataRequirements into a prefetch URL (in time to be added to a CDS Service's hooks discovery endpoint)?
Bryn Rhodes (Aug 20 2020 at 03:17):
We have it implemented in our CDS Hooks service, so we dynamically construct the discovery response by walking through the registered PlanDefinitions, and reading the DataRequirements from the Libraries used by those PlanDefinitions. Each PlanDefinition corresponds to a CDS Hooks endpoint, and we use this mapping to turn the DataRequirements into prefetch templates.
Bryn Rhodes (Aug 20 2020 at 03:21):
So decision support services exposing clinical reasoning content via the CDS Hooks API.
Josh Mandel (Aug 20 2020 at 13:26):
And is John using your CDS Hooks service? Maybe that's the context I'm missing.
Bryn Rhodes (Aug 21 2020 at 01:36):
@John Silva , there is a CDS Hooks Service PlanDefinition profile that we use to provide the CDS Hooks endpoint that a given PlanDefinition is surfaced on: http://hl7.org/fhir/plandefinition-cdshooks-service.html
Bryn Rhodes (Aug 21 2020 at 01:36):
That's how we know which PlanDefinitions to run through and what endpoint to use to surface them in the discovery.
Bryn Rhodes (Aug 21 2020 at 01:37):
Josh, I don't think John is using the CQF Ruler, not sure though, John?
John Silva (Aug 21 2020 at 02:43):
Were using some of the https://github.com/cqframework/cql-execution library for executing the CQL. Not sure that has support for working with the PlanDefinition and its DataDefinitions.
Last updated: Apr 12 2022 at 19:14 UTC
