A few remarks. Binding of items in an archetype to coding systems happens at two places (at least): names of labels and data fields. For both internal and external coding systems (including Snomed) can be used.
There are at least two different kinds of Archetypes we must consider: - the General Archetype: one that lists all items that can be recorded and exchanged about a specific topic - the Specialised Archetype: the Template. The Template consists of a Labelled structure filled with Archetypes, that is designed for a specific context and therefor has almost no optionallities left. This what a community has decided to use in their specific context. The General Archetypes in their data fields will have almost no fine grained binding to internal and external code sets. It will have strict bindings to internal or external coding systems. The Template will have strict bindings to internal and external code sets and coding systems. We can expect that these coding systems used in Templates are (internal or external) local ones, perhaps national ones, perhaps international ones. A strict binding to a local service is understandable. I foresee that an EHR-system without access to a local or remote Terminology Server is to inflexible. At the EHR-system level there will be increased separations of concerns: - Persistence layer - Document layer: archetype, template layer - Terminology Layer: coding system layer and some more. Gerard -- <private> -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 3-jan-2007, at 10:41, 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? > 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? > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070103/ab94d7be/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
