Thinking a little about node identifiers I have thought some
problematic use cases.
First, this is the current 'rule' in the wiki
(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633) for
when node identifiers are really needed. I copy the relevant part for
ease the discussion:
In which circumstance can a sibling occur of a DataValue? Certainly not in an ELEMENT.
I either cannot imagine another circumstance.
So why use a node-value? Write a nodeId if you want, it is not very interesting. The problem is another.
It annoys me quite some time, this issue, not if you use a nodeId or not, or if your archetype-editor does or does not.
***I would say, make it optional, configurable****
But what is the case?
The problem is that there are two main archetype editors.
One creates nodeIds in DataValues, and the other does not.
The designers have apparently a different opinion on this.
Sometimes the editors crash/choke on the ADL construct the other delivers.
And even when they do not choke, when you change one letter in an archetype, maybe in the ontology....
What happens? The editor quickly removes/adds the nodeIds on all DataValues. (one does this, the other does that)
This makes it impossible to work with them both. Ity makes it hard it exchange archetypes with other people.
this wiki page is (I hate to say…) out of date - the current rules are: ADL takes a minimalist approach and does not require node identifiers where sibling object nodes can be otherwise distinguished. Node identifiers are mandatory in the following cases: I think this probably deals with the cases you point out below. I’ll now go and update that wiki page 
- thomas
Well, I would say that "free or coded text" is quite common in
healthcare, but even if you argue that this exact example has no real
clinical validity in openEHR it is still an issue that could happen in
any other standard (I would say that CDA for example with his data
types and all his inheritances will suffer this problem for sure)
You can see that in these years even at-code rules have changed quite
a bit (just see current wording and compare with previous ones).
Specialization is a BIG part of archetypes and the more we use it the
more new problems we find. If you want we can wait until archetype
systems are in use to detect these kind of issues. Ignoring problems
won't make them disappear.
As we have discussed before, we want to add the functionality to turn
off the node autocompleting. But again having all nodes with at-code
is perfectly fine according to the specifications, and given the
issues we encounter with specializations I would say that is always be
better safe than sorry.
Good to know. I think the only remaining issue could be the one to
confirm if a specialized object should always have at-code.
And regarding use_node, I would also add that you have to be careful
not to create an internal reference from a sibling (and if you do then
you MUST put an at-code)
The problem with this rules come with the (explicit or implicit)
specialization of single attributes. take this example:ELEMENT[at0009] occurrences matches {0..1} matches { -- Position
value existence matches {0..1} matches {
DV_TEXT occurrences
matches {0..1} matches {*}
}
}What happens if a DV_TEXT is added on the specialization? Does it need
at code? Do we consider the rule to be applied to the archetype +
parent or only to the archetypes? Do we need to add an at-code also to
the parent?
If it were added in a specialisation with no code, it would be assumed to be a redefinition of an existing DV_TEXT constraint, assuming there was one. If added with a code, the post flattening validation (phase 3) in the current ADL workbench would need to detect this. Right now it doesn't have checks in that phase for this. I'll have to run this example through the compiler to see what it does.
This would need either a rewriting of the rule to state the issue with
flat archetypes or a potential problem if an at-code is not specified.
good point; the rules should specify that they apply to flattened archetypes, which means that ids are required even if each specialisation child introduces only one alternative. I'll fix this in the spec.
Another use case is when valid children types are part of the same
class hierarchy (no need for specialization). Do we need at-codes when
we create siblings such as DV_TEXT and DV_CODED_TEXT?
according to the current rules (see my previous post), yes. I would actually still rather avoid this, and am still thinking about it...
If we have several different data types, such as DV_BOOLEAN,
DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT,
which one of the data types gets an at-code? all? only the text ones?
none?
according to the previous rules, none. But DV_CODED_TEXT would be treated as a preferential constraint over DV_TEXT due to the RM inheritance relationship. It would be up to apps and tools to make use of that.
Again, rewording/clarification is needed or problems may occur.
yes - I doubt that we are at the final version of the wording on this - but have a look at the new version and see what you think.
What is so wrong about having at-codes in every class of the archetype
with no ontology definition for that code?
interesting question - so far (10 years!) we have always treated an at-code as something that is in the ontology. At the moment no tools at all would handle the assumption that only some codes had definitions; it would raise questions: how do you know which things need definitions and which don't? My guess is that there would need to be a special definition that is connected to the at-codes you want to have no definitions, which would complicate the archetype ontology section structure.
- thomas
I don't think archetype ontology would be more complicated at all.
There are currently archetypes with different set of properties in
each at code and tools can handle it well (if I remember correctly,
NEHTA archetypes have extra properties). I'm pretty sure tools are
currently robust enough to deal with missing at codes at the ontology.
It's even very easy to check if an at-code is on the ontology (if I
recall correctly from java implementation...)
Bert,
I would be very happy to test some archetypes created with the LinkEHR editor in the ADL workbench, but I don't think any are publicly visible are they? We need some definitive problem reports to know what to fix. Or log an issue here <http://www.openehr.org/issues/browse/AEPR>\.
I am pretty sure we can fix problems in both tools if we know what they are.
- thomas
(attachments)
I have quite a few generated archetypes. Not clinically valid (or clinically validated at least) but they should be simple and varied enough to test.
Or we could just try to generate a full cycle (I could open a CKM archetype, save it and give it back to you to test it).
(attachments)
Hi Thomas, thanks for your attention.
I experienced the problems with the Ocean Archetype Editor and The LinkEhr editor when used in the same work-environment, for example, which causes archetypes to be opened in both editors.
It is not difficult to reproduce the errors and inconviences. The issue is that both, Ocean and LinkEhr, do not recognize their responsibility and do not see a need to change this.
One problem easy to reproduce, easy, a few steps.
- create an archetype in the LinkEhr editor, most simple, based on Element with one DataValue. You will see it will have a nodeid on the DataValue.
- open it in the Ocean Editor, as I recall, this is not possible, first you need to change a few things, forgot what exactly. Small things, but this should not be. Ok, repair it in a text-editor, open it, and change one letter in the ontology, and save it.
- The nodeids in the DataValue are removed without notifying the user. The archetype has changed on other places then was the purpose of the user.
You can do this also the other way around and you will experience also problems.
The solution is: a good behavior would be that an archetype editor would conform to the archetype a user loads in it, changing it without notification is very wrong.
Another solution also needed would be that nodeids on locations where these are not enforced by the ADL-definition should be optional.
These problems exist for years now, everyone knows about them, If it was my software, I would comfort my users and customers with friendly solutions.
regards
Bert
(attachments)
well I think Nehta archetypes may have some hacks - they wouldn’t conform to ADL 1.5 and I am not even sure if their internal archetypes conform to ADL 1.4. IN any case, the things they want (annotations mainly) are done differently in ADL 1.5. It’s certainly easy to check for codes that are not in the ontology - and current the tools all do check, and generate lots of errors: VONSD, VATDF1, VATDF2, VATCD, VETDF, WETDF, VATCD, VACDF1, VACDF2; see meanings . I’m not saying it’s not an idea worth thinking about, but the current specifications and tools all work on the opposite premise. - thomas
The issue is that both, Ocean and LinkEhr, do not recognize their responsibility and do not see a need to change this.
Hi Bert,
Glad you've brought this up again, but the problem won't get fixed unless you report it. Can you report the problem at http://www.openehr.org/issues/browse/AEPR and attach an archetype that demonstrates it?
These problems exist for years now, everyone knows about them, If it was my software, I would comfort my users and customers with friendly solutions.
If I had a problem that I wanted fixed, I would report it in the problem tracker.
We are very busy and working on other projects. If this problem is important to you, please report it and we may get around to it some day. Please make sure that you attach an example of an archetype that demonstrates the problem.
Peter
Hi all, very interesting discussion.
> Another use case is when valid children types are part of the same
> class hierarchy (no need for specialization). Do we need at-codes when
> we create siblings such as DV_TEXT and DV_CODED_TEXT?
according to the current rules (see my previous post), yes. I would
actually still rather avoid this, and am still thinking about it...
Thinking about this case, shouldn’t be a better design approach to define DV_TEXT at the base archetype, and the DV_CODED_TEXT alternative (with further constraints) in a specialized archetype?
So the issue of the codes dissapear and anyone can choose to use the very generic archetype or the specialized one.
This is good from an Object Oriented design approach, but right now the specializations defined on the CKM are very specific concepts, not just a way to simplify modeling and reuse of artifacts (as it is in the case I mentioned).
I mean, the specialized archetype is not a more specific concept, is just the same concept with just “a little” more detail. E.g. if we take “Healthcare service request” and “Imaging examinaton request”, the specialized archetype I would create sits right in the middle of those concepts, in fact is closer to the more generic one.
In short, I don’t know if this should be defined at the model level or at the modeling proess level.
BTW, I aggree with Bert in that we need interoperable archetype design tools. Back in 2009 we needed to choose an editor, and we tested LiU, Ocean and LinkEHR, and we couldn’t load an archetype created by one tool into another tool :-/ Maybe now this has improve.
The issue is that both, Ocean and LinkEhr, do not recognize their responsibility and do not see a need to change this.
Hi Bert,
Glad you've brought this up again, Can you report the problem at http://www.openehr.org/issues/browse/AEPR and attach an archetype that demonstrates it?
Dear Peter,
First I have to start up a Windows computer, this means, digging up my notebook, clean my desk to have space to put my notebook on, and hope Windows will start on it, which is always a risk. Last time I remember my virusscanner was preventing Windows to start, I never tried again after that because my notebook also has Linux.
Both the LinkEhr as the Ocean-editor only run on Windows.
The LinkEhr editor should run on Linux too, but it is for a 32-bits JVM, and I cannot get it to run.
The Ocean editor should also run on Mono, but simply does not.
When I have succeeded both to run, than I must reproduce something. It will cost me a day or more.
To whom can I send the bill?
It is in the advantage of Ocean and LinkEhr to get this sorted out.
The problems are easy to reproduce. I told you how to.
Please make a copy of this and the previous email, and put it in Jira. It contains valuable information.
Or leave it and do nothing with it, like this has been done for years now. The market maybe will correct you.
Thanks again for your attention.
Have a nice day.
Bert
but the problem won't get fixed unless you report it.
Ah, PS: But don't put the blame on me for your software having problems. Thanks.
Nothing has been done about it, Bert, because no one has ever logged it as an issue.
If any one out there actually does care about this, then please log it at http://www.openehr.org/issues/browse/AEPR with an example archetype. Problems logged there do get fixed.
Peter
Someday, when I am busy with it, I will do it. Could well be coming month.
Or maybe I write my own archetype editor and thank Ocean and LinkEhr for giving me this business-opportunity, maybe even send a box of chocolates then. 
Bert
From Brussels, of course.
Bert,
all these tools are free, built and maintained by their originators at their own cost. So you might be sending yourself the chocolates...
- thomas
There ain't no such thing as a free lunch
Bert
I'll try to summarize the origin of the different views we have regarding
this topic and maybe this can be also useful to see why this is not just a
configuration problem of the tools.
We can find the explanation of node identifiers in two places (I use the
latest drafts, I think):
- In AOM 1.5 specifications, page 47: "Semantic identifier of this node,
used to distinguish sibling nodes of the same type. [Previously called
‘meaning’]. Each node_id must be defined in the archetype ontology as a
term code."
- In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of
the form [atNNNN] following a type name is used to identify an object node,
i.e. a node constraint delimiting a set of instances of the type as defined
by the reference model." and "A Node identifier is required for any object
node that is intended to be addressable elsewhere in the same archetype, in
a specialised child archetype, or in the runtime data and which would
otherwise be ambiguous due to sibling object nodes"
The definition in AOM is the one followed by the openEHR editor, i.e. a
node identifier or atNNNN code is just a pointer to the ontology section
and a mechanism to distinguish sibling nodes. Thus, wherever it is not
needed, the tool does not introduce that code in order not to dirty the
ontology section.
The first part of the definition in ADL is the one followed in LinkEHR
and, in our opinion, more correct formally. When you introduce an archetype
constraint for a C_OBJECT you are in fact creating a definition of a type
(a sub-type of the more generic type defined by the reference model class)
that will be used to create a subset of instances. We have to distinguish
this sub-type from the RM type, and since the class name cannot be changed,
the only solution is to use the atNNNN as type identifier. In other words,
our interpretation is that atNNNN codes are unique identifiers of each type
defined in the archetype, that may be also used to link to the ontology
section, but that is the optional part. In fact, the only exception to this
would be when you create constraints using a path, because then you are
just navigating through the RM but do not change the meaning of the
intermediate classes.
The logic of the tools and the validation checks of archetypes are built
based on those interpretations. I agree with Bert in one thing: tools
shouldn't change things without notifications, but in this case we face a
methodological difference, not just a configuration one, and that's why it
is not easy to be solved.
David