How can we re-use the CDS Hooks hooks?

[isaacvetter]

During the HL7 working group meeting in May in Köln, we talked about the re-use of CDS Hooks' hooks by FHIRcast.

CDS Hooks defines hooks which are workflow events for triggering external, realtime clinical decision support. FHIRcast events are workflow events for triggering external application synchronization.

The CDS Hooks helpfully defines a hook catalog, which currently contains patient-view (essentially equivalent to open-patient-chart), medication-prescribe and order-review. CDS Hook's wiki also lists additional, possible hooks. FHIRcast defines a very similar event catalog, which currently contains open-patient-chart, switch-patient-chart, close-patient-chart, open-imaging-study, switch-imaging-study, close-imaging-study, user-logout and user-hibernate.

CDS Hooks hook + FHIRcast event name unification could mean, in order of increasing compatibility: 1) Using the same name and understanding of where in the workflow this event actually occurs. 2) Unifying the type of contextual information passed as part of the hook/event. (E.g. open chart includes some reference of patient and encounter, but necessarily the same formatted content). 3) Unifying the actual message content.

Example:

CDS Hooks patient-view

CDS Hooks' patient-view requires sending contextual information including the patientId and optional encounterId. These are FHIR resource id's.

FHIRcast open-patient-chart

FHIRcast's open-patient-chart returns almost the same information; specifically, the results of these queries against the Hub's FHIR server:

• Required: Patient/{id}?_elements=identifier
• Optional: Encounter/{id}?_elements=identifier

[wmaethner]

Hey @isaacvetter I like the idea of having a robust, common set of workflow events that can be used in a variety of mechanisms. It is definitely better than defining them in two different standards with the amount of crossover there is likely to be.

In the same vein as this, I think it would be useful to call out the differences between the two standards more clearly. It came up at RSNA, why not just use CDS hooks, and I know we have talked about the differences and there are some clear use cases for each. It would be good to really define those and call them out somewhere to be fully transparent.

[bvdh]

We could also extend FHIRcast with CDS hooks events, which would allow the FHIRcast channel to be used to update the applications of CDS Hooks events. These events would be triggered from updates to the EMR context in the way that is described in the CDS Hooks standard.

Event-name: cdshooks-event Context: hook: the cds-hook hook context: the context as defined in the CDS-Hooks hook OAuth fhircast/cdshooks//receive - receive cdshooks hook events for this hook fhircast/cdshooks//send - send cdshooks hook events for this hook