I have a use case, which I believe is not too uncommon, and I would like to get your opinion, if that’s ok.
We are to publish a number of subsets of SNOMED CT for a national lab medicine specification (specimen types, findings, methods, etc.). The conceptual content is quite easy to find in SNOMED CT so that’s not a problem, but we also want to specify descriptions which are local to the application. E.g. in a list of specimen we want to use shorter, context-dependant terms which might not be good SNOMED CT terms, which we would not like to add to our extension/translation. We would like to have refsetids so we can publish the concepts through the SNOMED route. We could use ValueSet.compose.include.concept.display to add those terms, but that would require that we create an extensional value set. If we use the refsetid for the value set definition we lose the ability to supply display names.
Alternatively, we could add separate language refsets for the application, but that, in my opinion, complicates things for implementers.
Anyone has a solution? Did I get things wrong?
/Daniel
6 Comments
Michael Lawley
Below shows an example of a ValueSet defined in terms of a reference set (by including the contents of the corresponding implicit ValueSet), and that also specifies a different display text for a specific concept.
Peter G. Williams
Did Michael's example answer your question, Daniel, or were you looking for something else? Thanks, Peter
Daniel Karlsson
Kind of... I still find nothing in the specification about that including overlapping value sets is allowed and what the expected expansion is (but maybe I just didn't find it). Also, for the filter operator it is not specified whether display is included or not. Is this something that should be added? The problem of having ValueSet specific terms (descriptions/terms that do not fulfill SNOMED CT inclusion criteria because of (over) ambiguity) seems to be general, and we experience this problem frequently.
Thanks, Daniel
Michael Lawley
To quickly follow up on this, the R4 spec does not appear to include any requirements on terminology servers using additional display / designation text as part of the matching process for evaluating
/ValueSet/$expand?filter=
Additionally it does not talk about how to handle conflicting display values. As I see it, there a three main ways such a potential conflict can arise:
ValueSet.compose
with differing display textI think it would be reasonable to consider the third case above as a mechanism for resolving the conflict characterised by the second case.
This leaves the question of what should a terminology server do for cases 1 and 2?
$expand
,$lookup
, and relevant$validate-code
calls fail with a 400-series resultfilter
value ?) as the returned valueCodeSystem
-defined display valuePeter Jordan
We now have a similar issue in NZ with a set of 'patient-friendly' terms that have been introduced into our Edition via a new Language Reference Set (LRS). In common with all our other descriptions, these have a language code of 'en' and are all preferred terms - so I'm assuming that the LRS is considered to be a 'dialect', otherwise we would now have a number of concepts with two different preferred terms in the same language which, I believe, is not permitted. Either way, from a Terminology Services API perspective, my challenge now is to present the appropriate preferred term in context (provider or consumer) and to prevent unexpected responses from FHIR operation requests where a single preferred term is expected. One thought is to implement them as Code System supplements and restrict their usage to designations returned in $expansion and $lookup requests. What do others think?
Peter Jordan
As promised, here's a simple example of a FHIR ValueSet expansion containing designations from a CodeSystem supplement, returned from this request...
http://its.patientsfirst.org.nz/RestService.svc/Terminz/ValueSet/bundle-type-supplemented/$expand?_summary=data
<ValueSet xmlns="http://hl7.org/fhir">
<id value="bundle-type-supplemented" />
<meta>
<versionId value="1" />
<lastUpdated value="2018-04-13T05:03:16+00:00" />
<tag>
<system value="http://hl7.org/fhir/v3/ObservationValue" />
<code value="SUBSETTED" />
</tag>
</meta>
<url value="http://hl7.org/fhir/bundle-type-supplemented" />
<version value="1" />
<name value="FHIR Bundle Types including german terms defined in a code system supplement" />
<status value="draft" />
<experimental value="true" />
<date value="2018-04-13" />
<publisher value="HL7 International" />
<contact>
<name value="FHIR project team" />
<telecom>
<system value="url" />
<value value="http://hl7.org/fhir" />
</telecom>
</contact>
<description value="Example value set of FHIR Bundle Types including german terms contained in a code system supplement" />
<expansion>
<identifier value="urn:uuid:66e5708b-a742-4527-9ac6-57eeb6aaaad7" />
<timestamp value="2018-09-25" />
<total value="9" />
<offset value="0" />
<parameter>
<name value="version" />
<valueUri value="1" />
</parameter>
<parameter>
<name value="activeOnly" />
<valueBoolean value="true" />
</parameter>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="document" />
<display value="Document" />
<designation>
<language value="de" />
<value value="Dokument" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="message" />
<display value="Message" />
<designation>
<language value="de" />
<value value="Nachricht" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="transaction" />
<display value="Transaction" />
<designation>
<language value="de" />
<value value="Transaktion" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="transaction-response" />
<display value="Transaction Response" />
<designation>
<language value="de" />
<value value="Transaktionsantwort" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="batch" />
<display value="Batch" />
<designation>
<language value="de" />
<value value="Stapel" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="batch-response" />
<display value="Batch Response" />
<designation>
<language value="de" />
<value value="Batch-Antwort" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="history" />
<display value="History List" />
<designation>
<language value="de" />
<value value="Verlaufsliste" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="searchset" />
<display value="Search Results" />
<designation>
<language value="de" />
<value value="Suchergebnisse" />
</designation>
</contains>
<contains>
<system value="http://hl7.org/fhir/bundle-type" />
<code value="collection" />
<display value="Collection" />
<designation>
<language value="de" />
<value value="Sammlung" />
</designation>
</contains>
</expansion>
</ValueSet>
The relevant CodeSystem resources can be downloaded from...
http://its.patientsfirst.org.nz/RestService.svc/Terminz/CodeSystem/bundle-type
http://its.patientsfirst.org.nz/RestService.svc/Terminz/CodeSystem/bundle-type-german
Obviously, the later supplements the former.
Peter J