Nevertheless, I think it would have been good to move / remove the
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable
core, which would actually look a lot more like Philippe's (much
smaller) terminology.
This relates to the old debate on reference v interface terminology, and
just throwing out precoord concepts is probably not right - they need to
be in a completely different hierarchy.
The post-coordination grammar in SCT is good, its theoretical challenge
is the concept meta-model, i.e. what things like 'morphology',
'laterality' you can mention, and in what relationship. But this is hard
for all of us, and requires some serious ontology work (Mikael and other
experts know all about this of course).
What I would say is this: in a similar way that I think SNOMED should
have separated out 'SNOMED technology' (representation, APIs etc) from
content, I think the concept meta-model should have been / could be made
a separate artefact, maybe even an OBO ontology - at the moment it is
too hidden inside the giant content artefact. If that were done, we
could work more effectively on aligning with information / content
models, whose attribute names should, generally speaking relate to (or
be the same as) the meta-model ontology entities. If we pursued this
line, the ontology would instantly be expanded by examination of
archetypes, and conversely, many archetypes could be fixed where they
contain errors or questionable attribute names.
THis isn't to criticise experts or work done in SNOMED per se, but we
should be perfectly happy to /critique/ SNOMED, as long as that critique
is collegial, and above all intelligent. (BTW maybe Philippe was not
entirely diplomatic, but he did implement a very nice post-coordinating
terminology and clinical noting system, so he knows a thing or two).
So in that sense, I stand by my earlier comments that it would have
helped (and still would help) if SNOMED International would consider
some of my suggestions on separation of technology from content,
separate the meta-model, and also a more serious effort to help connect
terminology to information models / content models. We are slowly
solving this on our side, but strategic cooperation would be better.
One thing is clear: terminology is not a standalone proposition.
- thomas
On 21/03/2018 13:48, Mikael Nyström wrote:
Hi Philippe,
I think that you have missed that SNOMED CT is created for multiple use cases.
Your use case that you describe as "a modern approach" is a good use case that
I like. In that use case SNOMED CT can be used in the way you describe using SNOMED CT's
concepts a little higher up in the hierarchies together with SNOMED CT Compositional
Grammar and SNOMED CT's concept model.
Another use case, that many implementers consider is important but you don't seem to care about, is
the ability to handle legacy data to be able to keep a life-long health record. Most people alive
today where born when simple health records that only used simple coding where in massive use.
(When that era started and (potentially) ended is up to the reader to decide...) To cater for
information that are more of legacy information, SNOMED CT also has concepts that can represent
that kind of information. But SNOMED CT also has a machinery to transform between the different
representations. Your example "fracture of the left ankle" is not possible to express
using a single concept from SNOMED CT, but if it had been possible it had been possible to
automatically transform that concept to the expression below, which seems like to be what you argue
for in your "modern approach" use case.
64572001 | Disease (disorder) | :
{ 363698007 |Finding site| =
{33696004 |Bone structure of ankle (body structure)| : 272741003
|Laterality| = 7771000 |Left (qualifier value)|},
116676008 |Associated morphology| = 72704001 |Fracture (morphologic
abnormality)|
}
I therefore find your arguments against SNOMED CT equally relevant as arguments
of the type
"SNOMED CT is useless, because it contains the concepts 285336007 | Background
radiation (physical force) |, 60638008 | Planetary surface craft, device (physical
object) | and 242250006 | Crash landing of spacecraft (event) | and I don't need that
kind of concepts at my clinic."
because the simple solution is to not use what you don't need.
Regards
Mikael
--
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]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
