# Error in CKM body\_weight ADL2 form archetype

**URL:** <https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478>\
**Category:** Clinical\
**Tags:** adl\
**Created:** [21 September 2023 15:38 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478 "2023-09-21T15:38:16Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [21 September 2023 15:38 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/1 "2023-09-21T15:38:17Z")

</div>

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

```auto
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.

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [21 September 2023 16:17 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/2 "2023-09-21T16:17:54Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pieterbos](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pieterbos/32/512_2.png) [@pieterbos](https://discourse.openehr.org/u/pieterbos)\
**Post date:** [22 September 2023 14:04 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/3 "2023-09-22T14:04:09Z")

</div>

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

```plaintext
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 )](https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#toString-double-) or in java 17  
[Double (Java SE 17 & JDK 17)](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Double.html#toString(double))

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:

```auto
   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]](https://ckm.openehr.org/ckm/archetypes/1013.1.2960/adl) , 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.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [26 September 2023 05:44 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/4 "2023-09-26T05:44:36Z")

</div>

> [@pieterbos](#):
>
> 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.

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.

> [@pieterbos](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [26 September 2023 06:10 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/5 "2023-09-26T06:10:51Z")

</div>

> [@thomas.beale](#):
>
> I am thinking we should establish some soft rules for this kind of thing.

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.

---

<div class="post-metadata">

**Author:** ![pieterbos](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pieterbos/32/512_2.png) [@pieterbos](https://discourse.openehr.org/u/pieterbos)\
**Post date:** [26 September 2023 07:51 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/6 "2023-09-26T07:51:36Z")

</div>

> [@sebastian.garde](#):
>
> 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.

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](https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/adl14/log/ADL2ConversionRunLog.java#L15) and [archie/aom/src/main/java/com/nedap/archie/adl14/log/ADL2ConversionLog.java at master · openEHR/archie · GitHub](https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/adl14/log/ADL2ConversionLog.java#L8) . 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.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [26 September 2023 14:27 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/7 "2023-09-26T14:27:40Z")

</div>

> [@sebastian.garde](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![pieterbos](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pieterbos/32/512_2.png) [@pieterbos](https://discourse.openehr.org/u/pieterbos)\
**Post date:** [26 September 2023 14:40 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/8 "2023-09-26T14:40:47Z")

</div>

> [@thomas.beale](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [26 September 2023 16:23 UTC](https://discourse.openehr.org/t/error-in-ckm-body-weight-adl2-form-archetype/4478/9 "2023-09-26T16:23:43Z")

</div>

> [@pieterbos](#):
>
> needing 999 synthesized codes for a single archetype

…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