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
at-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 at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579
On Mon, Feb 9, 2009 at 17:04, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
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:
Hello to everybody.
We have detected an issue in the ADL grammar related to the node_id (at
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 at
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
| SYM_ALLOW_ARCHETYPE type_identifier V_LOCAL_TERM_CODE_REF
| SYM_ALLOW_ARCHETYPE error
