CDS Hooks
| This feature is currently incubating |
An endpoint to describe the CDS Service definition including the prefetch information required to invoke it according to the CDS Hooks standard.
| CDS Hooks integration requires the Healthcare Feature Set subscription. |
CDS Hooks
Content-Type: application/json`
HTTP-Methods : GET, POST
This endpoint implements the standard CDS Hooks discovery endpoint.
Pre-fetch
Using the CDS Hooks endpoint requires preparation in your service inputs. Each input that will be prefetched from FHIR needs to have a custom attribute called FHIR that contains the query for the prefetch.
For workflows, this can be added to Data Inputs and for decision models it can be added to Input Data.
Example prefetch queries:
| Query | Description |
|---|---|
Patient/{{context.patientId}} |
The current patient |
Observation?subject={{context.patientId}}&code=386661006 |
An observation with a specific code |
If the service is properly configured with the FHIR custom attributes, an HTTP get on the endpoint will result in a JSON description of the service.
The prefetched data can be posted at the base URL (removing the /cds-services from the discovery URL) to execute the service.
Generating CDS Cards with your service
Not all models will properly convert into a CDS service.
| The user interaction of CDS service is much more limited than what is allowed by the modeling language. the CDS Hooks standard defines a single interaction with the EHR system through the output of card(s) and the feedback can be gathered from that card. No additional user interaction is possible through CDS Services. |
The following topics address how to interact with users using CDS cards.
Default Mapping
By default, unless an explicit mapping is defined, an info card that has the name of the service as its summary will be automatically generated. Each service output will be added to the card detail in the format Key: Value.
Service outputs CDS Card(s)
If your service outputs a data type that is consistent with the CDS Card definition (required fields: summary, indicator, and source), only these outputs will be transformed to cards.
Note that your service can have one or many outputs that are CDS Cards. An output can also be a collection of cards. The data type of the output is what is considered to determine if the explicit mapping is taken for a service.
Decision Model example:
This model shows how to configure two prefetch (patient and Loinc weight observations) and how to construct 3 cards:
The Patient Name Card show how to simply use a context to map a single card required attributes and add custom extension to the card:
The Weight Cards decision is a little bit more complex and shows how a single decision can return multiple cards (one for the current weight of the patient and another one to display the number of observations found).
This example displays the following cards:
Workflow Model Example:
This example shows similar concepts using a workflow model. Note that the card construction is in the output data mapping of the Say Hello task:
Service contains a single user tasks with a CDS Card input and a Feedbacks output
| Applies only to Workflows, Decisions can’t collect feedback. |
If you need to collect the feedback from the suggestion interaction of your card, you can build a workflow similar to this one.
The task that presents the card will be completed once the user either choose a suggestion or dismiss the card (optionally with a reason). This feedback is collected in the output Feedbacks variable.
Collecting card Feedbacks
| Collecting Feedback is currently supported for a single card output per workflow. |
As an alternative to the definition of a user task to collect feedback, your workflow could instead output the CDS Card using a Data Output and wait on an message event with its payload defined with the Feedbacks data type (as a convenience, the Feedback data type can be replaced by the Text data type to simply received the uuid of the selected suggestion).
