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: <mailto:hugh.leslie at oceaninformatics.biz> hugh.leslie at oceaninformatics.biz Skype: hughleslie
_____ From: [email protected] [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 <mailto:gjb at crs4.it> <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070103/223a55c4/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
