Dear all, A few thoughts about this topic of Terminology Binding and Archetypes. In essence it is the topic of "the Boundary Problem". Archetypes are a solution for this problem. But in order to do so we need agreements on a few things.
We mus be extremely clear what we mean when speaking about binding terminologies in archetypes. Are we talking about Archetypes or Templates? (design-time versus almost run-time? Generic structures versus locally agreed structures?) Are we talking about 'Label' or ' Data fields' or ' Archetype slots'? Are we talking about Internal or External coding systems? Are we talking about General External Coding Systems or specially edited sub sets of External Coding Systems, like Oceans Terminology Server and editor provide? (Oceans product creates sub sets of a coding system to be used in a specific context. And acts at as a new refined, restricted, external coding system derived from a feeding general external coding system) What will be rules that govern these things and prevent hazards for patients and healthcare providers? Using the archetype editor we can provide bindings to Generic Basic Archetypes, Specialised Archetypes but also to Templates (Organising Archetypes) and Specialised Templates. Specialisations can be made for specific clinical (sub-)domains or legal jurisdictions. Archetypes define what maximally can be recorded about a clinical concept. Templates define what minimally must be recorded in a specific context, as the agreement between two or more communicating partners. Most (refined) constraints will be applied in Templates. Archetypes need some terminological bindings. Since they are general it can not be fixed fully at design time to what external terminologies they can be bound. Primarily they will use internal codes. In particular controlled circumstances a clinical domain might adopt a specific external coding system to be used in Archetypes designed for that domain. Most codes (internal and external) used in Archetypes will code 'labels' and less data fields. When data fields are bound to a specific external coding systems there will arrise the need for a similar Archetype but bound to an other coding system. This will need an Archetype Ontology where we can create a mechanism that establishes that two archetypes express the same clinical concept but in a different way, using an other (internal or external) coding system. In the world of Templates things are different. This is a space that is much less controlled. Local/regional/national agreements have to be made on the finest detail. Most codes will be used in data fields. A lot of local freedom will be necessary. I have not extended the discussion of binding Archetype Slots to a coding system that is used in connection to 'The Archetype Ontology'. Archetypes and specialised archetypes have to be subjected to quality control in order to prevent hazards, because of errors and non- interoperability. EuroRec (the European Institute for Health records) is executing an Europ[ean project: Q-Rec. Q-Rec will, among others, will realise an Archetype and Template Registry. Its main purpose is to realise: Quality Labeling and Certification of EHR-systems. This will have to include Archetypes. Eurorec will organise quality control of the archetypes and templates to be published. It might be a good idea to involve them. Helpful in this respect is that: - there is an agreement between OceanInformatics and EuroRec, - several players from OpenEHR and CEN/tc251 EN13606 are members of the Q-Rec consortium and EuroRec, - persons active in EuroRec and OpenEHR take part in worldwide developments on Archetypes/templates, Semantic Interoperability, discussions on the deployment of coding systems. Greetings, Gerard -- <private> -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 19-dec-2006, at 9:56, Williamtfgoossen at cs.com wrote: > In een bericht met de datum 18-12-2006 20:44:14 West-Europa > (standaardtijd), schrijft Thomas.Beale at OceanInformatics.biz: > > >> This is not an unreasonable request - it would not be particularly >> difficult to implement in the specs or the tools, if we know what to >> implement. We have to be careful with Snomed licensing issues however >> when the terminology is snomed... > > > I think there is no reason to be careful if within a realm. Key is > to take care where to apply and where not. My earlier comments on > binding not only to one terminology but to have mapping tables with > synonyms applies here too. > > William -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061219/0af95a77/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
