this is an eminently sensible suggestion for how to implement certain aspects of terminology processing in an openEHR system.
- thomas
Hi Ian, thanks for attaching that presentation, I saved it.
But I also read it, but I must admit, that is a bit hard, presentations are always a bit hard to read, the person who gives the information adds value.
But still, very informative.
And at the same time, the difference between FHIR and OpenEHR came to mind, and also the difference purpose of SNOMED in both. FHIR is a message format, while OpenEHR defines a storage environment complete with possibilities for a query engine, facilities for datamining, templates for screens, generating FHIR messages, etc.
In FHIR SNOMED is mainly be used, as I understand, to refer to SNOMED, conceptID's, Refsets, Compositional Grammar, Constraint Language. It are references to explain data, or the environment of the message producer.
While in OpenEHR, it can be used to facilitate the other features which can come out of a full featured OpenEHR environment. It are these facilities where I refer to when I talk about SNOMED in OpenEHR integration.
So I think it is another subject. But still, I am very grateful for the presentation. I almost never have chance to visit those occasions where these presentations are given.
Bert
it’s possible to use SCT more infrastructurally in FHIR, but this is something we are only now exploring with IHTSDO staff + other interested parties
Grahame
I am not sure that I understand you, but to keep it short, I just tell you how I think it should be implemented. The picture is not complete yet. In my idea, it would be best implemented like this. For example, to define a subsumption test, which is part of functionality ECL (expression constraint language). The best thing is when it is possible to adapt the ECL literally, and in interaction with the data in the data-set, return information if a concept used in the data-set satisfies the ECL constraint. Because ECL can be very complicated, and we need to give all freedom to the users, we must be able to implement the full ECL syntax in an embedded part of AQL. Then you offer more, and in a very elegant way, than most of the competition can offer. I think, this will really get the oohhh’s and aaahhhh’s at presentations. It will cost some engineering. But with help of ANTLR, maybe six months maximum for one experienced programmer. I could do that, but unfortunately, I have to earn money, this year, so far, was not so good for me. So I am happy when someone else will do this, and opensource the thing. It is not really rocket science, the definitions are more important. OpenEHR happens to have many prerequisites ready, but some need to be added. Let me do some shooting: We need a syntax to literally embed ECL in AQL. We need a syntax to map data-paths to parameters for doing constraint-tests in ECL And then, coming back to what Daniel Karlsson wrote. There must be predictable locations (reachable by AQL) in archetypes where SNOMED codes are to be found, because these are needed for doing the constraint-tests. For example, in a problem-diagnosis archetype, where always a clinical finding is the lead, there must be a path to that clinical finding-concept ID, that is the easy part. But a clinical finding can have attributes, maybe some of them are also included in the archetype, they also can have conceptID’s, they must also be found. What you are saying is that OpenEHR must also work without SNOMED. I agree with that. So the syntaxes and options needed for SNOMED integration must be optional. Maybe in a later stage, one can enrich archetypes in new versions to add SNOMED integration. We should think about that when formulating the SNOMED syntax requirements. Now we come to opinions on the position of SNOMED. So, my points of view. Point a) A lot of work is in when too many people are involved, and they all may have different interests and opinions. I am afraid that working with IHTSDO can result in slow processing, these kind of things always go too slow in my opinion. I am always amazed how slow organizations work on standards. But you can also see when there is a benevolent dictator, things can really speed up. (Microsoft took less then one year to ISO-certify the OpenXML standard, and Malta (400.000 inhabitants) became a voting ISO member for this occasion). Let me say it another way. We know the syntax from ECL (in this version), so we can implement it. Nothing is standing in the way. We are not talking about a new standard, but about a SNOMED implementation in a software definition. It is nothing big, but very important for OpenEHR. FHIR is another case, it aspires to become a worldwide standard and is going through all the painful stages. They need to talk with all stakeholders, also at IHTSDO. Point b) SNOMED is not the only terminology in the world, from worldwide perspective. But for the Netherlands it will become very soon the only terminology in the world, we will have SNOMED, LOINC and legacy (and some small things like UCUM, etc), and the legacy will be mapped to SNOMED. Kaiser Permanente based their CMT on SNOMED, the number of member countries is growing. When OpenEHR discloses the potential of SNOMED, this will be a unique selling point, the best opportunity for growth in last ten years and five years to come. Although I am not familiar with what CIMI has for us, and the HL7 term binding thinking, but it seems a good start, I hope the OpenEHR community, especially those people who are familiar with this kind of thinking, will do this very soon, so the implementation can start, and over a year by now, we amaze the world by having it running. I suggest someone takes the lead on this. If I can be of any help, please let me know Bert
Hi,
My more recent impressions from inside the SNOMED CT community are not entirely in line with Tom’s impression below.
The people that believe that SNOMED CT is on its own are nowadays quite few. My impression is that most people understand that SNOMED CT needs to be implemented using powerful information models (or data structures) to achieve all its benefits. However, the problem is that there are so many information models for health records around and some of them are (more or less) standardized and some of them are ad hoc and some of them are proprietary so there is difficult to interact and engage with all of them.
IHTSDO’s primary focus is their member countries (and potential member countries) and IHTSDO therefore focus on solving the terminology and ontology needs in these countries. In these member countries are SNOMED CT a large part of the terminology and ontology solution for the health care system. IHTSDO therefore focus on SNOMED CT and collaborations with other terminologies and classifications that are well used in the member countries, like ICD and LOINC. However, it is understandable that for people in non-member countries it seems like IHTSDO assumes that the whole world uses SNOMED CT.
Regards
Mikael
Thomas Beale wrote:
Indeed. Ideally we would work more closely with IHTSDO on this (I spent 4 y on standing committees there), but I think there is not yet the interest in this. There are still people who believe that a) SNOMED CT on its own, with only trivial data structures is all that is needed (that’s a categorical error of thinking) and/or b) that the whole world uses SNOMED CT and that therefore the only terminology approach is SNOMED CT (an error today, and I suspect for years to come).
By the way, this kind of things you describe is one of our group main
research areas right now. We have implemented a service to evaluate
the Snomed Expression Constraint Syntax (engine available at
http://snquery.veratech.es/) and we are already using it for data
validation (e.g. is the provided code in the subset) and
transformation/query (e.g. if diagnosis is one of X then put this
value). I hope we can release an online demo or paper soon enough.
Thanks Diego,
This would of considerable interest. I have a feeling that AQL and SCT query expressions are a pretty neat fit (plus of course the validation use-case you have mentioned).
Ian
That would be very interested, the use case of validation is also a good one.
I think the biggest problem is of formal nature.
How can archetypes be used to implement SCT functionality in a generic way.
I am not in a position, nor do I have the experience or time to solve/answer these formal questions.
Some requirements were already be mentioned between the lines
It should be possible within ADL 1.4/2.0
It should be able to enrich existing archetypes, while maintaining backwards compatibility.
It must be an extension on AQL, not a change to the existing query language.
I really hope someone will pick this up very soon.
Bert
sorry for the sloppy English, time for diner.
Mikaels thoughts resonate with some discussion we had during the MIE/HEC2016 openEHR Developers’ workshop.
Many of us think that a better integration of the openEHR and the Snomed CT modelling efforts would be great. But there are not enough resources (e.g. dedicated time of people with the right knowledge) being put into doing this, since this is hard (but interesting) work usually requiring somebody to pay people…
When there are countries (or other giant organizations) interested in using both openEHR and SNOMED CT, then such resources may start being allocated. (It is reasonable that organizations listen to their members’ needs.) Norway might be/become such a country - they already have a serious openEHR modelling effort and will likely start using SNOMED CT more.
What about Brazil? UK? Others? Dear list members, please tell us if you know about big efforts/programmes seriously interested in using both openEHR and SNOMED CT for real EHR systems etc.
Hi Erik,
I do not want to undermine the value of your statement, contrary, I think it is very good when some organization or country builds the thing, the money involved is a piece of cake for such an entity.
Let the people with good connections start working on getting this arranged!!!!
The sooner the better!!!
we should *NOT* sit down and wait until something will happen.
(sorry)
I wish there was any activity regarding SNOMED CT in Germany at all 
Cheers,
Birger
I realise that what I said made it sound like IHTSDO experts still think that terminology solves everything, but I didn’t mean to do that, I actually meant to imply that there are people in user orgs who still think like this (I often run into them). Mikael’s characterisation of IHTSDO thinking and strategy is of course more correct than mine.
- thomas
I will actually have some time to start to look at this in the next few weeks - i.e. to facilitate / coordinate some work, and possibly do some. I would propose to proceed as follows:
- gather current unmet requirements
- examine current state of AQL spec to clarify what it alredy says, what it lacks
- propose changes to AQL
The question of adding e.g. an Antlr grammar for the IHTSDO constraint expression syntax to AQL is almost trivial; the real question to me is: what is the querying + terminology interaction model we are trying to achieve.
So some example queries (pseudo-code is fine) would help. If Bert and others who want more progress can at least post some ideas at the requirements level - clear and succinct as possible please - it will help a lot.
Here is a wiki page for gathering this information. As usual, contributors should feel free to change it as required.
- thomas
Very good, Thomas, I appreciate your help.
I have some good starting thoughts and will write them tomorrow in the wiki.
Bert
Very good discussion.
Regarding Brazil - I cannot speak on behalf of the MOH but what we’ve been informed is that the MInister demanded the Financial Area to pay SNOMED-CT. We all hope this is going to happen soon.
Meanwhile some organizations (private hospitals) have a SNOMED license. THe Hospital I work with ( Sirio Libanes ) has recently developed a full POC using Marand’s backend, a Terminology server, an interoperability layer (Health Connect) and a legacy system (TASY from Phillips) and it was very successful. All archetypes we are using, specialising, or creating use SNOMED-CT as the reference terminology. We are working close with the team that is developing archetypes and templates for the national project.
I agree with Thomas. Terminologies are essential but not enough. It is necessary to have the information model and then the binding to the terminology set.
As soon as Brazil signs I think we could partner with Norway to support this OPENEHR -SNOMED CT initiative.
I invite you to come to the CBIS 2016 - The Brazilian COnference on Health Informatics, November 27th -30th. OpenEHR will be one of the topics and we plan to show what we are doing. http://www.sbis.org.br/cbis2016
Hi,
On my site, ideas grow slowly, during the week while writing and talking about it.
I think I have thought it over now.
let me tell you what I have thought:
1) There is not much change needed in the OpenEHR specs to unlock the full datamining potential of SNOMED.
2) Also there is hardly any change in software architecture needed (of course, this depends on the implementation)
3) It is an addition, and easy to create, and no problem if your archetypes are going to be used in a Non-SNOMED country. The integration is in a very transparent way possible.
4) There needs to be software written. But it is software, largely based on ANTLR. I don't think that is a big project.
Today, I wrote a post on it on my webblog.
Maybe I miss something, but I guess I will hear about that.
Check for yourself:
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/
Best regards
Bert Verhees.
This is perfect timing with ongoing activities in Norway.
There is a government lead activity to explore how to use SNOMED-CT and openEHR archetypes together. The first domain is to use SNOMED-CT to define anatomical location and structures.
The most important outcome for this is to be able to reason over data and use the hierarchical structure to query for all entries in lower left limb which should include knee and meniscus entries (pseudo-definitions given here).
In parallel with this activity we are involved in a project where they will build an ontology of all entities and make that ontology model/platform as a basis to query data from different sources (systems). We are involved since we think openEHR reference model with archetypes is such an ontology. But in addition to that we need to map terms from different other terminologies like SNOMED-CT, LOINC and also Disease Ontologies.
In the end I think we need a shared pattern on how to model and implement this – and as mentioned the most important thing is to be able to do queries on this hierarchical/graph structured ontologies/terminologies.
There is a mapping effort by IHTSDO en Regenstrief, they started that a few years ago, and it will be finished, next year, I think.