Interactions

The key interactions for the Clinical Decision Support API are represented in the diagrams below.

Service Validity Interaction

The Service Validity interaction is a custom FHIR Operation performed by an EMS at the start of a triage journey. The $isValid operation is intended to check whether the CDSS is able to provide ServiceDefinitions appropriate for the current journey.

This is an optional interaction, expected to be used where a CDSS may not be appropriate to all patients. For example where an online consultation system is only relevant to patients whose registered GP has a contractual relationship with the system supplier.

The $isValid operation is performed by the EMS passing the patient’s registered GP (as an ODS code) to the CDSS.

The CDSS will output a boolean - true if the CDSS is valid for this patient at this time, and false if not.

View the Service Validity interaction page for detailed guidance.

Invoke ServiceDefinition.$evaluate and GuidanceResponse

The triage journey starts with the system user, simply referred to as ‘user’ in this Guide, requesting decision support through the EMS.

The core of the triage journey is invoking the ServiceDefinition via the $evaluate operation by the EMS. This will return a GuidanceResponse resource from the CDSS. For more on choosing the ServiceDefinition, see the ServiceDefinition: Implementation Guidance.

This interaction is expected to be repeated multiple times during the triage journey as the EMS presents responses to CDSS questions until a result is reached.

The GuidanceResponse carries or references all information relating to the CDSS response.

View the Evaluate ServiceDefinition and GuidanceResponse pages for detailed guidance.

Questionnaire / QuestionnaireResponse

The CDSS determines the next question to ask and populates a Questionnaire resource accordingly. A reference to this Questionnaire is included within the returned GuidanceResponse.

The EMS presents the question to the user and the user responds via the EMS.

This response is used to populate a QuestionnaireResponse resource, a reference to which is returned to the CDSS within the next ServiceDefinition.$evaluate operation in the triage journey.

This interaction is expected to be repeated multiple times during the triage journey as different questions are presented to the user from the CDSS.

The CDSS evaluates the returned QuestionnaireResponse and uses its content to create an assertion which is carried within an Observation resource.

The CDSS determines whether there is enough information to arrive at a result. If not, another Questionnaire is populated with the next question to be answered.

The GuidanceResponse returned to the EMS now contains references to both an Observation and a Questionnaire resource.

View the Evaluate and GuidanceResponse pages for detailed guidance.

Arriving at a result

The EMS invokes a ServiceDefinition.$evaluate operation referencing a QuestionnaireResponse and any previous assertions (Observation resources) for the CDSS to evaluate.

The CDSS creates another assertion from the QuestionnaireResponse and determines whether a result can be provided.

The result is sent to the EMS within the GuidanceResponse and the EMS displays the result to the User.

View the Result section for more information.

Check Services Interaction

If at the end of the triage journey an onward referral is required, the EMS invokes a $check-services operation on a Directory Service. The $check-services operation references the generic ReferralRequest obtained as part of the triage outcome (chief concern, next activity and acuity).

The Directory Service uses the ReferralRequest and other IN parameters to find a specific set of services which can meet the need identified in the triage outcome.

The Directory Service returns a bundle of HealthcareService resources.

View the Check-Services page for detailed guidance.

Encounter Report Interaction

On completion of a patent’s triage encounter the EMS can hand over the journey to a different EMS or appropriate Healthcare Service.

The Encounter Report contains all the resources collected during the $evaluate interactions plus additional data required by a downstream service provider to provide safe clinical care to that patient. This provides conformant Encounter Report Receiving systems (ERRs) with structured triage information to drive business processes.

The aim is for the Encounter Report to be suitable for communicating triage information between any two Care Settings.

Notifying an ERR

The interaction notifying an encounter report is available begins after the $check-services interaction is complete and a Healthcare Service has been identified to handover to.

The EMS calls the HealthcareService.endpoint with the reference to the Encounter.

Retrieving an Encounter Report after being notified

The ERR having received the notification, now has the Encounter.id. The ERR requests the Encounter Report from the EMS specifying the Encounter.id and the EMS returns it.

Searching for an Encounter Report

The ERR can also query known endpoints based on patient details such as the NHS Number to find a relevant Encounter. The ERR can then fetch the Encounter Report based on the Encounter.id.

View the Encounter Report page for detailed guidance.