Stream: terminology
Topic: Mapping to a combination of code systems
Feikje Hielkema (Feb 07 2020 at 14:02):
We're working on a mapping between code systems which we'd like to export as a FHIR concept map. The source code system is a national table of laboratory tests used by GP's; these are mapped to a combination of LOINC and SNOMED, which are used by the laboratories who execute the tests and report the results back. Where the GP's use a single code for the combination of test and specimen (e.g. bacterial culture in urine), the labs frequently record it with a LOINC-code with unspecified specimen and a SNOMED code for the specimen (e.g. 6463-4
Bacteria identified in Unspecified specimen by Culture & 122575003 |Urine (specimen|).
Our first attempt at an example of this mapping contained one ConceptMap element with two group elements: one for SNOMED and one for LOINC. We received as feedback the suggestion two split it into two separate ConceptMaps. However I hesitate to adopt this suggestion, because I feel it would make the mapping harder to maintain (e.g. to ensure that the LOINC and SNOMED codes are compatible) and also that it would obscure the intention of the mapping: which is to map to the combination of both SNOMED and LOINC, not to either SNOMED or LOINC.
I would welcome a second opinion!
Alexander Henket (Feb 07 2020 at 18:35):
@Rob Hausam | @Michael Lawley This is the one we briefly talked about. I did not know about/realize this particular interrelationship between the SNOMED and LOINC parts of the mapping or I would have mentioned.
In FHIR you would apply LOINC parts of the mapping to Observation(.component).code while the SNOMED CT parts are helpful in Specimen.type connected to the Observation.
So while the mappings only make sense in conjunction they context of use in FHIR varies.
Rob Hausam (Feb 08 2020 at 06:34):
@Feikje Hielkema I think what is likely critical to the understanding of what you are requesting is "the combination of both SNOMED and LOINC". And with that understanding there may be a very good argument for using a combined single ConceptMap instance as you are considering. But I think that having some additional more specific examples would help a lot in determining if that in fact is likely to be the best approach.
Rob Hausam (Feb 08 2020 at 06:36):
@Alexander Henket I think that maybe I understand what you are describing, but I'm not really certain. Could you provide further examples or description?
Michael Lawley (Feb 08 2020 at 09:28):
It seems to me that this is probably a use-case for target.product where target.code would be the LOINC code and target.product.value is the SNOMED code (and target.product.property is the URI for Specimen.type).
Christof Gessner (Feb 08 2020 at 09:35):
Looks to me like a generic challenge of mapping between code systems with different granularity or scope. Also related to TermInfo problem. Another example is C-NPU to (LOINC & UCUM).
Feikje Hielkema (Feb 10 2020 at 08:38):
@Rob Hausam I'll list two examples that are typical of our two user types (clinical chemistry and microbiology): 1) source system code 1339 'kweek urethra' (lit. culture urethra), maps to LOINC 6463-4 |Bacteria identified in Unspecified Specimen by Culture| AND SNOMED 119393003 |Specimen from urethra (specimen)|; 2) 2979 'ijzer urine 24u' (lit. iron 24h), maps to LOINC (25937-4 |Iron [moles/volume] in 24 hour Urine| OR 14799-1 |Iron [Moles/time] in 24 hour Urine|) AND to SNOMED 276833005 |24 hour urine sample (specimen)
NB. LOINC contains more codes with which to measure iron in urine, but these are the only two in the Dutch Labcodeset (our target system), hence the only two we map to.
The reason we need the SNOMED concepts, is that the microbiologists consider the system field in LOINC insufficient; they require more detailed information on type, topography, morphology and collection method of the specimen. An initial attempt to extend LOINC with measurements which included the specimen led to the submission of >2.000 concepts and a backlog of two years at Regenstrief, and the microbiologists barely scratched the surface; so they abandoned that. So, we represent a labtest as a combination of LOINC and SNOMED in our Labcodeset; and the local table of the GP's needs to map to that combination.
Feikje Hielkema (Feb 10 2020 at 08:44):
@Michael Lawley You propose that we use one group, target system LOINC, but with the SNOMED specimen as the value of target.product in that group? That does seem a lot easier to parse, I mean it's more obvious that way that the mappings belong together. I don't really understand the documentation of 'dependsOn': what kind of element/value can we store there? Where could I find an example?
Feikje Hielkema (Feb 10 2020 at 08:45):
@Christof Gessner The C-NPU to LOINC/UCUM mapping sounds highly relevant; where could I find it?
Grahame Grieve (Feb 10 2020 at 08:50):
this example in the spec seems relevant: http://hl7.org/fhir/conceptmap-example-specimen-type.html
Christof Gessner (Feb 10 2020 at 09:16):
@Feikje Hielkema I was not precise: Such a mapping C-NPU to LOINC/UCUM would be another example. I don't have it available, but it will be discussed in the context of EU cross-border exchange of lab data. There was a cooperation between the organisations a few years back, but is has been dormant since then.
Feikje Hielkema (Feb 10 2020 at 09:23):
@Christof Gessner Oh, shame, it sounded very relevant; well, it clearly will be :-) In fact, our Labcodeset also contains UCUM units which are recommended for use in the Netherlands; but as the GP source table doesn't specify units of measurement, that bit is fortunately out of scope for our current mapping. One less complication to deal with!
Christof Gessner (Feb 10 2020 at 09:34):
@Feikje Hielkema Some work being done in the context of a funded project in Germany: https://www.miracum.org/wp-content/uploads/2018/12/Bietenbeck-et-al.-2018-NPU-LOINC-and-SNOMED-CT-a-comparison-of-termino.pdf
Christof Gessner (Feb 10 2020 at 09:34):
@Feikje Hielkema And apparently also in Sweden for SNOMED: https://confluence.ihtsdotools.org/display/FT/201931+SNOMED+CT%2C+NPU+and+LOINC+integration+for+semantic+interoperability+of+laboratory+test+results?preview=/87042653/87043077/201931%20SCT%20Expo%202019%20-%20Karlsson.pdf
Alexander Henket (Feb 10 2020 at 10:24):
@Feikje Hielkema actually... a mapping to UCUM already existed for years to support V3.
Feikje Hielkema (Feb 10 2020 at 15:10):
FHIR-NHG-map-example.xml @Rob Hausam I've updated our example mapping XML with your suggestion to use the product element. Could you check if this example is correct? I like the solution, it's much easier to understand than the original (which had the mapping split in two groups).
Michael Lawley (Feb 11 2020 at 00:26):
I'm not convinced that the HTML rendering in http://hl7.org/fhir/conceptmap-example-specimen-type.html is acurate -- it suggests that the values in the product element belong to the targetCanonical ValueSet, but this is not actually the case.
Grahame Grieve (Feb 11 2020 at 02:53):
yes it's definitely not satisfactory
Last updated: Apr 12 2022 at 19:14 UTC
