Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

ValueSet

Introduction

Snow Owl TS supports interactions and operations related to value sets, as described in the FHIR R5 terminology service specification. For certain toolings implicit value sets are also expandable; these are described below in detail.

Tooling support

SNOMED CT

Value set URIs following SNOMED International's URI format are evaluated based on the associated SNOMED CT code system's content. The following query parts can be added after the "version URL" of the code system to define an implicit value set:

Query
Definition

?fhir_vs

All concepts of the code system

?fhir_vs=isa/409822003

Descendants of 409822003|Domain bacteria|

?fhir_vs=refset

All reference sets of the code system

?fhir_vs=refset/733073007

Members of 733073007|OWL axiom reference set|

The URL portion should always include a module identifier to avoid confusion, e.g. http://snomed.info/sct/900000000000207008?fhir_vs to indicate that all concepts from the International Edition should be included.

LOINC

Value set identifiers described in Using LOINC with HL7 Standards resolve to a set of LOINC codes that match the criteria specified below. Snow Owl currently supports expansion of the "all codes" and "multi-axial hierarchy entry" variants:

URI
Definition

http://loinc.org/vs

All concepts of the code system

http://loinc.org/vs/LP7756-2

Descendants of LOINC Part LP7756-2|Allergy|

Persisted value sets

Regular value sets are only supported in the paid edition of Snow Owl.

Interactions

read (instance)

GET requests that include the value set identifier as the final path segment return the current (non-versioned) resource state:

The returned response uses a filter mentioned in Filters that is supported by SNOMED CT – this enables including or excluding concepts using an ECL expression.

Similarly to CodeSystem read interactions, query parameters _format, _summary, _elements and _pretty are also applicable, see Common request parameters for a detailed description of these options.

vread (instance)

To retrieve a single historical version of the resource, use the following GET request:

Notable differences between a versioned and the current representation are marked with a comment in the code block above:

  1. If a FHIR URL override value was set in resource settings at the time the version was created, it will be reflected in the response (in this case no such setting has been applied)

  2. Similarly, if the resource was configured to use its native url value as the FHIR version at the time it was created, it will also be reflected in the response (in this example the value of the version ID matches the value returned as the FHIR resource version)

  3. The effective time appears as the value of date

  4. The effective time also appears as the value of effectivePeriod.start

  5. Other properties like changes in value set composition will reflect the state of the resource at version creation time

The version path parameter accepts the following values:

Value
Behavior

HEAD

Returns the current resource representation

LATEST

Returns the most recent historical revision

Any other valid version identifier

Returns the specified historical revision

HEAD is implemented as a fallback to the regular resource read operation, while LATEST selects the latest historical version based on version timestamps.

history (instance)

GET requests that include a resource identifier with a _history path segment added to the end return a FHIR Bundle of type history, containing historical revisions of the specified resource:

Only versioned revisions are returned, not individual edits. The HEAD revision is also omitted from the history bundle.

Supported search parameters are:

Name
Description

_count

Limits the number of returned history entries (50 by default)

_since

Returns revisions created on or after the supplied ISO-8601 instant

_at

Returns revisions created on or before the supplied ISO-8601 instant

Note that while the specification allows a wider set of comparisons for date(time) inputs, Snow Owl currently only supports instant values without a comparison operator prefix.

Allowed values for the _sort parameter:

Value
Behavior

-_lastUpdated

Newest revisions first (default)

_lastUpdated

Oldest revisions first

none

Does not effectively override the default sort

Any other value

400 Bad Request is returned

update (instance)

PUT requests that include a resource identifier will update an existing value set or create a new instance:

The response code is 201 Created if the resource did not exist previously, and the URL is included in the Location response header. Existing value sets (like in the example above) are updated and a 200 OK response is returned instead.

The actual content of Location will differ depending on whether a versioned resource is sent in as the input or a draft one. The former will generate a vread interaction with the version value included, while the latter will be a URL that can be used to issue a read interaction on the most recent content.

If an error occurs during the update, a 400 Bad Request response with an OperationOutcome resource as the response body is emitted instead.

The following non-standard request headers can be used to control certain aspects of the commit process:

Name
Description

X-Effective-Date

The effective date to use if a version identifier is present in the resource without a corresponding date element (defaults to the current date if neither the resource nor this header specifies a value)

X-Author

Sets the user identifier that the commit should be attributed to (defaults to the authenticated user)

X-Owner

Sets the owner of the resource, for access control purposes in external systems (defaults to the author or the authenticated user if the former is not set)

X-Owner-Profile

Sets the human-readable name of the owner of the resource, for presentation purposes in external systems (optional)

X-Bundle-Id

Specifies the parent bundle's resource identifier (defaults to the root bundle if not set)

Value sets are currently limited to a single code system and version (domain) they can refer to when including or excluding concepts.

burst-new

Snow Owl now preserves the name property supplied in imported ValueSet resources. Previously generated or derived names are no longer used when a resource name is provided by the import payload.

delete (instance)

A DELETE request removes an existing value set:

Successful removal of a resource results in a 204 No Content response.

Value sets that have been published can not be removed without adding the force=true query parameter to signal a forced deletion (this option is only available to administrators however). The example value set was never published and so can be deleted without this option.

burst-new

The X-Author request header is optional, the default value corresponds to the authenticated user.

create (type)

In create interactions a POST request is sent to the path corresponding to the resource type. Any identifier included in the request body is ignored and a new, random one is generated from scratch.

FHIR URLs in Snow Owl must be unique. If a resource is submitted to the create interaction where the URL matches the value in an already persisted resource, an update will take place instead.

The response code is 201 Created if the interaction is successful and a new resource has been created, 200 OK if a resource update was performed.

The request URL in the response header named Location can be used in follow-up read or vread interactions; the latter is provided if the input resource also contained version information.

search (type)

GET requests with a request path that points to the resource type returns all value sets that satisfy the specified search criteria, in the form of query parameters. The following example uses the count summary mode to determine the number of draft value sets in the system, without returning any of the matches:

Just as with code system resources, POST requests are unsupported in Snow Owl and will be met with a 405 Method Not Allowed response.

The following search parameters are supported:

Name
Description

_id

Matches value sets by logical identifier

name

Matches value sets by name (in Snow Owl this is set to the logical identifier)

title

Matches value sets by title (Snow Owl uses exact, phrase and prefix matching during its lexical search activities)

url

Matches value sets by their assigned url value

version

Matches value sets by their version value

status

Matches value sets by resource status (e.g. draft, active, etc.)

Operations

$expand

Snow Owl supports the following input parameters for value set expansion:

Name
Description

url

The URI of the value set to expand (can be an implicit or an explicit one)

valueSetVersion

The version of the value set for use for the expansion

activeOnly

To return only active codes in the response

filter

To filter the expanded concepts lexically

includeDesignations

Whether to include all designations or not in the returned response

displayLanguage

To select the language for the returned display values

count

To select the maximum number of codes to be returned in the expansion (10 by default)

after

State tracking parameter for concept set paging

The value set with expanded concepts is returned in its entirety for this request. The expansion element includes a link that can be followed to retrieve the next page of expanded concepts:

The $expand operation returns a paged result. Snow Owl includes a link in the response that can be used to retrieve the next set of expanded concepts, but only if additional results are available. On the last page the expansion property next will not be present.

When expanding a SNOMED CT value set, Snow Owl automatically selects the preferred term for each concept based on the currently selected language. This is controlled by the displayLanguage parameter; if it is unset, the Accept-Language request header is also consulted as a fallback value.

For example, if the expansion request uses the en-GB language setting, concepts will be represented with their GB English preferred terms where available. If en-US is selected, the corresponding US English preferred terms will be returned.

If you need to run the operation on a versioned resource representation, add a valueSetVersion parameter to its input: Operation $expand on ValueSet, In Parameters

Supplying a value set as part of the request (via the input parameter valueSet) is not supported – nor can additional resources be supplied for expansion via the tx-resource input parameter.

$validate-code

The operation is supported both on the instance level (in this case the value set is located by resource ID) as well as the type level (a canonical URL must be supplied in the url input parameter to identify the value set to use).

If you need to run the operation on a versioned resource representation, add a valueSetVersion parameter to its input: Operation $validate-code on ValueSet, In Parameters

Codes can only be validated against persisted value sets, not implicit ones.

The following example checks whether 118363003|Orange laser light| satisfies the aforementioned conditions in the value set containing all basic dose forms we created earlier:

Encountering any of the following conditions will fail the code validation check:

  • The specified value set does not exist

  • The value set does not contain the specified code in its expansion

  • The code does not exist in the code system specified in the request (the corresponding parameter, system is mandatory in Snow Owl)

  • The specified code system version differs from the version referenced by the value set

Combinations of issues are also reported, both as separate OperationOutcome issue objects as well as a semicolon-concatenated message output parameter value.

The following example shows a negative lookup operation result where the concept exists but is not part of the value set:

Last updated