Hi and Happy New Year to everyone ! Andrew Patterson wrote:
>On 03/01/07, Gavin Brelstaff <gjb at crs4.it> wrote: > > >>http://www.cs.man.ac.uk/~qamarr/papers/Medinfo_Paper_RQamar.pdf >> >> >> > >An interesting paper. I'm not sure Rahil or Alan are on this list?? >Perhaps they should be cc'ed in on any discussion. Many of >the points about the difficulties of doing archetype binding >to snomed are excellent. I was just wondering about this >quote.. > >-------- >The intended purpose of archetypes is to empower clinicians >to define the content, semantics and data-entry interfaces of >systems independently from the information systems [1]. >Archetypes were selected because of their feature to separate >the internal model data from terminology. The internal data is >assigned local names which can later be bound or mapped to >external terminology codes. This feature eliminates the risk of >making changes to the model whenever the terminology >changes. >--------- > >In particular, I am referring to the concept of being bound >'later'. > >This is a point of view on archetypes that I had never really >considered. I had always assumed that the construction of >the archetype definition and the selection of terminology >binding would be part of the same process, either done by >the same person or the same clinical group. The paper discusses >some of the mapping problems that can occur when this >process is split, but surely that would never be the case? > > Infact the paper does not state that problems in the mapping process occur because of this 'split' feature. However, it tries to highlight that one of the problems in finding suitable SNOMED matches arises because the mapping is done at a LATER stage. For instance the evaluation of my MoST system was done by clinicians who were not the original authors of the archetype. This led sometimes to issues of understanding the need for using a particular term in the archetype model and sometimes its semantics. This problem arises mostly when there are different people modeling and mapping the same archetype. However, the aim is to include the mapping feature in Archetype Editors so that the original authors of the archetypes can themselves perform the mapping as well (of course with consensus if and when required). The system at present is performing mappings on pre-modeled archetypes depriving it the luxury of having access to the author. That having said, any model aimed at reuse should be explicit in its use and definitions to keep ambiguity at its minimum! Which is yet another point in case ! >The intention would be that within some master archetype >repository (be this a local/organisational/national repository), >the archetypes would include a full set of terminology >codes? (I can understand how one might think this because >none of the sample archetypes in the openehr repository have much >terminology data but that will surely that is a temporary situation >and the intention is that a real official repository i.e. one run >by nehta or nhs etc would have the term codes for their realm?) > >Which brings me onto a related point - at the snomed >workshop in Melbourne late last year there was an >(impressive) demonstration of some of the template building >tools written by Ocean. Part of the demonstration involved >creating a complex binding to snomed based on a >small query language (effectively the query was >"select all 'is_a' children of this snomed code up to a maximum >depth of 5"). This query binding was placed into the relevant >archetype as a URL reference to a webservice. Doesn't relying >on a URL in the ADL definition >make archetypes quite brittle. i.e. when the archetype definition >is loaded into the clinical system I either have to consult the >URL straight away and store the resulting codes, or else delay >the binding and risk having the terminology codes for my >ADL disappear in the future? > > I agree that this URL feature sounds a bit complex. Not having complete knowledge of the Ocean methodology and objective makes it rather difficult to comment though. However, 'is_a' trees are only part of the solution to the binding/mapping process. There are a few archetypes that have 'is_a' terms and can be dealt with in a less complex way i.e. without the use of URL's. Though am not sure whether the Ocean team had something else in mind when using URLs. Another aspect is to constrain free text entries in archetype models with the use of more intuitive/processable archetype definitions. A simple case of limiting the list of SNOMED codes that can act as 'legal' archetype entries should spare the clinician of too much and too frequent access to back-end codes and procedures else it'll simply discourage them from using the system! Perhaps someone from the Ocean team might want to throw some more light on this URL feature. It'll be interesting to know their view point. Thanks Regards Rahil >It just seems to me that if snomed is indeed the way things >seem to be going, that most terminology references in ADL will >either very simple (this node = 34242343) or need a moderate >level of complexity (all nodes in the 'is_a' 'route of administration' >heirarchy, but not ones with a qualifier 'blah'). Will all these >later style terminology bindings need to be done with URL's? >Isn't it going to be hard to keep these URL's alive for the >lifetime of the archetypes? On the other hand, if the URL's >are bound on archetype entry, how will they keep up with >changes to the terminology? > >Should there be a small query language for terminology >built into ADL? > >(btw happy new year to all!) > >Andrew >_______________________________________________ >openEHR-technical mailing list >openEHR-technical at openehr.org >http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- Rahil Qamar Ph.D. Student Medical Informatics Group Room 2.89 Kilburn Building University of Manchester Work number: +44 (0) 161 275 5719 Email: qamarr at cs.manchester.ac.uk Website: http://www.rahilqamar.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070103/b1e144b8/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
