Stream: terminology
Topic: Mapping of 1 OPS to several SNOMED CT within FHIR
Andrea Riedel (Aug 20 2020 at 15:17):
Dear FHIR community,
I am a newbie here and read an interesting study about „aligning an administrative procedure coding system with SNOMED CT“ (http://ceur-ws.org/Vol-2518/paper-ODLS8.pdf). Now I am uncertain how I can map different SNOMED CT codes, which stand for 1 OPS procedure, within one ConceptMap. Moreover, the paper differentiates between the logical connections AND, OR, and ADD.
I was thinking about to use the postcoordinated expressions (https://confluence.ihtsdotools.org/display/DOCSTART/7.+SNOMED+CT+Expressions).
I am really looking forward to hear about your experiences. Maybe you can give me a solution for these two examples of the pages 9/10:
OPS: 1-430.1 Endoscopic biopsy of respiratory organs: bronchus
SNOMED CT 1: 312849006312849006 Biopsy of bronchus
SNOMED CT 2: 10847001 Bronchoscopy
logical connection: ADD
OPS: 1-490.6 Biopsy without incision on skin and subcutaneous tissue: lower leg
SNOMED CT 1: 287538006 Non-surgical skin biopsy
SNOMED CT 2: 118714000 Procedure on lower leg
logical connection: AND
Lloyd McKenzie (Aug 23 2020 at 18:29):
I'm not familiar with any mechanism in ConceptMap to map to a 'combination' of concepts. If you can't define your concept in SNOMED CT using post-coordination, then I think you'd be looking at introducing a modifier extension to ConceptMap to do what you're looking for. @Rob Hausam @Grahame Grieve
Grahame Grieve (Aug 23 2020 at 21:08):
map to a 'combination' of concepts
that's what ConceptMap.group.element.target.dependsOn and ConceptMap.group.element.target.product are for. They don't work that well, but it's a tough problem
Michael Lawley (Aug 23 2020 at 22:01):
Your second example is a straight forward post coordination with + I.e., 287548006+118714000
The first example is more complex since it's a composite procedure -- you'd need to ensure the expression was subsumed by 55198006 | Bronchoscopy with biopsy|
Rob Hausam (Aug 23 2020 at 22:04):
The Schulz, et. al. paper is actually describing a mapping from OPS to SNOMED CT using a non-standard compositional syntax that is a simpler alternative to the official SNOMED CT compositional grammar. The definition of Coding.code states that it is "A symbol in syntax defined by the system". The definition of ConceptMap.group.element.target.code is "Identity (code or path) or the element/item that the map refers to", which is different. But in combination with ConceptMap.group.target I think it would be considered equivalent to Coding.system and Coding.code. So using the Shulz, et. al syntax (e.g. something like "312849006 |Biopsy of bronchus (procedure)| ADD 10847001 |Bronchoscopy (procedure)|") would be non-standard. But, with that said, if the syntax being used is declared and documented (as in the paper), then it seems that it would make sense for it to be allowed? I'm not sure that we have an explicit way to do that (unless I'm forgetting), but an extension with the Expression data type likely could do it, as Expression.language specifies the specific syntax used (with the limitation that it should be included, or at least should be includable, in BCP13).
Michael Lawley (Aug 23 2020 at 22:05):
The problem with product and dependsOn is that they don't involve the code system's semantics and thus you cannot clearly express your AND and ADD semantics. OR is tricky too - you need two maps and a target more specific relationship
Grahame Grieve (Aug 23 2020 at 22:07):
if we wanted to support that directly, it would be a different code system that defined a grammar that included snomed ct concept its
Rob Hausam (Aug 23 2020 at 22:31):
I suppose it could be a code system supplement that would do that. We can declare in the CodeSystem resource that it is 'compositional', but it seems that we still don't have a way (extension or otherwise) to declare the particular compositional syntax.
Grahame Grieve (Aug 23 2020 at 22:32):
the new syntax is what makes it a new code system. That the syntax uses SNOMED codes internally is specific to the syntax
Rob Hausam (Aug 23 2020 at 22:42):
Yeah, I get that. But it seems like you would need a way to describe the syntax within the CodeSystem resource that defines it (for FHIR). I guess you would do that in CodeSystem.description (likely including, in this case, a reference to the Schulz paper as well as some further description).
Grahame Grieve (Aug 23 2020 at 22:47):
yep, we've not tried to do anything other than narrative for syntax. Even if there's a formal grammar, it's not going to make sense or be usable without extensive human documentation
Rob Hausam (Aug 23 2020 at 23:51):
Upon a bit of further reflection, it seems to me that creating the new code system as a supplement to SNOMED CT probably isn't going to work (with the current specification), as defining a new compositional expression syntax will be adding "new codes" to the code system. It will define a new set of values that (if allowed) would be specified in CodeSystem.concept.code (or Coding.code) - which violates the rule:
A codesystem supplement cannot define any new CodeSystem.concept.code. i.e.: all CodeSystem.concept.code in the supplement must be a code from the "supplemented" code system
Noemi Deppenwiese (Sep 16 2020 at 14:51):
Thanks for your input! Based on it, my colleague @Andrea Riedel and our team arrived at the following solution that only uses SNOMED CT expressions and the basic ConceptMap without extensions:
- OR-joined Codes: easy, one element with two targets
- AND-joined codes: Use SCT postcoordination syntax to build one single "FHIR-code" as target
- ADD-joined codes: use target.product with some "property" value specific to ADD
- more complex expressions: transform into "Disjunctive normal form" like expression ((OR-less individual expressions seperated by OR). Use multiple element.targets and transform individual expressions as described above.
-Additional Material mapping: Use target.product with property specific to "material" (on all target elements of the mapping). In cases of only material mapping, leave target.code empty and use "relatedTo" Equivalence.
However, I do not yet quite understand what values to use for product.property, since the grammar is not in any formal CodeSystem / ADD and "Material" concepts are not in some formal information model. Can we just invent some Magic URI? E.g. with NamingSystems, there is a Resource with additional Information at the URL target. Is there any FHIR-way to provide people that might stumble upon this property with an explanation?
Robert McClure (Sep 16 2020 at 17:20):
@Michael Lawley
Michael Lawley (Sep 18 2020 at 06:58):
I _think_ the promoted approach to deal with composite (ADD) things in SNOMED is via the Situation hierarchy.
However, it's not a part of the semantics / editorial guidance I'm familiar with, and I generally shun use of that hierarchy anyway since it is tainted with a semantically broken approach to negation.
The place to start would be here https://confluence.ihtsdotools.org/display/DOCEG/Situation+with+Explicit+Context
Noemi Deppenwiese (Sep 18 2020 at 07:17):
Thanks @Michael Lawley , we will look into this. (For material, we're planning to use the material (attribute) SNOMED concept now, unfortunately, ADD is much less straightforward.)
Last updated: Apr 12 2022 at 19:14 UTC
