Archetype vs. ontology
Philippe Thank you for this...very informative and I am starting to see how we are converging with your work. I believe that the 'structured terminology' - fils guide down from the archetype nodes - is an important part - SNOMED are trying to address it generically (ie without archetypes) - I doubt this is possible in one language - and it is certainly not in other languages. From my experience with health one, French is particularly suited to the approach that you are taking as qualifying terms (such as adjectives) tend to follow their nouns and the subject, verb, object structure is usual in sentence. I know that moving to English - where qualifiers precede, that such an approach has to be more sophisticated - and in other languages it is far more complex. What is called for is getting to grips with some key archetypes for interoperability - from a range of stakeholders - and then really having a close look at where more complex terminology is sought. One place I have no doubt it is required is in anatomyhow you describe the location of a lesion or mass. Another is the characteristics of a mass or lesion. The high level 'smarts' you are talking about are impressive - and I do not know about this end of things. Cheers, Sam Hi Thomas, The very word we are talking about here is Knowledge management. Archetype and ontology are some (very strategic) components, but are not the whole thing. From my point of view, Knowledge management is a superset of (at least) 2 concepts : artificial intelligence (AI) and smart data management. An example of smart data management is the ability, when you expect a document of 'A' type and that a document of 'B' type arrives, to check if 'A' -is a- 'B' or 'B'-contains-'A', in order to close the goal get a A. So, Knowledge management doesn't only mean expert systems or smart agents, but a system that is globally aware of what it manages. In Odyssee, the ontology is the very kernel of the systems, since it is the langage used to tell the patient health journey, but also to represent the internal knowledge. The AI components are structured around a Blackboard (we started from Stanford's BBK, now largely adapted) that federates smart agents. The smart data management components are everywhere else, for example in the data model and interfaces management. This (somewhat long) introduction to tell that, in the way we use it, Archetypes are data model elements and Fils guides are interface elements of the smart data management category. A Fil guide is a multi-purpose information element aimed at answering the question what can I do now ? for something/someone that is somewhere in a tree (multi-purpose isn't it ;o)). So a Fil guide is made of two parts : a path (in the form colonoscopy/description/polyp or colonsocopy/*/polyp or */polyp) and a content (currently in the form of a list of ontology concepts that can allow to bring the description one step further, but it can be anything else - say an html page or a function pointer). When you describe something in the medical field, if there is a genuine gold standard description, you have to use a deterministic approach, since the user has to be compliant to the standard. This description becomes part of the information system reference model through an Archetype. And the instanciated data remember the mold (Archetype) they come from. But in most cases, there is just a fuzzy expertise, and you can just say something like being where you are, an expert would keep on the description that way : it is tipically what a Fil guide will do. You have many Fils guides in a big bag, and when the user is somewhere, you find the more relevant Fil guide (if any) : more relevant means the one whose path is the semantically closest from user actual current path. But the Fils guides are just oppostunistic description support in a non deterministic domain. So the data don't remember the Fil guide they come from. This (too) long description to explain that Fils guides neither belong to the reference model, nor to the ontology, but are interface components in a knowledge management system. Currently, we have nearly 3500 Fils guides, but most of them are used for our report management system and should be replaced with archetypes. By the way, the Fil guide engine, that decides which Fil guide to throw, can also decide to throw an Arcehtype if the user has entered a part of domain where a deterministic description should occur. And you also can go beyond the leaves of an Archetype using Fils guides (or just using the ontology by hand). I hope that all this is understandable ;o) Philippe AMELINE Hi, I just forgot to tell you that our ontology has only 50 000 terms (it means less than 50 000 concepts, since a concept can be represented by several terms). As you may have understood, the ontology
Episodes in openEHR
Tim These links are very helpful...particularly to show that the idea of episode is about one consultant - rather than admission. The Australian data dictionary is about an admitted patient episode. It is clear that many types of groupings will be required. The Folders solution may be one - but I believe a 'persistent' EVALUATION which is archetyped for the purpose is more likely to be usefulas it will allow collection of whatever data is required. Sam Tim Churches wrote: On Sat, 2004-11-20 at 12:42, Thomas Beale wrote: This is part of a discussion that started off the list. The need is to be able to model Episodes in openEHR, while remaining compatible with available structures. See http://bmj.bmjjournals.com/cgi/content/full/329/7476/1207 and http://snipurl.com/armv for definitions of statistical episodes, which may or may not correspond to clinical episodes. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
A patent application covering EHRs
There is some concern here in Australia over a patent application lodged by the Pharmacy Guild of Australia over some rather generic features of EHRs. These concerns are reported here: http://australianit.news.com.au/common/print/0,7208,11467621%5E15319%5E%5Enb%20v%5E15306,00.html or here: http://snipurl.com/atst The application has been lodged under the international PCT (patent co-operation treaty), and it appears that country level applications have been lodged in at least the UK, Canada and the US, as well as Australia. At a glance, there would not appear to be much in the way of novelty in the claims, and several groups here in Australia plan to lodge objections to the application. Others may wish to object to the applications in their own countries. If anyone can suggest clear prior art which was published before April 2002, and ideally before April 2001, then please let me know (or post details to this list so the prior art can be shared around). The details of the patent application, and a related one filed on the same date, are as follows: METHOD AND SYSTEM FOR SHARING PERSONAL HEALTH DATA can be found here: http://v3.espacenet.com/textdoc?CY=epLG=enF=4IDX=WO02073456DB=EPODOCQPN=WO02073456 or here: http://snipurl.com/atol Click on the tabs at the top to see the details of the patent claims. The details of the CR Group application for METHOD AND SYSTEM FOR SECURE INFORMATION can be found here: http://v3.espacenet.com/textdoc?DB=EPODOCIDX=WO02073455F=0 or here: http://snipurl.com/ator The filing dates for both are 14 march 2002, with earliest priority dates of 14 March 2001. Just to whet your appetite, here is Claim 1 of the Pharmacy Guild application: CLAIMS : 1. A method for a health care provider to obtain personal health data relating to a consumer, the method comprising the steps of : the consumer causing personal health data to be stored in a secure repository, said repository requiring authentication of the consumer's identity before the consumer is provided access to the repository; the consumer selecting items of personal health data to share and identifying a health care provider, or class of health care providers, to whom access will be provided for those items of personal health data; a health care provider providing authentication of their identity to the consumer's secure repository and being provided access to those items of personal health data of the consumer for which the health care provider has been identified for sharing; the health care provider using the personal health data of the consumer to determine health care advice or the provision of a health care service for the consumer; and the health care provider recording details of the consultation and the advice or service provided to the consumer in the secure repository of health data of the consumer. If this patent issues, we (or our govts) may find ourselves having to pay royalties to the Pharmacy Guild of Australia to use any EHR applications which meet this description, or having to challenge the patent in court (expensive). Hence there is value in demolishing it with prior art in the application stage - assuming that it survives the examination phase (which it shouldn't, but as we know, the US patent office seems willing to approve a patent for just about anything, no matter how obvious or well-known the idea is, and the Australian patent office managed to issue an innovation patent for the wheel a few years ago...true!). Tim C -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041123/6137d5e1/attachment.asc
Archetype vs. ontology
Hi Sam, The structured langage is not a direct mapping from natural langage. It is a tree of concepts ordered from generic to specific. Example (sorry if I don't use the proper medical terms in english) : polyp -- location left colon -- size 3 mm -- aspect pedonculated This tree means that you have found a pedonculated polyp whose size is 3 mm in the left colon polyp, location, left colon, size, mm, aspect, pedonculated are concepts taken from the ontology If you want to make a natural langage sentence out of the tree, you will have to put it in a grammatical generator if order to put all its parts at the right place in a sentence. Building a generic model for this polyp description tree is absolutely the same work as making an Archetype in openEHR, except that you directly build the Archetype with semantical concepts instead of abstract information mapped to terminologies. You can keep some mappings if you want to put automatic classification at work (for example, this polyp can be classified in ICD) but this mapping is no longer a semantisation concept. The ontology is a genuine component, and each time you put one of its term in a tree, you automatically get a bunch of inherited properties, for translation purposes, for example. Cheers, Philippe Sam Heard wrote: Philippe Thank you for this...very informative and I am starting to see how we are converging with your work. I believe that the 'structured terminology' - fils guide down from the archetype nodes - is an important part - SNOMED are trying to address it generically (ie without archetypes) - I doubt this is possible in one language - and it is certainly not in other languages. From my experience with health one, French is particularly suited to the approach that you are taking as qualifying terms (such as adjectives) tend to follow their nouns and the subject, verb, object structure is usual in sentence. I know that moving to English - where qualifiers precede, that such an approach has to be more sophisticated - and in other languages it is far more complex. What is called for is getting to grips with some key archetypes for interoperability - from a range of stakeholders - and then really having a close look at where more complex terminology is sought. One place I have no doubt it is required is in anatomyhow you describe the location of a lesion or mass. Another is the characteristics of a mass or lesion. The high level 'smarts' you are talking about are impressive - and I do not know about this end of things. Cheers, Sam Hi Thomas, The very word we are talking about here is Knowledge management. Archetype and ontology are some (very strategic) components, but are not the whole thing. From my point of view, Knowledge management is a superset of (at least) 2 concepts : artificial intelligence (AI) and smart data management. An example of smart data management is the ability, when you expect a document of 'A' type and that a document of 'B' type arrives, to check if 'A' -is a- 'B' or 'B'-contains-'A', in order to close the goal get a A. So, Knowledge management doesn't only mean expert systems or smart agents, but a system that is globally aware of what it manages. In Odyssee, the ontology is the very kernel of the systems, since it is the langage used to tell the patient health journey, but also to represent the internal knowledge. The AI components are structured around a Blackboard (we started from Stanford's BBK, now largely adapted) that federates smart agents. The smart data management components are everywhere else, for example in the data model and interfaces management. This (somewhat long) introduction to tell that, in the way we use it, Archetypes are data model elements and Fils guides are interface elements of the smart data management category. A Fil guide is a multi-purpose information element aimed at answering the question what can I do now ? for something/someone that is somewhere in a tree (multi-purpose isn't it ;o)). So a Fil guide is made of two parts : a path (in the form colonoscopy/description/polyp or colonsocopy/*/polyp or */polyp) and a content (currently in the form of a list of ontology concepts that can allow to bring the description one step further, but it can be anything else - say an html page or a function pointer). When you describe something in the medical field, if there is a genuine gold standard description, you have to use a deterministic approach, since the user has to be compliant to the standard. This description becomes part of the information system reference model through an Archetype. And the instanciated data remember the mold (Archetype) they come from. But in most cases, there is just a fuzzy expertise, and you can just say something like being where you are, an expert would keep on the description that way : it is tipically what a
Archetype vs. ontology
Philippe, Sam et Al : Seeking clarification .. Is it true to say : the real distinction between an Archetype and an Ontology is that - the role of an Archetype (item) is to provide contextual constraints the role of an Ontology (item) is to provide conceptual constraints an Ontology (item) concept can be applied as an Archetype (item) constraint an Ontology item must have object oriented properties e.g. it is composed an Archetype item must have data (info) properties e.g. it has a type a Set of Archetype items (whether or not linked to a template) may have info properties that are the equivalent of a particular Ontology (but not explicitly asserted) carl quote who=Philippe AMELINE Hi Sam, The structured langage is not a direct mapping from natural langage. It is a tree of concepts ordered from generic to specific. Example (sorry if I don't use the proper medical terms in english) : polyp -- location left colon -- size 3 mm -- aspect pedonculated This tree means that you have found a pedonculated polyp whose size is 3 mm in the left colon polyp, location, left colon, size, mm, aspect, pedonculated are concepts taken from the ontology If you want to make a natural langage sentence out of the tree, you will have to put it in a grammatical generator if order to put all its parts at the right place in a sentence. Building a generic model for this polyp description tree is absolutely the same work as making an Archetype in openEHR, except that you directly build the Archetype with semantical concepts instead of abstract information mapped to terminologies. You can keep some mappings if you want to put automatic classification at work (for example, this polyp can be classified in ICD) but this mapping is no longer a semantisation concept. The ontology is a genuine component, and each time you put one of its term in a tree, you automatically get a bunch of inherited properties, for translation purposes, for example. Cheers, Philippe Sam Heard wrote: Philippe Thank you for this...very informative and I am starting to see how we are converging with your work. I believe that the 'structured terminology' - fils guide down from the archetype nodes - is an important part - SNOMED are trying to address it generically (ie without archetypes) - I doubt this is possible in one language - and it is certainly not in other languages. From my experience with health one, French is particularly suited to the approach that you are taking as qualifying terms (such as adjectives) tend to follow their nouns and the subject, verb, object structure is usual in sentence. I know that moving to English - where qualifiers precede, that such an approach has to be more sophisticated - and in other languages it is far more complex. What is called for is getting to grips with some key archetypes for interoperability - from a range of stakeholders - and then really having a close look at where more complex terminology is sought. One place I have no doubt it is required is in anatomyhow you describe the location of a lesion or mass. Another is the characteristics of a mass or lesion. The high level 'smarts' you are talking about are impressive - and I do not know about this end of things. Cheers, Sam Hi Thomas, The very word we are talking about here is Knowledge management. Archetype and ontology are some (very strategic) components, but are not the whole thing. From my point of view, Knowledge management is a superset of (at least) 2 concepts : artificial intelligence (AI) and smart data management. An example of smart data management is the ability, when you expect a document of 'A' type and that a document of 'B' type arrives, to check if 'A' -is a- 'B' or 'B'-contains-'A', in order to close the goal get a A. So, Knowledge management doesn't only mean expert systems or smart agents, but a system that is globally aware of what it manages. In Odyssee, the ontology is the very kernel of the systems, since it is the langage used to tell the patient health journey, but also to represent the internal knowledge. The AI components are structured around a Blackboard (we started from Stanford's BBK, now largely adapted) that federates smart agents. The smart data management components are everywhere else, for example in the data model and interfaces management. This (somewhat long) introduction to tell that, in the way we use it, Archetypes are data model elements and Fils guides are interface elements of the smart data management category. A Fil guide is a multi-purpose information element aimed at answering the question what can I do now ? for something/someone that is somewhere in a tree (multi-purpose isn't it ;o)). So a Fil guide is made of two parts : a path (in the form colonoscopy/description/polyp or colonsocopy/*/polyp or */polyp) and a content (currently in the form of a list of ontology concepts that
Archetype vs. ontology
Hi, An other property of the Archetype is that it is derived from a a model that models the structure via which information is stored/represented/ retrieved in a system. GF -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 23 Nov 2004, at 17:26, Carl Mattocks wrote: Philippe, Sam et Al : Seeking clarification .. Is it true to say : the real distinction between an Archetype and an Ontology is that - the role of an Archetype (item) is to provide contextual constraints the role of an Ontology (item) is to provide conceptual constraints an Ontology (item) concept can be applied as an Archetype (item) constraint an Ontology item must have object oriented properties e.g. it is composed an Archetype item must have data (info) properties e.g. it has a type a Set of Archetype items (whether or not linked to a template) may have info properties that are the equivalent of a particular Ontology (but not explicitly asserted) carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1107 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041123/24b94efb/attachment.bin
