More generic reference model
bert.verhees at rosa.nl
Sun Sep 4 06:59:35 EDT 2016
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.
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.
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,
> * tracking the outcomes of CIMI term-binding and applying them where
> * reviewing recent HL7 term binding thinking
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical