On 13/03/2018 16:45, Philippe Ameline wrote:
Thomas,
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
