On 29/08/2013 08:12, David Moner wrote:
>
>
> I know that the openEHR archetype editor only allows introducing
> OBSERVATIONs and the other clinical classes through a slot at the
> COMPOSITION and SECTION, and probably that is a good methodological
> approach or good practice to improve archetype governance, but
> technically it is not the only possibility. You can create an
> archetype from the top COMPOSITION to the leaf data values in one
> single archetype.
yeps, that's certainly true, and it could easily make sense in some
situations.
> And in any case, it is just an example, we can use MY_CLASS_NAME or
> whatever to avoid thinking this is a problem about how things work at
> the openEHR reference model.
>
>>
>> I don't think a clinical modeller would have to mind about these
>> aspects. He/she creates an archetype node (internally, a unique
>> atNNNN code is created). He/she optionally gives it a name or
>> defines a terminology binding (internally the ontology structures
>> are created). When the archetype is used or processed, the
>> systems will only use the information they have available.
>
> Ok, but if tools have no rules, then we can end up with an
> archetype like this:
>
> OBSERVATION matches {
> data matches {
> HISTORY matches {
> ....
> }
> }
> }
>
>
> with no meaning on anything. What is to prevent that?
>
>
> To be exact, in our approach all those classes should have an atNNNN
> code, even if it is not described at the ontology section. But in any
> case, current atNNNN rules does not force to put a description with a
> sense either, except for the root node because it corresponds to the
> same concept as the archetype identifier when you create the
> archetype. It is more a duty of the clinical validation team to check
> those kind of things, not something that can be automatically
> validated by rules. Look at the following brand new archetype created
> with the openEHR editor, just choosing an OBSERVATION root:
>
> definition
> OBSERVATION[at0000] matches {-- Test example
> data matches {
> HISTORY[at0001] matches {-- Event Series
> events cardinality matches {1..*; unordered} matches {
> EVENT[at0002] occurrences matches {0..1} matches {-- Any event
> data matches {
> ITEM_TREE[at0003] matches {*}
> }
> }
> }
> }
> }
> }
>
> ontology
> term_definitions = <
> ["es"] = <
> items = <
> ["at0000"] = <
> text = <"Test example">
> description = <"unknown">
> >
> ["at0001"] = <
> text = <"Event Series">
> description = <"@ internal @">
> >
> ["at0002"] = <
> text = <"Any event">
> description = <"*">
> >
> ["at0003"] = <
> text = <"Tree">
> description = <"@ internal @">
> >
> >
> >
> >
>
>
> The only "meaning" there is the "Test example" name of the
> OBSERVATION, because it corresponds to the archetype name. But all the
> others have no meaning and no existing rules are checking that (having
> "Event series", "Any event" and "Tree" is the same as not saying
> anything). So, again, those ontological descriptions will be always
> checked by the authors, not by the tools.
well, ok, but that's just like saying that a half-made movie isn't
watchable. Intermediate development states of any semantic object can
clearly have meaningless placeholders for some period of time, while the
designer does his/her thinking.
>
> By the way, following the specifications, even that example archetype
> created with the openEHR editor is not perfect. Both the at0001 and
> the at0003 codes should not be needed according to the rules, since
> they are members of single value attributes without sibling nodes...
yes, I agree with that. I forget why that tool does that, but in any
case, don't take it as a design guide...
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/2f3d71d1/attachment-0001.html>
