I agree with the principle Daniel has expressed - that the ability to be precise about meanings of nodes within archetypes (and their potential semantic relationship to nodes within other archetypes) can be useful, and coding can help identify where sub-archetype semantics are intended to be consistent. For this, using an existing clinical terminology can help archetype designers re-use semantic meaning where applicable and may also have the benefit of avoiding re-inventing definitions for common concepts. (For example, when we asked UK stakeholders for comments on the openEHR blood pressure archetype, one of them said that ''Reclining' is not recognised as a useful category for position.' Assuming that similar discussions about which terms are clinically meaningful occurs in the terminology world, it makes sense to me to combine / re-use resources where applicable.) At this level, I see coding as a potential way to save time in designing and in interpreting archetypes with precise clinical meaning. I think the issue of the costs of coding with respect to implementation need to be tested, but I had assumed that archetypes may be 'coded' (potentially using more than one terminology) as a guide for those who want to use codes, without necessarily implying that the use of all codes (in data storage forms, processing, etc.) was mandatory. Best regards, Laura
_____ From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Hugh Leslie Sent: 11 June 2008 00:23 To: For openEHR technical discussions Subject: Re: Decision Support was: MIE-2008 Hi Daniel I would be interested in a real world use case where you need to know that "standing" has the same meaning in two different archetypes. If archetypes are designed properly, then the semantics of the model are self contained as a single concept. Specialisations of the model will maintain the same meaning of the contained elements, and the semantics of the contained elements relate to the whole concept. I would contend, that in any examples where the same element needs to have the same meaning across different archetypes, it is probably because the design of the archetype is bad. Coding everything to that level has great implications in terms of cost - not only in terms of development, but also in terms of maintenance. If there are compelling real world use cases for doing this, lets do it, otherwise lets do what is pragmatic and gets the job done as soon as possible. regards Hugh Daniel Karlsson wrote: Hugh, The argument comes when you say that every data point in an archetype needs to be coded and here there are arguments both ways. I would say that it is unnecessary to code every data point. There is little benefit for instance in coding sitting, lying, standing, reclining n a blood pressure archetype. The archetype contrains the value of position to these four values. The values are in context and their meaning is clear to anyone using this archetype. Translation is much easier as the archetype gives an absolute context for the meaning of the term. Coding these terms in SNOMED would be so that you can query your health record for every "standing" item? Its pretty unlikely that this would be a useful requirement. Coding everything s going to be a very slow and enormously expensive process to get right. It makes translation of archetypes much more difficult, especially for those many countries that don't (yet) have a SNOMED translation. Building archetypes is proving to be a very rapid and useful process. I think that there can be more reasons for binding archetype nodes to external terminologies apart from information re-use requirements in the "query for everything standing" example, e.g. to be able to express that "standing" in one archetype has the same meaning as "standing" in another archetype. Also, I didn't realise that I said that everything necessarily should be coded. Referring to David Markwell's report, he states (more or less) that things in the "grey zone" should be represented redundantly but he also states that terminology binding requirements should be driven by information re-use requirements. I agree with him on both points. /Daniel _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- ________________________________________________ Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Clinical Director Ocean Informatics Pty Ltd M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: www.oceaninformatics.com ********************************************************************** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ********************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080611/5e2cb297/attachment.html>
