CEN and HL7 methods and archetypes
Dear William, You write: > I believe it is very hard to accept the dogmatic approach of Gerard > Freriks once again :-( My simple dictionary reads: dogma |?d?gm?| |?d?gm?| |?d?gm?| noun a principle or set of principles laid down by an authority as incontrovertibly true : the Christian dogma of the Trinity | the rejection of political dogma. ORIGIN mid 16th cent.: via late Latin from Greek dogma ?opinion,? from dokein ?seem good, think.? By the way, I like the original old meaning of Dogma better. When we can agree on the modern meaning of Dogma, I will not object either:-) You find it hard to accept that something is 'inconvertibly true', is the way I interpret your quoted sentence. When you will choose to disagree with me then you must provide arguments and try to convert me and the readers. My list of positions and arguments, open for debate and written or presented or discussed several times at various occasions, are: Harmonisation: CEN and HL7 Harmonisation between CEN EN13606 EHRcom and HL7v2 is not taking place. Harmonisation between CEN EN13606 plus its Archetypes and HL7v3 message artefacts is not possible. Harmonisation between CEN and HL7 on the level of Archetypes as performed by humans using the OpenEHR Archetype Editor Tool (and therefor EHRcom part 2) is possible. This is very much needed and taking place. Harmonisation between CEN EN13606 EHRcom and HL7v3 work on the Clinical Statement might become possible and has to be proven. It depends on the way this HL7 Clinical statement is expressed; e.g. what Reference Model will be used. CEN/tc251 EN13606 EHRcom and HL7v3 mappings In general, mappings are possible, only, when both worlds share one or more meta-models that guide the transformation/mapping. At the Archetype level, when archetypes are presented to humans, only humans are able to translate in the absence of a formal complete and accepted Ontology. (This situation is what you write in your last sentence. Humans easily are able to translate clinical models expressed via HL7v3 to CEN Archetypes and vice versa) At the level of Archetypes, as expressed by a formalism describing constraints on a Reference Model, transformation is possible when both Reference Models can be mapped. Part 1 of the CEN/tc251 EN13606 is not the same model as the HL7v3 RIM. A mapping between these two is not possible. They are certainly NOT the same. Only a computational mapping might perhaps be possible with some effort between Archetypes on the basis of CEN/tc251 EN13606 part 1 and a HL7 R-MIM expressing EN 13606 part 1. By the nature of the process these meta-models can be mapped, partially. Extra models are needed to deal with all possible mappings of structural HL7v3 vocabularies and elements in the CEN Reference Model (part 1) and types of CEN archetypes (part 3) Requirements based standards CEN/tc251 EHRcom (and OpenEHR) is the only EHR related standard, I know, that is meticulously based on a well researched set of requirements for the EHR as published by ISO. Proof of Concept: working software CEN/tc251 EN13606 EHRcom is based on more than 15 years of research in Europe and Australia. Various Proof of Concept studies have been performed. The most recent one is OpenEHR, its open source specifications and published functional software. Plus the proprietary software produced by OceanInformatics from Australia based on CEN/tc251 EN13606 EHRcom and OpenEHR. Scalability Message paradigm versus the Archetype (Two Level Model Paradigm) Any solution derived from the RIM and expressed as a message using the HL7v3 MDF method will NEVER scale. Since each vendor has to write specific software for each artefact and version of it. Each clinical domain will consist of many messages. There are many clinical domains. Any solution based on the CEN/tc251 EN13606 is scalable by the fact that only one schema based on part 1 has to be implemented by the vendor, ever. Any CEN archetype or set of archetypes assembled in a Template can be read, stored, retrieved, presented and exchanged without the need to write any software by the vendor. Therefor EN13606 and OpenEHR provide build-in scalability. Decision support Systems that are conformant to EN13606 EHRcom have as an additional feature that software providing decision support is able to query ALL the data stored since all data in conformant systems is presented using one uniform method without any extra programming. Plug-and-play decision support becomes possible. Plug-and-play CEN/tc251 EN13606 EHRcom makes real Plug-and-Play semantic interoperability possible. Status EN13606 EHRcom not only is becoming an European Standard and a National Standard in its Member States, but is on its way to become an International ISO standard as well. Role of European standards European standarisation is subject to various European Directives. European standards play a specif
Antw: CEN and HL7 methods and archetypes
In een bericht met de datum 16-10-2006 13:47:24 West-Europa (zomertijd), schrijft gfrer at luna.nl: I will try to respond: > Dear William, > > You write: > > >> I believe it is very hard to accept the dogmatic approach of Gerard >> > My simple dictionary reads: > ht: 0px; margin-bottom: 0px; margin-left: 0px; ">dogma |'d?gm?| |?d?gm?| > |?d?gm?| > noun > a principle or set of principles laid down by an authority as > incontrovertibly true : the Christian dogma of the Trinity | the rejection of > political > dogma. > face="Baskerville" size="4">ORIGIN mid 16th cent.: via late Latin from Greek > dogma ?opinion,? from dokein ?seem good, think.? > > > By the way, I like the original old meaning of Dogma better.When we can > agree on the modern meaning of Dogma, I will not object either:-) > You find it hard to accept that something is 'inconvertibly true', is the > way I interpret your quoted sentence. > When you will choose to disagree with me then you must provide arguments and > try to convert me and the readers. > > I disagree with you on the premisse that ONLY openEHR provides the solution of semantic interoperability. M > y list of positions and arguments, open for debate and written or presented > or discussed several times at various occasions, are: > I will answer each of them with a brief comment. > > Harmonisation: CEN and HL7 > Harmonisation between CEN EN13606 EHRcom and HL7v2 is not taking place. Fine, I do not know anyone with an interest. I have not looked into v2 and cannot argue this case. H > armonisation between CEN EN13606 plus its Archetypes and HL7v3 message > artefacts is not possible. Disagree, it is taking place. H > armonisation between CEN and HL7 on the level of Archetypes as performed by > humans using the OpenEHR Archetype Editor Tool (and therefor EHRcom part 2) > is possible. This is very much needed and taking place. Agree. H > armonisation between CEN EN13606 EHRcom and HL7v3 work on the Clinical > Statement might become possible and has to be proven. It depends on the way > this > HL7 Clinical statement is expressed; e.g. what Reference Model will be used. > > This is ongoing work, and although called 'scary' not impossible. C > EN/tc251 EN13606 EHRcom and HL7v3 mappings > > In general, mappings are possible, only, when both worlds share one or more > meta-models that guide the transformation/mapping. Agree, this is the clinical specifation or ontology of the content. A > t the Archetype level, when archetypes are presented to humans, only humans > are able to translate in the absence of a formal complete and accepted > Ontology. Agree as long as this ontology is absent, hence proposals to develop OWL based ontologies that include the clinical, vocab and information model constraints to make it available. Ongoing work is promising. ( > This situation is what you write in your last sentence. Humans easily are > able to translate clinical models expressed via HL7v3 to CEN Archetypes and > vice versa) > Yes, for humans it it easy. I refer to the possibilities to enter clinical stuf in the archetype editor and spit it out in HL7 v3 XML from there. > > At the level of Archetypes, as expressed by a formalism describing > constraints on a Reference Model, transformation is possible when both > Reference > Models can be mapped. Yes. P > art 1 of the CEN/tc251 EN13606 is not the same model as the HL7v3 RIM. A > mapping between these two is not possible. They are certainly NOT the same. > They are definitely not the same, they are on different levels of abstraction. 13606 high generic and abstract, RIM more concrete on health care relevant information classes. > > Only a computational mapping might perhaps be possible with some effort > between Archetypes on the basis of CEN/tc251 EN13606 part 1 and a HL7 R-MIM > expressing EN 13606 part 1. Yes, and is the focus of ongoing harmonization work. By the nature of the process these meta-models can be mapped, partially. Extra models are needed to deal with all possible mappings of structural > HL7v3 vocabularies and elements in the CEN Reference Model (part 1) and > types of CEN archetypes (part 3) > > Of course, you bring in more complexity, you need more mappings. R > equirements based standards > CEN/tc251 EHRcom (and OpenEHR) is the only EHR related standard, I know, > that is meticulously based on a well researched set of requirements for the > EHR > as published by ISO. > > Disagree, I still have to find the research for the EHRcom. What ISO standard are you referring to? P > roof of Concept: working software > CEN/tc251 EN13606 EHRcom is based on more than 15 years of research in > Europe and Australia. Various Proof of Concept studies have been performed. > The > most recent one is OpenEHR, its open source specifications and published > functional software. Plus the proprietary software produced b
