What's new in ADL2.4?

Specifications ADL
1

Congrats everyone on reaching consensus! :partying_face:

Is there a summary about the changes and implications of ADL2.4 that us mere mortals can read? :innocent:

2

One of the things we decided is we need such a document. But itā€™s not there yet. If you want to get started before that: Archetype Definition Language 2 (ADL2)
Basically itā€™s ADL2.3 with AT coding of nodes. So as a modeller you get all the goodies from ADL2 (also described in that (and the current) spec), while keeping the data in the CDR the ā€˜sameā€™.
Feel free to ask, question, this will be great input for the documents mere mortals (unlike you;) can read). But could you please split these comments of into a separate topic. Iā€™d like to keep this topic about the formalisms and serialisations.

3

Nicely expressed @joostholslag .

Just be crystal clear, the only change from 2.3 to 2.4 is to allow ADL2 archetypes to use atCodes and the original atCode numbering system, which had been replaced by a new idCodes and atCode numbering system.

This proved to be a real blocker for getting current CDR vendors to move to ADL2 because of the real burden of the migration of existing code and data.

We now have consensus across the implementer community CDR / tooling to move.

1 Like
4

Thank you for finding a way to move to ADL2!

I have only one concern. Using atCodes instead of idCodes is a breaking change for those that already use ADL2/OPT2. Shouldnā€™t the breaking changes planned for ADL2.4 require to be released in ADL3?

ID_CODE is used in the existing ANTL4 grammar for up to ADL2.3. It will be confusing to use the same grammar for ADL2.3 and the new ADL2.4. It would make sense to have a separate ADL3 grammar without the idCodes.

The existing ā€œofficialā€ ADL2 grammars need to change anyway to ā€œremoveā€ the ID_CODE. To further confuse things, there are multiple ADL2 grammars at the moment and some ā€œredefineā€ idCode:

idCode:
      AT_CODE
    | ADL14_AT_CODE
    | ID_CODE
    ;

This ā€œsolvesā€ the problem of supporting atCode where idCode is expected but it means that the parser must have a handwritten code to check that there are no idCodes used in openEHR-RM based systems (quoted from the ADL2.4 specifications):

  • The at-code codesystem must be used for systems that need to be conformant to the openEHR Reference Model (RM).
  • The id-code codesystem is recommended for non-openEHR RM information models.

Some tools are already using ADL2.3 with idCodes. I would rather have separate ADL parsers generated from ADL2.3 and ADL3 grammars.

I guess ADL2.4 was chosen because ADL3 is already used but it would be prudent to rename ADL3 to ADL4 and release ADL2.4 as ADL3. Shortcuts are quick but usually cause problems down the line.

5

AT codes will be added tot adl2.4 alongside id codes. So itā€™s not a breaking changes. SEC will also bring the different grammar files together. With the Archie file as a new baseline. I think this is the commit that creates a draft of the new grammar file [WIP] ADL++ Ā· openEHR/archie@bcff4a4 Ā· GitHub and the opproach might be clear from that. So please share your concerns regarding the ā€˜newā€™ grammar files with @MattijsK.
IMHO ADL2.4 was chosen because thereā€™s some other controversial changes we might want to make that would be breaking change, and given the controversy and value of the at codesystem, we wanted to keep the change as small as possible. Calling it adl3 would trigger discussing the other issues at the same time, prohibiting progress. I know semver allows increasing major number for non breaking changes. And including other changes is a political choice. So we could call it adl3, but letā€™s first try to figure out the grammar file issue, before going there.

2 Likes