cds-hooks / docs

CDS Hooks website & specification
http://cds-hooks.org
Apache License 2.0
167 stars 61 forks source link

Define an approach to "trigger guards"? #6

Open kpshek opened 8 years ago

kpshek commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/cds-hooks/cds-hooks/issues/17

kpshek commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/cds-hooks/cds-hooks/issues/17#issuecomment-218530256

kpshek commented 8 years ago

in other words, not an XML-encoded AST

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

kpshek commented 7 years ago

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

vadi2 commented 7 years ago

Why not fhirpath? (insert Zoidberg here)

jmandel commented 7 years ago

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 commented 7 years ago

@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 commented 4 years ago

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