RE: SNOMED

[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:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Saturday, 30 April 2016 2:43 a.m.
To: openehr-technical@lists.openehr.org
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 

 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 

RE: SNOMED

[Mikael Nyström]

Hi Tom,

As with all kinds of standards and content that you can use, you need to 
investigate and select the ones that are most appropriate for your use case. 
That apply when selecting between openEHR, EN 13606, HL7 version 2, HL7 version 
3 and also when selecting which openEHR archetypes or SNOMED CT concepts to use.

When selecting how to represent the use cases when the information is from a 
situation with explicit context you need to investigate which alternatives you 
have and which of the possible alternative that are the best alternative. If 
the EHR system you use only can represent some codes and some free text, using 
concepts to explicitly state everything in the situation using a single coded 
concept is probably the only possible alternative. For these use cases the 
situation hierarchy in SNOMED CT are really useful. However, if the EHR system 
you use can represent a rich information model (which starts to be more and 
more common) then it is in many cases better to use the information model to 
represent the situations and use "pure" finding and procedure concepts in the 
information model. I can't see that the possibility to satisfy different use 
cases is a bad thing!

The possibility to use the "Refinability" feature with the qualifier values was 
deprecated when the Release Format 1 was deprecated and that deprecation is 
very well documented. (See for example Technical Implementation Guide section 
9.2.1.)

The record artefact hierarchy is a hierarchy that try to model how the records 
that are in use in different healthcare systems relate to each other and that 
is dependent on both national legislation and local policy. It would therefore 
be impossible to include a complete record artefact hierarchy for all 
healthcare systems in the international release of SNOMED CT. However I believe 
that it is at least better to include a skeleton where it is easier to add new 
kinds of record artefacts on a national or local level than not provide 
anything at all. (I agree that it would be better if concepts like 271531001 | 
British Association for Adoption and Fostering B1/2 - adoption: birth history 
(record artifact) |had been excluded. But for these concepts it is very easy to 
understand when to use and when to not use the concepts.)

I therefore believe that 'in line with my current use case', 'close to my 
current use case', and 'needs local extension to fit my current use case' is 
closer to the implementation reality than your labelling 'in use', 'not really 
in use' and 'outdated'. Your statement that some hierarchies (the situation 
hierarchy?) would be semi-deprecated just because they don't fit openEHR's 
archetype design principles also seems quite malicious as long as there are 
other EHR systems and standards on the market. If some kind of life cycle 
statement was included they probably need to be on a use case level and not on 
a general level.

However, when it comes to the use case you refer to below I hope that the 
implementers use the available help for selecting the appropriate content from 
SNOMED CT. There are quite extensive documentation that describe the content 
(including the Editorial Guide) they can use. IHTSDO (which is SNOMED CT's 
equivalent to openEHR Foundation) also have connected National Release Centers 
in all member countries that can guide implementations. I also expect that at 
least some of the implementers have taken at least one of the courses IHTSDO 
provide about SNOMED CT's content. IHTSDO's support function (including their 
implementation specialists and customer relation leads) could also help in 
cross-country implementations. I therefore doesn't see all the problems you see 
Tom!

(BTW: I would really like if openEHR set up national release centers and 
provide free on-line training courses in the same way as IHTSDO do. I think 
that would increase the use and usefulness of openEHR.)

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 30 april 2016 12:35
To: 
openehr-technical@lists.openehr.org
Subject: Re: SNOMED


Mikael

Ok, I take your point in one sense, but how are we to know what is 'in use', 
'not really in use', 'outdated', ? More importantly, how would a national 
programme signal to its user base which hierarchies are deprecated, 
semi-deprecated, needing work - don't use), or something similar? What happens 
if two national programmes have different ideas about using the same 
hierarchies, e.g. Sweden and Denmark. How would GP systems in CPH / southern 
Sweden deal with different policies on use / non-use of say the Qualifiers 
hierarchy?

What should an application do if it receives a code string containing terms 
from the Qualifiers hierarchy, but the user orgs have been told to 'avoid the 
Qualifiers hierarchy'?

The record hierarchy