Search loading...


Explore and Make use of Nationally Defined Messaging APIs


UEC Digital Integration Programme | Guidance Response implementation guidance

GuidanceResponse implementation guidance

GuidanceResponse: Implementation Guidance

The table below details implementation guidance for the GuidanceResponse resource in the CDS context:

Name Cardinality Type FHIR Documentation CDS Implementation Guidance
requestId 0..1 id The id of the request associated with this response, if any. This MUST be populated by the CDSS and MUST replicate the requestId received by the CDSS as a parameter in the ServiceDefinition.$evaluate operation.
identifier 0..1 Identifier Business identifier This MUST NOT be populated by the CDSS.
module 1..1 Reference
A reference to a knowledge module. This MUST be populated with the logical Id of the ServiceDefinition posted to the CDSS in the ServiceDefinition.$evaluate operation.
status 1..1 code Code datatype with Required binding to GuidanceResponseStatus The status of the GuidanceResponse is a trigger for the EMS.
subject 0..1 Reference
(Patient |
Patient the request was performed for. This SHOULD be populated with a reference to the Patient resource.
context 0..1 Reference
(Encounter |
Encounter or Episode during which the response was returned. This MUST be populated with the Encounter for this journey, from the ServiceDefinition.$evaluate.encounter
occurrenceDateTime 0..1 dateTime When the guidance response was processed. This MUST be populated by the CDSS and it represents the date/time at which the GuidanceResponse is returned to the CDSS. (This may differ from the time the message is received).
performer 0..1 Reference
Device returning the guidance. This SHOULD NOT be populated.
reason[x] 0..1 CodeableConcept |
Reason for the response. This SHOULD NOT be populated.
note 0..* CodeableConcept |
Additional notes about the response.
evaluationMessage 0..* Reference
Messages resulting from the evaluation of the artifact or artifacts. This SHOULD be populated in the case of error.
outputParameters 0..1 Reference
The output parameters of the evaluation, if any. This element carries the state of the patient triage and MUST be populated with the current state. The state is managed through QuestionnaireResponse elements (as provided by the user); assertions (typically populated as Observation resources) based on these responses which can be interpreted by other systems; and any other resources provided by the EMS, typically from external systems (e.g. known patient conditions).
Where an outputParameter can be interpreted by a system, it SHOULD be published as an assertion, typically an Observation. If the information can only be interpreted by a human, it can be published as a QuestionnaireResponse only.
result 0..1 Reference
(CarePlan |
Proposed actions, if any. The result element MUST be populated with a RequestGroup resource, if the CDSS has either a recommendation for a suitable next service, or some care advice. It SHOULD NOT be populated if the CDSS recommends transfer to a different ServiceDefinition.
dataRequirement 0..* DataRequirement Additional required data. The data carried in this element fulfils two purposes:-
If the evaluation could not be completed due to lack of information, or additional information would potentially result in a more accurate response for the current ServiceDefinition, the type of the data required will be 'Questionnaire'. The status of the GuidanceResponse MUST be either 'data-requested' or 'data-required'.
If the evaluation against the current ServiceDefinition has completed and the CDSS re-directs the EMS to another ServiceDefinition, the type of the data required will be 'TriggerDefinition'. In this case, the status MUST be 'success'.

GuidanceResponse Elements of note

OutputParameters element of the GuidanceResponse

This element contains the output parameters of the evaluation and is critical because it carries the current state of the triage journey.

Result element of the GuidanceResponse

Further guidance about the population of this element can be viewed on the Result interaction page.

DataRequirement element of the GuidanceResponse

The scenarios in which this element MAY be used are outlined below:-

Evaluation against the currently selected ServiceDefinition

If information is lacking for the evaluation to be completed or additional information could result in a more accurate response, this element will carry a description of the data required in order to proceed with the evaluation. A subsequent request to the service SHOULD include this data.

Re-direction to a new ServiceDefinition

In this scenario, the element will carry a description of the data required by the EMS to select the new ServiceDefinition to which it is being re-directed by the CDSS.
The dataRequirement.type element will be ‘TriggerDefinition’ and the CDSS will populate this to match the contents of the ServiceDefinition.trigger.eventData for the ServiceDefinition to which the EMS is to be re-directed.

Tags: rest fhir api

All content is available under the Open Government Licence v3.0, except where otherwise stated