Hi,
The code-examples were not completely correct. But the issue remains
The LinkEHR editor does not recognize a DV_ORDINAL made by OCEAN,
and also available as, f.e.
openEHR-EHR-OBSERVATION.apgar.v1.adl which I downloaded from CKM.
If I make I DV_ORDINAL in LinkEHR, it looks like this
ELEMENT[at0005] occurrences matches {0..*} matches { -- ELEMENT
value existence matches {0..1}
matches {
DV_ORDINAL[at0006]
occurrences matches {0..1} matches { -- DV_ORDINAL
value existence matches
{1..1} matches {1,2,3; 2}
}
}
}
Which is something else as
ELEMENT[at0009] occurrences matches {0..1} matches { --
Ademhalingsinspanning
value matches {
0|[local::at0010], --
Afwezig
1|[local::at0011], --
Matig of onregelmatig
2|[local::at0012] --
Normaal
}
}
from CKM, which is also created in the Ocean editor, which in another
case created a C_DV_ORDINAL, while I was placing an ORDINAL, but
constructed it in another way.
-----
But the DV_QUANTITY and C_DV_QUANTITY between two editors is much more
different, and incompatible in editors, they cannot interchange both
constructs.
Why is that, what is the problem, which one is not following the specs?
And there is also the issue on the NodeID on DataValues, which you can
see also on the DV_ORDINAL in the LinkEHR example
I am having guests now, so I have to stop describing this problem for now
I will come back tomorrow on this subject. But maybe this is enough clue
for the involved people to respond to.
thanks
Bert
Op 23-6-2012 13:01, Bert Verhees schreef:
> 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
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
