Support conversion of ADL1.4 to ADL2 at-coded

[VeraPrinsen]

In this PR, a configuration variable is added to the ADL14ConversionConfiguration class to be able to convert adl1.4 archetypes into adl2 archetypes, but based on the at coded system, this will be supported from adl 2.4+.

Still to do:

• What is the current adl version? That should also be updated in the configuration file.
• When converting, there are still some differences in the details section, where sometimes an extra space is within the text. Is this a problem?
• Also the order of terminology codes is different than in the example archetype, because the order is dependent on when the objects are added to the map. Is this a problem?

[VeraPrinsen]

Old code assumed all nodeId's were converted, now this is not the case

[codecov]

Codecov Report

Attention: Patch coverage is 77.61194% with 15 lines in your changes missing coverage. Please review.

Project coverage is 72.20%. Comparing base (262de90) to head (8c492c7).

Files with missing lines	Patch %	Lines
...om/nedap/archie/aom/terminology/ArchetypeTerm.java	0.00%	4 Missing and 1 partial ⚠️
...dap/archie/adl14/ADL14ConversionConfiguration.java	71.42%	4 Missing ⚠️
...ap/archie/aom/terminology/TerminologyRelation.java	20.00%	1 Missing and 3 partials ⚠️
...a/com/nedap/archie/adl14/ADL14NodeIDConverter.java	95.23%	0 Missing and 1 partial ⚠️
...dap/archie/adl14/ADL14TermConstraintConverter.java	91.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##             adl_2.4_support     #658   +/-   ##
==================================================
  Coverage              72.20%   72.20%           
- Complexity              7121     7135   +14     
==================================================
  Files                    672      672           
  Lines                  23156    23195   +39     
  Branches                3755     3767   +12     
==================================================
+ Hits                   16719    16748   +29     
- Misses                  4697     4702    +5     
- Partials                1740     1745    +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MattijsK]

Initial review done. I will test a bit more and also asked Joost if he can help with some testing. See also the comments of Joost (and my reaction to some of those)

[joostholslag]

I see you marked all my remarks as done. It looks like you applied all my suggestions. Thank you. Is there anything else you'd like me to review?

[VeraPrinsen]

I see you marked all my remarks as done. It looks like you applied all my suggestions. Thank you. Is there anything else you'd like me to review?

@joostholslag No that's fine, I just wanted to let you know I've implemented your comments and if you want you can look at it again. We are testing manually with a few more archetypes at our side

[joostholslag]

Cool. Nicely done. Thank you for the work!

[gardes]

Hi all,

I love this branch and the at-coded 2.4 conversion routine and could not resist to play with it - very nice work!

One thing I noticed is that the conversion of C_DV_ORDINALs from 1.4 archetypes to 2.4 at-coded archetypes may have a problem. It is best shown with an example from a CKM archetype, e.g. https://ckm.openehr.org/ckm/archetypes/1013.1.137 :

ADL 1.4

at-coded ADL2.4

The converted at-codes are incremented by 1 and not zero-padded. I would have expected them to remain unchanged and zero-padded?
Without this, it is well possible that the terminology has both of at14 and at0014 in the terminology, but with completely different meanings. There are actually examples in other archetypes where this happens in practice, see at27 vs at0027 - example from: https://ckm.openehr.org/ckm/archetypes/1013.1.7006/adl :

---

Order of terminology codes

Also the order of terminology codes is different than in the example archetype, because the order is dependent on when the objects are added to the map. Is this a problem?

It would be useful if they are in the natural alphabetical order of the codes, this is what we typically do I think (and may be easier to implement than explicitly keeping the original order in 1.4. In most cases, the result will be identical.

---

Demo archetype
BTW, I often like to use the Demonstration archetype in CKM https://ckm.openehr.org/ckm/archetypes/1013.1.1385 for any testing purposes, maybe it is helpful for you.

I hope these comments are helpful to you! Kind regards,
Sebastian