--- type: "valueset" title: "ValueSet: notes" valueset: "notes" --- # ValueSet: notes ## Narrative ## Composition Rules A value set can be a simple list of included codes, or it can be some kind of general selection criteria using the facilities provided by the [code system](codesystem). For these value sets: - Multiple `include` statements are cumulative - e.g. the value set contains the union of all the includes - Within an `include`, all the criterion apply -e.g. the value set contains the intersection of the criterion - Within an `include`, a single system with selection criteria may be listed, and/or one or more value sets may be listed - **`valueSet`(s) only**: Codes are 'selected' for inclusion if they are in all the referenced value sets - If a **`System` only** is specified, the following rules apply: - **no `concept` or `filter`**: All codes defined by the code system, independent of code status, are included - **`concept`**: Only the enumerated codes are selected - **`filter`**: Any codes meeting the filter criteria are selected - **`valueSet` and `System`**: Codes are 'selected' for inclusion if they are selected by the code system selection (after checking for `concept` and `filter`) and if they are in all the referenced value sets - If the system reference is not version specific and filters are present, then the contents of the value set are open and change over time as the underlying code systems are updated - The version reference may be the special value '`*`', which indicates that the value set includes codes from all versions of the code system. how to handle provision of the required versions and generation of expansions is at server discretion, including for poorly behaved code systems where a code changes in meaning). \[%impl-note%\] Use of this capability is subject to future clarification and conformance requirements based on implementation experience. \[%end-note%\] - Using the property filters is only possible where the code system in use defines the relevant properties. Note that in some cases the underlying code system defines the logical concepts but not the syntax for exercising them. In such cases, the literal definitions may be provided by a third party - In addition to include rules, codes may be excluded. Rules for interpretation of exclude statements match those for includes, but codes in the exclude statements are never in the value set - Value sets may include abstract codes - that is, codes designated by the underlying code system as not for use as a selectable concept in a particular context. These abstract codes are typically used as a grouping/searching mechanism, and can be included either by enumerating them, or by using a filter. - Any compose.exclude SHALL be processed such that excluded codes are not found in the expansion - Any compose.include SHALL NOT reference a CodeSystem supplement. - Any compose.exclude SHALL NOT reference a CodeSystem supplement. - Required CodeSystem supplements SHALL be declared using either the valueset-supplement extension, or the useSupplement $expand input parameter. ### Compose The rules for the content of the value set are found in the `ValueSet.compose` element, which are analogous to the Content Logical Definition (CLD) as defined by the [VSD Project](https://confluence.hl7.org/display/VOC/Characteristics+of+a+Value+Set+Definition+%28VSD%29+Project). The ValueSet compose is a set of instructions for what codes are in the ValueSet, and defined by the author consistent with the `ValueSet.description` The ValueSet composition can be defined in a number of ways: - By listing the codes that are in the ValueSet explicitly using `ValueSet.compose.include.concept` - By specifying the codes for inclusion using filter expressions in `ValueSet.compose.include.filter` - If the language in filter cannot be used, using the [Extension ValueSet.valueset-expression]([%extensions-location%]StructureDefinition-valueset-expression) to define some alternative expression, though this can only be evaluated by a system that understands the syntax used in the expression - For a few value sets, there is no formal expression, and the rules are expressed using the [Extension ValueSet.valueset-rules-text]([%extensions-location%]StructureDefinition-valueset-rules-text) that is not computable and is meant to be interpreted by a human. Such value sets are rare The first approach - listing codes explicitly - is called an 'extensional' definition; all the other ways are called 'intensional' definitions. ### Filters **Mapping from VSD to `ValueSet.compose`** | VSD Scenario | FHIR Implementation | | --- | --- | | When the `ValueSet.compose` is an expression (`ValueSet.expression`), declare the type of expression here | - `compose.include.filter.op` = "property" - `compose.include.filter.op` = regex - `compose.include.filter.value` = "property value" | | When the `ValueSet.compose` describes Concepts to include based on CodeSystem properties | `compose.include.filter.property` = "property name" Either the Value or Expression must be provided Value: - `compose.include.filter.op` = "=" - `compose.include.filter.value` =_the value_ Expression: - `compose.include.filter.op` = "regex" - `compose.include.filter.value` =_the Expression_ | | When the `ValueSet.compose` defines the types of relationships between concepts to include in the ValueSet Expansion | `compose.filter.property` = "RelationshipType" (note: filter property is a string in VSD, code in FHIR) - `compose.filter.property.op` = "=" - `compose.filter.property.value` = a code defined by the CodeSystem Example: to find all concepts in SNOMED CT with the SNOMED CT laterality qualifier relationship to the SNOMED CT concept "left": - `filter.property.name` = '272741003' - `filter.property.op` = '=' - `filter.property.value` = '7771000' | ### Using Filter Values The element `compose.include.filter.value` is a string. The actual format of the value depends on the value of `compose.include.filter.op` and/or the definitions of the underlying CodeSystem. The following rules apply (in order). - If the `op` is `regex`, the format is a regex expression - If the `op` is `exists`, the format is a [boolean](datatypes#boolean) (`true` or `false`) - If the `op` is `in` or `not-in`, the format is either a comma-separated list of [code](datatypes#code) values, or an absolute [uri](datatypes#uri), which is a canonical reference to a ValueSet. If the value is a code or list of codes, the interpretation of the codes is subject to the CodeSystem e.g. for SNOMED-CT reference sets. If the value is a valueSet uri, then commas and percents should be percent encoded - If the `property` is `concept`, the format is a [code](datatypes#code) - If the name in `property` refers to a [CodeSystem filter](codesystem#filters), the format is as defined in the filter table on the CodeSystem page, or as described in the applicable `CodeSystem.filter.value` - If the name in `property` refers to a [CodeSystem property](codesystem#defined-props), the format is as defined in the following table The format of `compose.include.filter.value` for Code System Properties depends on the property type: | string | Use the string directly | | --- | --- | | integer | Use the integer value directly | | boolean | Use `true` or `false` | | dateTime | Use ISO 8601 format, following the precision rules for the [dateTime](datatypes#dateTime) data type | | decimal | Use the decimal value directly | | code | Use the code directly | | Coding | Use the format `system`(|`version`)#`code`, which is effectively a [canonical](datatypes#canonical) reference to the CodeSystem, followed by # and then the code in the CodeSystem. There is no way to specify the display | For the ordered data types (integer, decimal and dateTime), the [search prefixes](search#prefix) can be used (eq, ne, gt, lt, ge, le, sa, eb, ap). Note that the Coding syntax is **not** the search syntax. #### Code Systems Note Each [Code System](codesystem) defines which filters can be used in `ValueSet.compose.include.filter`. All code systems have [base filters](codesystem#filter) and any additional filters defined in ([CodeSystem.filter)](codesystem-definitions#CodeSystem.filter). HL7 Terminology defines filters for various published code systems: - [LOINC](https://terminology.hl7.org/LOINC.html) - [SNOMED CT](https://terminology.hl7.org/SNOMEDCT.html) - [RxNorm](https://terminology.hl7.org/RxNorm.html) - [UCUM](https://terminology.hl7.org/UCUM.html) - [CPT](https://terminology.hl7.org/CPT.html) - [NDF-RT](https://terminology.hl7.org/NDFRT.html) ### Union and Intersection `ValueSet.compose` may reference other ValueSets. Intersection: - If the ValueSet definition contains references to multiple ValueSets within a single `ValueSet.compose.include` - The resulting expansion includes only those concepts that are in each expansion of the included ValueSets Union: - If the ValueSet definition contains references to ValueSets using multiple `ValueSet.compose.include` elements - The resulting expansion includes all concepts from the ValueSet expansions For expansion guidance, and how to manage _exclude_, see [Value Set Expansion](valueset#expansion) When a ValueSet definition includes other ValueSets, use the [ValueSet.valueset-compose-include-ValueSetTitle]([%extensions-location%]StructureDefinition-valueset-compose-include-valueSetTitle) extension to provide the human readable name of the included Value Set. ### Referencing CodeSystem Fragments The VSD Partition aligns with FHIR [CodeSystem Fragments](codesystem#fragments). Code System fragments are a unique and identifiable distinct segment of an overall Code System namespace. While most Code Systems are in essence one fragment and, therefore, do not have identifiable fragments, some Code Systems can be made up of a collection of distinct segments. SNOMED CT is an example of such a Code System. The SNOMED CT International Edition is the base fragment and can be used alone, but there are many distinct additional fragments that can be added to the international core to create what is known as a SNOMED CT Edition. The CodeSystem referenced in a `ValueSet.compose` may reference a CodeSystem fragment. ## ValueSet Alignment with VSD ### Author and Publisher Author, Steward and Publisher are roles associated with a Value Set Definition. ValueSet Author is the person or organization that creates and may modify the ValueSet. The Steward is the person or organization responsible for the content, maintenance and life cycle of the ValueSet. The Publisher is the person or organization that makes the ValueSet available. The publisher or a terminology server might provide the ValueSet expansions. In FHIR, `ValueSet.publisher` satisfies the requirements for both publisher and steward. ### Scope and Description Description and Purpose are standard elements that appear in many FHIR resources. Neither fully supports the intent of the VSD Scope element, however `ValueSet.description` does support Focus as defined in VSD. When a ValueSet definition includes other ValueSets, use `ValueSet.description` to provide information about the included value sets in context of the parent value set. Purpose may be used for the `ValueSet.author` to describe why the ValueSet was created. `ValueSet.description` may be used to provide the ValueSet Focus as described in VSD. Example: | Value Set Name | Description | | --- | --- | | Body Site Value Set | All SNOMED CT anatomic structures, locations, abnormal structures that can be considered to describe an anatomical site. | | Familial Hypercholesterolemia | This value set contains terms defining familial hypercholesterolemia, regardless of genetic origin. | ### Name and Title The VSD element _Name_ aligns with `ValueSet.title` which does not support preference or language. Use the [ValueSet.valueset-otherTitle extension]([%extensions-location%]StructureDefinition-valueset-otherTitle) when a language or preference is necessary. `ValueSet.title` or [ValueSet.valueset-otherTitle]([%extensions-location%]StructureDefinition-valueset-otherTitle) must be valued. ### Include Active Concepts Only VSD and FHIR support the constraining the $expand operation to return only active concepts as defined by the CodeSystem. The VSD element _ActiveOnly_ equal to TRUE is equivalent to `ValueSet.compose.inactive` equal to FALSE. ### Status The ValueSet resource defines a Value Set Definition _and_ a Value Set Expansion. VSD describes only the characteristics of the Value Set Definition. The VSD element _ActivityStatus_ aligns with `ValueSet.status`, which is the status of the entire ValueSet resource _with the exception of the_ `ValueSet.expansion`. This aligns with VSD using the word _definition_ to mean the Content Logical Definition _plus_ all the other non-expansion metadata. A Value Set Expansion is stateless. Note: `ValueSet.status` is bound with _required_ binding strength to the [PublicationStatus](valueset-publication-status) value set. The following table shows how the ActivityStatus values in VSD align with the values in the PublicationStatus Value Set Expansion. | VSD Activity Status Value | FHIR Publication Status Value | | --- | --- | | Preliminary | Draft | | Active | Active | | Inactive | Retired | | \* | Unknown | | Deleted | \* | \*There is no equivalent value in either VSD or the PublicationStatus Value Set. ## Display and Designations Concepts used in ValueSets can have a `display`, which is a short text that represents the meaning of the concept to human users in the context of the value set (which often has narrower meaning and therefore is amenable to shorter displays. If a display is not provided, the value set uses the [display from the code system](codesystem#designations) (which is the preferred approach, because overriding the display can lead to very unsafe outcomes). When a value set enumerates codes, it is sometimes useful to define an alternative display for the code that is to be used wherever the value set is expanded and used in a UI. This facility is provided to cover the following circumstances: - The system that defines the code or expression doesn't provide a display for this code (or any codes). - The system that defines the code or expression defines multiple choices for display. - The system provides a very long display name that is unnecessary or inappropriate in the context of this value set (e.g. a display name of "Glucose \[Mass/volume\] in Serum or Plasma --10 PM specimen" for LOINC code 48991-4, when the value set only includes Glucose mass/vol in serum/plasma codes). As the display names get longer, this becomes more important. Note that care must be taken in order to avoid "changing the meaning" of the concept by implying that it means something other than the explicit definition of the concept in the underlying code system (e.g., in the case above, using a display of "Glucose Concentration at 10pm"). For this reason, some contexts of use do not allow a display to be associated with a specific code in a value set. Any display name for a concept provided in the value set is for display to a human user. The display in the [Coding](datatypes#Coding) that results from a user selecting a concept from the expansion must be taken from the underlying code system definition, even if a value set is referenced explicitly in the Coding (e.g. by an [extension]([%extensions-location%]StructureDefinition-valueset-reference)). The correct display for a code can be determined by a [$lookup operation](codesystem-operation-lookup). Any alternative display specified in the value set would go in [CodeableConcept](datatypes#CodeableConcept).text, perhaps appended to the UI label for the matching data element. As an example, the [LOINC](http://loinc.org) code [`55423-8`](https://s.details.loinc.org/LOINC/55423-8.html?sections=Comprehensive) has a display value of "Number of steps in unspecified time Pedometer". A value set for a pick list in a patient generated data form might choose a simpler name: { "resourceType" : "ValueSet", "compose" : { "include" : \[{ "system" : "http://loinc.org", "concept" : \[{ "code" : "55423-8", "display" : "Step Count" }\] }\] } } The expansion generated by a terminology server will have this: { "resourceType" : "ValueSet", "expansion" : { "contains" : \[{ "system" : "http://loinc.org", "code" : "55423-8", "display" : "Step Count" }\] } } The expansion display is taken from the value set, and this is what is displayed in the pick list. Once the user picks the code, it will appear in the [Observation.code](observation-definitions#Observation.code) like this: { "resourceType" : "Observation", "code" : { "coding" : \[{ "system" : "http://loinc.org", "code" : "55423-8", "display" : "Number of steps in unspecified time Pedometer" }\], "text" : "Step Count" } } Note that the correct value for the display is not in the expansion above. The client can either omit the display, look it up using [$lookup](codesystem-operation-lookup), or the server might pre-populate it in the expansion: { "resourceType" : "ValueSet", "expansion" : { "contains" : \[{ "system" : "http://loinc.org", "code" : "55423-8", "display" : "Step Count", "designation" : \[{ "use" : { "system" : "http://snomed.info/sct", "code" : "900000000000003001" }, "value" : "Number of steps in unspecified time Pedometer" }\] }\] } } Irrespective of this, the display in the expansion always goes in [CodeableConcept.text](datatypes-definitions#CodeableConcept.text). ## ValueSet XML ```xml

Composition Rules

A value set can be a simple list of included codes, or it can be some kind of general selection criteria using the facilities provided by the code system. For these value sets:

Compose

The rules for the content of the value set are found in the ValueSet.compose element, which are analogous to the Content Logical Definition (CLD) as defined by the VSD Project. The ValueSet compose is a set of instructions for what codes are in the ValueSet, and defined by the author consistent with the ValueSet.description

The ValueSet composition can be defined in a number of ways:

The first approach - listing codes explicitly - is called an 'extensional' definition; all the other ways are called 'intensional' definitions.

Filters

Mapping from VSD to ValueSet.compose

VSD Scenario FHIR Implementation
When the ValueSet.compose is an expression (ValueSet.expression), declare the type of expression here
  • compose.include.filter.op = "property"
  • compose.include.filter.op = regex
  • compose.include.filter.value = "property value"
When the ValueSet.compose describes Concepts to include based on CodeSystem properties

compose.include.filter.property = "property name"

Either the Value or Expression must be provided

Value:

  • compose.include.filter.op = "="
  • compose.include.filter.value =the value

Expression:

  • compose.include.filter.op = "regex"
  • compose.include.filter.value =the Expression
When the ValueSet.compose defines the types of relationships between concepts to include in the ValueSet Expansion

compose.filter.property = "RelationshipType"

(note: filter property is a string in VSD, code in FHIR)

  • compose.filter.property.op = "="
  • compose.filter.property.value = a code defined by the CodeSystem

Example:

to find all concepts in SNOMED CT with the SNOMED CT laterality qualifier relationship to the SNOMED CT concept "left":

  • filter.property.name = '272741003'
  • filter.property.op = '='
  • filter.property.value = '7771000'

Using Filter Values

The element compose.include.filter.value is a string. The actual format of the value depends on the value of compose.include.filter.op and/or the definitions of the underlying CodeSystem. The following rules apply (in order).

The format of compose.include.filter.value for Code System Properties depends on the property type:

stringUse the string directly
integerUse the integer value directly
booleanUse true or false
dateTimeUse ISO 8601 format, following the precision rules for the dateTime data type
decimalUse the decimal value directly
codeUse the code directly
CodingUse the format system(|version)#code, which is effectively a canonical reference to the CodeSystem, followed by # and then the code in the CodeSystem. There is no way to specify the display

For the ordered data types (integer, decimal and dateTime), the search prefixes can be used (eq, ne, gt, lt, ge, le, sa, eb, ap). Note that the Coding syntax is not the search syntax.

Code Systems Note

Each Code System defines which filters can be used in ValueSet.compose.include.filter. All code systems have base filters and any additional filters defined in (CodeSystem.filter).

HL7 Terminology defines filters for various published code systems:

Union and Intersection

ValueSet.compose may reference other ValueSets.

Intersection:

Union:

For expansion guidance, and how to manage exclude, see Value Set Expansion

When a ValueSet definition includes other ValueSets, use the ValueSet.valueset-compose-include-ValueSetTitle extension to provide the human readable name of the included Value Set.

Referencing CodeSystem Fragments

The VSD Partition aligns with FHIR CodeSystem Fragments.

Code System fragments are a unique and identifiable distinct segment of an overall Code System namespace. While most Code Systems are in essence one fragment and, therefore, do not have identifiable fragments, some Code Systems can be made up of a collection of distinct segments. SNOMED CT is an example of such a Code System. The SNOMED CT International Edition is the base fragment and can be used alone, but there are many distinct additional fragments that can be added to the international core to create what is known as a SNOMED CT Edition.

The CodeSystem referenced in a ValueSet.compose may reference a CodeSystem fragment.

ValueSet Alignment with VSD

Author and Publisher

Author, Steward and Publisher are roles associated with a Value Set Definition.

ValueSet Author is the person or organization that creates and may modify the ValueSet. The Steward is the person or organization responsible for the content, maintenance and life cycle of the ValueSet. The Publisher is the person or organization that makes the ValueSet available. The publisher or a terminology server might provide the ValueSet expansions.

In FHIR, ValueSet.publisher satisfies the requirements for both publisher and steward.

Scope and Description

Description and Purpose are standard elements that appear in many FHIR resources. Neither fully supports the intent of the VSD Scope element, however ValueSet.description does support Focus as defined in VSD.

When a ValueSet definition includes other ValueSets, use ValueSet.description to provide information about the included value sets in context of the parent value set.

Purpose may be used for the ValueSet.author to describe why the ValueSet was created. ValueSet.description may be used to provide the ValueSet Focus as described in VSD.

Example:

Value Set Name Description
Body Site Value Set All SNOMED CT anatomic structures, locations, abnormal structures that can be considered to describe an anatomical site.
Familial Hypercholesterolemia This value set contains terms defining familial hypercholesterolemia, regardless of genetic origin.

Name and Title

The VSD element Name aligns with ValueSet.title which does not support preference or language. Use the ValueSet.valueset-otherTitle extension when a language or preference is necessary. ValueSet.title or ValueSet.valueset-otherTitle must be valued.

Include Active Concepts Only

VSD and FHIR support the constraining the $expand operation to return only active concepts as defined by the CodeSystem.

The VSD element ActiveOnly equal to TRUE is equivalent to ValueSet.compose.inactive equal to FALSE.

Status

The ValueSet resource defines a Value Set Definition and a Value Set Expansion. VSD describes only the characteristics of the Value Set Definition.

The VSD element ActivityStatus aligns with ValueSet.status, which is the status of the entire ValueSet resource with the exception of the ValueSet.expansion. This aligns with VSD using the word definition to mean the Content Logical Definition plus all the other non-expansion metadata. A Value Set Expansion is stateless.

Note: ValueSet.status is bound with required binding strength to the PublicationStatus value set. The following table shows how the ActivityStatus values in VSD align with the values in the PublicationStatus Value Set Expansion.

VSD Activity Status Value FHIR Publication Status Value
Preliminary Draft
Active Active
Inactive Retired
* Unknown
Deleted *

*There is no equivalent value in either VSD or the PublicationStatus Value Set.

Display and Designations

Concepts used in ValueSets can have a display, which is a short text that represents the meaning of the concept to human users in the context of the value set (which often has narrower meaning and therefore is amenable to shorter displays. If a display is not provided, the value set uses the display from the code system (which is the preferred approach, because overriding the display can lead to very unsafe outcomes).

When a value set enumerates codes, it is sometimes useful to define an alternative display for the code that is to be used wherever the value set is expanded and used in a UI. This facility is provided to cover the following circumstances:

Note that care must be taken in order to avoid "changing the meaning" of the concept by implying that it means something other than the explicit definition of the concept in the underlying code system (e.g., in the case above, using a display of "Glucose Concentration at 10pm"). For this reason, some contexts of use do not allow a display to be associated with a specific code in a value set.

Any display name for a concept provided in the value set is for display to a human user. The display in the Coding that results from a user selecting a concept from the expansion must be taken from the underlying code system definition, even if a value set is referenced explicitly in the Coding (e.g. by an extension). The correct display for a code can be determined by a $lookup operation. Any alternative display specified in the value set would go in CodeableConcept.text, perhaps appended to the UI label for the matching data element.

As an example, the LOINC code 55423-8 has a display value of "Number of steps in unspecified time Pedometer". A value set for a pick list in a patient generated data form might choose a simpler name: 

{
  "resourceType" : "ValueSet",
  "compose" : {
    "include" : [{
      "system" : "http://loinc.org",
      "concept" : [{
        "code" : "55423-8",
        "display" : "Step Count"
      }]
    }]
  }
}

The expansion generated by a terminology server will have this: 

{
  "resourceType" : "ValueSet",
  "expansion" : {
    "contains" : [{
      "system" : "http://loinc.org",
      "code" : "55423-8",
      "display" : "Step Count"
    }]
  }
}

The expansion display is taken from the value set, and this is what is displayed in the pick list. Once the user picks the code, it will appear in the Observation.code like this: 

{
  "resourceType" : "Observation",
  "code" : {
    "coding" : [{
      "system" : "http://loinc.org",
      "code" : "55423-8",
      "display" : "Number of steps in unspecified time Pedometer"
    }],
    "text" : "Step Count"
  }
}

Note that the correct value for the display is not in the expansion above. The client can either omit the display, look it up using $lookup, or the server might pre-populate it in the expansion: 

{
  "resourceType" : "ValueSet",
  "expansion" : {
    "contains" : [{
      "system" : "http://loinc.org",
      "code" : "55423-8",
      "display" : "Step Count",
      "designation" : [{
        "use" : {
          "system" : "http://snomed.info/sct",
          "code" : "900000000000003001"
        },
        "value" : "Number of steps in unspecified time Pedometer"
      }]
    }]
  }
}

Irrespective of this, the display in the expansion always goes in CodeableConcept.text.

In addition to the display, a concept can have one or more designation elements. The display is equivalent to a special designation with an implied designation.use of "primary code" and a language equal to the Resource Language. The designations can provide additional displays for other languages, as well as designations for other purposes. When using concepts, applications use the display unless the language or usage in context provides a reason to use one of the designations.

Value Sets with multiple code systems

Value sets may select codes from multiple code systems - either by including codes from different systems, or importing other value sets that include them. A typical use for crossing code systems is when including a set of codes, and adding a few additional codes to cover cases not catered to by the included codes (e.g. Data missing or workflow error codes).

Best Practice Note: Mixing definitional systems offers the potential for confusing, overlapping, and inconsistent definitions. Creating value sets that cross code systems should be done with care to avoid creating definitional confusion.

Value sets should only include well differentiated concepts, but many value sets and code systems do not have well differentiated concepts because of various real-world constraints.

Value Set Expansion

A value set can be "expanded", where the definition of the value set is used to create a simple collection of codes suitable for use for data entry or validation. There is a defined operation $expand to ask a server to perform this expansion. Expansions are most useful when a value set includes all the codes in a code system, or a set of codes by filter.

A resource that represents a value set expansion includes the same identification details as the definition of the value set, and MAY include the definition of the value set (.compose). In addition, it has an .expansion element which contains the list of codes that constitute the value set expansion. Each contained code can include nested contained codes - see below for further discussion.

When a request for an expansion is received (e.g., for the $expand operation), the following process should be followed:

The final "result set" is then represented in expansion. Note that the expansion structure is inherently ordered; this specification does not fix the meaning of use of the order. The conceptual approach described should not be understood to prohibit any implementation approach in these regards. In addition, note that the method described above is a conceptual approach; individual servers may choose to follow alternative approaches that are more efficient, as long as the outcome is the same.

[%dragons-start%]

The impact of Code System supplements on value set expansion - and therefore value set validation - is subject to ongoing experimentation and implementation testing, and further clarification and additional rules might be proposed in future versions of this specification.

[%dragons-end%]

Hierarchical Expansions

The expansion MAY be hierarchical - that is, it may have contains element that contain their own sub-elements, to any level of depth. This specification does not fix the meaning of the hierarchy: there is no implication about the logical relationship between the nested contain elements, and the structure cannot be used for logical inferencing. The structure exists to provide navigational assistance for helping human users to locate codes in the expansion.

Note that the CodeSystem resource and ValueSet.compose offer no direct support for defining hierarchies and groups. An expansion may include entries in the expansion that only serve an arbitrary grouping purpose, to make it easier for a human to use the list. These entries have no system or code, and must be marked as abstract.

Uniqueness of Concepts in Expansions

Value set definitions may lead to more than one instruction to include a given concept in the value set across the includes and imports. No matter how many times the definitions include a concept, it is only present in the value set once, and will only appear once in a flat expansion of the value set. Note, however, that a concept may appear more than once in a nested hierarchy when the expansion is prepared for UI use (irrespective of how many times it is included in the definitions). Note that uniqueness is based on system/version/code; it is possible to include the same concept from different versions of a code system in the same expansion, though this is generally confusing for users and should be avoided.

The codes in the expansion should be treated as case sensitive - implementers should use the correct case. Implementers can consult the definition of the underlying code systems to determine whether the code system that defines the code is case sensitive or not.

Expansion Identifiers

It is important that expansions be identified properly. Any value set definition may produce an infinite number of expansions, depending on the operation parameters. Any expansions produced must be clearly identified so that there is no confusion. The following rules apply:

Expansion Parameters

The expansion contains a set of parameters in ValueSet.expansion.parameter that record what controlled the expansion process. These parameters may be used by users of expanded value sets to check whether the expansion is suitable for a particular purpose, or to pick the correct expansion. The server decides which parameters to return in ValueSet.expansion.parameter, but at a minimum, the list SHOULD include:

The following parameters are predefined by the $expand operation, and are suitable for use in the expansion parameters:

[%shortparameterlist ValueSet/$expand:filter,date,offset,count,includeDesignations,designation,includeDefinition,activeOnly,excludeNested,excludeNotForUI,excludePostCoordinated,displayLanguage,exclude-system,system-version,check-system-version,force-system-version%]

The count and offset parameters are important. If the expansion is a page out of the whole expansion, the offset and count parameters SHALL be populated. Clients can reliably use the count/offset parameters to determine whether the whole expansion is returned.

Other parameters that servers may be required to use:

[canonical]#CodeSystem.content[content] : The content value for the code system for the canonical URL. Applications generating expansions SHALL use this parameter if the CodeSystem.content value is "fragment"
[canonical1]#supplement[canonical2] : Indicates that the specified supplement (canonical2) contributed to the content of the expansion for the code system canonical1 (by influencing selection, or providing designations). Applications generating expansions SHALL use this parameter to record that a supplement was used during the expansion process

There's also some parameters that only go in the response to an expand, so that the server can inform the consumer of the expansion which value sets, code systems and supplements were used as the basis for the expansion:

used-systemuriThe canonical URL (system | {version} if available) of a code system that was used during the expansion of the value set
used-supplementuriThe canonical URL (system | {version} if available) of a code system supplement that was used during the expansion of the value set
used-valueseturiThe canonical URL (system | {version} if available) of a different value set that was used during the expansion of the value set

Beyond all these parameters, servers MAY define their own parameters, though Terminology server authors are requested to bring additional parameters to HL7 (via 'Propose a change' link below) in the interests of interoperability.

Servers can also create and store Provenance statements about the expansion, or AuditEvent records of the expansion process if further transparency is required. These resources can contain considerable detail about the various inputs to the process, and any significant decisions by the expansion engine. Further details around this (and profiles on the relevant resources) may be provided in future versions of this specification or related implementation guides.

[%feedback-note%] The existing set of parameters are intended to cover the vast majority of use cases, but there are some cases where the parameters do not provide enough control to a client, particularly with regard to combinations of parameters, and the interplay between code system versions and other parameters. Implementers may need to define their own value sets to meet these requirements.

Ongoing feedback is welcome at [link to be provided] [%end-note%]

Storing Expansions

Whether to store expanded value sets, or simply to store their definitions and expand on the fly is a matter for system deployment. Some servers, including public value sets servers, only store expansions. However, any system that stores an expansion must be concerned with how to determine whether the expansion is still current, and this requires deep knowledge of how the expansion was created. A system with a dedicated terminology server that returns expansions on demand avoids this problem, but leaves open the question of how to audit the specific expansion that was used for a particular case. One solution to this is to use a dedicated terminology server, and have the clients ask for expansions on demand based on the value set definitions, and for the server to store (and reuse as appropriate) the returned expansion (when it reuses the expansion, ValueSet.expansion.identifier will be the same). If expansions are shared, users need to be aware of how expansion identifiers (which may be server specific) work.

Searching for codes in value sets

The search parameters defined on ValueSet include the code parameter. This is intended to allow a consumer to find all the value sets that include a particular code. However, fully evaluating this search parameter is extremely onerous for a server. Further, whether a code is in a value set depends on the context in which expansions are performed (see the $expand operation). For this reason, the degree to which the search parameter is supported can be declared in the Terminology Capability statement.

Combinations of .compose and .expansion

Use cases for the different combinations:

Implicit Value Sets

Instead of a ValueSet resource as the definition, implicit value sets are defined in a specification which references the underlying code system structures and includes a prescribed URI pattern to identify the value set. HL7 has defined implicit value set URI patterns for some key code systems.

Implicit value sets allow the URI to serve as the basis for ValueSet operations such as $expand and $validate-code without the need to create a defining ValueSet resource instance.

Some advantages of using implicit value sets are that they may be used:

In some cases it is not possible to express a value set definition using ValueSet.compose - but it may be possible to express the value set definition with an implicit value set URI. An example of this scenario is all SNOMED CT concept IDs that identify reference sets.

If there is an explicit value set resource with the same URI as a known implicit value set, it SHALL conform the pattern described in the definition of the implicit value set. It is up to the discretion of the server how to handle explicit instances when it is also able to process requests for the implicit value set.

[%impl-note%] If the relevant server(s) support implicit value sets, implementers are discouraged from creating their own explicit value sets with the same URI, as their existence may create confusion. [%end-note%]

Implementers SHOULD NOT create ValueSet resources where the ValueSet.url value matches the pattern of a known implicit value set.

Implicit value set URIs can be used anywhere a value set URI can be used. Support for implicit value set URI patterns varies across terminology servers.

Some (but not all) code systems have implicit value set URI patterns defined by HL7 and documented for use with FHIR terminology services. Code system publishers may also define implicit value set URI patterns. FHIR terminology servers might or might not support any or all of these URI patterns. Caution should be exercised when using value set URI patterns that have not been defined by HL7 or the code system publisher.

The following links describe the currently defined FHIR implicit value set URL patterns for these listed code systems:

```