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.