Stream: cds hooks
Topic: Filter Matching
Travis Cummings (Jan 18 2017 at 17:30):
I've been thinking there might be a good way to apply a filter to a CDS Hook (and other event-driven use cases). The technique used by subscription is not event-driven. Subscription allows a specifying "Criteria=a search criteria". Of course a search criteria is by definition, searching over the database for matching records. This isn't what often needs done. Often, we have the data already and need to find the matching Hooks (or Subscriptions even).
Travis Cummings (Jan 18 2017 at 17:34):
What makes more sense for an event-driven model is something that a rules engine would use...pattern matching. This could be something like "code=123". This is different than "Observation?code=123" because the first is a property on a resource I already have identified and the second is an expression of resources I havent' identified.
Travis Cummings (Jan 18 2017 at 17:40):
There is a form of pattern matching that is already defined in the spec that could be very well suited for this operation...a Profile. A profile of course is a set of rules that an already idenitified resource abides by. For example, if I wanted to write a CDS Hook with a focus on smoking status, I could simply say in my Hook definition "Profile=daf-smokingstatus".
Kevin Shekleton (Jan 18 2017 at 17:44):
In your daf-smokingstatus profile example, are you trying to only have your CDS service invoked when you know the patient is a smoker?
Travis Cummings (Jan 18 2017 at 17:44):
Slightly more general, in that example, it would just be a patient with a known smoking status
Travis Cummings (Jan 18 2017 at 17:45):
It might be more valuable to have a cds-hooks service only when the smoking status is known, and "true"
Travis Cummings (Jan 18 2017 at 17:45):
So in that case, a new profile would be needed that logically extended daf-smokingstatus, something like my-daf-smoker
Travis Cummings (Jan 18 2017 at 17:47):
but this allows the cds-hooks service and the cds-hooks engine to share an agreement of what "matches" before hand, and also allows the cds-hooks engine (or backing EHR) to pre-calculate the matching operation and save it as a profile claim on the resource.
Travis Cummings (Jan 18 2017 at 17:48):
so filtering becomes an O(1) operation in the cds-hooks engine
Kevin Shekleton (Jan 18 2017 at 17:56):
I'm still thinking through the implications of all of this
Kevin Shekleton (Jan 18 2017 at 17:57):
I agree we could do many filtering use cases through profile matching
Kevin Shekleton (Jan 18 2017 at 17:59):
I'm just not sure a generic method using profiles would be best. There is also FHIRPath (or CQL) which provides generic methods of qualifying on a desired data set
Kevin Shekleton (Jan 18 2017 at 18:00):
All of those bring with it considerable implementation complexities. I'm not saying those aren't ultimately the right thing to do, but they haven't seen widespread implementation (partly due to the complexity/cost IMHO).
Kevin Shekleton (Jan 18 2017 at 18:02):
To be fair, I haven't spent a lot of time thinking through ways to implement all of this but I'm happy to hear you're thinking through options, Travis!
Kevin Shekleton (Jan 18 2017 at 18:04):
Perhaps it would help to solicit feedback & concrete use cases on filtering that would be desired *today* by the current CDS services in production (not via CDS Hooks) or those planned in the near future. From those, we can see if there is a simple approach that we could employ or something more generic that would cover the things desired today as well as those that may come up in the future
Kevin Shekleton (Jan 18 2017 at 18:04):
Btw, we have a Github issue for this: https://github.com/cds-hooks/docs/issues/6
Kevin Shekleton (Jan 18 2017 at 18:05):
One of the benefits/draw of CDS Hooks is its simplicity so I would like to keep that goal in mind here too. Travis, your profile proposal may turn out to be that, I just need to play around with things further (including profiles)
Josh Mandel (Jan 18 2017 at 18:10):
I think we could have a pretty simple *optional* execution model where you list (resource, fhirpath ) tuples and the EHR can use them as a trigger guard, only calling your service if your expressions return true. like:
{
"triggerGuard": [{
"for": "Patient/{{patient}}",
"require": "Patient.name.given.exists()"
}]
}
Josh Mandel (Jan 18 2017 at 18:11):
if somebody was interested in exploring this...
Kevin Shekleton (Jan 18 2017 at 18:13):
I'd personally like to explore that (though it will be after the other areas we need to wrap up first)
Travis Cummings (Jan 18 2017 at 18:29):
The FHIRPath approach does seem interesting. Is the scope of FHIRPath limited to the usage of resources, or could it also be used in expressing constraints in the definition of a resource?
Isaac Vetter (Jan 18 2017 at 18:31):
Hey Guys - understanding the Clinical Reasoning approach to "trigger guards", data requirements and formal cds logic definitions would be useful here:
Isaac Vetter (Jan 18 2017 at 18:31):
http://build.fhir.org/cqif/cqif-topics-using-expressions.html
Isaac Vetter (Jan 18 2017 at 18:33):
http://build.fhir.org/cqif/cqif-topics-using-expressions.html#data-requirements
Travis Cummings (Jan 18 2017 at 19:02):
If I understand, FHIRPath, FluentPath, CQL are ways to create an expression and a Profile is way to define an agreement for extensions and constrains on a resource. If that is correct, then a Profile in theory could use FHIRPath, FluentPath, CQL as a means to define the agreement. I'm asking because I've heard different takes on Profile.
Ewout Kramer (Jan 18 2017 at 19:19):
Yes, a Profile is a way to express constraints on any given resource type both to reflect constraints on the datamodel (e.g. change in cardinalities), add FhirPath based additional constraints on it, ensure extensions are present on the model and it can in fact be used to define new extensions as well.
Bryn Rhodes (Jan 18 2017 at 19:28):
Yes, DataRequirement can be used with a TriggerDefinition to describe when something should be invoked. @Travis Cummings one of the things we tested at this connectathon was a HAPI JPA plugin that can run CQL and FHIRPath. It would be interesting to try the pattern matching approach you're suggesting with that plugin. We'd be interested in trying it out with the HSPC containers, can we chat about how to get that plugged in to one of those?
Travis Cummings (Jan 18 2017 at 19:45):
Thanks for getting me up to speed on some of these approaches. Using this approach, a CDS-Hook definition could use a DataRequirement that referenced a FHIR Profile that used FhirPath to describe an expression that matched a resource!
Isaac Vetter (Jan 18 2017 at 19:48):
I wonder if this is a place where cds-hooks could simplify / define an implementation approach for a limited subset of the Clinical Reasoning artefacts.
Josh Mandel (Jan 18 2017 at 19:54):
Would be good to get some use cases on the table. I'm interested to see how far we can go with FHIR REST API + fhirpath.
Travis Cummings (Jan 18 2017 at 20:02):
I'd be interested in that. start with the expression language itself before layers of containment.
Last updated: Apr 12 2022 at 19:14 UTC
