Hi Philippe,
If you only would like to use some of the basic concepts as building blocks in
post-coordinated expressions using for example the SNOMED CT Compositional
Grammar Specification and Guide (http://snomed.org/scg) and skip the more
complex/combined concepts you are more than welcome to do so. It is very easy
to automatically translate between the post-coordinated expressions and the
more complex concepts if we need to transfer information between information
systems that uses the two different approaches.
One of the main reasons why the complex concepts are there is that is gives the
possibility to easily associate the complex concepts with two or more terms
that describe the concepts, which many implementers and users appreciate very
much.
Regards
Mikael
From: openEHR-technical [mailto:[email protected]] On
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 17:45
To: [email protected]
Subject: Re: [Troll] Terminology bindings ... again
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"?
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).
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.
Philippe
Le 13/03/2018 à 15:21, Thomas Beale a écrit :
The killer move would be to do something I advocated for years unsuccessfully:
separate SNOMED technology from content and allow them to be independently
licensable and used. Here, technology means representation (RF2 for example),
open source programming libraries for working with ref-sets, specs and implems
for e..g the constraint language, URIs and so on.
It should be possible for a country (the one I am most familiar with w.r.t. to
terminology today is Brazil) to create an empty 'SNOMED container' of its own,
and put its existing terminologies in there - typically procedure lists, drug
codes, lab codes, devices & prosthesis codes, packages (chargeable
coarse-grained packages like childbirth that you get on a health plan) and so
on. There are usually < 20k or even 10k such codes for most countries (UK and
US would an exception), not counting lab analyte codes (but even there, 2000 or
so codes would take care of most results). But the common situation is that
nearly every country has its own version of these things, and they are far
smaller than SNOMED. Now, SNOMED's version of things is usually better for some
of that content, but in some cases, it is missing concepts.
The ability to easily create an empty SNOMED repo, fill it with national
vocabularies, have it automatically generate non-clashing (i.e. with other
countries, or the core) concept codes and mappings, and then serve it from a
standard CTS2 (or other decent standard) terminology service would have
revolutionised things in my view. This pathway has not been obviously available
however, and has been a real blockage. The error was not understanding that the
starting point for most countries isn't the international core, it's their own
vocabularies.
The second killer feature would have been to make creating and managing
ref-sets for data/form fields much easier, based on a subsetting language that
can be applied to the core, and tools that implement that. Ways are needed to
make the local / legacy vocabularies that have been imported, to look like a
regular ref-set.
The third killer feature would have been to make translation tools work on the
basis of legacy vocabulary and new ref-sets, not on the basis of the huge (but
mostly unused) international core.
I think IHTSDO's / SNOMED International's emphasis has historically been on
curating the core content, and making/buying tools to do that (the IHTSDO
workbench, a tool that comes with its own PhD course), rather than promulgating
SNOMED technology and tooling to enable the mess of real world content in each
country to be rehoused in a standard way, and incrementally joined up by
mapping or other means to the core. I think the latter would have been more
helpful.
There is additionally an elephant in the room: IHTSDO (now SNOMED
International) has been tied to a single terminology - SNOMED CT, but it would
have been better to have had a terminology standards org that was independent
of any particular terminology, and worked to create a truly
terminology-independent technology ecosystem, along with technical means of
connecting terminologies to each other, without particularly favouring any one
of them. It's just a fact that the world has LOINC, ICDx, ICPC, ICF and
hundreds of other terminologies that are not going anywhere. What would be
useful would be to:
* classify them according to meta-model type - e.g. multi-hierarchy
(Snomed); single hierarchy (ICDx, ICPC, ... ); multi-axial (LOINC); units
(UCUM, ...), etc
* build / integrate technology for each major category - I would guess < 10
* help the owning orgs slowly migrate their terminologies to the
appropriate representation and tools
* embark on an exercise to graft in appropriate upper level ontology/ies,
i.e. BFO2, RO, and related ontologies (this is where the <10 comes from by the
way)
* specify standards for URIs, querying, ref-sets that work across all
terminologies, not just SNOMED CT
A further program would look at integrating units (but not by the current
method of importing to SNOMED, which is a complete error because of the
different meta-models), drugs and substances (same story), lab result normal
and other range data, and so on. None of this can be done without properly
studying and developing the underlying ontologies, which are generally small,
but subtle.
I'll stop there for now. I suspect I have kicked the hornet's nest, but since
Grahame kicked it first, and I can run faster than him, I feel oddly safe.
Probably an illusion.
- thomas
On 13/03/2018 12:12, Grahame Grieve wrote:
I am get the impression that SNOMED CT is hard to implement, and therefore
wondered if we are at some kind of tipping point, like where HL7v3 was a few
years ago, and some bright spark came along, and now we have FHIR that is
gaining great traction in the health community due to the ease at which it can
be implemented.
this is very true, and I wish that someone would stick their neck out and do
this at scale with
a community behind them. Many of the parameters for how it could be done are
obvious around
free and crowd-support etc. But the big problem is that there is no capacity
for it to happen as a
palace revolution; it must be a full civil war first.
Grahame
_______________________________________________
openEHR-technical mailing list
[email protected]<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
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
[email protected]<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
