Archetype vs. ontology
HI GF : Do you agree that this can also be true for an Ontology . carl quote who=Gerard Freriks 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 -- Carl Mattocks co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC co-Chair OASIS Business Centric Methodology TC CEO CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart Compendiums (AOL) IM CarlCHECKMi - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype vs. ontology
Hi, I can buy this. But have you ever seen the UML model behind ICD, ICPC, or even SNOMED? I know I;ve seen the one behind the CEN/TC251 EN 13606 where a kernel model (UML) representing a generic document will be populated by Archetypes that are derived from a Archetype model (UML). Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 24 Nov 2004, at 17:29, Carl Mattocks wrote: HI GF : Do you agree that this can also be true for an Ontology . carl quote who=Gerard Freriks 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 -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 863 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041124/385a9fad/attachment.bin
Archetype vs. ontology
Gerard : Good point. I would like to see the UML models .. does anyone have them to share ? carl quote who=Gerard Freriks Hi, I can buy this. But have you ever seen the UML model behind ICD, ICPC, or even SNOMED? I know I;ve seen the one behind the CEN/TC251 EN 13606 where a kernel model (UML) representing a generic document will be populated by Archetypes that are derived from a Archetype model (UML). Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 24 Nov 2004, at 17:29, Carl Mattocks wrote: HI GF : Do you agree that this can also be true for an Ontology . carl quote who=Gerard Freriks 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 -- Carl Mattocks co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC co-Chair OASIS Business Centric Methodology TC CEO CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart Compendiums (AOL) IM CarlCHECKMi - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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
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
Archetype vs. ontology
b.cohen wrote: I was responding to the original message from Chris Feahr, to which Gerard had already responded, which was indeed calling for a universal ontology. But the issue here is what to do about enterprises that have to live with ontological variety. If standards can't make the problem go away, what tools can make it tolerable? Better still, how can these tools assist, rather than impede, strategic development and sustainability of the heathcare enterprise in the face of increasingly 'asymmetric demand' from its clients: the patients, like you and me, who desire specific consideration of their individual situations. These enterprises, like all others, are exposed to three classes of risk: performance risk - that the component capabilities on which one relies do not behave in the way that one expected them to; composition risk - that components that are well-behaved in isolation do not interoperate in the way one expected them to; and maybe I would call this integration risk implementation risk - that the product or service delivered by a well-constructed system of interoperating components does not satisfy the client in her context of use. Do you mean that it just doesn't satisfy requirements, or that it doesn't take care of local specificities properly (which is a non-trivial problem in clinical software)? It is possible to construct a model that reveals the degree to which an enterprise is exposed to all these risks. Such a model is an invaluable tool for strategic development but also, as an side-effect, generates an ontology that most accurately describes the distinctions that are necessary to the enterprise's operational and regulatory behaviour. This is, in effect, the 'data model' on which the enterprise's IT system must be based if it is to provide adequate, and meaningful, support to the enterprise's actors (e.g. clinicians and administrators), clients (e.g. patients), suppliers (e.g. pharmaceuticals) and regulators (e.g. government). In the openEHR way of thinking, such a model would be the 2 layers of models - the reference model (in UML) and the clinical layer, comprised of archetypes, computerised guidelines, enterprise business rules and other domain-level / enterprise knowledge resources. Our point of view is that you don't want to put much into the UML which becomes software and databses, because it produces long-term unmaintainable systems - this has been the big problem in the history of information systems engineering to date (with some notable exceptions). Clearly, a major part of this model is concerned with the 'healthcare record' and much of that is ontologically (quasi-)universal, in form of (say, Western) medical science. But much of the healthcare record is also ontologically specific to the enterprise, particlarly that concerned with composition and implementation risks (e.g. referral pathways, inter-service relations, chronic care). The openEHR EHR model tries to be at a point of generality where it reflects 'science' - i.e. things like Observations, Evaluations (opinions) etc, also captures auditing information, but doesn't really any clinical elements in it as such - these are all in the archetypes, and in future artifacts like workflow rulebases or whatever. In order to be of value, all international standards in this area must demonstrate that they do not prevent the individual enterprise from 'orchestrating' the systems and services at its disposal into the variety of 'systems of systems' that it considers requisite for the asymmetric demand that it faces. Agree completely with that - which means: a) the reference models are domain-invariant - i.e. the concepts expressed in the base models mean the same thing right across the domain, to all users (e.g. an Observation as modelled means the same thing to eveyone, and everyone agrees with the model, as far as it goes) b) there must be flexible, systematic ways for enterprises to define their own screens, forms, 'information shapes', rules etc - this capability needs to be built right into the infrastructure. I have yet to see a demonstration of this property, or even a desire to meet it, from any healthcare standards body. well, I don't know if you would consider it an endorsement of such a point of view, but CEN TC/251 recently voted to include the Archetype Definition Language in part 2 of its revised EN13606 standard, and has recognised the need for an archetyping approach for probably 2 years now. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
