More generic reference model

Bert Verhees bert.verhees at rosa.nl
Sun Sep 4 06:59:35 EDT 2016


Hi Thomas,

On 03-09-16 21:30, Thomas Beale wrote:
> I'm not sure if it was clear from the above - the WHERE clause is 
> testing for membership of a code in some EHR data in a SNOMED ref set, 
> i.e. a value set of cancer diagnoses (or you could make it Lung cancer 
> if you want). The (fake) concept code 42570301000090487 stands for an 
> evaluated ref set, assumed to be known inside whatever terminology 
> service the AQL service talks to. How the membership comparison is 
> done may vary, with many possible implementations.

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.

> some of the needed 'attributes' can potentially derived from the 
> SNOMED concept model and data might even be represented using SNOMED 
> expressions. But, don't forget, openEHR is for the whole world, not 
> just the SNOMED world. Much of the world doesn't use SNOMED CT. So 
> such mappings have to be done in archetypes, and only directly 
> represented in data for those locations that really do have SNOMED. We 
> have not worked out all the tricks to make it work for both worlds.

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.

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

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.

>
> But there are certainly things we can do to improve on our side, 
> including:
>
>   * tracking the outcomes of CIMI term-binding and applying them where
>     possible
>   * reviewing recent HL7 term binding thinking
>     <http://wiki.hl7.org/index.php?title=Binding_Syntax#Current_Working_Material>and
>     using what we can
>   * making sure we use all the IHTSDO new standards we can, e.g. URIs,
>     Constraint language as per above discussion etc.
>
> Principally I think we need some openEHR community members to work on 
> some of this and make recommendations for improvements to AQL and 
> archetype terminology binding.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160904/a2be58a0/attachment-0002.html>


More information about the openEHR-clinical mailing list