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 by > OceanInformatics > from Australia based on CEN/tc251 EN13606 EHRcom and OpenEHR. > Beyond the Proof of concept, is there any implementation actually working in practice? No there is not after 15 years. The link between the 13606 and research is not present. In the whole standard there is no reference at all to the research literature. > > 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. Disagree: the NEVER cannot be substantiated at this stage. This is what I would call dogmatic, however a belief in something untrue which is wrongly held for being 'incontrovertibly true' 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. Agree, and all domains often have many data items in common, and one message can hold many different data items without changing the message structure perse. In fact the smartness of 13606 approach is used in the message as well: you specify the template (as similar to archetype) and you can include 1..many of these in the same message. In the CDA this is the level 3 approach. A > ny 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. WG: basically this is the same for the care provision message: if you want to send clinical information (clinical statements), you only have to implement one message specification only and one way of getting the relevant data of choice from the database of the EHR and put them in the message according to the template (clinical statement) specification. Thus the scalability is high: ranging from 1 data item to multi million data items in one message (in principle, multi million would not be practically for both an EHR and a message). A > ny 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. > This is only valid for those software that have included this approach. It is not different from building in the care provision model of HL7 v3 on both sides. An addition with HL7 v3 message: it is possible to ship an XML stylesheet so that a receiving system without HL7 v3 implemented is still able to show the data content readable to the end user. > > 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. > Exactly a good approach. We have the same kind of specification available in HL7 v3. The query can be specified based on the care provision (or other message spec) and the HL7 v3 templates (care information models). Of course the DSS will need a correct formalism to express the decisions. As with HL7 v3, in OpenEHR 13606 the DSS formalism is not explicit. > > Plug-and-play > CEN/tc251 EN13606 EHRcom makes real Plug-and-Play semantic interoperability > possible. > This works if both systems have the built in capability to read this stuff. It is possible to do the same in HL7 v3, once both systems have this. E.g. the HL7 v3 Care provision based EHR system in Nijmegen: if it does get a HL7 v3 template which is not available in the system yet, the system automatically generates a screen design and storage pattern in the database. It is all XML based. > > <B>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. > As are parts of HL7 v3. > > Role of European standards > European standarisation is subject to various European Directives. No, European Directives can refer to particular standards. E > uropean standards play a specific role in legislation and procurement in > all its Member States. No, Member states can choose to refer to Eu standards in their legislation and procurement. T > he European "Stand-still rule" ensures that in Europe conflicting standards > are impossible. > This is goobly gook to me. I see thousands of conflicting standards in Europe. Try to travel around in Europe and plug in the power plug of your laptop. Or travel in Europe with a care and pay no attention to the side of the road you have to drive. Or again travel around and plug in a modem or standard phone: all plugs differ Or go around with the Euro and find out that UK, Denmark, Switzerland and others use something else than a Euro. Luckily we have adapters that help us transforming :-) > > Greetings, > > > > > Gerard > > Thanks for bringing it partly back to the level of arguments instead of NEVER and ONLY. Captain Picard said: things are impossible until they no longer are. William -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/d84980e4/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
