Specialized node ids are lost on OPT export

We have found a bug regarding OPT export and sibling nodes with specialized node ids. When exporting, specialized node id is changed into the original one, which in the end the makes the OPT lose the descriptions of all the sibling nodes. The error can be easily reproduced by creating some sibling specialized nodes and then exporting the OPT.
As an example, take a look at the following template


Each one of the analytes has its own specialized atxxxx code (at0001.1 for result coded text, at0001.2 for result quantity, etc. all the way to at0001.5 for result proportion)

When exporting the OPT, every alternative correctly fixes the name of the alternative to the corresponding text, however, the node ids are changed to the parent one (at0001) which creates several problems

Term definitions are mixed up and lost, as the last one to enter overrides all the other ones. The node ids in the stucture are also being transformed into at0001, creating again the sibling collision that was avoided in the modelling.

This functionality working right would be the solution to this discussion. Moreover, having specialized node ids would remove the need of creating paths that use the name.

4 Likes

Thanks for reporting. Added to ToDo list. :wink:

3 Likes

Hi @borut.fabjan the screenshot from the amazing @yampeku’s post is from one of our templates and for now we are thinking about putting in place a temporary work-around where we “fix up” the OPT file before we build our mapping and import it to our openEHR CDR.

I assume we can’t be so sure of any timeline for a more permanent fix but in the meantime I was wondering if someone could just give a quick sanity check that what we intend to do “should” match (at least regarding the main points) what will come from Archetype Designer’s OPT export in the future? This way we can move forward with our mapping+testing, and then swap out our “fixed up” OPT with the real one exported from Archetype Designer once the change is in place.

But this it means that we would want to make sure that we update the different elements in the XML file with the right values from the beginning.

My assumption is that you will just copy the nodeId exactly from for example where I can see in the .t.json file under $.templateOverlays[*].definition.attributes[*].children[*].nodeId, the same as it looks in Archetype Designer on the Path field under Details, is this correct?

For example the first one shows Path = /items[at0001.1] in Archetype Designer, but right now it is exporting to the OPT file as //attributes/children/node_id = at0001 instead of at0001.1 (and that at0001 is duplicated to all of them in the list).

So what I have thought to change in the OPT file is to do two things:

  • Set all of these node_ids (at their respective //attributes/children/node_id) to match (so to replace all of the duplicated at0001s with at0001.1, at0001.2, etc as they exist in the .t.json file).
  • Rename the existing code="at0001" in its right place under //attributes/children/term_definitions to the correct nodeId and then add in the name for all of the other ones as new term_definitions (this is mostly a nice cosmetic bonus so that they have all of the “right” text in the mapping tool).

Hopefully this is more clear with a full example!

So currently where the OPT file looks sort of like this:

...
<children xsi:type="C_COMPLEX_OBJECT">
    <rm_type_name>ELEMENT</rm_type_name>
    <node_id>at0001</node_id>
    <attributes ...>...
                    <item xsi:type="C_STRING">
                        <list>Analyte result coded text</list>
                    </item>
    ...</attributes>
</children>
<children xsi:type="C_COMPLEX_OBJECT">
    <rm_type_name>ELEMENT</rm_type_name>
    <node_id>at0001</node_id>
    <attributes ...>...
                    <item xsi:type="C_STRING">
                        <list>Analyte result quantity</list>
                    </item>
    ...</attributes>
</children>
...
...
<term_definitions code="at0001">
    <items id="text">Analyte result proportion</items>
    <items id="description">The value of the analyte result.</items>
    <items id="comment">For example '7.3 mmol/l', ...</items>
</term_definitions>
...

We will change it to something like this instead:

...
<children xsi:type="C_COMPLEX_OBJECT">
    <rm_type_name>ELEMENT</rm_type_name>
    <node_id>at0001.1</node_id>
    <attributes ...>...
                    <item xsi:type="C_STRING">
                        <list>Analyte result coded text</list>
                    </item>
    ...</attributes>
</children>
<children xsi:type="C_COMPLEX_OBJECT">
    <rm_type_name>ELEMENT</rm_type_name>
    <node_id>at0001.2</node_id>
    <attributes ...>...
                    <item xsi:type="C_STRING">
                        <list>Analyte result quantity</list>
                    </item>
    ...</attributes>
</children>
...
...
<term_definitions code="at0001.1">
    <items id="text">Analyte result coded text</items>
    ...
</term_definitions>
<term_definitions code="at0001.2">
    <items id="text">Analyte result quantity</items>
    ...
</term_definitions>
...

So namely that we will rename the node_id of each child attribute as appropriate, and then add a new term_definitions to cover each of the node_ids that we add.

Does this look right to you, or anything else we should consider?

(keeping in mind that the biggest thing we care about currently is that we can continue with building our mapping, and then that the resulting compositions we write based on this mapping should be “correct” after the export function is updated from Better’s side)

2 Likes

@borut.fabjan to me @joshua.grisham’s analysis and suggested new output above looks correct, could you ask the person(s) who will analyse the bug in your end to check the suggested corrected output above? (I believe reading the post will at the same time help them do the analysis and fix.)

@pieterbos you are likely good at this stuff too, do you see if the sugesstion looks ok?

@joshua.grisham could likely share our bugfixing post-processing code here if the appreoach seems ok