SNOMED

[system]

Hi Mikael,

I really did not intend my remarks about the ‘missing’ content in SNOMED-CT to be seen as a complaint, or criticism. I fully understand that this, by definition, is work in progress and there is a perfectly good change request mechanism to have new terms added.

I was only responding to Bert’s suggestion that most of the needed terms were already there, particularly for ‘names’ of nodes.

Actually I had thought that ‘record artefacts’ might be what we use in the future to identify archetypes.

I agree with you about ‘situation with explicit context’ but there was a time not so long ago in the UK when this was seen as a key part of fully defining clinical content as part of the Logical Record Architecture project.

Ian

[mikael (Mikael Nyström)]

Hi Ian,

My comments were not directed to you. Sorry. My intention was more to shift focus from looking for strange concepts and comment to looking for potential improvements and make suggestions about these improvements in general. (And as many non-native English speakers I lack some of the nuances in the language.)

Regards

Mikael

[Gavin_Brelstaff]

A sidenote:

20C Philosophy might help here. Wittgenstein's Tractatus (1921)
was failed attempt to pin-down a logical structure on to what can be expressed. Wittgenstein's Philosophical Investigations (1953)
especially his language games - accounted for different contexts.

/Gavin

[system]

Ian,

I need to correct you.

1- CIMI and SNOMED.
The nodes are NOT labeled using SNOMED, but LOINC is used.
SNOMED is reserved for the data fields.

2- SNOMED is a Reference Terminology and should in the ideal world be orthogonal to structures as used in HL7v2, v3, and 13606.
The natural role of SNOMED is to define ‘atomic’ concepts like any dictionary. These concepts are universal.

In the ideal world the structures equate the syntax of a sentence and the Reference Terminology provides the ‘atomic’ concepts, the words.

The dictionary defines for instance the concept: 'story’.
And defines the concepts; ’tell’, ’ by’, ‘as’, ‘patient’ and ‘mother’.
The dictionary never describes as one single concept: ‘Story as told by mother’.
This complex, pre-co-ordinated, concept is no longer universal, but specific.
In language we use the syntax and the ‘atomic’ words to create statements.
In the world of archetypes we use structure and ‘atomic’ codes to create Archetypes.

3- Helas SNOMED started to incorporate things from the world of structures in their coding system.
They were no longer orthogonal.

For example:

The dictionary defines for instance the concept: 'story’.
And defines the concepts; ’tell’, ’ by’, ‘as’, ‘patient’ and ‘mother’.
The dictionary never describes as one single concept: ‘Story as told by mother’.
This complex, pre-co-ordinated, concept is no longer universal, but it is specific, it is particular.
In language we use the syntax and the ‘atomic’ words to create statements.
In the world of archetypes we use structure and ‘atomic’ codes to create Archetypes.

4- CIMI decided to use the ‘atomic’ codes, as much as possible in their structures in order to express results in data fields and use LOINC to label nodes.
This is the CIMI preferred way.
And yes, as a service, iso-sematic expressions are provided, but these are NOT the CIMI preferred way.

Gerard

Gerard Freriks
+31 620347088
gfrer@luna.nl

[system]

Thomas,

I fully agree,
as you know, already.

Gerard

Gerard Freriks
+31 620347088
gfrer@luna.nl

[system]

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 just doesn’t belong in SNOMED CT. IAO / OBI maybe.

I would have much less of a problem if the ‘use status’ of these hierarchies was clearer, but as far as I can see, it is not - there is no lifecycle state (other than for properly obsoleted terms)…

• thomas

[system]

Interesting, the idea that SNOMED-concepts could need some status-attributes.

When thinking about that, there could be attributes to serve other purposes too.

Maybe the enormous amount of knowledge collected in SNOMED is not used as extensively as possible.
There may be much more potential in it. Interesting opportunities, maybe.

I want to thank everyone who took part in this thread to discuss the initial idea I published yesterday on this list and/or followed up on it.
It really helped me understanding some issues.

Best regards
Bert

[mikael (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

[system]

Mikael,

selecting standards based on use cases, if you mean narrow use cases in the sense of IHE (e.g. microbiology result), isn’t a great idea. We shouldn’t really talk about ‘standards’ anyway, we should talk about ‘design frameworks’. Each of these embodies a paradigmatic philosophy that can’t be easily mixed and matched. There’s no sensible way to mix and match ISO 13606 and HL7v3 (I’m sure something has been done somewhere, but that is just semantic hacking). If you mean ‘use case’ in the broad sense, i.e. ‘EHR’, ‘messages’, your statement is more reasonable! well, if SNOMED CT had all its clinical content, pre-coordination problem, upper level ontology underpinnings sorted out, it might make sense to try and codify e.g. characterisations of time. But while the former three things are not sorted out (not unreasonably perhaps - they are horribly difficult challenges) I can’t see the sense in a half done job of trying to codify things that are outside the main purview of a clinical terminology. Codifying situations needs an underpinning theory of situation, and that is not in evidence in SNOMED CT as far as I can see. This is a challenging area on its own, better left to ontologies I think. That is good, but it would be good if the deprecation status was more visible in the IHTSDO browser… this is way outside the remit of SNOMED CT, and again, I can’t see the justification for half-described / ad hoc hierarchy of e.g. document headings / sections, certificate types, report types etc. This just competes with ‘headings projects’ designed to standardise some of the heading structures used in certain sectors of healthcare in a country, e.g. General Practice, ED, general hospital admissions, etc… well your characterisations are to do with ‘fitness for (someone’s) purpose’, not what IHTSDO’s guidelines for use are, which is what I was trying to get at. Both apply; I want to know if IHTSDO is recommending (or not) the use of e.g. Qualifiers hierarchy. If the advice is ‘avoid’ then we will not use it, even if it does appear to be ‘close to my current use case’. Firstly a) my comments are nothing to do with openEHR’s archetypes, or even openEHR, just general usability and computability in the inferencing sense within the general EHR domain. I can’t see any useful inferencing that would be possible with relationships like Action IS-A Qualifier value Adjectival modifier IS-A Descriptor IS-A Qualifier value Blood pressure fall IS-A … IS-A Qualifier value Nor how ‘Blood pressure fall’, ‘Down and left’, and ‘hanging down’ are usefully computable as sibling children of Down IS-A … IS-A Qualifier value (just to start: a quantitative drop in a value has nothing to do with a spatial downward movement.) I’m happy to be educated on this. Secondly, none of my comments are remotely intended to be malicious, or again, specific in any way to openEHR; I had thought that was clear. We are interested in usability and computational reliability generally; I am struggling with how some of these hierarchies help, and can see ways in which they can in fact hinder. Again, I think it must surely be a higher priority to get the clinical hierarchies and upper level ontologies into place, to enable computability of terms about real clinical phenomena. I don’t think this is an unreasonable view from a user / implementer point of view. The editorial guide is pretty good, and we used to have links to it from the openEHR website. However, the URLs to that (and the TIG) all broke some time back, and we have not re-established links, which I think we should do. I do think it would be a great idea to connect editorial guideline and TIG information with the browser, which by the way is an excellent piece of work. Me too. If only we had the many millions of dollars to enable that that IHTSDO has. And if only IHTSDO had not outright rejected the official partnership proposal put together by Professors David Ingram and Martin Severs some years ago, I am sure that many shared areas of work would be significantly more advanced than they are today. But we are where we are. - thomas

(attachments)

[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.

[system]

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

[mikael (Mikael Nyström)]

Hi Tom,

Yes, I mentioned use case in the broad sense for selection of standards and use case in the narrow sense for selecting archetypes and concepts, but I didn’t explain that to keep the e-mail shorter.

I think that we have different views on when a specific method can be used. My view is that it is enough that a specific method add some value to the implementation given the current conditions and requirements. However, your view seems to be that the method must be perfect in every possible aspect to be used in an implementation. For example, if the EHR system only allow the use of single codes I believe that it is better to use the concept 704145004 | Maternal history of insulin dependent diabetes mellitus (situation) | (http://browser.ihtsdotools.org/?perspective=full&conceptId1=704145004&edition=en-edition&release=v20160131&server=http://browser.ihtsdotools.org/api/snomed&langRefset=900000000000509007) to code a free text statement about that the patient’s mother has an insulin dependent diabetes mellitus than to abstain the coding because the situation model could have been more perfect in some sense. However, I agree that that if it is possible to express the situations in the information model (which you seem to assume always are possible) it is in many cases better to do so. (However, as a researcher I also preferred the perfect solutions, but I don’t want to let the best be the enemy of the good.)

The concept model for the situation hierarchy is quite simple (see for example Editorial Guide section 6.4.3 ‘Attributes used to define Situation with Explicit Context concepts’, https://confluence.ihtsdotools.org/display/public/EditorialGuide/6.4.3+Attributes+used+to+define+Situation+with+Explicit+Context+concepts), but it can still provide value even if a more detailed concept model probably could add even more value for a number of use cases. However, your argument “Codifying situations needs an underpinning theory of situation, and that is not in evidence in SNOMED CT as far as I can see.” insinuate that the concept model for the situation hierarchy would be non-existing. It would be more interesting if you could explain your view of the major weakness of the model so it would be possible to consider to propose a revision of the model to IHTSDO.

(If someone would like to read more about the “Situation with explicit context hierarchy” the hierarchy is described in the Editorial Guide section 6.4 “Context terminological Model”, https://confluence.ihtsdotools.org/display/public/EditorialGuide/6.4+Context+terminological+Model . )

My view is that what kind of information that is presented in the IHTSDO browser needs to be carefully selected so the browser interface doesn’t start to be too crowded. Information about the SNOMED CT content are therefore probably better presented in the supporting documents than in the browser. It is also easier to provide good explanations in documents than in a browser window. However, if you are of another opinion there is a “Feedback” button close to the upper right corner in the browser where you can provide feedback about the browser. (My impression is that IHTSDO’s tooling team are always looking for new suggestions of improvements.)

I understand why you with your use cases argue that the Record artefact hierarchy should not be included in SNOMED CT. However, some other implementers with other use cases than yours believed that the hierarchy would be useful and it is therefore included. Implementers are free to select to use the hierarchy or, as implementers with your use cases probably will do, not use the hierarchy. I still can’t see why giving implementers the freedom to select what to use and what not to use based on which option that best fit their use cases is a bad thing.

The Qualifier hierarchy is described in the Editorial Guide section 6.8.11 (see https://confluence.ihtsdotools.org/display/EditorialGuide/6.8.11+Qualifier+value) as “The | Qualifier value | hierarchy contains some of the concepts used as values for SNOMED CT attributes that are not contained elsewhere in SNOMED CT. Such a code may be used as the value of an attribute in a defining Relationship in precoordinated definitions, and/or as the value of an attribute in a qualifier in a postcoordinated expression. […]” The content in this hierarchy together with the requirement that each concepts, except the root concept, need to have at least one parent might make the hierarchy odd. However, proposal for improvements can be submitted at SIRS (see https://sirs.nlm.nih.gov/) and comments about a specific hierarchy would probably increase the priority for that hierarchy in the continuously ongoing content improvement process.

As far as I know IHTSDO is migrating to a new platform for the documentation to make the documentation easier to maintain and present for the users. Unfortunately, it seems that all links to specific sections in a document will break in the migration process. The stable link to the document repository where all current documents are collected is http://www.snomed.org/doc . Some documents are also accessible using stable links, like the Technical Implementation Guide (http://snomed.org/tig) and the Editorial Guide (http://www.snomed.org/eg). (It also seems that the Editorial Guide already is migrated, so the links to the sections in the Editorial Guide is probably already stable.)

I don’t know any details of the proposed partnership between IHTSDO and openEHR Foundation, so I don’t comment on that.

Sorry for my late reply. (I have been on vacation.)

Regards

Mikael

(attachments)