FHIR Chat · Codesystem: get code for display · implementers

Stream: implementers

Topic: Codesystem: get code for display

Patrick Werner (Feb 04 2020 at 12:44):

i always thought there was a operation to get (potential) codes for a display value. Unfortunately i couldn't find such an operation.
use case: study nurses entering diagnoses into text field. The field is autocompleting by display values of concepts of a CodeSystem (ICD 10), when automcompletion triggered the corresponding ICD code is used to capture the diagnosis

Richard Kavanagh (Feb 04 2020 at 13:20):

Perhaps the $expand on ValuseSet with the filter set to your input text

Rob Hausam (Feb 04 2020 at 13:36):

Probably what you are thinking of, @Patrick Werner, is the CodeSystem $find-matches operation? If I understand what you are wanting, it seems like it would fit. But so far I don't know of anyone who has actually used it - or if any terminology server has actually implemented it? Richard's suggestion of $expand on ValueSet with a filter is more mainstream and likely useful.

Patrick Werner (Feb 04 2020 at 13:55):

Thank you both for your suggestions. $find-matches looks good (wasn't aware that i could use it for a display lookup). Also $expand is a nice workaround.
I'm still wondering why $lookup doesn't support display as an input parameter. Would be so easy and convenient.

Richard Kavanagh (Feb 04 2020 at 14:22):

Ah - I was looking at STU3 and had not noticed the new operation in R4. As per the documentation, it should be noted that that operation is currently tagged as "Trial Use".

Yunwei Wang (Feb 04 2020 at 15:07):

@Patrick Werner I think this is a typical ValueSet use case. You have a value set expansion bound to the input field and use some logic to filter the available coding based on the user input.

Marcelo Cabello (Feb 06 2020 at 14:31):

Agree with @Patrick Werner . Time before I was looking a way to search by name of the concept (_display_) (https://chat.fhir.org/#narrow/stream/179202-terminology/topic/search.20concepts.20by.20name). Nowaday, for that search I have to use a VS and $expansion + filter to get a concept.

Michael Lawley (Feb 08 2020 at 03:50):

I would not have expected $find-matches (which AFAIK is not a widely supported operation) to be used for this purpose.
If you want to search for a code in a CodeSystem by designation ('display' is just a special designation), then $expand with the filter parameter is the way to go. It requires you to either know the URI for the code system's all codes ValueSet or to POST a ValueSet with compose.include.system = the code system's URI

Rob Hausam (Feb 08 2020 at 10:33):

That was my final suggestion, too - as I agree that at this point $find-matches certainly isn't widely (or at all) supported (and possibly it won't ever be?).

Patrick Werner (Mar 21 2020 at 17:43):

the expand with filter works nice for searching a code for a display, lookup on CS is good for getting the display of a code. Still think it would be nice to have a operation which does both through string matching at the same time.
UseCase: auto-completing suggestion list input field for diagnosis codes. Some physicians enter the code, some want to search through the display values. Very dirty hack: adding the codes to the display values, so they also will be found when filter expanding.
If $find-matches would have a display IN property, it could be used for both.

Patrick Werner (Mar 21 2020 at 17:44):

(Yes we also could do 2 Rest calls for every debounced entry into the input list: lookup and expand with filter. But this doubles the requests, and the js client has to merge the two concept sets

Joshua Wiedekopf (Jul 09 2021 at 09:03):

I stumbled on this thread in a search for servers that implement find-matches, and couldn't find any! Neither the known terminology servers nor the common reference implementations seem to support it. Does anyone know of a server that does implement find-matches?

I'm asking mostly not because I need that operation for something, but because I wanted to try it out in action to get a feel for the operation and to find use-cases for it (we are working on requirements specifications for a national terminology server in Germany, and are wondering about the merits of that operation). I've written a script to post that operation to a server, but testing proves difficult without any endpoints. The only real mention I could find are these slides from DevDays 2019 by @Rob Hausam, where you said that there is "Very Limited server support and experience". Do you know of some implementation that I haven't found? ;)

I am now thinking of implementing a proof-of-concept server that exposes find-matches so we can try and get a feel for that operation. Otherwise, I would have to agree with Rob's conclusion in their presentation: if no one implements find-matches (which will only happen if implementers want it), it might need to be withdrawn.

Alexander Zautke (Jul 09 2021 at 09:08):

@Joshua Wiedekopf Firely Server implements $find-matches. See https://docs.fire.ly/projects/Firely-Server/en/latest/features/terminology.html

Alexander Zautke (Jul 09 2021 at 09:09):

Only limitation here is that it only works for CodeSystems that can upload to the administration database of Firely Server. So no LOINC or SNOMED CT support at the moment. You could try it with matching the properties for ICD-10-GM for example.

Alexander Zautke (Jul 09 2021 at 09:09):

Let me know if you need assistance in getting it up and running.

Joshua Wiedekopf (Jul 09 2021 at 09:10):

Thanks! I'll make sure to get a new evaluation licence for firely server after my holiday ;)

Rob Hausam (Jul 09 2021 at 13:02):

@Alexander Zautke That's good to know that Firely Server does support $find-matches. I'll have to take a look at that. I am curious how you have dealt with the 'exact' parameter, and the corresponding note suggesting that setting exact=false indicates that "potential matches based on text matching are desired". One issue, of course, is that we are looking at matches based on properties, and (certainly strictly speaking in FHIR) designations are not properties. In a rather "property-rich" code system, like SNOMED CT, I think this actually might prove to be useful and usable. But I wouldn't expect that a code system like ICD-10-GM (or other ICD variants) would have many (if any) properties that could be leveraged. It would be interesting to look at a CodeSystem resource example for ICD-10-GM (is there an official one?) and see what may be available. @Joshua Wiedekopf

Joshua Wiedekopf (Jul 09 2021 at 13:08):

+1!
Well, sort of official. We (as the Medical Informatics community in Germany) are working on a proper infrastructure to distribute those resources in FHIR. Until then, your best bet if you want to take a look is: https://simplifier.net/medizininformatikinitiative-moduldiagnosen/codesystemicd10gm2021 , since ICD-10-GM is provided in CLaML, not FHIR by the respective federal agency...

Joshua Wiedekopf (Jul 09 2021 at 13:10):

We do have some properties on that:

"property":  [
        {
            "code": "kind",
            "type": "code"
        },
        {
            "code": "coding-hint",
            "type": "string"
        },
        {
            "code": "exclusion",
            "type": "string"
        },
        {
            "code": "inclusion",
            "type": "string"
        },
        {
            "code": "introduction",
            "type": "string"
        },
        {
            "code": "modifierlink",
            "type": "string"
        },
        {
            "code": "note",
            "type": "string"
        },
        {
            "code": "preferredLong",
            "type": "string"
        },
        {
            "code": "text",
            "type": "string"
        }
    ],

I am not sure whether there are use cases that wouln't be better adressed by an appropriate ValueSet, but they are there... :)

Alexander Zautke (Jul 09 2021 at 13:37):

Rob Hausam said:

Alexander Zautke That's good to know that Firely Server does support $find-matches. I'll have to take a look at that. I am curious how you have dealt with the 'exact' parameter, and the corresponding note suggesting that setting exact=false indicates that "potential matches based on text matching are desired". One issue, of course, is that we are looking at matches based on properties, and (certainly strictly speaking in FHIR) designations are not properties. In a rather "property-rich" code system, like SNOMED CT, I think this could actually might prove to be useful and usable. But I wouldn't expect that a code system like ICD-10-GM (or other ICD variants) would have many (if any) properties that could be leveraged. It would be interesting to look at a CodeSystem resource example for ICD-10-GM (is there an official one?) and see what may be available. Joshua Wiedekopf

Sorry to disappointment. It's a rather basic implementation. Only it only returns partial or complete matches, we have no means of guessing what is a "possible" match.

Alexander Zautke (Jul 09 2021 at 13:38):

Except that everything excluding property.subproperty should be working. I haven't heard of anyone using it, happy to get some feedback on the implementation.

Last updated: Apr 12 2022 at 19:14 UTC