The problem
There are various long-running problem(s) with archetype node ids in ADL 1.4 and also the current ADL/AOM 1.5 specifications, which are:
...
In trying to deal with these, I sent an email to some archetype software developers to discuss some more radical ideas, see below, by way of background. I have also been chewing over various posts by Bert Verhees, David Moner, Diego Bosca and others who don't agree with the current rules, and implemented different rules a long time ago in their LinkEHR tool. After much thought, I decided I don't either.
...
The main aim here is to create an archetype node-id system that really works for everyone in the same way.
Solution - round 1
The proposal here is to fix the node id system properly. The cost of doing that is to take a new tack on backwards-compatibility of ADL/AOM 1.5 with ADL 1.4:
...
Below is the same archetype in the modified ADL workbench.
 |  |
|---|
Advantages
These changes should make implementation a lot easier, because now regular rules are used to define all codes at all levels, and also, every node really does have a code now.
One nice advantage of having id-codes and at-codes is that now we can distinguish codes for 'names' from codes for 'values'. We could potentially imagine going even further and arranging the archetype terminology so that at-code value sets are properly grouped.
Possible Problems
One potential problem with the above solution is that since a list of codes will typically be sorted lexically (e.g. in some visual list control), the numeric order is not preserved. I.e. now we get the following in a flat archetype codes list:
...
It's not yet clear if this matters anywhere.
Solution - round 2
In the next step we would rationalise all coded term constraints to URIs, following recent IHTSDO work, and particularly Harold Solbrig's analysis of both terms-as-URIs and of ADL/AOM 1.5 specifications. This has not yet been implemented, but would have the following effect:
- ac-codes would be converted to at-codes, and the 'constraint_definitions' part of the archetype terminology would disappear
- or possibly, keep the 'ac' code leader, to distinguish, but still merge 'constraint_definitions' into 'term_definitions'
- the CONSTRAINT_REF type would be removed entirely, and its semantics merged into C_TERMINOLOGY_CODE. This will simplify the specification, getting rid of an annoying C_OBJECT subtype, and making terminology constraints more regular.
Conversion of ADL 1.4 archetypes
I have implemented a converter for ADL 1.4 and also existing ADL 1.5 archetypes which does:
- convert the 'ontology' section to be named 'terminology'
- add the new id_definitions section into the archetype terminology
- for all at-codes used as node ids, renumber and reformat them as follows:
- at0000 => at1id1; at0000.1 => id1.1 and so on
- at000N => idN+1 e.g. at0003 => id4, at0022 => id23
- move all id codes from the term_definitions section to the new id_definitions section
- for all other at-codes, reformat by removing leading zeroes in the top level of the codes
- interior nodes that are missing codes get new id-codes.
- implem guidance: these can be created by injecting a fake code (e.g. id110011 is used in the ADL workbench) early on in
- parsing (the same code can be used), and then running a post parse processor over the structure, looking for these codes, and converting them to normal id-codes. This is done so that in specialised archetypes, the same corresponding nodes are matched and if no constraint overrides are detected, the same code is reusedfound and the id-code replaced with the same code, ensuring that specialised archetypes remain correct.
- leaf C_PRIMITIVE_OBJECT nodes always get the special code id9999.
The above rules can be applied deterministically to convert an ADL 1.4 archetype to a new-style ADL 1.5 archetype, and also (in reverse) to extract a set of ADL 1.4-compatible paths from the new 1.5 archetype.
NOTE: I have build this capability into a new version of the ADL workbench, to avoid others having the write the same converter. For release soon..
Upgrading of existing ADL 1.5 Tools
All current implementations of ADL / AOM 1.5 rules would need to be upgraded if the community decides to go forward with this proposal (or one like it). However, the pain of that should hopefully be offset by the code simplifications that result, and more clarity for future implementers and users of relevant libraries.
Background
The following is an email sent to some archetype software implementers on 9 Dec 2013. The implementation work above is based on a modified version of option A4 below. Not everyone I wrote to agrees with this choice! I didn't like it that much either, but in implementation it turns out to be quite nice.
...