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. 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. 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. 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. Cheers, -koray -- 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 4265 (20090721) __________ 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/20090722/63a8da04/attachment.html>
