FHIR Chat · docs / Issue #202 Standard Context Field Names · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #202 Standard Context Field Names

---

Github Notifications (May 07 2018 at 17:54):

hadleynet opened Issue #202

Should the specification define a standard set of context field names such as patientId, encounterId etc? Currently it seems like a human needs to read the hook definition and manually implement support for a particular hook and its context fields rather than being able to consumer a machine readable description.

The spec goes part way by providing machine readable service discovery but that seems to be predicated on existing support for the hooks referenced in the discovery response.

Github Notifications (May 07 2018 at 19:33):

kpshek labeled Issue #202

Github Notifications (May 07 2018 at 19:40):

kpshek commented on Issue #202

Thanks for the question @hadleynet!

Even if we were to figure out a way to standardize on the hook context parameters like patientId or encounterId, we'd be left with gaps that still require a person to read through the hook to understand it fully.

For instance, the entire scenario the hook is representing is not something that can be machine readable. In order to full understand how an application, EHR, or CDS Service implements a hook, you need to know the clinical scenario the hook represents. "This hook is invoked when the user starts the process of charting a lab result" or "This hook is invoked when the user begins a Zika screening workflow" are just two examples of scenarios that really can only be understood through some narrative text.

Additionally, as hooks define their own context, I don't know how we can standardize on context names/values because, well, they are unique to hooks. :smile: We would never be able to define a comprehensive set of possible hook context field as some new hook will always be created that has a new context field that doesn't exist in that standard set. And for each hook context field, we again need some narrative to explain just what the field represents.

I'm open to more concrete ideas and suggestions for improving our current definitions while still balancing the simplicity that makes CDS Hooks so attractive for implementers.

Github Notifications (May 08 2018 at 02:20):

kpshek labeled Issue #202

Github Notifications (May 14 2018 at 12:55):

robs16 commented on Issue #202

I agree with @kpshek, but the documentation could be updated to prefer re-use of existing named context fields like encounterId and patientId, etc. There are times when that might not be appropriate - such as referencing two encounters - in which case the context field name should probably be a bit more specific.

Github Notifications (May 14 2018 at 12:57):

isaacvetter commented on Issue #202

What about creating swagger documentation as part of the hook creation process?

Github Notifications (May 14 2018 at 13:28):

hadleynet commented on Issue #202

Are there classes of hooks of which there could be many different instances? E.g. I could imagine whole host of CDS hooks that support the "prescribing a new medication" scenario that could easily share a context such that you add a new hook automatically without treating it as a snowflake. Maybe I'm underestimating the complexity but it seems like some level of standardization here could bring benefits.

Github Notifications (May 14 2018 at 13:33):

robs16 commented on Issue #202

I can see that - so order-review (sign order) vs order-entry (when the order is first created) vs order-validate (any point from order-entry till past order-review). medication-prescribe is related to all of the above, since a medication is prescribed via an order.

Github Notifications (Jun 13 2018 at 15:53):

kpshek milestoned Issue #202

Github Notifications (Jun 13 2018 at 15:53):

kpshek unlabeled Issue #202

Github Notifications (Dec 12 2018 at 16:43):

kpshek closed Issue #202

---

Last updated: Apr 12 2022 at 19:14 UTC