FHIR Chat · docs / Issue #6 Define an approach to "trigger guards"? · cds hooks

Stream: cds hooks

Topic: docs / Issue #6 Define an approach to "trigger guards"?

Github Notifications (May 06 2017 at 00:01):

kpshek commented on Issue #6

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

Github Notifications (May 06 2017 at 10:54):

vadi2 commented on Issue #6

Why not fhirpath? (insert Zoidberg here)

Github Notifications (May 06 2017 at 11:17):

jmandel commented on Issue #6

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.

Github Notifications (May 06 2017 at 11:36):

kpshek commented on Issue #6

@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.

Last updated: Apr 12 2022 at 19:14 UTC