ADL/AOM 1.5 - id-codes unification - the final change

Technical (archive)
1

happy new year and best wishes for 2014. I hope your new year’s day is a bright one (unless you live in the UK, in which case it’s a lost cause today :wink:

I have been working in the last few months to produce a final version of ADL/AOM 1.5, based on:

  • existing requirements,
  • emerging requirements - Intermountain, CIMI,
  • Harold Solbrig’s proposals for terms-as-URIs,
  • Dave Carlson’s MDHT / AML work at OMG led by Robert lario,
  • general feedback on this list, particularly from David Moner’s group at UPV, where they have implemented different rules
  • implementer feedback
    I have cc:d some relevant people who are not on this list - they might want to consider joining. If not, please email me and I’ll post any views you have on the list, or else feel free to feedback on the wiki page below.

So here’s the proposal. To date, We have been trying to keep ADL/AOM 1.5 backwardly compatible at the syntax level for ADL 1.4. However, I think this keeps too many old problems unsolved. I propose a new approach:

  • make the central ADL/AOM 1.5 specifications as clean as possible
  • provide a series of updates to ADL 1.4, coming from the 1.5 specs, that are carefully designed to be applied to 1.4 tools, to bring them up to date
  • e.g. things like how to post-fit the new identifiers, tuple support, annotations, to DAL 1.4 archetype tools
  • provide rules and tooling to deal with differences between archetype paths, upon which querying is based
  • provide a 1.4 => 1.5 upgrade tool to completely convert existing ADL 1.4 archetypes to the new format

The latest changes I propose (and have in fact implemented) are primarily about dealing properly with the long-running problem(s) of archetype node ids.

It’s documented here on the wiki.

All comments and criticism welcome. If you think the proposal is broken in some way, or could be done better, don’t be afraid to say so. Please comment on this list, or for substantive comments, the wiki page is probably better. Let’s try and get to a final proposal that works for all ADL/AOM users - not just openEHR. I think that would be a real achievement.

thanks

  • thomas
2

Made a comment on the wiki page, but I will copy that here too:

Still thinking about this, but I have a first doubt:

What is the result of generating the standard equivalent ADL for this ADL code? (from the example)

ELEMENT[id31] occurrences matches {0..1} matches {
                                        value matches {
                                            DV_CODED_TEXT[id5002] matches {
                                                defining_code matches {
                                                    [local::
                                                    at31,     -- Naked
                                                    at32,     -- Reduced clothing/bedding
                                                    at33,     -- Appropriate clothing/bedding
                                                    at34;     -- Increased clothing/bedding
                                                    at0033]    -- Assumed
                                                }
                                            }
                                        }
                                    }

Do atxx codes get changed to id codes magically or just new idxx are generated? new idxx codes or id500x ones? new objects added to the 1.5 archetype should always have id50xx?

I’m still wondering if the at000N => idN+1 rule and the id5000 rule are a good idea. I see a lot of potential problems and not much benefits:

I don’t really think that keeping a at->id correspondence is a critical issue: The user defining archetypes shouldn’t even be aware of the changes, and if we want reuse current systems, things like AQL paths should still had to be rewritten to deal with the missing atxx codes, so not much benefit of having a rule for direct translation.

My suggestion is to keep things as simple as possible and just put idxx codes where needed. Maybe it’s a good idea to use the at000N => idN+1 rule, but for the missing ones I would just make another pass and put new idxx codes starting from the last idxx code we assigned on the first pass. As the 1.4 to 1.5 process only has to be done once, I think it’s better to make two passes to the original archetype and just put new idxx codes from now on.

I’m not a fan of having different ranges of id with different meanings. With templates being archetypes I won’t discard having idxxxx with values dangerously near to 5000…

3

Thanks for the input; see the wiki page <http://www.openehr.org/wiki/pages/viewpage.action?pageId=49053703&gt; for response.

4

Hi Thomas, best wishes to you too, and all other readers.

ADL is a generic modeling language, one should not stick to the OpenEHR RM while defining it.

it looks like a good idea to reflect the structure of an archetype in the idCodes, like this:

definition[at0000]
     list[at0000.1]
         element[at0000.1.1]
             datavalue[at0000.1.1.1]
         element[at0000.1.2]
             datavalue[at0000.1.2.1]

But there is a suggestion of ordered elements, but ordering can make archetypes immutable towards derived versions in the context of backwards compatibility.
Because imagine you want to insert an element, this can be confusing

definition[at0000]
     list[at0000.1]
         element[at0000.1.3]
             datavalue[at0000.1.3.1]
         element[at0000.1.1]
             datavalue[at0000.1.1.1]
         element[at0000.1.2]
             datavalue[at0000.1.2.1]

So I would suggest a non-numerical reflection of the structure, or, a design which leaves room for inserts, like this.

definition[at0000]
     list[at0000.100]
         element[at0000.100.100]
             datavalue[at0000.100.100.100]
         element[at0000.100.20]
             datavalue[at0000.100.200.100]

After insert this would become this
definition[at0000]
     list[at0000.100]
         element[at0000.100.50]
             datavalue[at0000.100.50.10]
         element[at0000.100.10]
             another_datavalue[at0000.100.100.5]
             datavalue [at0000.100.100.10]
             another_datavalue[at0000.100.100.15]
         element[at0000.100.20]
             datavalue[at0000.100.200.10]

Of course, this is limited, but I have seen this kind of constructions before, for example in distribution of phone numbers inside a company. Building-number, room-number, telephone-number, but this also get sometimes messed up in modern buildings in which it is easy to restructure rooms.

Bert