Hi,
In LinkEHR, every C_COMPLEX_OBJECT must have its own at-code. From our point
of view, when you define an archetype you are defining set of types (type =
Object node) constraining the types (classes) of RM or the parent archetype
if it exists. Then it is necessary to have a unique identifier for every
single constrained type. This has nothing to do with the fact that some of
these types need an ontological description with their associated text,
description or terminological binding. But when this is not needed, we just
leave the ontology reference void or with a generic description:
PQ[at0005] occurrences matches {1..1} matches { -- PQ
units matches {
CS[at0009] occurrences matches {0..1} matches
{ -- CS
codeValue existence matches {0..1} matches
{"mm[Hg]"}
codingSchemeName existence matches {0..1}
matches {"UCUM"}
}
}
value matches {|0.0..<1000.0|}
}
["at0005"] = <
text = <"PQ">
description = <"This is a PQ object">
>
["at0009"] = <
text = <"CS">
description = <"This is a CS object">
>
You are right when you say that this may "pollute" the ontology and the
paths, but this is a minimal problem since at the end, archetypes should be
managed by the appropriate tools that can hide this extra information very
easily.
With regard to using implicit order-based ids, it doesn't seem a very good
solution since it may have conflicts with the values of some attributes of
the RM in data instances, e.g the LOCATABLE.archetype_node_id which
explicitly requires a valid atXXXX syntax.
2008/7/17 Thomas Beale <thomas.beale at oceaninformatics.com>:
> David Moner wrote:
>
> Hello,
>
> I totally agree. When we implemented the semantics of specialisation in
> LinkEHR-Ed we also took that decission. Since LinkEHR-Ed is mainly based on
> archetype specialisations, we always need to have identifiers for every node
> and for that reason we automatically complete every node with an internally
> generated [at-code]. In fact, we have never understood why the node_id
> attribute is mandatory in the C_OBJECT of the AOM but it is not in the ADL
> syntax.
>
>
> *David,
>
> just thinking about your response further, does this mean that you put node
> ids on data value level nodes, e.g. like on the QUANTITY example I showed in
> the previous email? What did you put in the ontology part of the archetype
> for these ids? One alternative I have thought of is to use implicit
> order-based ids like in Xpath, e.g.
>
> *ELEMENT[at0004] matches { --
> speed limit
> value matches {
> QUANTITY*[1]* matches {
> magnitude matches {|0..55|}
> property matches {"velocity"}
> units matches {"mph"} -- miles
> per hour
> }
> QUANTITY*[2]* matches {
> magnitude matches {|0..100|}
> property matches {"velocity"}
> units matches {"km/h"} -- km per
> hour
> }
> }
>
> These would not need to be stated necessarily in the archetype, but they
> would work in Xpaths e.g. xxx[at0004]/value[2] would refer to the second
> Quantity.
>
> The alternative is to just use at-codes absolutely everywhere, but it seems
> heavy handed semantically.
>
> - thomas beale
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
--
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/mailman/private/openehr-technical_lists.openehr.org/attachments/20080717/328f825b/attachment.html>
