On 24/06/2012 09:45, David Moner wrote:
> Dear Bert,
>
> I'll try to answer your questions about LinkEHR and the decision we
> took when the editor was developed. All these decisions are based on
> ADL & AOM 1.4 specifications, that are the ones implemented in both
> LinkEHR and the Ocean archetype editor.
>
> Your first question is about dealing with Domain Types. LinkEHR Editor
> is a multireference model editor. That means that you can edit
> archetypes for any reference model you import to it: openEHR, ISO EN
> 13606, HL7 CDA, CDISC ODM, ASTM CCR, MML... From that perspective, we
> originally did not incorporate specific features for just one
> standard. With regard to Domain types, they are extensions to the
> standard ADL to facilitate defining constraints over a few data types.
> At the 1.4 specifications they are in fact introduced in a section
> called "Customising ADL". In the case of openEHR, it incorporates
> domain types for DV_ORDINAL, DV_QUANTITY and CODE_PHRASE.
it should be noted that although the openEHR data type names are used
here (something had to be used), the problem and (I would argue) the
solution is the same for any reference model that has types to represent
ordinals, quantities and codes. But - see my other mail on potential
alternative approaches.
>
> When a domain type is found in LinkEHR, it cannot be edited at the
> graphical editor but you can either go to ADL to modify it or
> right-click at the node and select "Expand Domain Type". This option
> will automatically convert the Domain Type into its canonical form
> that can be edited in LinkEHR.
you can see from my other post how ineffecient the canonical forms are -
that was the reason for the more efficient types in the first place.
> In any case, we have recently implemented the specific support for
> editing openEHR domain types at LinkEHR, but it has not yet included
> at the published version.
> On the other hand, should the Ocean archetype editor be able to
> edit the canonical or standard form of those data types? In my
> opinion, clearly yes, since it is pure ADL, but currently I think it
> is not supported there.
>
> Now, your second question is about using node identifiers at the data
> types level, and by extension, being able to add node descriptions to
> them. Node_ids are used to identify nodes at the archetype definition
> tree and also to add term definitions and term binding to them. In
> LinkEHR, every node that is added has its own node_id.
>
> From the ADL specs: "Node identifiers are required for any object node
> which is intended to be addressable elsewhere in the cADL text, or in
> the runtime system and which would otherwise be ambiguous i.e. has
> sibling nodes."
>
> Our interpretation is that they are required in case of sibling nodes,
> but it is not prohibited to use them at any other case. In other
> words, it is not strictly necessary, but is is not incorrect either.
> Any ADL parser should accept those node_id even if they afterwards
> ignore them for any reason.
yes, this is correct. I think the Archetype Editor probably doesn't do
this properly at all levels. The only exception to the 'sibling nodes'
rule is if the sibling constraints are of different RM types, e.g.
DV_TEXT and DV_CODED_TEXT. The current text of the 1.5 draft reads:
Summary of Object Node Identification Rules
As indicated in the section Node Identifiers on page 47, node
identifiers are needed on some object nodes in order to disambiguate
them from sibling nodes. This enables the construction of paths to any
node in the cADL structure, and also allows specialised versions of
nodes to be defined in specialised archetypes (see section 10 on page 100).
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:
* for an attribute defined as multiply-valued in the underlying
information model (i.e. a container type such as a List<T>, Set<T>
etc), all immediate child object nodes. This applies even if a
particular archetype only specifies one child object of the attribute;
* for single-valued attributes with more than one child, all immediate
child object nodes that are of the same reference model type, i.e.
of the form of the example shown in section 5.3.2;
* with the exception of use_node constraints where the node identifier
can be inferred from that of the target node.
In all other cases node identifiers are optional.
[It is arguable that the 2nd bullet point may need to become mandatory
regardless of RM type, because of the need to be able to match redefined
nodes in specialised archetypes that further change the RM type...]
> In fact, there is a mismatch between this definition for node_ids and
> the attribute "node_id" at the C_OBJECT class of the AOM, where it is
> defined as a mandatory attribute. Something about this topic was
> already discussed in the mailing list back in July 2008, but there
> were no conclusions, I think:
> http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2008-July/003948.html
In the current draft, it states that the node_id attribute must be
'unknown' if it is not a proper code. I currently think this is
problematic, and it would be better simply to require it to be a
non-void string, which can be empty if there is no identifier.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/29c500ae/attachment.html>
