C_ARCHETYPE_ROOT.slot_node_id in OPT files

There is an attribute slot_node_id in C_ARCHETYPE_ROOT elements of OPT test files used by EHRbase:

<children xsi:type="C_ARCHETYPE_ROOT" slot_node_id="at0002">

One example: ehrbase/service/src/test/resources/knowledge/operational_templates/IDCR Medication List.v0.opt at 296a1693d01fc3069e20b7c5621d2478798a7828 · ehrbase/ehrbase · GitHub

I don’t find this attribute in ADL1.4 (Archetype Definition Language 1.4 (ADL1.4)). Is there a specifications page for OPT files?

What is the intended use of the slot_node_id attribute?

Is it related to OPT2: node identification scheme - #2 by pieterbos?

Edit: “Moved to Tools Support, CKM” since the attribute is probably created when exporting an OPT file.

Hi @borut.jures

Is there an template in CKM where CKM creates this?
I don’t think CKM does this.

Having said this, I believe that this attribute may aim to solve the problem that the original SLOT’s at code is not carried through otherwise.
Without it may not be possible to know downstream what the SLOT’s text/description was, especially relevant if there are multiple SLOTs to choose from as in e.g. the following excerpt from https://ckm.openehr.org/ckm/archetypes/1013.1.611/adl)

	SECTION[at0000] matches {    -- Referral details
		items cardinality matches {0..*; unordered} matches {
			allow_archetype INSTRUCTION[at0001] occurrences matches {0..*} matches {    -- Referral request
				include
					archetype_id/value matches {/openEHR-EHR-INSTRUCTION\.service_request\.v1/}
			}
			allow_archetype ENTRY[at0002] occurrences matches {0..*} matches {    -- Details
				include
					archetype_id/value matches {/openEHR-EHR-EVALUATION\.clinical_synopsis(-[a-zA-Z0-9_]+)*\.v1|openEHR-EHR-OBSERVATION\.story(-[a-zA-Z0-9_]+)*\.v1|openEHR-EHR-OBSERVATION\.exam(-[a-zA-Z0-9_]+)*\.v1|openEHR-EHR-OBSERVATION\.imaging_exam_result(-[a-zA-Z0-9_]+)*\.v0|openEHR-EHR-OBSERVATION\.laboratory_test_result(-[a-zA-Z0-9_]+)*\.v1/}
			}
		}
	}

But I don’t know for sure, EHRBase may be the better category for this after all.

1 Like

I found slot_node_id when Converting OPT14 to OPT2.

When the slot_node_id is used instead of node_id, it is converted to this OPT2 representation (which seems consistent with ADL2 and OPT2 files produced by Archie):

use_archetype CLUSTER[at0002, openEHR-EHR-CLUSTER.medication_item.v1] occurrences matches {0..1} matches {    -- Medication item

@sebastian.garde The use of slot_node_id is what makes it work. The template says it was created with: Ocean Template Designer Version 2.7.87Beta.

There is another version of the IDCR Medication List.v0 OPT which was created with a newer version: 2.8.94Beta and doesn’t use slot_node_id.

The linked IDCR Medication List.v0.opt is the only OPT file with slot_node_id that has a value. There are a few others without the value (slot_node_id=""). This is a collapsed excerpt:

<children xsi:type="C_COMPLEX_OBJECT">
  <rm_type_name>ITEM_TREE</rm_type_name>
  <node_id>at0001</node_id>
  <attributes xsi:type="C_MULTIPLE_ATTRIBUTE">
    <rm_attribute_name>items</rm_attribute_name>
    <children xsi:type="C_ARCHETYPE_ROOT" slot_node_id="at0002">
    <children xsi:type="ARCHETYPE_SLOT">
    <children xsi:type="ARCHETYPE_SLOT">
    </children>
  </attributes>
</children>

@sebastian.garde I couldn’t find an OPT that uses the linked eReferral archetype. There is an eReferral OPT but it uses only the first allow_archetype INSTRUCTION[at0001]. It would be interesting to see how the linked eReferral archetype is presented in an OPT when exported from the CKM.

p.s.
OPTs shown in CKM don’t provide the generator version - only: Ocean OPT Generator webservice. This would be a useful information :thinking:

Ah - that’s one of mine and would have been created (some time ago) with Ocean Template Designer. I would definitely not have added that manually.

1 Like

I’m 99% sure the slot_node_id is not an ADL/OPT 1.4 thing.

1 Like

Agree. Whether it may be should be is a different story.

That said, @borut.jures I have used the ereferral archetype to create an oet template.
Whatever I do, it does not create an opt with a slot_node_id, neither in the current version of Template Designer nor when uploading the oet to a CKM.

This may of course be my lack of understanding of when or why this slot_node_id is added and when not. However, 2.7.x of Template Designer is roughly a decade old I believe, so whatever it may or may not have produced, I have no idea.

So unless someone can produce a template file set (archetype + oet) that leads to the generation of an opt with slot_node_id either in CKM or an up-to-date (or even an older version) of TD, not sure what else we can do.

In summary, as far as I can see, this is not an issue of CKM.

1 Like

Thank you @sebastian.garde for investigating this. I guess this is an old OPT as Ian mentioned and we don’t have to worry about it. It is probably only found as a test in EHRbase.

However as you mentioned slot_node_id or something similar might be needed as it was discussed in the linked post.

2 Likes

At least we took the XSD from Ocean tooling as a base, and I think it’s the same the SEC published here openEHR - XML Schemas (ITS-XML) Component - 2.0.0

This is a sample valid OPT 1.4 against our copy of the schema

                     <children xsi:type="ARCHETYPE_SLOT">
                        <rm_type_name>CLUSTER</rm_type_name>
                        <occurrences>
                           <lower_included>true</lower_included>
                           <lower_unbounded>false</lower_unbounded>
                           <upper_unbounded>true</upper_unbounded>
                           <lower>0</lower>
                        </occurrences>
                        <node_id>at0002</node_id>
                        <includes>
                           <expression xsi:type="EXPR_BINARY_OPERATOR">
                              <type>Boolean</type>
                              <operator>2007</operator>
                              <precedence_overridden>false</precedence_overridden>
                              <left_operand xsi:type="EXPR_LEAF">
                                 <type>String</type>
                                 <item xsi:type="xsd:string">archetype_id/value</item>
                                 <reference_type>attribute</reference_type>
                              </left_operand>
                              <right_operand xsi:type="EXPR_LEAF">
                                 <type>C_STRING</type>
                                 <item xsi:type="C_STRING">
                                    <pattern>.*</pattern>
                                 </item>
                                 <reference_type>constraint</reference_type>
                              </right_operand>
                           </expression>
                        </includes>
                     </children>