Select ServiceDefinition Interaction
This action is performed by the Encounter Management System (EMS) in order to get a ServiceDefinition from a Clinical Decision Support System (CDSS).
When the CDSS publishes a ServiceDefinition, the ServiceDefinition will have elements which describe how the ServiceDefinition can be used, for example the ServiceDefinition.useContext element could carry patient gender, age group.
The description of where in the clinical process a ServiceDefinition sits is described in the ServiceDefinition.trigger. This element will hold all the data conditions which need to be satisfied for the ServiceDefinition to be chosen.
The ServiceDefinition.trigger will typically be defined through Observation resources which MUST be true in order for the ServiceDefinition to be suitable for evaluation. For a given CDSS, these will typically be aligned to the ServiceDefinition.dataRequirements of a prior ServiceDefinition.
Each CDSS SHOULD provide a ServiceDefinition where the trigger is NULL (i.e. no information is required).
During a given patient journey, there may be points where there is more than one ServiceDefinition available. Any one CDSS should avoid this situation, but if a provider has more than one CDSS available, there may be situations where more than one CDSS can provide an appropriate ServiceDefinition. In this case, it will be up to local providers on how to choose between the available ServiceDefinitions.
Request Headers
The following HTTP request headers are supported for this interaction:
| Header | Value | Conformance |
|---|---|---|
Accept |
The Accept header indicates the format of the response the client is able to understand, this will be one of the following application/fhir+json or application/fhir+xml. See the RESTful API Content types section. |
MAY |
Authorization |
The Authorization header MUST carry a base64url encoded JSON web token. See the RESTful API Security section. |
MUST |
Get ServiceDefinition
The EMS will select a preferred ServiceDefinition using chosen parameter(s).
The interaction is performed by the FHIR RESTful search interaction as shown:
Search Parameters and Responses
Detailed guidance relating to searching for FHIR resources can be viewed.
Two scenarios which may be used to search for a ServiceDefinition in the CDS context are outlined below:
Searching for a ServiceDefinition by _id
The search parameter _id refers to the logical id of the ServiceDefinition resource and would be used when the EMS already knows the _id of the required ServiceDefinition.
When the _id search parameter is used by the EMS it SHALL only be used as a single search parameter and SHALL not be used in conjunction with any other search parameter to form part of a combination search query with the exception of the _format parameter.
The _id parameter can be used as follows:
This search finds the ServiceDefinition resource with the given id (there can only be one resource for a given id).
Further details relating to the _id search parameter are available.
Search Response
Success
- MUST return a
200OK HTTP status code on successful execution of the interaction. - MUST return a
Bundleof type searchset, containing either:- One
ServiceDefinitionresource or - A ‘0’ (zero) total value indicating no record was matched i.e. an empty
Bundle.
- One
Failure
The following errors can be triggered when performing this operation:
- Invalid parameter (if using the ‘_format’ parameter without a mime type recognised by a CDSS or EMS server).
- Resource not found
Searching for a ServiceDefinition using a named query
A second scenario would occur when an EMS needs to search for a ServiceDefinition which corresponds to selected search criteria. This would require a search using a customised search profile. Such advanced search operations of this type are specified by the _query parameter.
This parameter is used as follows:
The _query parameter will define additional named parameters to be used with the named query and these will be used in combination where criteria for all of them must be satisfied.
The recommended additional parameters for a ServiceDefinition are outlined below:
| Name | Type | Description | Conformance | Path |
|---|---|---|---|---|
status |
token |
The status of this service definition | SHOULD | ServiceDefinition.status |
experimental |
token |
For testing purposes, not real usage | SHOULD |
ServiceDefinition.experimental
|
effectivePeriod |
date |
When the service definition is expected to be used | SHOULD |
ServiceDefinition.effectivePeriod
|
useContext.code |
token |
Type of context being specified | SHOULD |
ServiceDefinition.useContext.code
|
useContext.valueCodeableConcept |
token |
Value that defines the context | SHOULD |
ServiceDefinition.useContext.valueCodeableConcept
|
useContext.valueQuantity |
quantity |
Value that defines the context | SHOULD |
ServiceDefinition.useContext.valueQuantity
|
useContext.valueRange |
quantity |
Value that defines the context | SHOULD |
ServiceDefinition.useContext.valueRange
|
jurisdiction |
token |
Intended jurisdiction for service definition (if applicable) | SHOULD | ServiceDefinition.jurisdiction |
trigger.type |
token |
The type of triggering event | MUST | ServiceDefinition.trigger.type |
trigger.eventData.type |
token |
The type of the required data | MUST |
ServiceDefinition.trigger.eventData.type
|
trigger.eventData.profile |
uri |
The profile of the required data | MUST |
ServiceDefinition.trigger.eventData.profile
|
Servers will define their own named queries to meet the use case outlined above by using an OperationDefinition resource.
Search Response
Success
- MUST return a
200OK HTTP status code on successful execution of the interaction. - MUST return a
Bundleof type searchset, containing either:- One or more
ServiceDefinitionresources - A ‘0’ (zero) total value indicating no record was matched i.e. an empty
Bundle.
- One or more
Failure
The following errors can be triggered when performing this operation:
