Modeling generic concepts, considerations for querying

Thomas Beale thomas.beale at
Tue Oct 10 11:44:44 EDT 2017

On 10/10/2017 16:26, Birger Haarbrandt wrote:
> Hi Thomas,
> sorry for the late answer, I just came back from my vacation. For our 
> project, we would certainly like to start with commercial openEHR 
> repos for the larger sites. From my understanding, most products of 
> the bigger openEHR vendors are ready for ADL 2. If I'm wrong on that, 
> we need to reconsider this demand. The reason why we would like to use 
> ADL 2 in particular is its improved handling of specialization which 
> we think will be very important for our project.
> Can you elaborate a bit on what would need to be done by our local devs?

The ideal is certainly to have a model base that is expressed in 
ADL2/AOM2 form, because of the numerous improvements of ADL2 over 
ADL1.4. That can be partially achieved with the new Marand ADL-designer, 
which will enable your source /archetypes/ to be managed in AOM2 
internally, with the old-style archetypes being importable, and the 
old-style OPT being exportable. The down-side is that your source 
/templates /will be in .oet form, which can't represent languages and 
various other things properly. I believe a  next version of this tool 
could fairly easily implement ADL2 templates however, but still generate 
old-style OPTs, based on a 'null .oet' that treats the real ADL2 
templates as if they were just archetypes.

In terms of EHR back-end, I think you have two choices:

  * use an existing implementation and populate it with '1.4' OPTs,
    generated from a tool like ADL-designer. This OPT form will be
    consumed by all of today's systems.
  * upgrade an existing implementation to handle v2 format OPTs, which
    properly represent languages and various other elements of templates
    that .oet templates can't represent.

The first option is a compromise, but likely to be reasonably 
acceptable. However, if you want to get the full power, some upgrading 
will be needed of whichever implementation you choose. The amount of 
work involved would require a detailed look at the particular 
implementation and a discussion with the developers on how to upgrade it 
for OPT2. If this work can be shared and does not impact too greatly on 
the main research purpose (which is presumably building interesting 
things on top of the EHR repository), it would be a nice project to set 
up within openEHR.

- thomas

Thomas Beale
Principal, Ars Semantica <>
Consultant, ABD Team, Intermountain Healthcare 
Management Board, Specifications Program Lead, openEHR Foundation 
Chartered IT Professional Fellow, BCS, British Computer Society 
Health IT blog <> | Culture blog 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list