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. 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. 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. 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 Regards, David 2012/6/23 Bert Verhees <bert.verhees at rosa.nl> > Hi, > > I have some questions, I find hard to explain to my customers. > See below. > > But first, I explain how I handle this problem, but I don't know if that > is the best way. > I always tell my customers to create archetypes in the LinkEHR editor, and > if they want a C_DV_QUANTITY, create it by hand in a text-editor > (because the LinkEHR editor does not offer dadl-code inside the > definition, like the Ocean-editor tends to do in case of a DV_QUANTITY or > DV_ORDINAL) > > It is a strange thing, because both, Diego Bosca, who is an important > person inside the LinkEHR development, is often on this list. > Also are the Ocean-developers of their Archetype-editor. > There seems however no public discussion between the both approaches which > seem incompatible. > > This is not very satisfying. > > Below I have the problems I find, worked out. > > Can someone please explain what is going on, and how I should explain this > to people which have to work with archetypes. > > I was thinking of writing my own archetype-editor, which is not very hard, > with all the published code available (thanks Rong) > But I don't have time, coming months to do so. > > But if I would write one, this kind of problems would have been solved, > that is for sure. > I wonder, who's problem is it anyway? > > It is mine as developer on OpenEHR-kernel and working with customers. > > Thanks a lot > Regards > Bert Verhees > > ------------------------------**-- > The problem worked out > ------------------------------**-- > > The LinkEHR editor creates a DV_ORDINAL in ADL if an ORDINAL is wanted. It > looks like this: > > DV_ORDINAL[at0015] occurrences matches {0..1} matches { -- DV_ORDINAL > symbol existence matches > {1..1} matches {*} > value existence matches > {1..1} matches {1,2,3; 1} > } > > The OCEAN-editor creates a C_DV_ORDINAL which is empty in the definition > but handles the constraint in the term-defitions > ADL-part: > C_DV_ORDINAL < > > > And in the term-definitions, it looks like this (it is under the NodeID > from the parent ELEMENT) > ["at0004"] = < > description = <"*"> > a1 = <"een"> > text = <"New element"> > a2 = <"twee"> > > > ----------------- > Both methods are in compatible to each other. Both archetype-editors do > not open each others archetypes. > > This is very inconvenient. > > Another difference: > The LinkEHR editor offers a NodeID on the DataValue inside the ELEMENT, > giving the opportunity to give the data-value another description (in the > term-definitions) then the ELEMENT has. > The OCEAN does not offer this, but also does not accept archetypes made by > the LinkEHR editor > Even the most simple archetype created by the LinkEHR editor cannot be > opened by the OCEAN editor. > > Like this snippet: > definition > EVALUATION[at0000] occurrences matches {1..1} matches { -- sda > data existence matches {1..1} matches { > ITEM_TREE[at0001] occurrences matches {0..1} matches { -- > ITEM_TREE > items existence matches {0..1} cardinality matches {0..*; > unordered; unique} matches { > ELEMENT[at0002] occurrences matches {0..*} matches { > -- ELEMENT > value existence matches {0..1} matches { > DV_TEXT[at0003] occurrences matches {0..1} > matches {*} -- DV_TEXT > } > } > } > } > } > } > > ontology > terminologies_available = <...> > term_definitions = < > ["en-us"] = < > items = < > ["at0000"] = < > text = <"sda"> > description = <"sda"> > > > ["at0001"] = < > text = <"ITEM_TREE"> > description = <"This is a ITEM_TREE object"> > > > ["at0002"] = < > text = <"ELEMENT"> > description = <"This is a ELEMENT object"> > > > ["at0003"] = < > text = <"DV_TEXT"> > description = <"This is a DV_TEXT object"> > > > > > > > > > > > > > > ______________________________**_________________ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org<openEHR-technical at > lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/12ac978f/attachment-0001.html>
