More generic reference model

Bert Verhees bert.verhees at
Sun Sep 4 05:58:55 EDT 2016

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


On 03-09-16 20:43, Ian McNicoll wrote:
> I found this excellent document from GEHCO 
> <>. It refers mostly to FHIR but has some examples 
> from openEHR, and I think the challenges and principals are pretty 
> well identical.
> I know CIMI has a key aim of trying to create the kind of iso-semantic 
> models that Bert is advocating, and while this is a laudable 
> objective, the challenge should not be under-estimated.
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: ian at <mailto:ian at>
> twitter: @ianmcnicoll
> Co-Chair, openEHR Foundation ian.mcnicoll at 
> <mailto:ian.mcnicoll at>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> On 3 September 2016 at 17:34, Bert Verhees <bert.verhees at 
> <mailto:bert.verhees at>> wrote:
>     On 03-09-16 18:17, Thomas Beale wrote:
>>     Bert,
>>     doing most of what you want should come in AQL, e.g. the
>>     following in a WHERE clause is already possible.
>>     SELECT
>>         e/ehr_status/subject/external_ref/id/value,
>>     diagnosis/data/items[at0002.1]/value
>>     FROM
>>         EHR e
>>             CONTAINS Composition
>>     c[openEHR-EHR-COMPOSITION.problem_list.v1]
>>                 CONTAINS Evaluation
>>     diagnosis[openEHR-EHR-EVALUATION.problem-diagnosis.v1]
>>     WHERE
>>         c/name/value='Current Problems'
>>         AND diagnosis/data/items[at0002.1]/value/defining_code
>>     *matches* {|cancer
>>     <> Dx refset|}
>     That is a very OpenEHRish way to do it, is comparing the code.
>     But what if you also want to find the subtypes, lungcancer (30
>     sub-types), etc, if you want to know about SNOMED attributes.
>     For that purpose is the Expression Constraint language, and you
>     need to query the terminology to know what you need to compare
>     your data with.
>     The best way to do it is not invent another way to do it, but
>     embed that language.
>     <>
>     When that is done well, you have the full power in one move.
>>     One interesting question is whether 'inline' refset definitions
>>     would be allowed, e.g. using the SNOMED constraint grammar. We
>>     probably should add this to AQL as a plug-in syntax, since IHTSDO
>>     standardised it
>>     <>.
>>     What the solution is for ICDx I don't know.
>     I don know either.
>     There is more then just a plugin which does some separate work.
>     Because the ECL also works on subtypes and attributes, and the
>     attributes are not available. AQL must deliver them to the SNOMED
>     engine, because they are on another path. There is code
>     infrastructure needed.
>     For example: Find systolics higher then 165, in the archetype the
>     type of the measurement can be in another element then the value
>     of the measurement.
>     This mapping between SNOEMD attributes and where they are in the
>     archetypes must be done in some elegant way.
>>     The main thing to understand is that if a SNOMED or ICD code for
>>     say leukaemia is found in EHR data, the code alone doesn't tell
>>     you the epistemic status, i.e. the kind of statement being made -
>>     i.e. current diagnosis, no risk of, risk of, fear of ... etc.
>>     Querying properly means understanding where in the data you are
>>     looking, and the archetypes help with that.
>     That will be one of the added values of archetypes.
>     Bert
>     _______________________________________________
>     openEHR-clinical mailing list
>     openEHR-clinical at
>     <mailto:openEHR-clinical at>
>     <>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list