Non existing constraints: closed or open interpretation?

Clinical (archive)
1

Hi all,

I’m adding some extra checks on the EHRServer, and found cases where users were committing compositions with nodes that are not defined in the referenced OPT.

That made me think of the interpretation of non existing constraints. For instance, the extreme case of can empty COMPOSITION OPT (no constraints defined for the COMPOSITION.content), how that should be interpreted?

  1. open: any structure is allowed on the COMPOSITON.content

  2. closed: structures not defined in the OPT are not allowed

On a normal case where the full OPT is defined, from COMPOSITION to ELEMENT.value, how that OPT is interpreted? open or closed? Are extra ENTRIES and other nodes allowed even no definition for them is on the OPT? (open interpretation), or only OPT defined nodes are allowed? (closed interpretation).

I think this is key to understand implementation, and it is sad I didn’t recognized this issue before, but here we are :slight_smile:

Best,
Pablo.

2

Templates further constrain archetypes, that constrain the reference model. In both cases, if the ANY constraint is used, that means that anything defined in the underlying archetype (or in the underlying reference model) is acceptable. Thus, you have to do an open interpretation.

On a normal case where the full OPT is defined, from COMPOSITION to ELEMENT.value, how that OPT is interpreted? open or closed? Are extra ENTRIES and other nodes allowed even no definition for them is on the OPT? (open interpretation), or only OPT defined nodes are allowed? (closed interpretation).

If you mean the case when we already have an structure defined in the template (or in the archetype), then the interpretation is closed. If you already constrained an OBSERVATION inside a COMPOSITION, you removed the ANY constraint, and thus the OBSERVATION is your only option. This is not completely true in specialized archetypes, where you can expand the definition and create new constraints, but that is a special case that is not possible (as far as I know) at the template level.

David

3

Adding a new observation to the content attribute of an existing composition Archetype is certainly possible in ADL2 templates...

Any idea on why people that did this would want this?

Pieter

4

Hi David,

5

Hi Pieter, my case is not adding nodes to the model, is adding nodes to the RM instances that are not defined by the model (archetypes/templates).

Adding nodes to an archetype/template would lead to a new version/revision of that artifact, that is perfectly supported by the specs.

6

It seems to me that allowing that is an error or needs a clarification in the AOM/ADL 2 specifications. Archetypes are the place for the structural and semantic definition of the clinical information models. Templates are only local configurations of them by a constraining approach. Think about the implications. If in a template we can add a complete new structure, then we will need to also share templates (and not only archetypes) to reach a complete semantic interoperability. Moreover, that would mean that there is no real difference between creating specialized archetypes and creating templates. Thus, why we would need the latter?

7

In my interpretation, not saying anything means no constraining anything, including having a path with an empty content. Then the archetype definition rules. The problem is not of the template, but a problem of the root archetypes used for the template. If the COMPOSITION.content is open in the archetype (with the presence of ANY at that point), and the template doesn’t further constraint it, then you have to accept anything from the RM there. It is not a technical interpretation problem, but a problem of using a badly designed archetype/template. I always say in my courses that archetypes provide a great flexibility and power, but you have to accept the consequences of a bad (or incomplete) archetype design.

This interpretation is also coherent with AOM/ADL 2. There the grammar won’t allow to have those empty definitions in a template.

8

This is a VERY GOOD question!
(Please consider that I am completely ignorant of specification details.)
(Coming from the templates of HL7, they are part of the harmonised specification, and shared, and essential for enabling interoperability, and - most important - enable reuse of existing concepts. Archetypes can definitely do all of that as well.)

All the best,
Stefan

9

I know, but my case is not the use of ANY, is that no constraint is
defined, it's just empty. The meaning of ANY or * is clear, but I think the
meaning of absence of constraints is not so clear. This can affect
implementation dramatically, since "open" interpretation is "I can add any
content, even if it's not defined by the archetype/OPT", and the "closed"
interpretation is "I can only add what's defined by the constraints. One
case can be when OPTs have SLOTs, should those slots be resolved by
software at runtime or should a specialization of that OPT define reference
in the SLOT to have a concrete structure and no other content can be added
at runtime.

This is the case that troubles me. Because the "open" interpretation
means that I can define an empty OPT with just a COMPOSITION, but no
COMPOSITION.content definition, and at runtime I can put anything on the
content and the instance will be valid against the OPT. Having ANY is a
different case, as also having all nodes as optional would be another case
(of course respecting the RM optional/required occurrences).

In my interpretation, not saying anything means no constraining anything,
including having a path with an empty content. Then the archetype
definition rules. The problem is not of the template, but a problem of the
root archetypes used for the template. If the COMPOSITION.content is open
in the archetype (with the presence of ANY at that point),

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.

2. If that is not interpreted as ANY allowed (my case), should the
interpretation be a) open or b) closed?

a) at runtime anything can be added to the COMPOSITION instance, so this
works as an ANY allowed :slight_smile:

b) that definition means the COMPOSITION doesn't have a content and if
content is present, then the instance is invalid, so absence of constraints
means no other nodes can be added there on instances (this case considers
there is no further definition on templates, so templates don't add
structure for "content", it is empty on the template at runtime).

The same questions can be asked about COMPOSITION.context, that some
archetypes don't define and some templates might or not define over
archetypes that don't have it.

I know this is very border case, but just happened to be a real case with a
client :slight_smile:

and the template doesn't further constraint it, then you have to accept
anything from the RM there. It is not a technical interpretation problem,
but a problem of using a badly designed archetype/template.

Exactly! And related to what is the clinical modeling criteria for
something that the specs and modeling tools allow.

BTW: this is on the clinical list because it is related with clinical
modeling, and IMO this little case needs to be clarified for correct
implementation in software.

10

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 :smiley:

11

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

12

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.

Best,
Pablo.