Stream: implementers
Topic: binding strength bug?
Josh Mandel (Jul 05 2016 at 14:58):
https://www.hl7.org/fhir/condition-definitions.html#Condition.clinicalStatus is a code with a binding strength of preferred. That's a bug, yes?
Robert McClure (Jul 05 2016 at 15:22):
Actually, as I look at https://www.hl7.org/fhir/condition.html#def I see other in-line code systems used in value sets that have Preferred binding (https://www.hl7.org/fhir/condition-definitions.html#Condition.category, https://www.hl7.org/fhir/condition-definitions.html#Condition.verificationStatus.) DId this happen because of worries about using SNOMED CT? If so, I suggest these would be excellent candidates (once the SCT equivalent concept is found) to submit to the HTA as requests to IHTSDO for universal access. This would men we could reference these as SCT concepts in the model and any implementer could use them (independent of IHTSDO membership). If FHIR agrees @Rob Hausam and I can can work that out and take it to HTA.
Lloyd McKenzie (Jul 05 2016 at 15:34):
@Robert McClure I can't imagine us tightening the bindings for the value sets you identified to be "required". We generally only use required bindings on super-small value sets where there's global consensus or at least where mappings are super-straightforward. Also, the universal access rule doesn't provide access to relationships, which in SNOMED are what essentially provides the definitions. Codes without the ability to share or use the definitions isn't much use.
Lloyd McKenzie (Jul 05 2016 at 15:34):
@Josh Mandel please raise a publishing tracker item - this should be caught by the build tool.
Robert McClure (Jul 05 2016 at 15:45):
@Lloyd McKenzie Not sure why SCT relationships in this case matter, but I could be missing something. It seems to me these meet all your requirements: they are "super small" by my assessment - well less than 10 codes each (usually <5,) mappings would be straight forward, and you get exactly the same thing you have here right now. So what is the complaint?
Eric Haas (Jul 05 2016 at 19:32):
+1 should be required.
Grahame Grieve (Jul 05 2016 at 19:32):
it's not clear whether they are only preferred because of SCT Licensing rules or because of lack of consensus. I suspect more the latter, but I'm guessing
Grahame Grieve (Jul 05 2016 at 19:33):
Given that in SCT the relationships define the meaning of a concept, it's astonishing to think that it's meaningful to license the concepts with the relationships
Eric Haas (Jul 05 2016 at 19:40):
Oops I forgot the licensing prevents it from being anything beyond preferred. - Drat -If we make it required - then should be code with a fhir code system
Josh Mandel (Jul 05 2016 at 20:03):
Added GF#10272 to capture this.
Lloyd McKenzie (Jul 05 2016 at 20:05):
I'm quite certain it's lack of consensus. There's no clear agreement on what the categories mean or when they get used. Nor is there consistency in industry around these notions. @Robert McClure I misread what value sets you were referring to. I'm happy for these to be "preferred" from SNOMED - and in fact we must move away from HL7-defined codes here. But I don't think they can/should be required and don't think we'd consider using required bindings to SNOMED in UV content given the current license terms.
Rob Hausam (Jul 06 2016 at 04:58):
@Robert McClure The fact that SNOMED CT binding strengths are example is because of those concerns about SNOMED CT licensing and accessability. So, I agree that these would be good candidates to request that we have universal access for. I will mention that I still think that a much simpler and still viable (for IHTSDO and others) process to deal with would be to provide universal access for all concepts and descriptions (not relationships). But without that, or in the meantime if we ever do get to that, then submitting these to the HTA for access makes sense.
Grahame Grieve (Jul 06 2016 at 05:04):
So these are not currently using SCT. They are custom terminologies.
Grahame Grieve (Jul 06 2016 at 05:06):
looking at SCT to see what we might use underscores my grounds for concern. Take, for example, 'relapse' as a status. Would you recommend 263855007? 134409004? neither of them are appropriate, but this is not evident in their descriptions, only in their relationships.
Grahame Grieve (Jul 06 2016 at 05:07):
It's extremely inappropriate for IHTSDO to propose making concepts and descriptions available when you do not know what a description means unless you can look at the relationships
Grahame Grieve (Jul 06 2016 at 05:07):
if they publish fully descriptive descriptions, then, fine.
Grahame Grieve (Jul 06 2016 at 05:10):
maybe HTA would like to propose new codes under 394731006. That would seem right to me
Grahame Grieve (Jul 06 2016 at 05:10):
though there's the condition vs problem thing, of course
Rob Hausam (Jul 06 2016 at 05:19):
@Grahame Grieve "Given that in SCT the relationships define the meaning of a concept" is true only partly , or not at all, in many cases. The official statement has always been that the determination of the meaning of a concept is based on the fully specified name. There is discussion of changing that, but I'm not aware that it has actually been changed (happy to stand corrected if so). But we know there are issues with relying on the FSNs, as in the examples that you cite. For the large number of primitive concepts (including those two), the FSN is at least the primary source of the meaning - the set of relationships is by definition/declaration inadequate for that. In those two examples, looking at the stated isa relationships does provide additional clarity regarding the meaning (theoretically, if the FSNs were complete, that wouldn't be necessary), but the relationships alone do not constitute or represent the definition of the concept.
Grahame Grieve (Jul 06 2016 at 05:28):
no, but my point is that neither, in many/most cases, does the definition. You need the relationships. And so it's wrong to think that making SCT - relationships available in a meaningful way
Grahame Grieve (Jul 06 2016 at 05:29):
if IHTSDO wants us to use SCT, they need to license the subset of relationships for the terms that they license, or got all the descriptions correct
Rob Hausam (Jul 06 2016 at 05:35):
Yes, I agree with you - your two examples illustrate that. And you're right on the last point - it's a fiction to think that you can really get along without the relationships for the concepts that are "accessible", at least given the current state of SNOMED CT. That state will change and hopefully will improve significantly over time, but it won't be changing substantially enough to resolve this issue any time soon.
Robert McClure (Jul 06 2016 at 15:56):
@Grahame Grieve @Rob Hausam I don't agree that we need the relationships to make this valuable. Yes, it would be better but I am baffled as to why you would think making up words here in FHIR is so much better? As for the "meaning" of SCT concepts currently, yes it is the FSN full stop. The relationships, while very useful (when they are not in error) are not a part of the "official" meaning. If you want a complex statement that defines the meaning of a SCT concept then we can suggest one as it is my understanding that IHTSDO is considering adding them, and we can keep that in our own terminology service as a code system supplement. @Grahame Grieve as for your relapse examples, yes there is a missing concept "Patient with relapse" that we would need to add as a child to 271299001 (Patient codition worsened). That would be similar to concepts like 313386006 (Patient in remission), and 359748005 (Paient codition unchanged) for example. Again I suggest we use SCT and request these concepts be universally available instead of creating more HL7 terminology that the HL7 Board has already said we should not be doing.
Robert McClure (Jul 06 2016 at 16:00):
@Josh Mandel You are correct that the actual problem you found was an aligned technical issue that we've gone on a tangent about. Yes I agree a "code" should not have a Preferred strength. These should be codeableconcept datatype
Last updated: Apr 12 2022 at 19:14 UTC
