When modelling templates, a repeating element or cluster can be explicitly cloned and further constrained from the original archetype, like the way the “Atypical finding” cluster is cloned in this screenshot:
This doesn’t seem to be possible when making an archetype specialisation using Archetype Designer. Is this a limitation of the tool, or of the specs?
No opinions at all? This is highly unusual! 
Hi siljelb ,
yes you are right there is no “cloning” option when making the archetype but is there any difference between cloning and copying? I am able to copy and then after selectin the cluster parent I am able to paste the elements. One major difference I notice is that the nodeID is not a sequence of the original i.e 14.1.2 ,14.1.3 but rather a complete new at00xx.
Hi Rony,
The difference is as you point out; the node ID will be completely different. So it’s considered a completely new container instead of an instance of the initial repeatable container, and won’t be queryable as instances of that container.
It’s AD. Adl2 definitely supports this. So does Sign In with Auth0
In adl2 the model and syntax for specialised archetypes is the same as for templates. So it can’t make a difference regarding specialising repeating cluster nodes either.
Thanks @joostholslag!
Any ADL experts know whether this is possible with ADL 1.4? @sebastian.garde @thomas.beale @ian.mcnicoll
I don’t know of a mechanism to achieve this in ADL1.4 specialised archetypes only.
A lot of the specialisation syntax and semantics has really only been properly specified in 2.x.
What you could do is to predefine the individual clusters in the parent archetype (at least rudimentary) and constrain them further in specialisations (which I understand is only minimally helpful for your example) or use templates where this is well supported.
I did actually get this to work in AD (I think!).
Some of combination of specialising a cluster, doing a copy /paste, which inserted the new cluster inside the original, and then I moved it ip a level, at which time I got the correct specialisation hierarchy of the original node and 2 specialisations.
And now I can’t reproduce how I made it work 
I guess the good news is that it seems to be legal ADL1.4.
openEHR-EHR-OBSERVATION.family_history_screening_questionnaire-ian.v1.adl (51.3 KB)
I have a method for a cluster
Repeat for more clones
If you end up with 2 many clones or copies of the original, you can delete them by specialising them first, then delete.
I have not tested for Elements
Syntactically legal in the sense that nobody has explicitly forbidden you to do it, yes, I agree. 
I have no problem doing it that way, but from a specs point of view, the semantics are mostly unspecified nonetheless as far as I can tell.
For example, there is nothing substantial except the “specialise” clause described in the ADL1.4 doc that directly relates to specialisation. In the AOM1.4 doc the extent of the description is along the lines of this:
Archetypes can be specialised. The formal rules of specialisation are described in the openEHR Archetype Semantics document (forthcoming), but in essence are easy to understand.
We can of course implicitly apply all the relevant 2.x insights around specialisations gained since then (and it is somewhat easier in 1.4 land because of the lack of a adl source format), but if all current tooling would handle all edge cases the same way, especially when you then add a template on top of it, I don’t know.
I don’t think this dodge will work for Elements. The method above relies on the copy/pasted cluster retaining the same atCode , since it is pasted in the context of the specialised cluster, then it can be moved back to the parent level and it essentially re-instates the original.
What was the use-case? This feels like a change to AD behaviour is required
Awesome Ian, thanks! 
I found that it worked better if I specialised the clone and not the original, otherwise I wasn’t able to continue adding clones in a way that worked as intended. Now for getting this into a proper AD "clone " function…
I was able to create a template, export OPT and persist data using this archetype, so it looks like it’s perfectly legal ADL1.4:
{
"_type": "COMPOSITION",
"archetype_node_id": "openEHR-EHR-COMPOSITION.encounter.v1",
"name": {
"value": "test_specialised_clones"
},
"uid": {
"_type": "OBJECT_VERSION_ID",
"value": "88a9e878-5fcb-467c-8467-64c1243576c6::fqm::1"
},
"archetype_details": {
"archetype_id": {
"value": "openEHR-EHR-COMPOSITION.encounter.v1"
},
"template_id": {
"value": "test_specialised_clones"
},
"rm_version": "1.0.4"
},
"language": {
"terminology_id": {
"value": "openehr"
},
"code_string": "nb"
},
"territory": {
"terminology_id": {
"value": "openehr"
},
"code_string": "NO"
},
"category": {
"defining_code": {
"terminology_id": {
"value": "openehr"
},
"code_string": "433"
}
},
"composer": {
"_type": "PARTY_IDENTIFIED",
"name": "unknown"
},
"context": {
"start_time": {
"value": "2025-12-11T11:32:18.9425734+01:00"
},
"setting": {
"value": "secondary medical care",
"defining_code": {
"terminology_id": {
"value": "openehr"
},
"code_string": "232"
}
},
"other_context": {
"_type": "ITEM_TREE",
"archetype_node_id": "at0001",
"name": {
"value": "Tree"
}
}
},
"content": [
{
"_type": "OBSERVATION",
"archetype_node_id": "openEHR-EHR-OBSERVATION.exam.v1",
"name": {
"value": "Physical examination findings"
},
"archetype_details": {
"archetype_id": {
"value": "openEHR-EHR-OBSERVATION.exam.v1"
},
"template_id": {
"value": "test_specialised_clones"
},
"rm_version": "1.0.4"
},
"language": {
"terminology_id": {
"value": "ISO_639-1"
},
"code_string": "en"
},
"encoding": {
"terminology_id": {
"value": "IANA"
},
"code_string": "UTF-8"
},
"subject": {
"_type": "PARTY_SELF"
},
"data": {
"archetype_node_id": "at0001",
"name": {
"value": "Event Series"
},
"origin": {
"value": "2025-12-11T11:32:18.9425734+01:00"
},
"events": [
{
"_type": "POINT_EVENT",
"archetype_node_id": "at0002",
"name": {
"value": "Any event#1"
},
"time": {
"value": "2025-12-11T11:32:18.9425734+01:00"
},
"data": {
"_type": "ITEM_TREE",
"archetype_node_id": "at0003",
"name": {
"value": "Tree"
},
"items": [
{
"_type": "CLUSTER",
"archetype_node_id": "openEHR-EHR-CLUSTER.exam-test.v0",
"name": {
"value": "Physical examination findings"
},
"archetype_details": {
"archetype_id": {
"value": "openEHR-EHR-CLUSTER.exam-test.v0"
},
"template_id": {
"value": "test_specialised_clones"
},
"rm_version": "1.0.4"
},
"items": [
{
"_type": "CLUSTER",
"archetype_node_id": "at0013",
"name": {
"value": "Atypical finding#1"
},
"items": [
{
"_type": "ELEMENT",
"archetype_node_id": "at0014",
"name": {
"value": "Finding type"
},
"value": {
"_type": "DV_TEXT",
"value": "Something"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0015",
"name": {
"value": "Presence"
},
"value": {
"_type": "DV_CODED_TEXT",
"value": "Present",
"defining_code": {
"terminology_id": {
"value": "local"
},
"code_string": "at0016"
}
}
}
]
},
{
"_type": "CLUSTER",
"archetype_node_id": "at0013",
"name": {
"value": "Atypical finding#2"
},
"items": [
{
"_type": "ELEMENT",
"archetype_node_id": "at0014",
"name": {
"value": "Finding type"
},
"value": {
"_type": "DV_TEXT",
"value": "Something else"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0015",
"name": {
"value": "Presence"
},
"value": {
"_type": "DV_CODED_TEXT",
"value": "Absent",
"defining_code": {
"terminology_id": {
"value": "local"
},
"code_string": "at0017"
}
}
}
]
},
{
"_type": "CLUSTER",
"archetype_node_id": "at0013.1",
"name": {
"value": "Redness#1"
},
"items": [
{
"_type": "ELEMENT",
"archetype_node_id": "at0014",
"name": {
"value": "Finding type"
},
"value": {
"_type": "DV_TEXT",
"value": "Redness"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0015",
"name": {
"value": "Presence"
},
"value": {
"_type": "DV_CODED_TEXT",
"value": "Absent",
"defining_code": {
"terminology_id": {
"value": "local"
},
"code_string": "at0.2"
}
}
}
]
},
{
"_type": "CLUSTER",
"archetype_node_id": "at0013.2",
"name": {
"value": "Solid tumour#1"
},
"items": [
{
"_type": "ELEMENT",
"archetype_node_id": "at0014",
"name": {
"value": "Finding type"
},
"value": {
"_type": "DV_TEXT",
"value": "Solid tumour"
}
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0015",
"name": {
"value": "Presence"
},
"value": {
"_type": "DV_CODED_TEXT",
"value": "Present",
"defining_code": {
"terminology_id": {
"value": "local"
},
"code_string": "at0.18"
}
}
}
]
},
{
"_type": "ELEMENT",
"archetype_node_id": "at0001",
"name": {
"value": "System or structure examined"
},
"value": {
"_type": "DV_TEXT",
"value": "Bladder"
}
}
]
}
]
}
}
]
}
}
]
}
Edit: Although it looks like it’s messing up the at-codes for the value set in the “Presence” element in the cloned clusters..
Indeed - the atCoding is using the shortened atCode specialisation that was originally defined in ADL2. That has now been changed to revert to the ADL1.4 approach, to make transition easier. I will report this to Better.
We encountered this both in archetype definition and mappings definition (similar to what templates problems would be) and used different approaches for both.
In archetype definition we allow the copy & paste of subtrees, which you can reuse wherever the RM lets you put it in (e.g. an ELEMENT inside of a CLUSTER but not inside of an entry archetype). This was one of the reasons we opted to add at codes to every node of the archetype, and in this particular case copy and paste just regenerates all at codes for the new branch.
We also had this problem with defining mappings, which I think is a comparable problem of defining clones in the opt. For example you could want to say that a medication in the template is split into two in the mapping (e.g. active medication/closed medication). These ‘virtual’ nodes that could held extra constraints by creating a new kind of at codes for the clones (clxxxx) and are only applicable in definition time (at run time they are replaced by the correct at code). These clxxxx cannot be new atxxxx codes as you would lose their relation to the original atxxxx code in data