Error in CKM body_weight ADL2 form archetype

Clinical
1

We’ve just noticed that there is something strange in the body weight archetype, ADL2 version see the last item:

DV_QUANTITY[id29] matches {
  property matches {[at30]}
  [magnitude, units] matches {
    [{|0.0..1000.0|}, {"kg"}],
    [{|0.0..2000.0|}, {"[lb_av]"}],
    [{|0.0..1e+006.0|}, {"g"}]

That 1e+006.0 should just be 1000000.0. Is this an Archie generation thing (@sebastian.garde )? It breaks other parsers that try to consume it, and can’t be used in JSON either.

2

Yes, this is Archie generated.
@pieterbos, maybe there is a configuration for this?

3

That is indeed an issue. The ADL 2 grammar does allow for exponent notation, but not in that format. From the ADL2 grammar:

INTEGER : DIGIT+ E_SUFFIX? ;
REAL :    DIGIT+ '.' DIGIT+ E_SUFFIX? ;
fragment E_SUFFIX : [eE][+-]? DIGIT+ ;

This is the same form as is supported in json, and that should be 1.0e+6 or 1000000.0.

So the order of the fraction and the exponent segments appear to be reversed. The serialiation Archie uses is the Double::toString method in java. That has a clear specification, as in java 8:Double (Java Platform SE 8 ) or in java 17
Double (Java SE 17 & JDK 17)

That conforms exactly to the correct format. I would also not expect this to ever generate a 10E6, only a 10E7 and greater. So, either I am missing something, or this is a bug in the JVM used, or Archie is not used for this conversion.

I checked the CKM, and that converts this correctly:

   DV_QUANTITY[id9002] matches {
                                                property matches {[at9000]}    -- Mass
                                                [magnitude, units] matches {
                                                    [{|0.0..1000.0|}, {"kg"}],
                                                    [{|0.0..2000.0|}, {"[lb_av]"}],
                                                    [{|0.0..1000000.0|}, {"g"}]
                                                }
                                            }

From Observation Archetype: Body weight [openEHR Clinical Knowledge Manager] , select adl 2 with the radio button at the bottom. The generated id code, id29, also suggests that Archie was not used in conversion, or that it was converted using very strange custom settings. Because id29 is likely to conflict with future codes in ADL 1.4, and id9002 is not.

So @thomas.beale , how did you obtain this archetype? Could it be that this was converted using either the ADL workbench or the Better archetype designer? Those do not use Archie for conversion.

1 Like
4

I thought I had taken it from CKM, but now that I double check, I see that CKM is not causing this error, and it appears that it is the Workbench doing it, which I now need to investigate. Apologies for implying it was CKM, I got my files mixed up and thought it was.

I am thinking we should establish some soft rules for this kind of thing.

1 Like
5

Wasn’t the idea to use codes starting from 9000 for this purpose and keep a conversion log for consistency - this is what Archie(+CKM) is doing.

1 Like
6

That is indeed what Archie is doing. Both are necessary to make sure that further edits to the ADL 1.4 files result in ADL 2 archetypes that are compatible with the previous ADL 2 versions.

It is of course possible and I think also a good idea to standardize the conversion log. It is not documented at the moment, other than the java file at archie/aom/src/main/java/com/nedap/archie/adl14/log/ADL2ConversionRunLog.java at master · openEHR/archie · GitHub and archie/aom/src/main/java/com/nedap/archie/adl14/log/ADL2ConversionLog.java at master · openEHR/archie · GitHub . The created codes map is keyed by path. The value sets - I think also by path where the converted encountered a place where a value set was missing.

7

I possibly would have chosen some other numeric starting point like id5000 for nodes that previously had no codes, because id9999 is documented as the special code for primitive nodes, that occasionally appears in an archetype.

8

This is already in use, including the converted archetypes from the CKM, so it is tricky change. And the chance of needing 999 synthesized codes for a single archetype appears to be quite small. if that number is ever reached, we can easily change the range to continue at id8000 or even lower after id9998.

1 Like
9

…or put it that way: If you find the need to synthesize 999 codes, you may also have 5000 or 9000 or so existing normal codes in the archetype.

We could augment the rule for the (let’s hope) theoretical case of exceeding 9000 normal codes and/or 999 synthesised codes. But then I think neither should continue before 10000