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 for Patient View.
Pre-fetch
Using the CDS Hooks endpoint requires preparation in your service on its 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.
CDS Cards
A CDS Card is automatically generated from the service unless your service is designed to explicitly output cards.
Default Mapping
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.
Explicit Mapping
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 show 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:
