Search loading...


Explore and Make use of Nationally Defined Messaging APIs


UEC Digital Integration Programme | ServiceDefinition implementation guidance

ServiceDefinition implementation guidance

ServiceDefinition: Implementation Guidance


The Service Definition resource is published by the CDSS, describing what decisions the CDSS is able to provide support for. The resource describes in what circumstances the CDSS is valid, and what information is needed to render the decision. A CDSS can publish one or many ServiceDefinition resources. The resources SHOULD form a logically complete set. All CDSS MUST publish at least one ServiceDefinition.

A ServiceDefinition can encapsulate any amount of information – some CDSS may find it simpler to have a single ServiceDefinition, and routing of patients through the CDSS is managed entirely within that single ServiceDefinition. Other CDSS may publish a different ServiceDefinition for different areas – for example, a ServiceDefinition for each presenting complaint. It is also possible to be even more granular, with a CDSS having a different ServiceDefintion for different complaints, and also for different types of user (e.g. headache for adult females, and a separate ServiceDefinition for headache for male children).

In general, more granular ServiceDefinitions will make change management simpler, as these can be updated without changing other ServiceDefinitions. Conversely, fewer ServiceDefinitions can make the triage journey simpler to control.

Details of how a ServiceDefinition SHOULD be implemented within the Clinical Decision Support context is outlined in the table below:

Name Cardinality Type FHIR Documentation CDS Implementation Guidance
url 0..1 uri Logical URI to reference this service definition (globally unique) This absolute URI would be used to locate a ServiceDefinition when it is referenced in a specification, model, design or instance. It MUST be a URL, SHOULD be globally unique and SHOULD be an address at which the ServiceDefinition is (or will be) published. This is generally used by FHIR servers.
identifier 0..* Identifier Additional identifier for the service definition This is a business identifier and COULD be used to identify a ServiceDefinition where it is not possible to use the logical URI. This is generally used by FHIR servers.
version 0..1 string Business version of the service definition This is used to identify a specific version of a ServiceDefinition when it is referenced in a specification, model, design or instance. This is generally used by FHIR servers.
name 0..1 string Name for this service definition (computer friendly) The name is not expected to be globally unique. The name SHOULD be a simple alpha-numeric type name. This is generally used by FHIR servers.
title 0..1 string Name for this service definition (human friendly)
status 1..1 code draft | active | retired | unknown PublicationStatus (Required). Alongside the experimental element, this is used to identify the lifecycle of a ServiceDefinition. This MUST be populated with the value 'active' in live service.
experimental 0..1 boolean For testing purposes, not real usage This will carry the value 'false'.
date 0..1 dateTime Date this was last changed
publisher 0..1 string Name of the publisher (organization or individual)
description 0..1 markdown Natural language description of the service definition
purpose 0..1 markdown Why this service definition is defined
usage 0..1 string Describes the clinical usage of the module
approvalDate 0..1 date When the service definition was approved by publisher
lastReviewDate 0..1 date When the service definition was last reviewed
effectivePeriod 0..1 Period When the service definition is expected to be used
useContext 0..* UsageContext Context the content is intended to support This element SHOULD be populated with the appropriate expected usage of the ServiceDefinition. This will be determined by the EMS and CDSS specific to each implementation.
jurisdiction 0..* CodeableConcept Intended jurisdiction for service definition (if applicable) Jurisdiction ValueSet (Extensible) Geographical jurisdiction only in a CDS context. The contents of this element can assist an EMS in identifying the most appropriate service.
topic 0..* CodeableConcept E.g. Education, Treatment, Assessment, etc DefinitionTopic valueset (Example)
contributor 0..* Contributor A content contributor The information in this element COULD be used to assist consumers in quickly determining who contributed to the content of the knowledge module.
contact 0..* ContactDetail Contact details for the publisher
copyright 0..1 markdown Use and/or publishing restrictions Consumers MUST be able to determine any legal restrictions on the use of the ServiceDefinition and/or its content.
relatedArtifact 0..* RelatedArtifact Additional documentation, citations, etc
trigger 0..* TriggerDefinition "when" the module should be invoked The contents of the trigger element are used to advertise when the module should be invoked. On encountering a specific trigger, a clinical application can invoke the modules associated with the trigger using the $evaluate operation.
dataRequirement 0..* DataRequirement What data is used by the module This element MUST be populated with the set of machine-processable assertions (see GuidanceResponse.
outputParameters) which the CDSS requires in order to render the response fully.
operationDefinition 0..1 Reference |
Operation to invoke A reference to the operation that is used to invoke this service.
Tags: rest fhir api

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