Stream: terminology
Topic: How to extend designation-use
Stefan Karl (Sep 14 2018 at 13:11):
I need to define some additional codes for CodeSystem.concept.designation.use, which has an extensible binding to http://hl7.org/fhir/ValueSet/designation-use. And a Note for Implementer:
Licensing note: this value set has an extensible binding, and includes concepts from SNOMED CT. The SNOMED CT concepts included in this value set - description types for SCT terms - are for use with SNOMED-CT, and not expected to be used with other code systems.
The code system I'm working on is not related to SNOMED and for worldwide use, so I don't like using the SNOMED CT codes e. g. for "synonym" designations. How can I do that without violating the binding rules?
Rob Hausam (Sep 14 2018 at 13:22):
Since it's an extensible binding, if the existing codes in the value set don't "cover" the meaning that you are wanting to represent, you can use code(s) from outside the value set (which in this case will be from a different code system than SNOMED CT) and that will still be conformant. What codes are you considering? In this case, since the code in the value set for "Synonym" (900000000000013009) is stated to apply specifically and only to SNOMED CT, you could add a new "synonym" code and that should still be acceptable since you are using a different code system.
Rob Hausam (Sep 14 2018 at 13:28):
The codes that you are adding need to be from some code system. If you can find an existing code system with the codes that you need, that's great, otherwise you can define them.
Stefan Karl (Sep 14 2018 at 13:36):
Thanks. The code system is for 11073-10101 MDC codes from the Rosetta database, which has some "synonym" terms, and useful additions like "common term", "systematic name" and "acronym" that I'd like to keep as designations. The codes for designation-use do not yet exist, I will need to define another (small) code system for that.
Lloyd McKenzie (Sep 14 2018 at 14:34):
I thought we had a policy that no required or extensible bindings within HL7 would reference SNOMED CT codes unless they were licensed for use by everyone. I find this very problematic. At minimum we need a SHALL assertion that these codes are only permitted to be used with SNOMED and nothing else - which essentially leaves us with an empty binding for all non-SNOMED code systems, which is problematic too. I don't know how we fix this at this point in the ballot process, but we need to minimize the damage.
Rob Hausam (Sep 14 2018 at 14:58):
We've always said that, but I'm not sure how well we've documented it. This one is an exception that has been there since we first introduced CodeSystem. I think the current licensing note might be sufficient: "Licensing note: this value set has an extensible binding, and includes concepts from SNOMED CT. The SNOMED CT concepts included in this value set - description types for SCT terms - are for use with SNOMED-CT, and not expected to be used with other code systems." And we could very likely (almost certainly) have these three codes added to the free set of SNOMED CT codes for use in HL7 specifications - which, incidentally, I am scheduled to provide the proposed set to Jane Millar by this coming Monday (17th). The proposal is intended to be based on what we're using in IPS, but, as I said, I'm sure that these can be added. Presumably if the free set proposal is approved then that would mitigate the concern in this case, and then there wouldn't be a need to restrict their use to only SNOMED CT.
With all that said, it might have been better if we had just created a FHIR code system and value set for this, but we didn't. This isn't something that has changed since the May ballot, but maybe we could consider ballot comments and possibly changing it before CodeSystem goes officially normative (assuming that it does)?
Lloyd McKenzie (Sep 14 2018 at 15:39):
I'd like "not expected to be used" to be "SHALL NOT be used", but we probably can't introduce that language at this point. Getting these opened as free codes would be very helpful.
Michael Lawley (Sep 14 2018 at 20:37):
Getting them generally available is clearly the best option at this point
Grahame Grieve (Sep 17 2018 at 09:18):
why make them shall not be used? license holders might want to do that... why stop them?
Lloyd McKenzie (Sep 17 2018 at 14:10):
Because then they can't share with license holders. If it's content a no - license holder could otherwise consume, we need to ensure that the use of SNOMED codes to define the display types doesn't become the barrier that prevents consumption.
Rob Hausam (Sep 17 2018 at 15:47):
Well, we should have a better idea by Baltimore (at least by the end) about how it is looking.
Michael Lawley (Sep 17 2018 at 18:44):
It's only the creator of the code system that needs to be a snomed licence holder; consumers (receivers) of content are fine.
But, for clarity, we should just expedite the process of getting these metadata codes unencumbered.
Grahame Grieve (Sep 17 2018 at 22:28):
of course making it unencumbered would be good. But a SHALL not is a too far.
Last updated: Apr 12 2022 at 19:14 UTC
