Decision Support was: MIE-2008
Dear Everyone, just to add another perspective, in the Galen project post coordination was the norm while IHTSDO sits on a heritage of some 300 000 things Snomed CT needs to take care of. Also, pre-coordination is (I think) required for making fixed length identifiers. Still, Snomed CT is unusable without post-coordination, making pre-coordinated entities for everything in Snomed CT that has laterality would mean approcimately 700 000 entities. /Daniel On Thu, 2008-06-05 at 20:19 +1000, Hugh Leslie wrote: Hi Stef, SNOMED can be pre or post co-ordinated. A pre coordinated term is something like left foot where the side is included as part of the whole code and there is a separate term for right foot. There are many such codes in SNOMED. A post coordinated term is one which is described by a number of codes i.e. foot, left. This can get as complex as you like such as this example from wikipedia 284196006|Burn of skin|: 246112005|Severity|=24484000|severe, 363698007|Finding Site|= (113185004|Structure of skin between fourth and fifth toes|:272741003|Laterality|=7771000|left) We believe that building and querying for these complex post coordinated sentences is very difficult. The marriage of archetypes and terminology is a good one as much of the complexity of trying to express these things in a terminology can be expressed more simply using an archetype with the terminology enabling inferencing. hope this helps regards Hugh Stef Verlinden wrote: Hi Ian and Gerard, Could you please explain what post-coordination is and maybe provide an example of post- (and pre-?) coordination? Cheers, Stef Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven: most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, ___ 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
? In order to solve it we must look forward and reduce the 'grey zone' by acknowledging that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end. Gerard Realizing that the current Snomed CT Concept Model is not enough (today, unfortunately by far) and that the tools for supporting constrained post-coordination mainly are lacking, at least Snomed CT provides *some* constraints on semantics in areas where openEHR provides none. Also, the suggestion by David Markwell, I believe, is to represent semantics in Snomed space *as well as* in the archetype space. Also, I firmly believe that the grey zone will always exist as it is the result of the concurrent use of two different models of semantics. Thus, the boundary problem will not be solved, rather we will have to develop methods that makes the grey zone related problems less harmful. Regards, Daniel -- Daniel Karlsson, PhD Department of Biomedical Engineering/Medical Informatics Link?pings universitet SE-58185 Link?ping Sweden Ph. +46 13 227573, +46 70 8350109
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/d6b41912/attachment.html
openEHR Querying specifications
On Thu, 2008-06-05 at 11:36 +0930, Heath Frankel wrote:
The v1draft convention is already deprecated. The BNF for AQL doesn't
support it deliberately, to ensure only non-draft archetypes are used when
committing/retrieving data.
Heath
The previously referred to AQL BNF carries this header:
Name= 'EhrBank Query Lanaguage (EQL) - {Equal}'
Version = '0.4'
Date = '14 September 2006'
Author = 'Chunlan Ma Heath Frankel'
We know it has been renamed from EQL to AQL but I am wondering if there
is a newer version available anywhere?
Thanks,
Tim
--
Timothy Cook, MSc
Health Informatics Research Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
**
*You may get my Public GPG key from popular keyservers or *
*from this link http://timothywayne.cook.googlepages.com/home*
**
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/e51608d9/attachment.asc
Decision Support was: MIE-2008
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
Decision Support was: MIE-2008
Hi Daniel, Hugh et al. A couple of weeks ago I started a section on the wiki to collect use cases for terminology mappings from archetypes: http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes IMHO this is a very important topic and it would be good if the people following this thread could use it to share their ideas in the wiki. Cheers, Thilo On Tue, Jun 10, 2008 at 3:52 PM, Daniel Karlsson daniel.karlsson at imt.liu.se 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
Decision Support was: MIE-2008
Dear colleague, I agree with you that the grey zone is a relic from the past we have to deal with. Never the less, I want to argue that we have to reduce this grey-zone. By means of my suggestion to do post-coordination as much as possible in the archetype. The main reason is: - In language post coordination is done in the syntaxis and not in the dictionary. Gerard On Jun 10, 2008, at 9:37 AM, Daniel Karlsson wrote: Realizing that the current Snomed CT Concept Model is not enough (today, unfortunately by far) and that the tools for supporting constrained post-coordination mainly are lacking, at least Snomed CT provides *some* constraints on semantics in areas where openEHR provides none. Also, the suggestion by David Markwell, I believe, is to represent semantics in Snomed space *as well as* in the archetype space. Also, I firmly believe that the grey zone will always exist as it is the result of the concurrent use of two different models of semantics. Thus, the boundary problem will not be solved, rather we will have to develop methods that makes the grey zone related problems less harmful. Regards, Daniel -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/31d12655/attachment.html
Decision Support was: MIE-2008
leslie, I agree with the statement below. Gerard On Jun 10, 2008, at 10:06 AM, Hugh Leslie wrote: openEHR needs SNOMED and I believe that SNOMED needs archetypes. The decision will be where archetypes and SNOMED should begin and end and I think there will be a lot of debate in the next year or so! -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/7e3ed64c/attachment.html
