Define an approach to "trigger guards"?

[kpshek]

From @jmandel on May 11, 2016 15:45

Providing "trigger guards" for CDS Service Invocation: We’ve encountered several CDS services that are only relevant for a particular set of patients. For instance, a bilirubin CDS service would only be of interest to newborns, so it would be optimal if the EHR would only call the service for that subset of qualifying patients. It would be great to have a discussion around this topic and see if we can at least define conventions for how this is documented in CDS services.

Copied from original issue: cds-hooks/cds-hooks#17

[kpshek]

From @dmccallie on May 11, 2016 17:22

I think we should be cautious to avoid over-engineering the notion of
"trigger guards." Even if you could specify some "executable" logic as a
trigger guard, there would likely be lots of local detail (setting of care,
provider specialty, provider's preferences, etc) that could not be captured
in the external service's trigger guard logic statements. This could lead
to a messy mix of local rules engine trying to interplay with the external
logic defined by a different rules model.

It makes sense to define some recommendations about how to document the
external service's specification. For example, the external definitions
could be encouraged to use FHIR Profile value sets to define their logic
(e.g.,use the profile's valuesets to minimize the chance of data mismatch.)

--david

On Wed, May 11, 2016 at 10:45 AM, Josh Mandel [email protected]
wrote:

Providing "trigger guards" for CDS Service Invocation: We’ve encountered
several CDS services that are only relevant for a particular set of
patients. For instance, a bilirubin CDS service would only be of interest
to newborns, so it would be optimal if the EHR would only call the service
for that subset of qualifying patients. It would be great to have a
discussion around this topic and see if we can at least define conventions
for how this is documented in CDS services.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
cds-hooks/cds-hooks#17

[kpshek]

From @jmandel on May 11, 2016 17:27

Thanks for weighing in! I think I agree in principle -- but I'll also say that one of the best ways to document an expectation unambiguously can be to use a well-defined grammar. In other words, I wouldn't necessarily be against using something notionally executable as a documentation format.

[kpshek]

From @dmccallie on May 11, 2016 18:39

As long as "notationally executable" is readable by humans (in other words,
not an XML-encoded AST)...

On Wed, May 11, 2016 at 12:27 PM, Josh Mandel [email protected]
wrote:

Thanks to weighing in! I think I agree in principle -- but I'll also say
that one of the best ways to document an expectation unambiguously can
be to use a well-defined grammar. In other words, I wouldn't necessarily be
against using something notionally executable as a documentation format.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
cds-hooks/cds-hooks#17 (comment)

[kpshek]

in other words, not an XML-encoded AST

Well, there goes 2 days worth of work... 😜

[kpshek]

For reference, Clinical Reasoning has defined this under ServiceDefinition.useContext which uses the UsageContext data type.

[vadi2]

Why not fhirpath? (insert Zoidberg here)

[jmandel]

I think FHIRPath is a big help here. We'd need some way to define what resources(s) a FHIRPath expression runs against. A couple of possible models:

"Basic Resource Set"

We can imagine a small set of resources like: a single Patient and a bundle of Conditions as the implicit target for expressions. Then a CDS service would register a set of FHIRPath expressions, like:

{
  "patient": "now() - Patient.birthDate > 18 and Patient.gender = 'male'",
  "conditions": "Bundle.entry.resource.code.coding.where(system='http://snomed.info/sct' and code='84114007')"
}

(Leave aside how brittle this kind of SNOMED matching is.)

"Ad-hoc Resource Sets"

We could imagine a more general capability where services register search queries combined with boolean FHIRPath expressions. The equivalent of the above would be:

[{
  "query": "Patient/{{Patient.id}}",
  "fhirpath": "now() - Patient.birthDate > 18 and Patient.gender = 'male'",
}, {
  "query": "Condition?patient={{Patient.id}}",
  "fhirpath": "Bundle.entry.resource.code.coding.where(system='http://snomed.info/sct' and code='84114007')"
}]

Either of these representations could be automated (or manually implemented on a case-by-case basis inside of a given EHR, using the formal expression as a set of requirements)... but it's unclear how general-purpose and expressive these approaches are. For example, important trigger guards might need pretty rich value set semantics, where the service needs to define a (potentially big) valueset ahead of time. FHIRPath could handle this too, but we need more experience before I'd be happy making this call.

[kpshek]

@vadi2 - FHIRPath has come up previously. 😄 In addition to what Josh already stated, a concern with FHIRPath is the complexity in implementing this.

My opinion is that we won't address this for 1.0 and instead rely upon the native capabilities of the EHR's underlying rule engine to handle this.

[dennispatterson]

Noting that this came up on Zulip - https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/Client.20side.20pre-conditions