These API events help facilitate real-time, immediate clinical decision support (CDS). CDS hooks are events that are triggered during the provider's workflow, typically appearing as a popup modal or separate iFrame. The most common hooks are triggered upon:
- opening a patient chart
- signing an order
- creating an order
- scheduling
We support these type of hooks that allow you to:
- request a list of supported CDS hooks within the EHR system;
- return a list of supported CDS hooks within the EHR system;
- view context for a patient upon opening or interacting with their chart;
- view context when creating and selecting an order from a list of order types; and
- view order context and insights when signing an order.
Return order context (e.g., dose, quantity, route) when a user is ready to sign one or more orders for a patient. This is typically triggered at the end of the order workflow when an order moves out of draft status.
Request Parameters
- sourceIdrequired, string
Displays the unique identifier of a source within a given environment.
- serviceIdrequired, string
Identifys the destination system for the CDS Hook call
Request Body Schema
- Metarequired, object
- DataModelrequired, stringReliable
CDSHooks
- EventTyperequired, stringReliable
order-sign
- EventDateTimestring, nullReliable
Displays the UTC date and time that an outgoing request is delivered or an incoming request is received.
ISO 8601 Format - Testboolean, nullReliable
Indicates whether the request is a test or not.
- Sourceobject
Contains the information for the system initiating the message, including the source ID and name.
Included in messages from Redox- IDstring, nullReliable
Identifies the system initiating the message. If you have multiple OAuth API keys per environment type, this value is required. If you have only one OAuth API key per environment type, or you're using legacy API keys, this value is optional.
UUID - Namestring, nullReliable
Displays the name of the system initiating the message.
- DestinationsArray of object
Contains the information for the endpoint(s) receiving the request. A request must contain at least one destination, but asynchronous requests can have more than one destination. Synchronous requests like queries can only support one destination.
Required when sending data to Redox.- IDstring, nullReliable
Identifies the endpoint that the request is directed to.
UUID - Namestring, nullReliable
Displays the name of the endpoint that the request is directed to.
- LogsArray of object
Contains the log identifier(s) for the request.
- IDstring, nullReliable
Identifies the request log(s) that correspond to this request. You can use this value to locate the relevant log in the Redox dashboard for support and reference.
UUID - AttemptIDstring, nullReliable
Identifies the request log attempt value, which is useful when retries are possible.
UUID
- FacilityCodestring, nullPossible
Code for the facility related to the message.
Only use this field if a health system indicates you should. The code is specific to the health system's EHR and might not be unique across health systems. In general, the facility fields within the data models (e.g. OrderingFacility) are more reliable and informative.
- hookrequired, string
Specifies the type of event that triggered this CDS service call.
- hookInstancerequired, string
Contains a universally unique identifier (UUID) for this specific hook instance.
- fhirServerrequired, string
Contains the base URL of the CDS client's FHIR server.
IffhirAuthorizationis provided, this field is required. - contextrequired, object
Contains contextual data about the hook, or triggered event, that the CDS service will need.
- patientIdrequired, stringReliable
Contains the unique identifier of the patient that the order is being placed for.
- userIdstring, nullReliable
The user ID of the user who triggered the hook.
Must be in the format [ResourceType]/[id]. For this hook, the user is expected to be of type Practitioner, PractitionerRole, Patient, or RelatedPerson. Patient or RelatedPerson are appropriate when a patient or their proxy are viewing the record. For example, Practitioner/abc or Patient/123. - encounterIdstring, nullProbable
Identifier of the encounter associated with the order.
This is typically a FHIR resource ID such as Encounter/12345. - draftOrdersobject
Lists all unsigned orders in the current session, including newly selected ones, in a FHIR bundle.
This may include details such as the medications, dosages, and instructions for the order.- resourceTypestring, null
Describes the type of resource being drafted. Typically, this is a FHIR resource type (e.g.,
Bundle,MedicationRequest, orServiceRequest) - idstring, null
Contains a unique identifier for the unsigned, draft order. This ID is used to reference the order within the EHR system.
- entryArray of object
Lists unsigned, draft orders. Each entry represents a specific item in the order.
- resourceobject
Specifies the resource being drafted.This is typically a FHIR resource type such as
MedicationRequestorServiceRequest.- resourceTypestring, null
Describes the type of resource being drafted. Typically, this is a FHIR resource type such as
MedicationRequestorServiceRequest. - idstring, null
Contains a unique identifier for the unsigned, draft order. This ID is used to reference the order within the EHR system.
- userstring, null
Identifies the user who triggered the event. Typically, this is the clinician or healthcare provider viewing the patient record.
IffhirAuthorizationis present, theuserfield should match thesubjectin the OAuth token. - fhirAuthorizationobject
Defines the OAuth 2.0 bearer access token (including supplemental information) that grants the CDS service access to FHIR resources.
- accessTokenstring, nullProbable
Contains the token that authorizes access to the FHIR server.
- tokenTypestring, nullProbable
Describes the type of access token.
- expiresInstring, nullProbable
Specifies the access token's expiration time (in seconds).
- scopestring, nullProbable
Defines the scope, or access granted, with the token.
- prefetchobject
Defines the FHIR data (e.g.,
Patient,Condition) that the EHR system should retrieve in advance to include in the CDS service request when the event is triggered. This reduces latency by fetching required data ahead of time and ensures that the CDS service has the necessary context to make informed decisions.- {{key}}string, nullPossible
Defines additional fields under the prefetch object, where each key represents a FHIR query defined by the EHR. These queries are used to retrieve data in advance to optimize CDS service performance.