# openEHR-technical Digest, Vol 27, Issue 1

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2008-10-01 15:07 UTC
**Views:** 8
**Replies:** 5
**URL:** https://discourse.openehr.org/t/openehr-technical-digest-vol-27-issue-1/14830

---

## Post #1 by @Greg_Caulton

> Currently you can get the paths from the Archetype workbench \- path
> view\. See
> http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/doc/adl_workbench_help.htm
>
> \- thomas beale

Oh oh, now I am more confused :\-\)

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\) \.

http://www.patientos.org/forum_temp/archetype.png

But the query path shown in the tool suggests that sometimes the
ATxxxx identifier is dropped \- perhaps because it was a single item?

http://www.patientos.org/forum_temp/query_path.png

This is confirmed in the Java reference parser as it parses the ADL
and looking at the path property on the quantity it shows a path of

/data\[at0002\]/events\[at0003\]/data\[at0001\]/item\[at0004\]/value

which is very different\.

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\.

---

## Post #2 by @Greg_Caulton

>> This is confirmed in the Java reference parser as it parses the ADL
>> and looking at the path property on the quantity it shows a path of
>>
>> /data\[at0002\]/events\[at0003\]/data\[at0001\]/item\[at0004\]/value
>>
>
> 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\.

thanks\!

Greg

---

## Post #3 by @thomas.beale

I should be clear here for everyone's benefit - such paths are guaranteed mathematically to be equivalent. Things to be resolved are:

1. whether we use at-codes on nodes where they add no semantic value and are not needed for dis-ambiguation
1. regardless of which way we go on 1., whether we use 'simplified' paths (only have at-codes where needed) for querying
1. 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).
1. 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.

- thomas beale

Greg Caulton wrote:


[details="(attachments)"]

![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png)

[/details]

---

## Post #4 by @erik.sundvall

Hi!

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.)

Best regards,
Erik Sundvall
[erisu@imt.liu.se](mailto:erisu@imt.liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-227579

---

## Post #5 by @thomas.beale

Erik Sundvall wrote:
> Hi\!
>
> 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\.

\- thomas

---

## Post #6 by @system

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

Thomas Beale wrote:


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---


**Canonical:** https://discourse.openehr.org/t/openehr-technical-digest-vol-27-issue-1/14830
**Original content:** https://discourse.openehr.org/t/openehr-technical-digest-vol-27-issue-1/14830