On 13/03/2018 16:45, Philippe Ameline wrote:


Since, in that domain (terminologies, classification, ontologies...), it is not that easy to understand someone else's explanation without a sketching tool available, do you think I betray your thoughts if I sum it up as "Snomed should not be licensed as a "one size fits all" package but should be mainly usable as a set of tools and services in support of localized adaptations by national organizations"?

well, it would be very helpful if anyone had the right to use 'SNOMED technology', to create their own terminology content (mainly by importing legacy vocabularies). Now, that's not ideal of course, but in reality, that is the starting point for nearly all countries - outside of the UK and some locations in the US, I don't know of a country that makes any extensive use of the international core (I am talking operational, not research use of course). That can change in time, but it's not how it is today.

So the core SNOMED CT terminology needs to be licenced separately, as one thing that can co-exist in a SNOMED-technology container (now it starts being obvious why even the naming is problematic - it would be better to have an 'IHTSDO technology stack', which could accept SNOMED CT, ICDx, LOINC, UCUM, and anything else. With smart tricks to do with mapping and concept code generation to create partitions (which SNOMED codes already have - it's a good system), you can create order from the chaos. But the starting point is the chaos, not the order, as some people seem to think.

It is certainly a good thing to be discussed in order to have Meriterm fill the gap.

Besides, as you probably remember, the main reason I don't like Snomed is because it is structured like a coding system and not a "narration ontology".

As an example, I would say that a narration ontology should contain atomic concepts, like "fracture", "location", "right ankle", but should let "fracture of the right ankle" be built as a description structure (say a small tree that express that the fracture is located at the right ankle). Snomed inherited the incorporation of meta-concepts from its history as a coding system (the kind of component that is to be used in systems where information are stored in simple value-pair slots that don't allow for elaborated description structures), as would be the vocabulary of a massively agglutinating language... Since our languages are not massively agglutinating ones (we built sentences), each group has to invest a very long time selecting the subset that fits their "local language" (for example the subset for GPs).

you can do the equivalent of agglutination these days - post-coordination - for which there is a grammar, but this brings its own challenges, and I have yet to see anything but the simplest post-coordinations (e.g. laterality) in real use (but to be fair, 5 or so simple post-coordinations would solve many, many real use case situations). Formally, the post-coordination idea is quite nice, but the real-world tension and main reason it may never work outside the basic cases (laterality etc) - actually there are two, as follows:

 * *data in a real data set is not all coded* - only some items are -
   these are mixed in with plain text, quantities, numbers, ordinals,
   dates, times, durations and various URI / multimedia like things
 * *data is conveniently collected and displayed in pieces* (i.e.
   'shredded' form), not as a grammar string; these pieces may be mixed
   up with other non-coded data types. So the question is: if we have
   formal models of the structured form such as archetypes (maybe even
   FHIR profiles), why bother with the grammar strings?

Inspection of any archetype, e.g. pregnancy summary will show this to be true, but in fact, you can just look at almost any screen form in almost any EMR product to see the same thing. The world just isn't all coded, often not even mainly coded.

LOINC comes with a 6-axis meta-model, so it is an automatically aggluinating terminology as well.

I have always seen Snomed as a system that could be fit to "fill slots in forms" but not as a proper vocabulary to tell a patient's health story... in my own terms, it means that it is not the proper component for modern applications.

well filling slots in forms is useful, especially for fields like 'diagnosis'... but it can only fill some slots - the coded/codable ones. Its real promise would be to support a) high-quality structured ref-sets (not flat vocabularies) and b) reasoning-based inferencing. I think these things will eventually come to pass, but they really should be done in a meta-model that makes them work for ICDx, LOINC, RxNorm, ICF, ICPC, and anything else, not just SNOMED CT.

- thomas

Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org/category/6044> Health IT blog <http://wolandscat.net/> | Culture blog <http://wolandsothercat.net/>
openEHR-technical mailing list

Reply via email to