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">
>
>
>
>
