ADL internal references change proposal

Hello to everybody.

We have detected an issue in the ADL grammar related to the node_id (atXXXX value) of Internal References. An Internal Reference node, as any other C_OBJECT, inherits the node_id attribute. But its ADL grammar does not allow to define this value in a textual representation.

archetype_internal_ref:
SYM_USE_NODE type_identifier c_occurrences object_path

SYM_USE_NODE type_identifier error

We think it is necessary to allow the introduction of this information in some cases. When we re-use an internal data structure, we are maybe also changing its meaning. For example, looking at the example provided in the ADL 1.4 document, page 59.

CONTACT [at0004] ∈ { – home contact
purpose ∈ {-- etc --}
addresses cardinality ∈ {0..*} ∈ {
ADDRESS [at0005] ∈ { – phone
type ∈ {-- etc --}
details ∈ {-- etc --}
}
ADDRESS [at0006] ∈ { – fax
type ∈ {-- etc --}
details ∈ {-- etc --}
}
ADDRESS [at0007] ∈ { – email
type ∈ {-- etc --}
details ∈ {-- etc --}
}
}
}

CONTACT [at0008] ∈ { – work contact
purpose ∈ {-- etc --}
addresses cardinality ∈ {0..*} ∈ {
use_node ADDRESS /contacts[at0004]/addresses[at0005] – phone
use_node ADDRESS /contacts[at0004]/addresses[at0006] – fax
use_node ADDRESS /contacts[at0004]/addresses[at0007] – email
}
}
}

We re-use nodes at0005, at0006 and at0007 but we do not assign a new atXXXX code to them. Structurally, this is correct, but not semantically (i.e. we reuse structure but not meaning). It is not the same a “home” phone number than a “work” phone number. In fact, SNOMED uses diferent codes for each case: a “Patient home telephone number” (code 429697006) and a “Patient work telephone number” (code 428843000).

To sum up, it would be necessary to change the ADL grammar to support the use of new definitions of term_codes in the archetype internal references, something like:

use_node ADDRESS**[at1234]** /contacts[at0004]/addresses[at0005] – phone

Finally, it is necessary to remember that the archetype slot (which is a very similar use case) allows this kind of definition.

c_archetype_slot_id:
SYM_ALLOW_ARCHETYPE type_identifier

Hi David,

you are saying that in the ‘work contact’ cluster you should be able to override the [at0005] etc because they have meanings like ‘phone’ etc, and are defined within the CONTACT [at0004] node, which is to do with ‘work’. But the definition of [at0005] is just ‘phone’; the full meaning of that node is given by its path, which will be …/contacts[at0004|home]/addresses[at0005|phone] (i.e. home phone), and the same goes for the phone under the at0008 node, i.e. it will have a path …/contacts[at0008|home]/addresses[at0005|phone] (i..e work phone). So I think the current approach is correct for this example. It is also correct in my view for examples like Apgar, where the 2 min, 5 min, 10 min samples all refer to the 1 min sample - but clearly they are not the 1 min sample data.

The Slot does allow an override, but that is for the typical situation where the referring node needs to be more specific in meaning than the archetype being used in the slot. E.g. the main archetype might have a slot called ‘joint pain’, but might just use a ‘pain’ archetype to specify this. In this case, it makes sense to override. Now I can imagine the same argument being applied to the Internal reference - a more specific node carrying a reference to a more general one, e.g. work address referring to an ADDRESS node under an ‘addresses’ (i.e. completely general list) node, but I have never seen an example of it. But there is no reason why it could not happen I guess - I think this would be a better example for your argument…

  • thomas beale

David Moner wrote:

(attachments)

OceanCsmall.png

Hi!

I'm catching up with old mail...

If the underlying issue was SNOMED CT binding (or other
terminology/coding system bniding), then the distinction beteween two
alternatives of "code binding" (associating external code to a single
atNNNN-code) and "path binding" (associating external code to an
entire path) in the openEHR binding mechanisms is relevant. In the LiU
editor, and I assume also others, you select either "code binding" or
"path binding" each time you create a binding in the GUI.

See near the end in Fig 35 and in the first section of text in chapter 12.4 of
http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/terminology.html

Sorry if I happened to state something you already considereded obvious.

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