Stream: terminology
Topic: SNOMED hierarchy mapping strategy
Mary Dobbins (Nov 10 2016 at 19:05):
In the DAF Medication Resource, for the Medication.package.container path (definition: kind of container a medication is packaged in), the example terminology binding references a set of SNOMED CT qualifier codes such as “bag – unit of product usage (qualifier value).” Given the definition of the path for this binding, it seems the SNOMED CT Physical object hierarchy may be more appropriate than the Qualifier value hierarchy. Interestingly, the mapping exercise reveals there are similar concepts in both branches, e.g., 404218003 Ampule – unit of product usage (qualifier value) and 469844003 Ampule (physical object). With a focus on interoperability, we are interested in learning what strategy others have applied or what strategy should be applied here when the value set conformance is example and, arguably, multiple hierarchies could be used.
Mary Dobbins
Terminology Management, Mayo Clinic
Robert McClure (Nov 10 2016 at 19:11):
@Mary Dobbins I agree, it should be the physical object hierarchy. Not sure how that is fixed.
Grahame Grieve (Nov 10 2016 at 19:13):
it's in the definition of the medication resource itself. You would create a gForge task proposing the pharmacy fix the example binding
Mary Dobbins (Nov 11 2016 at 13:33):
Thanks for the feedback. I'll create a gforge.
Guillermo Reynoso (Nov 13 2016 at 19:58):
Talking strictly from the SNOMED CT point of view, ongoing work on defining a proposed drug model for new/future national drug extensions will likely have to revise and clean up units of usage on the qualifier hierarchy to align with established drug terminologies. Rob's comment makes a lot of sense, but it would imply a much broader revision of the SNOMED content model [and therefore more time/iterations] (e.g. not all units of usage are physical objects, most medicinal products are physical objects, some devices contain substances as active ingredients, some units of usage are actually devices, etc.) I am an absolute FHIR beginner, so my personal opinion is entirely SNOMED-centric and might not be relevant to Mary's original question.
Grahame Grieve (Nov 13 2016 at 22:17):
I think it's confusing to have duplicated concepts in the heirarchies that differ by mode of use, not underlying meaning, and then to have inconsistencies between them
Guillermo Reynoso (Nov 13 2016 at 22:49):
Agree it is confusing. But ampule (physical object) was created in 20140731 together with thousands of device categories originated in GMDN with different use cases in mind. The drug/medication use cases would likely need to consider the unit of product usage under qualifier hierarchy. It would be helpful to raise a request to IHTSDO reporting the issue, so it gets considered.
Grahame Grieve (Nov 13 2016 at 23:07):
how would one do that?
Guillermo Reynoso (Nov 14 2016 at 00:27):
Issues/requests for change/guidance can be posted through https://request.ihtsdotools.org/#/dashboard if you/FHIR/HL7 have an IHTSDO-provided account, or contacting IHTSDO staff working on those subjects and/or interested or participating on this thread. Also through NRCs (if you are based on a member country). Many participants here have access to request submissions, but I was assuming there were already established processes and defined channels at the institutional or project level to deal with this kind of issues. If there aren't it would be worth exploring such an option.
Grahame Grieve (Nov 14 2016 at 01:03):
the FHIR project itself doesn't have any formal channel for this. We have an active collaboration though. @Linda Bird what is the right way to do this?
Robert McClure (Nov 15 2016 at 03:15):
The correct process is through the HTA. HTA is the fomally defined conduit for all IHTSDO interactions from HL7. @Grahame Grieve we don't have a formal process to request modeling approaches to SCT but I think you should attend a meeting to clarify what you want HTA to do and we'll find a solution.
Grahame Grieve (Nov 15 2016 at 03:19):
well, it's not really about me. We kind of need some kind of streamlined process around user discovered issues with SCT. And streamlined processes isn't really what people associate with the HTA at this moment
Robert McClure (Nov 17 2016 at 22:33):
That is the process non-the-less. You don't get to directly submit changes to IHTSDO per the agreement between HL7 and IHTSDO
Grahame Grieve (Nov 18 2016 at 05:59):
ok, well, how to do this through the HTA then?
Robert McClure (Nov 18 2016 at 15:06):
Help me understand exactly what you want to see change in SCT and what that will fix for FHIR. The point here is that HTA is the conduit for HL7 requests to IHTSDO. It's fine if the request is not something that only fixes HL7 stuff (as I suspect this might) but we still need to explictly state the requested change and justify why HL7 is asking.
Grahame Grieve (Nov 19 2016 at 16:08):
well, it's a general issues that 2 heirarchies have overlapping content, and they don't seem properly differentiated. see @Guillermo Reynoso comments above. But this is a general issue, not a specific issue that we've identified
Robert McClure (Nov 20 2016 at 01:08):
So by general you mean it is not directly affecting FHIR functionality (at a minimum there is a work around). So this is a general concern, correct?
Grahame Grieve (Nov 20 2016 at 05:24):
yes
Last updated: Apr 12 2022 at 19:14 UTC
