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_id
s (at their respective //attributes/children/node_id
) to match (so to replace all of the duplicated at0001
s 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_id
s 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)