SNOMED

Technical (archive)
1

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

2

Part two is of course, generating templates, and we almost have the GUI's in place.

It is the enormous collection of medical datastructures which can be the source of many generated EPD-software.

Bert

3

You can do some very clever things with Snomed CT especially if using “post-coordination” in a good way. Sadly many current EHR-systems can’t utilize that power of Snomed CT fully. Clever archetyping with e.g. some built in post-coordination-generating logic combined with some extended (AQL?)querying-capabilities in openEHR storage systems could help openEHR-based systems jump ahead of a lot of the EHR competitors regarding efficient Snomed CT use…

It is often good to look at Snomed CT when designing archetypes. Especially the high quality parts of Snomed CT (there is constant maintenance and cleanup going on). I believe this is happening more already when designing archetypes today.

Regarding licensing I believe there has been a discussion going on between IHTSDO and the openEHR foundation for a long time, perhaps the management board has an update?

I believe we might need to add a function to repositories/CKMs that removes Snomed bindings/codes from archetypes if downloaded by non-licensed users. (A lot of the structure/content itself is based on (non protected) general medical knowledge and I believe IHTSDO concludes it can be partly reused without license, thus not stopping global use of Snomed-inspired archetypes.)

Others will surely add more to the discussion.

//Erik Sundvall

fredag 29 april 2016 skrev Bert Verhees <bert.verhees@rosa.nl>:

4

Thanks Erik, for your reply. I did some more thinking in the meantime.

In SNOMED you have disorders, and they have attributes, and we all know there are thousands of them. Writing so many archetypes is impossible, and probably not necessary, but when you take in account to limit the number of used paths, (this helps also limiting the length key-index for a key value store), and you really think smart how to do it, so it can be generated.

Because SNOMED is in fact a description of many clinical meanings with post-coordinate expressions and allowable attributes, just like archetypes are a way to describe the same, it seems quite a potential, especially because it can be used to generate archetypes, I had never thought of the idea until yesterday. So I haven't worked it out.

I don't know which part is of high quality and how you define high quality, (or do "they" define it?), and also to consider, are archetypes always of high quality?

Archetypes are version-able, so, they could follow SNOMED versions. You cannot build the world in one day. It has to grow, but a lot of work can be done in one major blow.

In the Netherlands we can use SNOMED for free, so that is a good thing.

By the way, the semantics which are baked in the OpenEHR RM make it a bit more difficult. I think that a data-storage, modeled like CEN13606 would make it easier to do this. But it may also be possible in OpenEHR, we must work it out, to find it out.

Bert

5

Hi Bert,

This is going to sound controversial but …

I am a big fan of SNOMED-CT and at some pint in the far distant future, what you are proposing (or something like it) will happen. However, I have seen endless similar proposals/projects in the UK and beyond, entranced by the potential of post-coordination, repeatedly falling over, wasting huge amounts of resource and energy and achieving nothing. That includes CIMI, which has, IMO, been largely stalled by setting itself the goal of labelling all CIMI nodes as SNOMED terms, and for archetypes being ‘iso-semantic’ with post-coordinated SNOMED expressions.

Whilst this is a laudable goal, it is hugely complex and it is, I think significant that where progress has been made (openEHR and FHIR) both have largely taken a prgamatic and limited approach to use of SNOMED-CT.

SNOMED is a primarily an ontology of biomedical fact, not of clinical practice/documentation. Used

@Erik - we have only just been asked to resume discussion with IHTSDO. The view of the MB is that it is not our place to police the use of SNOMED-CT by end-user systems. All SNOMED-CT bindings in openEHR artefacts are optional mappings. We are happy to add a boilerplate license to each archetype (as for any third-party IP) that implementers must ensure that any use of SNOMED-CT is allowed. There is no intention to otherwise adapt or strip-out content for unlicensed consumers, as I think you were suggesting. If IHTSDO feel the need to enforce more onerous terms than a simple boilerplate “Please respect IP” statement, I think we might find that very problematic.

Regards,

Ian

6

Thanks, Ian,

As I understand well, CIMI has many nodes, and labels them as SNOMED, so for each concept one node. I think that is impossible. It is like doing the SNOMED work over again.

That was not the approach I was considering. I was thinking about more generic structures where in SNOMED fits in a variable way.

But maybe you are right, but Stubborn is my second name, as you may now, so I am not yet convinced.
I have done a few times certain things in the past, something others, experienced people, considered impossible.
I will see what further thinking and more discussion brings.

Have a nice day
Bert

7

Dear All,

while there may be some benefit in cross pollination between SNOMED CT and archetypes, and while there also may be some low-hanging fruit in bridging the semantics of both models (pre- or post-coordinated laterality would be an often mentioned example) in general I’m a skeptic for a few reasons :

  • the use cases are not the same - ontologies represent universal truths about the world, archetypes represent record keeping requirements
  • ontologies and archetypes have different “reasoning” requirements and thus different representation languages, algorithms etc. (the ontology-information model separation is a divide-and-conquer approach)
  • for ontologies to compute meaningfully, a larger degree of consistency is needed, archetypes may be (and are being) developed and used with such a need

(ontologies here refer to (at least) DL ontologies in general, archetypes to any information modeling framework)

/Daniel

8

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
9

As an example of how not to try to do things …

http://www.kith.no/upload/6407/HelsIT-2011_T2-2_Laura_Sato.pdf

#fail

Ian

10

Hi Daniel, thanks, I posted the idea also to some Dutch groups, one argument was that there is no workflow in SNOMED.

It is not a perfect solution.

Therefore I am glad you mention the low hanging fruit, and maybe it is more then "some", maybe it is a lot.

So let us concentrate on that, and see where we would be able to come.

* the use cases are not the same - ontologies represent universal truths about the world, archetypes represent record keeping requirements

I understand your argument, but is that universal true? aren't there any structures usable for recording in SNOMED. I am not a clinician. So, I always have the wrong examples.

I checked "fever" in the SNOMED browser.

There are many subtypes, Malarial fever, Hay fever, Q fever, etc....
But there is also the primitive attribute Body Temperature (observable entity) which can contain to a value. So that can be used for recording, can't it?

* ontologies and archetypes have different "reasoning" requirements and thus different representation languages, algorithms etc. (the ontology-information model separation is a divide-and-conquer approach)

There are a lot of similarities, supertypes, subtypes, attributes, I haven't found until now a structure which does not fit in an archetype.
I think, I must be missing something.

* for ontologies to compute meaningfully, a larger degree of consistency is needed, archetypes may be (and are being) developed and used with such a need

I am not sure I understand what you want to express here. Can you explain it, maybe with an example.

Thanks
Bert

11

Thanks Thomas,

I read your text a few times, and now I think I understand what you are saying.
You say that SNOMED (first remark is not of that high quality to be useful for this purpose) is too extended, too many datapoints, and many useless datapoints for a clinician to be able to do his work, although there are also observable datapoints, as I gave an example in reply to Daniel Karlsson

I think that every leaf-node in an Archetype can be encoded in SNOMED, don't you think?
But that does not say it works the other way around. It is hard to filter out which datapoints are to show to a clinician.
We don't want to fill his screen with useless data-entry-points, and especially not when it is a tablet or something.

Is there a way to solve this problem in an ergonomic way?
Or is it a problem which needs to be solved (if possible) in the datastructures itself.

I think I need to let the idea rest for a while.

Thanks all for your reply
Bert

12

Hi,

I can just add that those entities Tom mentions below as

“The waters are muddied further by the attempts to represent informational, timing and context-related entities in SNOMED CT.”

Are the clearly separated sub-hierarchy called “Situation with explicit context” (http://browser.ihtsdotools.org/?perspective=full&conceptId1=243796009&edition=en-edition&release=v20160131&server=http://browser.ihtsdotools.org/api/snomed&langRefset=900000000000509007) and that sub-hierarch contains only 1 % of the concepts in SNOMED CT. It is therefore no problem to use SNOMED CT without these concepts for those who want to do it.

Regards

Mikael

13

Hi Bert,

comments below!

Yes, let’s see. I’m still a skeptic though :wink: Yes, the terminology may be used to populate value sets for coded elements. SNOMED CT will additionally tell you that fever has some connection to body temperature. This is needed in SNOMED CT to formally define the SNOMED CT concepts, but won’t help anyone building an archetype for patients with fever (perhaps not the best of examples). It’s universally true definitional knowledge, and thus typically not that exciting to record. The way it would be used would be to bind it to an archetype node. Still, while SNOMED CT can well be used for terminology binding, using the structure of SNOMED CT, the SNOMED CT concept model, is a different matter. The SNOMED CT concept model might tell you that a Finding has a Finding site which is a kind of Anatomical or acquired body structure. This might have some relation to the Body site in the openEHR-EHR-EVALUATION.problem_diagnosis.v1 archetype. Of the 14 attributes of that archetype though only a few has any such correspondence to the SNOMED CT concept model. Of the 15 allowed attributes for Findings only a few corresponds to archetype elements. Then, there might be somethings to be done (the low-hanging fruit), like if the Body site (not Structured body site!) also has a SNOMED CT code you might bridge between a SNOMED CT concept with a Finding site and an archetype instance with a Body site. However, I assume the archetype Body site would often be used when there isn’t a simple site which can be given a single code. True, but also dissimilarities: open vs. closed world, unique name assumption vs. not, untyped vs. typed, different sets of operators, etc. Sure, I’ve been working on creating some templates for an assisted living/IoT kind-of project and the archetypes I used have a few different patterns for representing measurement values, e.g. simple ones like openEHR-EHR-OBSERVATION.body_temperature.v1 where the kind of observation is in the element name and more complex ones like openEHR-EHR-OBSERVATION.lab_test.v1 where you have to specify the kind of observation with a specific element (at0005::Test name). For archetypes this is generally no problem, if you know which archetype is used, you know how to query. This “lack of consistency” also allows the archetypes to be tailored to specific needs. For an ontology, if you were to have different patterns you would end up with different hierarchies and you would get false negative subsumption test results. Cheers, Daniel

14

Hi Bert,

“I think that every leaf-node in an Archetype can be encoded in SNOMED, don’t you think?”

I’m afraid not even close, especially when you take into account the changes in the meaning of datapoints that apply when used in differing contexts. When doing modelling for histopathologym I was not even close to getting 50% binding of SNOMED to archetype leaf-nodes, ands histopath is one of the better covered parts.

We have been here before!! This was the whole drive of the English national program, and cost us almost 10 years of sensible progress. That is not to say that SNOMED-CT is a bad thing, just that it has to be used appropriately.

At it’s simplest, information models should provide structure and context ‘names’ , terminology provides the values. It is clearly much more complex than that but not a bad start point if we are looking to play to the strengths of each.

Ian

15

I understand now, Daniel, thanks for explaining.

Have a nice day.

Bert

16

Leaf-node datapoints should not have much context. Like observable items like Body Temperature, it should be there as a lego brick, and receive its context where used in an archetype, but this is a simple item. The problem is of course that there is need for complex structures like there probably are for histopathologym So I agree that SNOMED is not fit for the purpose I made up. It is far from complete, and it has another purpose. I am convinced by now. That is too bad. It seemed like some elegant idea, generating archetypes from a hierarchical collection which contains very many connected datapoints, like SNOMED does. So I think the collection needs another purpose to start off with. Dedicated to archetype-leafnodes, with according paths. I wonder, would it be possible to generate a subset of SNOMED which would be usable for archetypes? Or is it a future plan from IHTSDO to work on such a refset? These questions may be understood as rhetorical. Thanks Bert

17

I agree with all, most of the terms are difficult to be translated to
archetypes. What it is possible using snomed is to specify the
valuesets of a given data element by using the snomed expression
constraint syntax. We have been experimenting with it for a while, we
have even put an execution engine online.
http://snquery.veratech.es/

Another idea to achieve what you want (which is something that some
countries are doing and HL7 also does but with Loinc) is to extend the
terminology in order to provide new codes with a meaning of exactly
the archetype element meaning (or CDA template/FHIR resource). These
come in an extension, so not all that interoperable, but al least you
could bind the archetype to something

18

in theory, it might be possible to attached a SNOMED code to every node that says what the node 'is-about'... but just look at the path list of the apgar archetype. 6 principle data points x 4 time values = 24 main data points. Is 'Apgar muscle tone @ 2 minutes' codeable in SNOMED CT? In fact, you have to use LOINC to do it...

- thomas

19

Hi Mikael,

right… but the usual idea is that these codes would be used in a post-coordinated expression. I think most of those expressions are problematic as well.

Aside: quite what ‘Abuse counselling for non-offending parent (situation)’ is doing there is another question. Or ‘Both parents misuse drugs (situation)’…

But the problem is more widespread than Situation with explicit context.

The ‘Qualifier value’ hierarchy is also problematic, particularly ‘Context values’, and the ‘Temporal context’ sub hierarchy. Having all this under ‘Qualifiers’ is an information recording view of things, not an ontological view. Also terms like ‘Current - time specified’ don’t really make sense.

‘Descriptors’ - a huge bag of ontologically different things lumped together… none of these would be usefully computable as far as I can see, since they are not connected to meaningful parents.

Then we have ‘Record artifact’, also informational in nature, and specifying an ad hoc set of headings. I can’t see what use this is.

  • thomas
20

Hi Tom,

Most of the concepts in the situation hierarchy had probably been added because they have been useful in EHR systems without advanced information models and without the possibility to post-coordinate and they are probably still in SNOMED CT because some of these EHR systems are still in use. However, if you have the possibility to use better EHR systems there are no need to use these concepts. I therefore doesn’t see any real problem with them.

The concepts in the qualifier value hierarchy are no longer in use to the same extent as they were when SNOMED CT was new 2002 and will probably be cleaned up in the future.

I agree that the Record artefact hierarchy could be more useful, but I guess that this hierarchy to a quite large extent needs to be filled with content on the national level, because a quite large part of the administrative concepts are country dependant.

However, I believe these kinds of complains about the content in SNOMED CT are less useful. It is more like complains about openEHR because there are some outdated or draft archetypes of lesser usefulness in the CKM. This kind of content is always possible to ignore to use. Much more useful complains would be complains about lack of content or incorrect modelled content in areas that are central for the healthcare system. These kinds of complains can improve the content and make SNOMED CT easier and better to use. Please submit them in the SNOMED CT International Request Submission (SIRS) System at the address https://sirs.nlm.nih.gov/ .

Regards

Mikael