Hi all,
We’re wondering if there’s a historical modelling error (possibly because of default settings in older tools?) in a lot of archetypes where the cardinality of the ‘data’ section is set to 1..*, 2..*, 3..* or similar, instead of 0..*. This leads to some issues when using these archetypes in low code development.
Are there any reasons why we shouldn’t change these archetypes make the cardinality of ‘data’ 0..*? This should be a non-breaking change.
There are a couple of issues here.
Historically AE (Archetype Editor) added default 1…* constraints to the ADL , on the basis that data is a mandatory structure. I don’t think that happens now, but I suspect data is still 1…* , based on the RM , so you may still have problems with that.
Also historically AE tried to do something clever with cardinality, which in openEHR is the number of nodes allowed in a list such as data It used to count the number of mandatory (occurrence) nodes in the list, and set the minimum cardinality to the same number (which sort of makes sense). However the reverse is not true i.e if someone during archetype development makes one of the nodes optional, you cannot assume that the cardinaility is less, and AE did not do that.
The upshot is that there wee a few archetypes with cardinality e.g set to 3…* where at one point in development there had been 3 mandatory nodes but perhaps now there is only 1.
My own feeling isa that cardinality is both confusing and practically unhelpful. I think it would be perfectly reasonable (and a non-breaking change to remove any cardinality statements from the ADL, unless tere is a very clear reason from them to be there.
However that may not resolve the first issue if the default RM cardinality kicks in.
In ADL2, cardinality should only ever be added as a constraint if it needs to be different from the RM (which is usually 0…*). As you say, most likely rare. Another reason to move 
I agree, mostly. There are some very few good use cases, where you need an internal cluster to contain one of two elements.
Great! We’ll wait a bit more to see if anyone else have differing opinions.
Can you point to some examples?
I had a super quick look, but couldn’t find any. I thought we did this in CLUSTER.medication, but it must have been in an earlier iteration.
I asked partly because I though that at some point we had tried to tidy up the ‘erroneous’ examples.
What was the example of the 1…* data that caused an issue in form generation - my guess might be something like an Observation exclusion (via protocol) where there is a mandatory element in data?
That is correct but for me, it is really obscure (though elegant) and difficult way to express a choice. AD does not expose cardinality, which I agree with . If we need to express a Choice, let’s find a better way of doing it. I don’t teach newbies about Cardinality at all now.
I understand that the need to constrain it is rare, but I don’t see how it is at all conceptually complicated - it’s just ‘how many things should be allowed in this container?’ In cases where there really is a maximum, then cardinality is the only thing you can constrain to achieve that.
There is a related [SPECAM-20] - openEHR JIRA for this.
I can assure that most people, including me, found/found the occurrences/cardinality thing really, really hard to understand, and using it to enforce a choice even harder.
Of course, once you ‘get it’ it makes sense but I think one of these things that is too elegant for its own good
Tbh I think the difficult bit is the name. If it was called “how many things have to or can be inside this box” it would be easy.
The form rendrer doesn’t understand form rules of excluding an archetype from the resulting composition based on no elements being used, when there needs to be at least one element 
Do you men that a whole archetype has been constrained out, or that the root of the archetype is there but all of the data elements have been constrained out?
The first should not be a problem. The root 0…0 should override any child data 1…*
The archetype root is 0…1, and all other containers down to and including the data element used are 1…1. If the data element is left empty , the form contains logic to leave out the entire archetype.
To be fair, it is completely normal to IT people. So it’s a bit like if healthcare professionals were thinking we were a bit thick for not knowing what ‘fundus’ or ‘lumen’ or ‘process’ mean.
So I would say it is down to documentation and more importantly, contextual help inside tools. To wit:
Or something like that
A confession from an IT person - I’ve spent 30+ years drawing E/R diagrams with cardinality but was confused when I found cardinality + occurrences used in openEHR. They are used correctly and they make sense but I still slow down whenever they are mentioned 
Just repeat in your sleep…
c o n s t r a i n t s c o n s t r a i n t s c o n s t r a i n t s c o n s t r a i n t s c o n s t r a i n t s c o n s t r a i n t s c o n s t r a i n t s c o n s t r a i n t s …