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 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 MAY 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 MAY 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 | (OperationDefinition) |
Operation to invoke | A reference to the operation that is used to invoke this service. |