Stream: terminology
Topic: Value Set Designations
Robert Bjervås (Jan 13 2021 at 15:36):
HI,
We need a Value Set where each code has alternatives, where each alternative is a kind of specialisation of the concept. Each alternative should be tagged with the "specialisation type". An example to make it easier to understand: In a value set of units, one unit (the concept) would be "ampoule" with the alternatives "pcs" tagged as abbreviation and "ampoules" tagged as plural.
The obvious solution seams to be using ValueSet.compose.include.concept.designation and use designation.use to specify the type. However designation.use is marked as Extensible. How should the rules regarding extensible be interpreted in this case? Can we add Abbreviation and Plural as codes for designation.use without breaking the spec or is there a better option than using designation?
If the answer is to use designation, the next question is, the value set designation-use has a note saying "are for use with SNOMED-CT, and not expected to be used with other code systems". However the FHIR spec says about Extensible "To be conformant, codes in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated". Lets say that we add a 3rd alternative to "ampoule" and use the designation-use code "Synonym" to map it to a code in another code systems. The rules regarding Extensible ad the note about only use the designation-use codes for SNOMED codes are in conflict, or how should the spec be interpreted in this case? Shall we create our own "Synonym"-code (wouldn't that break interoperability) or use the SNOMED code in the designation-use value set?
Lloyd McKenzie (Jan 14 2021 at 05:09):
@Rob Hausam
Peter Jordan (Jan 14 2021 at 06:21):
@Robert Bjervås - the Terminology Services Track has a breakout session on this topic tomorrow...
12:00 - 1:00 PT - Updated designation-use value set and updated proposed designation-use-context extension design and testing
(hopefully, this will be placed on the Agenda in Whova early tomorrow PT).
Robert Bjervås (Jan 14 2021 at 13:01):
Unfortunately, I cannot attend that session.
Grahame Grieve (Jan 14 2021 at 17:25):
The current designation use "Synonym (core metadata concept)" is a snomed specific term. While the concept of synonym obviously applies outside snomed, the definition of that designation use is specific to snomed ct. So it's appropriate in this case to create your own code. But HL7 should define some codes like this
Peter Jordan (Jan 14 2021 at 19:10):
Possible Designation Use Codes for LOINC, expressed as designation token parameters used in an $expand request...
http://loinc.org|LONG_COMMON_NAME (default)
http://loinc.org|SHORT_NAME
http://loinc.org|CONSUMER_NAME
Michael Lawley (Jan 15 2021 at 01:45):
It would, however, be good for client software (the main consumer-base of designations) to have a stable, consistent, and useful set of designation use codes to work with. Otherwise UIs are going to have to have CodeSystem-specific code to deal with the inevitable proliferation of alternate codes for specifying abbreviation, patient-friendly-name, etc (eg, we are now already facing a tradeoff between http://loinc.org|CONSUMER_NAME and the FHIR R5 proposed patientFriendly
As @Grahame Grieve says: "...HL7 should define some codes..."
Peter Jordan (Jan 15 2021 at 01:58):
That was discussed at one of the TS Track breakouts at the Connectathon today. One suggestion was to add generic codes to the HL7 Designation Use Valueset that would make sense to clients and delegate the complexity of finding the Code System specific designation types to Servers. Problem is that some of the designation types (e.g. Synonym) have different meanings in different Code Systems. For example, synonym is only one of 15 distinct description types in NZMT.
Rob Hausam (Jan 15 2021 at 07:00):
I'm not sure how fully we've answered your questions so far, @Robert Bjervås. I feel like some things may be being mixed in the discussion. Value sets are primarily about sets of codes (which identify concepts). You are describing a scenario "where each code has alternatives" and "each alternative is a kind of specialisation of the concept". But the subsequent discussion seems mostly about alternative display strings or designations, rather than alternative codes. It would be helpful to clarify that in the examples and the discussion, if possible. I do believe that a code for "Abbreviation" might be acceptable as a designation use, but at least at the moment I don't see how "Plural" would be. I think Grahame explained the situation around the SNOMED CT codes that are currently in the designation-use value set. We did discuss this further in our session today. I think there is some general agreement with the "Note for Implementer" stating that the SNOMED CT codes for 'Fully specified name' and 'Synonym' should be understood as applicable only for use with SNOMED CT. But I think the statement that you made of 'use the designation-use code "Synonym" to map it to a code in another code system' likely reflects a misunderstanding. Again, designations are about alternative display strings for a single concept in a specific code system, and the notion of mapping to another code system doesn't apply for that. Mappings between concepts in different code system certainly can be done, though, and in FHIR the ConceptMap resource would normally be used for that. To answer your last question on whether to create your own "Synonym" code or use the SNOMED CT code for "Synonym" in the CodeSystem or ValueSet concept.designation.use element (it wouldn't actually be added to the value set itself), my answer is "it depends". If you are not coding your data using SNOMED CT, then, as mentioned, the SNOMED CT "Synonym" code in the current value set technically doesn't apply. But, if you really do need to state that a particular designation is a "synonym" (which you may or may not need to do), creating your own new and different "Synonym" code certainly isn't going to improve interoperability, so I think in that case you could decide to use the existing SNOMED CT code anyway, if you prefer - at least until HL7 defines a set of new additional codes to be used for this, as Grahame and Michael have suggested. That's my take, anyway. I hope it helps a little, and at least doesn't add (too much) confusion.
Robert Bjervås (Jan 15 2021 at 09:40):
Thanks for the input all of you . @Rob Hausam you are right my wording is bad. This case is not about mapping codes between different value sets, it's about using multiple display texts within the same concept. I agree that it would be good if FHIR includes generic codes. I would also like to point out that much of our confusion is because the binding strength of designation use is extensible. Based on what you say it should maybe be example instead taken from SNOMED.
Michael Lawley (Jan 18 2021 at 08:00):
On the plethora of description types, I think there's a key issue relating to what a client / consumer of a code system is expected to do differently for each description type. Are there really 15 different designation treatments/behaviours that might be expected of a client for NZMT codes?
A (the?) key piece of value that FHIR Terminology Services delivers, IMO, is a level of common behaviour, and that necessarily means that details get blurred. If you need complete fidelity from a "raw" code system into a FHIR CodeSystem, then that's the place for extensions.
Last updated: Apr 12 2022 at 19:14 UTC
