ServiceDefinition: Implementation Guidance

Usage

The ServiceDefinition 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 a 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 ServiceDefinition 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.

CDSS Suppliers MUST ensure that all ServiceDefinitions end in the provision of CareAdvice, a ReferralRequest or redirection to another ServiceDefinition to reduce the risk of triage failing to complete. ServiceDefinitions that end with a redirection to another ServiceDefinition MUST NOT redirect to the initiating ServiceDefinition either directly or indirectly.

Details of how a ServiceDefinition SHOULD be implemented within in the scope of this implementation guide is outlined in the table below:

ServiceDefinition: Element Guidance

useContext

The useContext element is used to describe the expected usage of the ServiceDefinition. This SHOULD be populated where available to reduce the risk of using a ServiceDefinition that is inappropriate for the context, for example the service type, patient type or user role (which may lead to inappropriate triage).

The EMS will typically use the ServiceDefinition.useContext to filter available ServiceDefinitions in the Select ServiceDefinition interaction.

The following json code block shows how to define the useContext in a ServiceDefinition. Note that useContext can only use key value pairs.

"useContext": [
  {
    "code": {
      "system": "http://hl7.org/fhir/usage-context-type",
      "code": "age",
      "display": "Age Range"
    },
    "valueCodeableConcept": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "133936004",
          "display": "Adult (person)"
        }
      ]
    }
  },
  {
    "code": {
      "system": "http://hl7.org/fhir/usage-context-type",
      "code": "user",
      "display": "User Type"
    },
    "valueCodeableConcept": {
      "coding": [
        {
          "system": "http://hl7.org/fhir/valueset-provider-taxonomy.html",
          "code": "103GC0700X",
          "display": "Clinical"
        }
      ]
    }
  }
],

jurisdiction

The jurisdiction element is used to describe the intended usage jurisdiction of the ServiceDefinition. If no jurisdiction is defined as part of the ServiceDefinition then it is deemed to be appropriate for any/all jurisdictions.

The EMS will typically use the ServiceDefinition.jurisdiction to filter available ServiceDefinitions in the Select ServiceDefinition interaction.

The following json code block shows how to define the jurisdiction in a ServiceDefinition.

"jurisdiction": [
  {
    "coding": [
      {
        "system": "urn:iso:std:iso:3166",
        "code": "GB",
        "display": "United Kingdom of Great Britain and Northern Ireland (the)"
      }
    ]
  }
]

version

If a CDS decides not to populate the version element, then there is deemed to be only a single version in existence.

In practice this SHOULD be populated where available although not mandatory.

Where a set of ServiceDefinitions provide a set of unified content, they must share a common version.

publisher

Population of the publisher element is optional.

The EMS will always know (and be able to log) exactly which ServiceDefinition was ‘called’ for any patient journey - at a minimum, through the url which was invoked during evaluation.

title, description, usage

The human readable title, description and usage elements MUST be populated by the CDSS to help mitigate the risks of selecting an inappropriate ServiceDefinition.

It is the decision of the EMS how and when, if ever to display this information.

trigger

If populated, this MUST be populated with DataRequirements for the clinical assertions required for this ServiceDefinition to be valid.

It is valid for this not to be populated - a NULL trigger means that the ServiceDefinition does not require any preconditions to be valid.

The custom ValueSet for trigger.eventData.value is UEC-ObservationCode-1.