Page tree

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

  • No labels

6 Comments

  1. 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.

    {
    "resourceType": "ValueSet",
    "url": "http://example.com/spec-type-example",
    "name": "Daniel's Specimen Type ValueSet",
    "status": "draft",
    "compose": {
    "include": [
    {
    "system": "http://snomed.info/sct",
    "concept": [
    {
    "code": "439628000",
    "display": "Urine collection bag"
    }
    ]
    },
    {
    "valueSet": [
    "http://snomed.info/sct?fhir_vs=refset/4021000036102"
    ]
    }
    ]
    }


  2. Did Michael's example answer your question, Daniel, or were you looking for something else?   Thanks, Peter

  3. 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

    1. 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:

      1. The same concept is referenced explicitly two or more times in the ValueSet.compose with differing display text
      2. Two or more other ValueSets are included and between them contribute differing display text
      3. A combination of the above; an explicitly referenced concept has differing display text to that contributed by an included ValueSet(s)

      I 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?

      1. Declare the ValueSet as not well-formed and thus have $expand, $lookup, and relevant $validate-code calls fail with a 400-series result
      2. Pick one display (consistently / at random / first one encountered / last one encountered / best match with filter value ?) as the returned value
      3. Fall back to the CodeSystem-defined display value


      1. 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?

  4. 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