I understand from the discussion that there are different levels of
quality, and also some concepts are worked out completely unusable for
the purpose I talked about three days ago (generating archetypes from
SNOMED structures. The idea was not only quite naive, but also quite
controversial,in the Netherlands, and that suprised me )
But there are not many people who can judge the complete SNOMED repository.
Mikael give some hints how a first selection can be done. Old concepts
are of lower quality, and he advised looking at the explicit
content-attributes
So, my idea, maybe it is good to create a tool to create an archetype
from a specific concept, it is not very difficult to build. So, when a
specific archetype is needed, try generating it first, if it is OK, or
needs slight modification, then it would be good to use it, because
there is much alignment with SNOMED in that way, and the work of others,
the designing and maintaining of concepts and structures will be reused.
If it is not OK, nothing is lost because it is only the work of a
generator which run for a few seconds, and the concept can be marked as
not suitable in a shadow database ( for private use.)
I don't know if any structures are usuable for this purpose, does anyone
with much knowledge of the complete repository know?
We have seen examples were it does not work, so it is proven that taking
the complete SNOMED repository is not useful.
But it is not proven that nothing is usable.
Of course, it is just an idea, maybe worth studying. maybe later, if no
one does look at it, I will do it. But I am afraid, earning money has
some priority. ;-)
Best regards
Bert Verhees
Op 2-5-2016 om 01:40 schreef Koray Atalag:
Hi,
Just to add some historical context – SNOMED evolved from a
terminology designed to be a Reference Terminology (as opposed to
Interface/Clinical Terminology) at a time where ontologies were non
existent or very primitive (<90s). Hence the poor formal ontological
commitment as of today – in the past 10-15 years they have transformed
the content to serve a different purpose – to act as
Interface/Clinical terminology and most flaws are related to this
baggage. That said they are actively working to align with current
ontology good practices; e.g. I learned there’s work underway to
restructure anatomical sites as per FMA which is a good step forward.
I heard they are also looking at other content areas to align with OBO
etc.
Cheers,
-koray
*From:*openEHR-technical
[mailto:[email protected]] *On Behalf Of
*Thomas Beale
*Sent:* Saturday, 30 April 2016 2:43 a.m.
*To:* [email protected]
*Subject:* Re: SNOMED
Hi Bert
Erik and Ian partly answered this, but it is always worth remembering
that SNOMED CT, if based on proper ontological principles, contains
assertions that represent entities in the real world. This means
taxonomy (IS-A) and properties, qualities, possible relationships and
so on (see BFO2
<https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjkjrG8hrTMAhWEWxQKHc_dDsIQFggcMAA&url=https%3A%2F%2Fbfo.googlecode.com%2Fsvn%2Ftrunk%2Fdocs%2Fbfo2-reference%2FBFO2-Reference.docx&usg=AFQjCNFaciudhkU555FkqpQscrO0rRJUmQ&sig2=wWITHga_L6Vp1RTU4lvEEw&bvm=bv.120853415,d.d24>for
a modern top-level ontology providing these ideas). These are
properties, qualities and relationships of real things in the real
world, i.e. actual hearts, cardiac arrests, disease types and so on.
The openEHR RM and derivative archetypes are built to represent
information 'about' these real things. The relationship is often
written as 'is-about'. There are important differences to be aware of:
* what information is written 'about' many things can sometimes
resemble a description of the thing itself, e.g. parts of a
colonoscopy report tend to follow anatomical structure of colon
and things found in it;
* sometimes it relates to a surrogate phenomenon, e.g. an archetype
for heart rate that actually records pulse; a great deal of
clinical observation is of surrogates e.g. state of skin,
palpation, heart sounds, asking about pain, blood glucose etc, but
they are actually about something else;
* what gets recorded can be what is cheap and painless to record;
consider that we don't do an echocardiogram every time you want
simple BP or heart rate.
* what gets recorded about X can be culturally determined; different
in other ways from 'how X really is' in nature.
* most important: most clinical data recordings don't replicate
'textbook' relationships found in an ontology, e.g. the fact that
there are 5 heart Korotkoff sounds at different phases of the
cardiac cycle will never be written down by a physician, neither
will the fact that systolic BP is-a pressure of blood in a vessel
is-a pressure of fluid in a vessel etc. So if we were to generate
an information structure from part of an ontology representing the
heart / CV system, it would generate numerous useless data points
and relationships on the information side.
How well or how much SNOMED CT follows underlying ontologies like BFO2
or Biotoplite or whatever is another question. I am not up to date on
the progress, but I am fairly sure that most of SNOMED has not been
validated against these kinds of ontologies. The waters are muddied
further by the attempts to represent informational, timing and
context-related entities in SNOMED CT.
Thus, my view is that: in principle, generating information structures
straight from an ontology (even a perfectly built one) will simply
never work, for the reasons in the list above; in practice, what you
would get from SNOMED CT, given its imperfect adherence to ontology
would be even harder to understand or use.
- thomas
On 29/04/2016 07:50, Bert Verhees wrote:
Hi,
I got an idea when reading the nice story from Heather on
LinkedIn. In fact it is hers idea, but in a opposing way.
https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie
https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie
I wonder in how far it is feasible and useful to create archetypes
from SNOMED concepts, it would be possible to generate them, with
attributes and so on.
In a few hours time, one would have a complete forest with
archetypes, including ontology in more languages.
Maybe some smart handling, filtering, combining can create a
better collection, also looking at the paths, so that there are
similar paths for similar situations, to keep the number of
different datapoints low, which can help creating a faster
key-value storage.
I don't know how it is about copyright, with members, and
licensing, that should be looked at.
The argument that SNOMED is fragmented should not count, I think
(however without having an expertise on this), because, when
working with handwritten archetypes will always be incomplete and
fragmented.
Bert
_______________________________________________
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
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
