Page tree

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:

NameDescriptionExpressionDiscussion
codeThis special parameter searches for codes in the value set. See additional notes on the ValueSet resourceValueSet.expansion.contains.code | ValueSet.compose.include.concept.codeGeneral 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 TUA use context assigned to the value set(ValueSet.useContext.value as CodeableConcept)See http://build.fhir.org/metadatatypes.html#UsageContext
context-quantity TUA quantity- or range-valued use context assigned to the value set(ValueSet.useContext.value as Quantity) | (ValueSet.useContext.value as Range)
context-type TUA type of use context assigned to the value setValueSet.useContext.code
context-type-quantity TUA use context type and quantity- or range-based value assigned to the value setOn ValueSet.useContext:
  context-type: code
  context-quantity: value.as(Quantity) | value.as(Range)

context-type-value TUA use context type and value assigned to the value setOn ValueSet.useContext:
  context-type: code
  context: value.as(CodeableConcept)

dateThe value set publication dateValueSet.date
descriptionThe description of the value setValueSet.description
expansionIdentifies the value set expansion (business identifier)ValueSet.expansion.identifier
identifier TUExternal identifier for the value setValueSet.identifier
jurisdiction TUIntended jurisdiction for the value setValueSet.jurisdiction
nameComputationally friendly name of the value setValueSet.name
publisherName of the publisher of the value setValueSet.publisher
referenceA code system included or excluded in the value set or an imported value setValueSet.compose.include.system
statusThe current status of the value setValueSet.status
titleThe human-friendly name of the value setValueSet.title
urlThe uri that identifies the value setValueSet.url
versionThe business version of the value setValueSet.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 G. 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 G. 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 G. 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"
}

  • No labels