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 specific role in legislation and procurement in all its Member States. The European "Stand-still rule" ensures that in Europe conflicting standards are impossible. Greetings, Gerard -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 16-okt-2006, at 8:37, Williamtfgoossen at cs.com wrote: > I believe it is very hard to accept the dogmatic approach of Gerard > Freriks once again :-( > > I thought we would have stopped, working on the implementable > harmonization artifacts. It has been proven to work with HL7 v3 > messages. > > For clinical content it does not matter at all in which technical > formalism or spec it is operationalised. A clinical concept sorting > out takes 2 weeks, transforming from HL7 to Open EHR takes 15 minutes. > > William Goossen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/7095b57c/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
