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 at imt.liu.se http://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 (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 > | SYM_ALLOW_ARCHETYPE type_identifier V_LOCAL_TERM_CODE_REF > | SYM_ALLOW_ARCHETYPE error
