FHIR ConceptMap equivalence / relationship mappings

[joeflack4]

Description

The TIMS (Terminology Infrastructure Management Systems) team is looking to make an SSSOM extension for FHIR ConceptMap. One of the fields in ConceptMap is called equivalence in R4, AKA relationship in R5. It is a categorical variable indicating the relationship between two concepts. The task here is to decide which relationship field CURIEs (that's what I call them, at least) map to each of these categories.

This mapping will need to be done for two different FHIR versions:

• R4
• R5

R4 Sub-tasks

Pertaining to any boxes checked below, the check indicates that I've located what I feel are some good mappings. But it doesn't necessarily mean that we've located all of the CURIEs that might appropriately map to the field.

• 1. relatedto
• 2. equivalent
• 3. equal
• 4. wider
• 5. subsumes
• 6. narrower
• 7. specializes
• 8. inexact
• 9. unmatched
• 10. disjoint

R4 Sub-tasks, expanded

1. relatedto

Definition: The concepts are related to each other, and have at least some overlap in meaning, but the exact relationship is not known.
Candidates:
i. skos:related
ii. skos:relatedMatch

2. equivalent

Definition: The definitions of the concepts mean the same thing (including when structural implications of meaning are considered) (i.e. extensionally identical).
Candidates:
i. skos:exactMatch

Notes: Whatever maps to this cannot also be used for equal, and vice versa.

3. equal

Definition: The definitions of the concepts are exactly the same (i.e. only grammatical differences) and structural implications of meaning are identical or irrelevant (i.e. intentionally identical).
Candidates:
i. owl:equivalentClass

Notes: Whatever maps to this cannot also be used for equivalent, and vice versa.

4. wider

Definition: The target mapping is wider in meaning than the source concept.
Candidates:
i. skos:broader
ii. skos:broadMatch

5. subsumes

Definition: The target mapping subsumes the meaning of the source concept (e.g. the source is-a target).
Candidates:
i. sssom:superClassOf

6. narrower

Definition: The target mapping is narrower in meaning than the source concept. The sense in which the mapping is narrower SHALL be described in the comments in this case, and applications should be careful when attempting to use these mappings operationally.
Candidates:
i. skos:narrower
ii. skos:narrowMatch

7. specializes

Definition: The target mapping specializes the meaning of the source concept (e.g. the target is-a source).
Candidates:
i. rdfs:subClassOf

8. inexact

Definition: The target mapping overlaps with the source concept, but both source and target cover additional meaning, or the definitions are imprecise and it is uncertain whether they have the same boundaries to their meaning. The sense in which the mapping is inexact SHALL be described in the comments in this case, and applications should be careful when attempting to use these mappings operationally.
Candidates:
i. skos:closeMatch

9. unmatched

Definition: There is no match for this concept in the target code system.
Candidates:
i. ?

10. disjoint

Definition: This is an explicit assertion that there is no mapping between the source and target concept.
Candidates:
i. owl:disjointWith

R5 Sub-tasks

Pertaining to any boxes checked below, the check indicates that I've located what I feel are some good mappings. But it doesn't necessarily mean that we've located all of the CURIEs that might appropriately map to the field.

• 1. related-to
• 2. equivalent
• 3. source-is-narrower-than-target
• 4. source-is-broader-than-target
• 5. not-related-to

R5 Sub-tasks, expanded

1. related-to

Definition: The concepts are related to each other, but the exact relationship is not known.
Candidates:
i. skos:relatedMatch

2. equivalent

Definition: The definitions of the concepts mean the same thing.
Candidates:
i. skos:exactMatch

3. source-is-narrower-than-target

Definition: The source concept is narrower in meaning than the target concept.
Candidates:
i. skos:narrowMatch

4. source-is-broader-than-target

Definition: The source concept is broader in meaning than the target concept.
Candidates:
i. skos:broadMatch

5. not-related-to

Definition: This is an explicit assertion that the target concept is not related to the source concept.
Candidates:
i. skos:related + NOT predicate_modifier

Additional information

Links to external conversations

Slack: OBO Community: SSSOM channel: https://obo-communitygroup.slack.com/archives/C0281J34Z6J/p1653423363148969
Zulip: FHIR: Terminology stream: https://chat.fhir.org/#narrow/stream/179202-terminology/topic/SSSOM.20and.20ConceptMap.20relationship.20.2F.20equivalence/near/284800056

Related issues

timsbiomed/issues#3
mapping-commons/sssom-py#253
mapping-commons/sssom-py#254

[matentzn]

We should work with the FHIR data model team to verify this mapping between FHIR and Semantic Web properties.

In the context of SSSOM, we only use the skos:*Match vocabulary, not skos:broader/narrower etc.

• inexact should probably be skos:closeMatch
• unmatched is defined more precisely in SSSOM as a negative match. Negated mappings and the standardisation of mapping predicate modifiers #40
• specialises can be solved by sssom:superClassOf, but I we should be really digging into the distinctions of specialises vs broadMatch - for most practical purposes these are similar, and while my ontologist heart does like that distinction, I am uncertain if we can ever train the world to make it correctly.

MONDO:carcinoid heart disease skos:broadMatch Orphanet:heart disease
MONDO:carcinoid heart disease rdfs:subClassOf Orphanet:heart disease

The intention in both cases is the very similar. I think mappings are more about the former, as the latter makes presumptions about the semantics which will be nearly always wrong.

[joeflack4]

Nice feedback. Updated the issue as well as tentative mappings in my code.

@DaveraGabriel Can you recommend 1 or more people at FHIR we can talk to about this issue?

@matentzn More specifically regarding unmatched, it seems like there could be several combinations of relation_id / predicate_id and predicate_modifier that can map to this. Can we enumerate all combinations?

Here's what I can think of so far:
predicate_ids / relation_ids:

• skos:exactMatch

predicate_modifiers:

• NOT
• INVERSE

[DaveraGabriel]

This is the kind of thing that can be discussed in the terminology stream on Zulip, but if I may offer advice as to how to present the issue, I think the response may be more satisfying if you keep a couple of things in mind

There are two levels of response on Zulip: 1 will be to reference the literal interpretation of the ConceptMap and ConceptMap2 value set for ConceptMap.group.element.target.relationship and ConceptMap2.group.element.target.relationship which you already know: its limited and doesn't cover the issues(s) Nico references above, and I think you will find this unsatisfactory.

The second approach would be elicit a hypothetical response achieved in the way a Zulip post is framed... e.g.: a) our group is developing an SSSOM extension to ConceptMap2 b) in considering the use case you detail above are there additional resources (aspects of the FHIR model) that could be leveraged to achieve FHIR support while we develop this extension

Also becuase its a forum - you may get some random, less-than-helpful-responses. It may be that the feedback generated will fall back to interpretation of the source & target code semantics, but if you can posit the issue well, the Terminology Zulip stream is an active forum that is monitored by Grahame, members of both Vocab and FHIR-I and generates changes to the FHIR specification.

Even if imperfect, until we have an SSSOM extension proposal ready - Zulip is the best point of entry for exploratory discussions like this. Doing that will socialize the questions you have, in the absence of a project or proposal, and COULD lead to getting time allocated in a Vocab or other working group meeting becuase the FHIR-I folks are working toward completion of R5.

I hope that helps... I'll be there to monitor / support the discussion

PS: the Vocab WG is aware we are working on the SSSOM extension - we briefly mentioned this in the WGM / Connectathon sessions

[joeflack4]

Thanks, Davera! I know we also chatted about this over Teams as well. I elicited some feedback on Mondo / OBO community slack. I should've posted in Zulip already, but I'll do tomorrow. And I'll also get a chance to touch base w/ the folks you mentioned at Dev Days!

[DaveraGabriel]

@joeflack4 I spoke with Bob Dolin just now. He was aware that you tagged him on Zulip, but wasn't sure how to answer. This is the short version of what I learned... the Genomics mapping use case they developed operations for started a long time ago. It was and remains a edge case for core FHIR as it stands today. It wasn't until they had a reference implementation, that the vision they had of the need for these novel operations started to be accepted. So as for "talking with the FHIR modelers" the specification development is based on developed specs, as such something thing we can do in the near term is develop a reference implementation of our extension on FHIR.

[joeflack4]

@DaveraGabriel Hmm, perhaps Bob is not too experienced with this area of the semantic web. I think it's probably alright, though. So far Nico and I have probably found good candidates for most of these mappings. I may get a chance to chat with some people here at dev days though and have them look over the list / give their input.

[DaveraGabriel]

@joeflack4 to be clear, Bob is a seasoned ontologist, and I didn't ask him your specific mapping question. Rather, I asked him about the process he & Bret engaged in to achieve the wholly out of the (FHIR / HL7) box approach they took - tokenizing the genome terminologies and developing unique operations for these. How it is they worked outside the established FHIR spec to achieve solutions their use case uniquely required.

The issue is, the kinds of questions you are asking about happen inside of HL7 projects, and you would then ask your working group members, and failing that because it was an approved project / scope of work under the TSC - this could be taken to the Vocabulary Working group to ponder. Melissa has a a plan to provide some monitoring / representation within the Clinical Genomics WG which will also enhance our collective reach for resources / collaborators when questions like this arise. What this team should do to solve this specific question is is either a) take a best guess at an approach (what you and @matentzn are already doing), leverage Zulip as you already are doing and the new contacts you will be making at DevDays as you are planning for advice, or b) rally the group to develop a project proposal within an HL7 WG for the HL7 Technical Steering Committee to approve (this gets you a spot on a Vocab WG meeting agenda).

[joeflack4]

Hmm, good suggestions. This is only a small part (but probably one of the most important parts) of the SSSOM/ConceptMap harmonization.

I spoke to Rob Hausum yesterday here at dev days, and he acknowledged that indeed, ConceptMap R5 relationships are basically SKOS. He agreed that it would be a good idea for me to open a Jira ticket to include some note about that in the documentation, so I'll be doing that. I can ask that the same be done for the R4 ConceptMap docs, if possible.

But I don't necessarily want this to take up a lot more time, so we can always move forward with our current operating assumptions for the time being. For any more formal HL7 process involving more people, if you think we should do it, I'd hope to defer to you to set that up. 🙇