Hi Tom, thanks for the comments. I see your point (and others' who mailed me directly).
However I am not totally satisfied with the assumption that we can separate descriptions of information vs. real world in a perfectly clear way. I mean the organisation and hierarchy plus the at/ac terms given in an archetype for a clinical model still gives a lot of clues about the real world aspects. Am I still missing something here? So now I'd like to withdraw my previous suggestion and present another: What about having the means to be able to define a relationship type and the relationship between individual terms (with at/ac codes) given in the ontology section. I am talking about really simple relationships but also aware that this is clearly a duplication of terminology functionality; however this would greatly ease most of the typical implementations of openEHR - I mean without going into complexity and potential performance problems when working with a terminology service. I can also see relatively easy GUI generation if the relationships behaviour is straightforward. Of course for SNOMED and possibly other decent terminologies terminology service is a must. The thing I have in mind is like this: > ontology > term_definitions = < > ["en"] = < > items = < > ["at0001"] = < > text = <"Term A"> > description = <"Term"> > > > ["at0002"] = < > text = <"Term B"> > description = <"Term"> > > > ["at0011"] = < > text = <"Term 1"> > description = <"Related term"> > > > ["at0012"] = < > text = <"Term 2"> > description = <"Related term"> > > > relationship_definitions = < > ["is_part_of"] = < > items = < > ["at0011"] = <"at0001"> > ["at0012"] = <"at0001"> > ["at0012"] = <"at0002"> > > > > > ["another relationship"] = < > items = < > ["atXXXX"] = <"atYYYY"> > Hope I am not pushing too far ;) Any feedback from implementers? Cheers, -koray Thomas Beale wrote: > Koray Atalag wrote: >> Hi All, >> >> I have a use case which I am having quite hard time to model. The >> thing is in fact very simple to express with a tabular list, >> spreadsheet or XML - which we do not fancy much because ADL is >> claimed to have much more expressive power (well in general yes)! >> >> Here is the use-case: >> A CLUSTER archetype for depicting the anatomical sites of a finding >> for a given organ. The clinical domain is digestive endoscopy but >> this applies to others I think. >> >> So we have an _organ, then list of sites and a list of "modifiers"_ >> which further specify a particular site. The simple modelling >> strategy to model each organ with an ELEMENT and then putting sites >> as values might work given that these "modifiers" can be expressed in >> the archetype separately and tell the application to combine these >> during runtime. Another option is of course using terminology service >> to get the proper semantics (i.e. post-coordination and subsets) - >> but this is not an option in my case and I must stick with local >> codes. I talking about 5-10 sites per organ so it does not make sense >> to use terminology service. > > using a 'terminology service' doesn't depend on the number of terms in > the terminology, it just depends on the need for standardised meaning > , dissemination, and a capability to keep evolving the terminology. > Now, it may not make sense to use an expensive big SNOMED-capable > system, but logically speaking the required facility is still a > terminology service, and that's how the software should be built - > even if it is a fake system just talking to a simple XML file. > >> Also you can say that this can further be specified by templates - >> true but why not putting such simple constraints at the archetype >> level - if we say that archetypes represent discrete clinical >> concepts for reuse then we should do it at archetype level. > > but don't forget, archetypes are essentially models of information > use, not descriptions of the real world; the latter is the job of > terminology. Archetypes are a frame-logic artefact, even for the > representation, things are different - terminologies are a description > logic artefact. Practically speaking, this means that archetypes are > more heavily oriented to machine notions of the is-a and particularly > compositional part-of relationships, while terminologies are oriented > to is-a (classification) and a rich set of other relationships that > occur in the real world, like part-of, uses, caused-by, has-site, > symptom-of and so on. > >> >> And here is a worse version of the use-case: _a given set of >> modifiers_ apply to certain - _not all sites_ for a given organ. For >> example the modifiers "anterior wall", "posterior wall" applies to >> fundus and body sites (of stomach) >> >> Finally here is the nightmare version: _a different set of modifiers_ >> apply to _different _and _not all sites_ for a given organ. For >> example the modifiers "Lower third", "Middle third" applies to "Main >> duct" site of pancreas and the modifiers "Left intrahepatic >> branches", "Right intrahepatic branches" apply to "Liver ducts" of >> pancreas. > > this is classic terminology / ontology stuff - we are talking here > about an ontological description of the various organs, gut etc. > >> >> Of course a (non-elegant) modelling strategy would be to make each >> site as an ELEMENT and then the set of modifiers for each and every >> one of them as values. Then this might be problematic during GUI >> design and also during querying. >> >> Here is what I suggest: add a feature in which some "attributes" can >> be specified for values of leaf nodes, like XML. I know this would >> result in dramatic changes in RM and tools (and existing >> implementations) but the sooner the better if you think this is useful. > > for other reasons, this has been suggested before, and I suspect it > would not be that hard to do, but so far there is not strong enough > evidence of the need. I think the above problem is best solved in the > terminology/ontology world! > > - thomas beale > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4283 (20090727) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4283 (20090727) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz __________ Information from ESET NOD32 Antivirus, version of virus signature database 4283 (20090727) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090728/74b138b3/attachment.html>
