So looking at body weight node structure I would have parsed a path
that would have included AT0004 in it to identify the discrete weight
data element (as in mass) .
This is tough because as I build out reusable clinical documentation
sections I was hoping to tag the data elements with the appropriate
codified elements - e.g. I can just add
source: LOINC code: 3141-9
source: SNOMED code: (concept id)
but to add
source: OpenEHR code:
openEHR-EHR-OBSERVATION.body_weight.v1/data[at0002]/events[at0003]/data[at0001]/item[at0004]/value
is going to be manual typing if the workbench is right or I will do it
with code if the java parser is right.
this path identifies the same element as
/data/events[at0003]/data/item/value
When there is only one element under a single-valued attribute, the
[atcode] is not needed; this is not an openEHR specific thing, it is
standard Xpath. Some intermediate nodes currently have codes but do not
need them, such as HISTORY (at0002 node), the ITEM_SINGLE node (at0001)
- the codes don't add any more semantics than already in teh underlying
reference model (i.e. HISTORY is a 'history' and ITEM_LIST is a 'list').
However, ideally the Weight ELEMENT node (at0004) would retain its
at-code, because it is semantically significant.
This issue has not yet been properly discussed in openEHR, and I should
probably turn back on the more slavish mode of path generation, with all
the at-codes included. If you are not doing your documentation
absolutely immediately, you can use an updated form of the workbench
which I will release in the next few days (which has a lot of other
archetype checking implemented).
BTW, you can just do ctrl-C on rows in the workbench path list and paste
into another tool.
- thomas beale
Yes I tried the ctrl-C but anyway that is a relief that the two paths
are equivalent.
I will just import the ADL and that will add the path as an identifier
I can use when I translate AQL to SQL down the road.
I should be clear here for everyoneâs benefit - such paths are guaranteed mathematically to be equivalent. Things to be resolved are:
whether we use at-codes on nodes where they add no semantic value and are not needed for dis-ambiguation
regardless of which way we go on 1., whether we use âsimplifiedâ paths (only have at-codes where needed) for querying
what we do in the AOM spec, which says that all C_OBJECTs have a node_id; this clearly is not necessary 100% of the time, and there are easily statable rules for when they are needed (which you will see in the ADL 1.5 draft I will put up in the next day or so).
how we populate the LOCATABLE.archetype_node_id field in data, for archetype object nodes that have no at-code.
I am personally in favour of the minimal approach - it makes paths shorter and more readable. I know the guys in Valencia have gone the other way. I can see reasons for this in the past when the specificatoins were not strong enough, but the new set of specificatoins will take care of many points of validity not previously defined.
I also think that shorter more readable paths are preferable for query strings, but maybe software should be required to accept both. The semantics for default path resolution algorithm might be good to put in the specs however we do to reduce the risk of misinterpretation.
A possibly stupid question regarding some of the points below: Arenât there cases when software using different human language translations of archetyped EHR content becomes easier to write if the at-codes are stored in the all LOCATABLE nodes of EHR data. (That way a simple at-lookup to the âontologyâ-part will give you a label in the preferred language.)
I also think that shorter more readable paths are preferable for query
strings, but maybe software should be required to accept both. The
semantics for default path resolution algorithm might be good to put
in the specs however we do to reduce the risk of misinterpretation.
A possibly stupid question regarding some of the points below: Aren't
there cases when software using different human language translations
of archetyped EHR content becomes easier to write if the at-codes are
stored in the all LOCATABLE nodes of EHR data. (That way a simple
at-lookup to the "ontology"-part will give you a label in the
preferred language.)
*Hi Erik,
Currently they are stored in all EHR nodes; the only question is whether
we make it optional for those nodes that don't need it; i.e. sole
children of single-valued attributes. Or - we can always put at codes in
the data, but allow the shortened paths. For the at-codes on nodes like
HISTORY etc, the text & description in the ontology is not useful - it
just says 'history' - so it is a distraction.
Hi All
I am for consistancy here - we are dealing with machines with paths, not people. I do not think paths are very readable and it is only the text that makes them readable - as in the logical paths in the workbench.
Keep it simple - use the codes on all locatables until we are over other mountains!
Cheers, Sam
