Non existing constraints: closed or open interpretation?

Pablo Pazos pablo.pazos at
Fri Jul 6 12:50:06 EDT 2018

Thanks Ian and David,

The conclusion for these would be:

1. The clinical modeler intent when constraints are not added, is that
anything is permitted where constraints are not defined, of course in
validity with the RM.

2. To define a closed structure, clinical modelers need to explicitly
define the whole structure in templates, maybe mark some nodes as
mandatory, and constraint the cardinality of collections to allow only the
defined nodes there (but this is more difficult, for instance on
INSTRUCTION.activities if cardinality is 1..2, and just one ACTIVITY is
defined and marked as min occurrences = 1, another ACTIVITY with a
different structure can be added at runtime on INSTRUCTION.activities, on
these cases of collections is really difficult to express "only these types
of nodes are allowed and no others"). All this would be done at the
template level.

3. Each implementation would need to state what's the interpretation of
accepting an OPT, even if the template is a more generic than the defined
constraints (allows extra nodes to be added but are not defined in the
template). So implementations, on their conformance statement need to say
"we interpret OPTs as closed and accept only the structure defined by the
OPT" or "we interpret OPTs as open and accept the OPT nodes and any other
valid nodes that can be added at runtime".

Interesting point on dynamic validation, but I think that is a RM
validation only, since there are no AOM/TOM constraints to validate
against, IMO data might be a little insecure with this approach.

On my case, I'll need to add to my conf. statement that the interpretation
is "closed".

Thanks everyone, this helped me a lot, and hope this discussion help other
people in the future.


On Fri, Jul 6, 2018 at 4:27 AM, Ian McNicoll <ian at> wrote:

> Hi all,
> Good question Pablo.
> There is definitely a use-case for an open composition content slot,
> though it would probably have a little more context data.
> The prime example is a GP Encounter when the potential content is very
> open i.e you have no idea what Observations, in particular, might be
> required.
> However, this of course leaves CDR servers with a validation problem and I
> suspect most CDRs actually validate directly against the templated content
> i.e extra content will be rejected.
> In these situations we tend, therefore to build maximal dataset templates
> which is a little clunky but technically correct. I understand that a
> couple of vendors have/are experimenting with dynamic
> validation i.e. the template is in some way rebuilt to reflect the content
> but I don't know the details.
> So in practice, although technically open slots are valid, I think most
> CDRs treat them as closed. Dynamic validation would be really useful and I
> think ADL2 allows us to constrain slots as closed.
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: ian at
> twitter: @ianmcnicoll
> Co-Chair, openEHR Foundation ian.mcnicoll at
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> On Fri, 6 Jul 2018 at 07:57, David Moner <damoca at> wrote:
>>> As I mentioned on my previous message, my case is not when an ANY / {*}
>>> appears in the ADL, but when there is no definition at all, I'm talking
>>> this:
>>> definition
>>>     COMPOSITION[at0000] matches {
>>>         category matches {
>>>             DV_CODED_TEXT matches {
>>>                 defining_code matches {[openehr::433]}
>>>             }
>>>         }
>>>     }
>>> 1. I'm not sure if that is interpreted as ANY allowed in
>>> COMPOSITION.content.
>>> For instance the AE doesn't allow to put a "content matches {*}" there,
>>> which was my interpretation of what you called ANY.
>> Yes, if you don't constrain anything, then the underlying model rules.
>> And that's equivalent to saying ANY, that's why I insist on that :D
>> --
>> David Moner Cano
>> Web:
>> Twitter: @davidmoner
>> Skype: davidmoner
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

*Ing. Pablo Pazos Gutiérrez*
pablo.pazos at
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list