Navigating the documentation releases

As a newbie writing code using openEHR, I’m keen to make sure I try and stick to the specifications wherever I can.

I am using the openEHR - Release Baseline to help me identify the current versions, having everything signposted from one place is really useful.

The tools I am building revolve around archetypes in ADL 1.4 - so I have been working through the ADL 1.4 and AOM 1.4 specifications.

HAving work through parsing the ODIN based components and constructing the relevant classes, I find myself at the ‘ontology’ section where things don’t seem to align.

The ADL spec has this

Whereas the AOM has the relevant classes described at Archetype Object Model 1.4 (AOM1.4)

I’m missing something as I don’t see any relationship between the ARCHETYPE_ONTOLOGY Class and the ARCHETYPE_TERM Class in the AOM content.

How are the two related? The ‘functions’ within the ARCHETYPE_ONTOLOGY Class make frequent reference to the terminology language yet this is not present in the class attributes (though is of course present in the ADL).

What have I missed?

The ontology section (mis-named because we thought we were going to put ontology directly in there) in AOM1.4 was not fully specified. In AOM2 it is fully specified and you will see the relationship.

Nearly all the archetype tools today are ADL/AOM2 based internally, and they just treat ADL1.4 as a syntax; it is parsed and converted to AOM2 form internally. This is true for ADL Workbench, Better’s Archetype Designer, the Archie library, the Nedap tool, and (mostly) for LinkEHR. (Links to all these tools.)

I would suggest using the code in Archie, which does both ADL1.4 parsing and AOM2 representation and will save you a lot of work.

Hi Thomas - thanks for the reply.

I had thought that I could leave AOM2 until a later phase in my development, but it appears not. I’ll pivot onto that model going forwards. It was always my plan to support it eventually but looks like it will be sooner rather than later. At least it replaces AOM1.4 and I don’t need to do both.

I am making reference to the Archie library, indeed the extension in Visual Studio is really helpful.
Although arguably creating ‘another parser’ might be a fruitless task, it does force me to get a deeper understanding of the underlying openEHR specification (including the versioning :slight_smile: ).

For my ‘project’ it will be beneficial to have the parser in C# so I’m taking the time to try and do it properly. My first (partial) implementation of the parser is already in AWS as a microservice. There’s loads more to do, at the moment it’s creating a whole stack of test scripts for regression testing.

1 Like

Well you might go further than I have on those openEHR-antlr4 grammars. They should (eventually) be better grammars than the current production ones (by virtue of being a cleaner design, modal etc) but they’ve only had a modicum of testing and have not yet been implemented. So it will be very interesting what you come up with, and doing it with another language (not Java) will surely surface some lessons.

1 Like