FHIR Chat · cds-hooks: issue 13: Rename activities to hooks · cds hooks

Stream: cds hooks

Topic: cds-hooks: issue 13: Rename activities to hooks

CDS Hooks Bot (Mar 21 2016 at 21:29):

kpshek commented on issue 13

Cool, that makes sense to me. I'll have a PR late tonight with proposed changes!

CDS Hooks Bot (Mar 22 2016 at 02:13):

kpshek commented on issue 13

From #10:

In the case where a single $cds-hook endpoint serves multiple different activities (medication-prescribe and patient-view, for example -- btw, see how using the word "hooks" there would have been akward?), I see the value in having a list of hooks.

I would have worded that something like:

In the case where a single $cds-hook endpoint offers multiple services across several hooks...

CDS Hooks Bot (Mar 22 2016 at 02:15):

jmandel commented on issue 13

Mmm. Maybe the operation shouldn't be called cds-hook though. I mean, is the "hook" something the EHR does, or something the CDS Service exposes, or both? Both feels unsatisfying here, like we need more/better/clearer terms.

CDS Hooks Bot (Mar 22 2016 at 02:19):

kpshek commented on issue 13

I agree. It doesn't feel completely right. I'll mull over this more tonight...

CDS Hooks Bot (Mar 22 2016 at 02:43):

kpshek commented on issue 13

What about this?

EHRs offer hooks for areas or activities within the EHR in which a CDS Service can *hook* into.

CDS Providers offers services which are invoked by the EHR at the desired hook.

So,
- CDS Providers, not CDS Services. This is because it's awkward to say "CDS Services offers services..."
- Hooks, not activities (see above). Activities imply user action and certainly today our hooks are invoked as a result of explicit user action. However, I'm certain we'll see hooks in the future which are purely passive (eg, the EHR offers a hook into an *area* of the application that is always visible; like a notification bar / system tray)

This terminology would have the following ramifications:

- POST /$cds-service for invoking a service in the CDS Provider
- GET /$cds-service-metadata to get the metadata for all services offered by the CDS Provider

Thoughts @Josh Mandel?

CDS Hooks Bot (Mar 23 2016 at 22:50):

jmandel commented on issue 13

I find this very clear, and I like the notion that hooks are exposed by the EHR, and services are exposed by the CDS Provider. That solves a naming problem that's been bugging me for a while.

Slight tweaks to the overview (see if you are okay with "workflow" in this sense - I do agree with your point about areas of the screen, but it's hard to express concisely):

EHRs offer "hooks" into specific points in the workflow where external CDS Providers can be consulted

CDS Providers offer services that respond when an EHR triggers a hook

(I'm still on the fence about "trigger".)

CDS Hooks Bot (Mar 24 2016 at 11:01):

kpshek commented on issue 13

I'm fine with your changes @Josh Mandel and like using _workflow_ as this describes the intended integration much better!

Last updated: Apr 12 2022 at 19:14 UTC