Thanks for the much clearer explanation Hugh. Is there a power point presentation (pref the Oz Snomed Conf) and/or paper(s) about your work that you can share with us?
Thanks Rahil Hugh Leslie wrote: > Hi All > > The Ocean Archetype Editor allows the designer to map one or more > coding systems to a particular term or to map a set of terms from a > coding system to a particular element to constrain the values for that > element to that term set. The editor actually doesn't dictate how the > terms are retrieved in the latter instance. In the demo that I did at > the Oz snomed conference in December, I showed how the term set can be > defined using the Ocean terminology service, and in this particular > instance, it was mapped to a web service running in another state of > Australia. This is really just one way of making it work and could > just as easily be retrieved from a locally cached query etc. A URL is > just a unique way of identifying the query that is being used. > > The point of the demonstration was that you could make snomed easier > for clinicians to use by creating these subsets ie medication route. > These subsets to be useful would need to be defined at a > jurisdictional level or higher so that everyone can use the same one. > This allows for a change in the query to be distributed easily and > updates to the coding system to be distributed in the same way. To > make this work, it will be necessary to have some centrally controlled > repository that the URL or other identifier can match the query to. > Analogous to archetype identifiers I guess. It may be possible to > include term set queries in the archetype if some universal query > language is available. > > I agree with Gerard and Andrew that using a particular terminology set > in a generic archetype probably makes the archetype more brittle and > should probably be used in templates in a particular jurisdictional > setting where an archetype is constrained further for a specific use case. > > It will be interesting to see how this all pans out. > > regards Hugh > > __________________________________ > *Dr Hugh Leslie* > MBBS, Dip. Obs. RACOG, FRACGP, FACHI > > Director and Senior Clinical Consultant > *Ocean Informatics Pty Ltd* > *M:* 0404 033 767* E:* hugh.leslie at oceaninformatics.biz > <mailto:hugh.leslie at oceaninformatics.biz> *Skype*: hughleslie > > > ------------------------------------------------------------------------ > *From:* openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] *On Behalf Of *Rahil > *Sent:* Wednesday, 3 January 2007 10:35 PM > *To:* For openEHR technical discussions > *Subject:* Re: Preprint re: SNOMED codes > > 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/ > > > > __________ NOD32 1954 (20070103) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > -- 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/a4d4860e/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
