In latest Archetype Designer v1.24.7, it seems at codes are not assigned to ITEM_TREE in EVALUATION and ACTION archetypes. Same doesn’t happen with OBSERVATION and INSTRUCTION archetypes. See screenshot below:
Has anyone else noticed it? It seems like a bug to me, can’t think of a reason why it would be intended.
I wonder if this relates to fixing this issue in 1.24.7
The rule should be (as I understand it) don’t put terms on RM attributes unless they are LOCATABLE?
EVE NT_CONTEXT is not a LOCATABLE but ITEM_TREE is a LOCATABLE
I have detected that recently and needed to edit my archetypes and templates manually to add that atcode, so I switched back to the good old Ocean Archetype Editor 
In the Better Designer I also detected it adds atcodes at the DV_xxx level, which I also needed to remove manually.
@ian.mcnicoll just checked the model and it seems EVENT_CONTEXT is PATHABLE but not LOCATABLE. I’m wondering, since it has an ITEM_STRUCTURE that needs to be archetyped, if it should be LOCATABLE.
Ping @thomas.beale
Thanks for the feedback & confirmation, it’s less than ideal to have to add/remove these codes manually. When saving a composition with missing at code on item_tree, CDR does throw validation error correctly. But this happens much too late in the tool chain, ideally this error of missing at code should be caught or prevented early on. Wonder if CKM detects it when archetypes with missing at code get uploaded. @sebastian.garde
I just wondered the same.
Indirectly only a present:
If the rule is indeed the one Ian mentions…
…then this validation shouldn’t be too hard to add as an explicit additional validation check.
It is as Ian mentioned, below is what the specs says about the attribute archetype_nod_id of LOCATABLE:
I think it’s necessary to add an explicit validation check on this to prevent missing at code in LACATABLE classes from causing issues in downstream software.
In ADL2, every object node has to have a code (but not every code has to have a terminology definition - that is only needed if there are siblings).
I’m mentioning ADL2 because inside Archetype Designer it is AOM2, and there should be internal codes on every node, so AD should be able to provide an equivalent at-code on every object node in the AOM1.4 view.
Maybe @borut.fabjan could comment?
I don’t know about the internal model, what the user sees is ADL 1.4
I guess there is a mismatch there that generates issues, also when exploring opts 1.4
Agree. Will fix ASAP.
Remark - not too far in the past CKM was reluctant to upload archetypes using description ‘@ internal @’. @sebastian.garde ? 
There are heaps of archetypes in CKM that have an @internal@ description text, to pick one at random:
ACVPU Scale Observation archetype and I believe we have always supported it (I think Ocean even invented this originally for the Archetype Editor a long time ago.)
Maybe I don’t quite understand what you mean, @borut.fabjan ?
it’s fixed with AD 1.24.8.
Default Item tree description is set to: “@ internal @”
Example;
[“at0001”] = <
text = <“Item tree”>
description = <“@ internal @”>
@rong.chen @thomas.beale @ian.mcnicoll @pablo @borut.fabjan
The closest match of an existing 1.4 validation error type seems to be VACSI:
From a quick look at the int’l CKM, I could locate e.g. the following archetype:
where a node id is missing on ITEM_TREE.
This is probably uncontroversial.
There’s also:
This archetype has a protocol ITEM_TREE without anything constrained in it.
protocol matches {
ITEM_TREE matches {*}
}
This would be reported as a validation error then as well.
Just making sure we are all on the same page with this.
Great job, Sebastian! This looks fine to me, both the text and type of error. It’s important that we detect it in CKM and prevent it from impacting downstream systems.
Thanks for fixing the issue in the Archetype Designer @borut.fabjan !
Why is the validation about the “single-valued child node”?
I think multiple-valued member child nodes should also have the node_id.
“Any object node with a node identifier added as a child of a single-valued must have a node identifier…”
I’m getting lost there. Wouldn’t be simpler to say any C_OBJECT that constrains a LOCATABLE should have a node_id?
Then the comment about the node_id that should be different than the siblings. If you have two alternative LOCATABLE objects in a single attribute, should them have different node_ids? (generally we have alternatives at the DATA_VALUE level where there is no node_id, though AOM supports LOCATABLE alternatives). For other cases I think there are other rules that already state sibling node_ids should be different.
Best,
Pablo.
Why is the validation about the “single-valued child node”?
I think multiple-valued member child nodes should also have the node_id.
True, but this one about a single valued ones - other validation codes exist for multiple (VACMI for example instead of VACSI…) - but they are not new and I think cover everything already as far as I can see.
“Any object node with a node identifier added as a child of a single-valued must have a node identifier…”
I’m getting lost there. Wouldn’t be simpler to say any C_OBJECT that constrains a LOCATABLE should have a node_id?
Right, but this is the general VACSI explanatory text and I didn’t want to reinvent the spec, just stretch it a little bit, so that we do not need to invent more codes at this stage for 1.4 - hence the specific explanation in the middle.
The explanatory text might need a SEC review, IMO it’s cryptic, saying something simple in a very difficult way. @sebastian.iancu @thomas.beale
Similarly to what I said for AQL in a recent post (Improve AQL to simplifying the querying of terms - #19 by damoca), we should avoid making any mention in the AOM to specific cases/classes of the RM. A rule talking of the validity of a C_OBJECT in relation to a LOCATABLE would only be usable in an openEHR environment.
That’s ok with me, though we need some way to say “of the type referenced by the constraint has a node I’d attribute, then…”. For the openEHR case it’s easy to mention LOCATABLE, but not sure how to rephrase that for any RM.