Hi Mikael,
On 23/03/2018 09:05, Mikael Nyström wrote:
Hi tom,
I can agree with you that if SNOMED CT was created when all patients
in the world already had all information in their health record
recorded using cleverly built and structured information models (like
archetypes, templates and similar), but that is not the case. Instead
SNOMED CT also tries to help healthcare organizations to do something
better also with their already recorded health record information,
because that information to a large extent still belongs to living
patients.
but that would appear to be an argument that since data in systems is
dirty, badly designed, so SNOMED will reflect this by being badly
designed! I don't agree with this at all. I think that the majority of
SCT concepts which are arbitrary pre-coordinations (presumably due to
the fact that someone saw them in real data, or knows they are in use in
their hospital) constitute part of a (pretty messy, but practically
useful) interface terminology. I remember myself and others arguing for
this in the I&I standing committee in about 2011.
That should be moved to a whole separate 'piece' of SNOMED - leaving a
clean core that follows proper rules like mutual exclusion, collective
exhaustiveness, coherence in distinction criteria down the IS-A tree and
so on. That core would be small, manageable, and the concept model could
then be worked on properly to build it out, providing a far richer basis
for pre-coordination. This model would be something that certain
archetype structures could be harmonised with. (Note though that many
archetype structures don't have a biochemical or biophysical basis, but
something like 'cultural models of recording').
The interface part could then start to be cleaned up and have some
discipline of its own; it could be more effectively connected to tools
that are actually used in real interfaces, like choosing widgets, or
underlying logic for searching. These terms would all be mapped back to
the core via post-coordinated expressions - the ultimate test of the
approach.
The main problem with the current state of affairs is simply that the
vast majority of concepts creates incoherent cognitive noise when people
are trying to:
* bind archetype elements to terminology
* create terminology subsets for particular uses - form fields and so on
* curate SNOMED itself
In these situations, anytime anyone looks up a concept lexically, they
get what I showed in the previous post (the actual list for BP is 3
times that) - a huge list that they try to mentally process -
unnecessarily. Errors will of course come with this.
- thomas
It would be interesting to have your opinion about why it is a real
problem with the “extra” pre-coordinated concepts in SNOMED CT in
general and not only for the use case of creating archetypes or what
would be nicest in theory.
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
