There are indeed porblems in design and technical implementation with rebuilding SNOMED hierarchy manually, with how it is structured in our Standardized Vocabularies.
In just talking points:
- SNOMED comes into OMOP from three different sources, and they have varying levels of support.
- Most (about 180) of the routes belong to SNOMED CT Core, as expected – something that is universal for every healthcare system is eventually expected to end up in the SNOMED Core, and the set of possible ways to put medicine into a human is pretty universal. This is probably the best supported part.
- 18 routes come from SNOMED UK version. They contain full duplicates to the International version, their hierarchical links unmaintained, and only update to happen to it was in 2020 – and it did not even fix all duplicates that were present at the time. That would require the most manual work.
- One very exotic route (Arteriovenous graft route) comes from SNOMED US version. My guess is that it exists only for ICD-10-PCS compatibility.
- Any sort of manual support on our side would had to adapt to any changes and fixes SNOMED sources do themself. What happens, if SNOMED Core completely removes a route as “ambiguous” without a replacement mapping? What happens, if SNOMED UK releases an update and fixes all their routes, and they end up being different to ours? If changes are incompatible, do we accept the source logic, or double down on the changes that were already released by us? How would we determine precedence between new duplicates between the local versions?
- If we take the responsibility to maintain the routes, would we handle community requests for a new concept? After all, manually changing hierarchy and handling duplicates is not very far from manually adding concepts. Do we forward the request to SNOMED, just to still end up maintaining the added concept ourself?
- Most of the SNOMED UK routes will be gone from OMOP Vocabularies soon. Do we make an effort just to keep and maintain a tiny part of the Drug Extension module, which is also expected to drift further and further away from shared SNOMED structure?
I would argue that creating and supporting a manual hierarchy, and creating mappings for the old SNOMED Route concepts just once as a transition measure, is strictly less complicated than hacking into the hierarchy of SNOMED.