Working with ValueSets

Notes on versioning and modules

Use of ValueSet versioning in relation to SNOMED CT modules / versions

When authoring ValueSets, do not tie them to a particular version of the terminology (or risk a maintenance nightmare)

https://snowstorm-fhir.ihtsdotools.org/fhir/ValueSet/GPS/$expand?system-version=http://snomed.info/sct|http://snomed.info/sct/module/X/version/20200131

SNOMED allows the membership of a set to be made inactive (the concept is considered to be no longer part of the set at this point), independently of the active state of the concept itself. In FHIR elements are deleted entirely when they are no longer part of the ValueSet - a previous version would need to be consulted.

Filtering a ValueSet with ECL during Expansion

No, you can't mix ECL and named ValueSets at expansion time.

But if a ValueSet was based on a ReferenceSet then an implicit ValueSet could be constructed which was the intersection between the members of the reference set and some other ECL.

Searching for a specific ValueSet

The specification page https://build.fhir.org/valueset.html#search indicates a number of parameters that can be specified in order to search for matching ValueSets:

Name	Description	Expression	Discussion

Name	Description	Expression	Discussion
code	This special parameter searches for codes in the value set. See additional notes on the ValueSet resource	ValueSet.expansion.contains.code \| ValueSet.compose.include.concept.code	General agreement to only search ValueSet.compose.include.concept. This is backed up by comments in http://build.fhir.org/valueset.html#search 4.9.9.6 and this is declared in Terminology Capabilities http://build.fhir.org/terminologycapabilities-definitions.html#TerminologyCapabilities.codeSearch
context TU	A use context assigned to the value set	(ValueSet.useContext.value as CodeableConcept)	See http://build.fhir.org/metadatatypes.html#UsageContext
context-quantity TU	A quantity- or range-valued use context assigned to the value set	(ValueSet.useContext.value as Quantity) \| (ValueSet.useContext.value as Range)
context-type TU	A type of use context assigned to the value set	ValueSet.useContext.code
context-type-quantity TU	A use context type and quantity- or range-based value assigned to the value set	On ValueSet.useContext: context-type: code context-quantity: value.as(Quantity) \| value.as(Range)
context-type-value TU	A use context type and value assigned to the value set	On ValueSet.useContext: context-type: code context: value.as(CodeableConcept)
date	The value set publication date	ValueSet.date
description	The description of the value set	ValueSet.description
expansion	Identifies the value set expansion (business identifier)	ValueSet.expansion.identifier
identifier TU	External identifier for the value set	ValueSet.identifier
jurisdiction TU	Intended jurisdiction for the value set	ValueSet.jurisdiction
name	Computationally friendly name of the value set	ValueSet.name
publisher	Name of the publisher of the value set	ValueSet.publisher
reference	A code system included or excluded in the value set or an imported value set	ValueSet.compose.include.system
status	The current status of the value set	ValueSet.status
title	The human-friendly name of the value set	ValueSet.title
url	The uri that identifies the value set	ValueSet.url
version	The business version of the value set	ValueSet.version

Which Description type should be returned?

Terms that are returned when requesting implicit valuesets. Snowstorm returns FSN, Ontoserver returns Preferred Terms.

ML: Intention is that this list would be used to populate a resource and so the PT is appropriate "The best display is the preferred". DisplayLanguage parameter should be used for the client to specify what they want - how would we use that for FSN vs PT vs Other (eg Patient Friendly Terms)?

Designation parameter should be used to recover the FSN (pulls from Designation Use ValueSet)

@Rob Hausam add to agenda for discussion (Designation Use ValueSet) in Atlanta (Sept)

@Peter Williams rework Snowstorm to return PT by default and FSN as additional designation when designation parameter is present

Group's current interpretations is that includeDesignations=true (with no other designations specified) would return all designations whereas specifying the specific designations is a request to return those specific designations.

Note for Vocab group that although 900000000000548007 |Preferred (foundation metadata concept)| exists, we do not ( ?) have a concept to represent patient friendly terms.

Note issue with licence restrictions in ValueSet. Tracker needed to remove text -

@Reuben Daniels to raise tracker to note that FSN and Preferred Term concepts are now part of the GPS therefore licence restrictions no longer apply. See 22856.

@Jane Millar to note that additions to this ValueSet would require adding << 900000000000511003 |Acceptability (foundation metadata concept)| to the FHIR Free Set

@Peter Williams add to agenda for KL. Is this really needed? Do we just need to specify a table in the IG of what parameter to specify and what to expect back in each case.

@Peter Williams move this item to IG pages.

Example ValueSet using descendants and exclusion:

{"resourceType": "ValueSet",
"url": "http://csiro.au/ValueSet/education-levels",
"id" : "education-levels",
"version": "1",
"name": "Education Levels",
"status": "draft",
"compose": {
"include": [{
"filter": [{ "property": "concept",
"op": "is-a",
"value": "365460000"},

{ "property": "constraint",
"op": "=",
"value": "<<365460000" }],
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/32506021000036107/version/20160630"
}],
"exclude": [{ "concept": [
{"code": "224298008"},
{"code": "365460000"},
{"code": "473462005"},
{"code": "424587006"}],
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/32506021000036107/version/20160630"
}]
},
"description": "A selection of Education Levels",
"text": {"status": "generated"},
"experimental": true,
"date": "2016-07-26"
}