Antw: Re: Antw: Re: AW: HL7 templates/archetypes
Hello all, While I recognize the importance of analyzing the differences between openEHR and HL7, I feel that we are wasting our energies as a community in this ongoing debate. I think that our health IT visions are more important than how exactly they are enabled by the various standard specifications. Let me illustrate this argument through my HL7 Clinical Genomics work. The essence of that effort in my mind is the vision of encapsulate bubble-up and the way it is realized through HL7 is less important. This vision is about enabling personalized medicine where care is given to the patient based among other thing on his/her genetic profile as well as individual variations. Many innovative genetic labs nowadays provide advanced genetic testing like gene expression panels. They run proprietary (sometime patented) algorithms to calculate the raw genomic data and come up with the result. Typically this result is minimal like a single number representing for example the probability of tumor reoccurrence (e.g., the test OncotypeDX). The encapsulate bubble-up vision is about having the genetic lab send the final result *along* with the raw data to be encapsulated in the patient EHR. In this way, when new discoveries become available (and this is a rapid evolving field), the raw data could be parsed again and new results might be bubbled-up from the same raw data. Now, back to the data models argument, in my mind it's less important how this vision is enabled. If I had the bandwidth - I guess that I could have modeled it with openEHR as well. What matters in my mind is to have a deep discussion on the vision itself - for example - do you agree with the encapsulation of raw genomic data in the patient EHR? Obviously, it could be that one model is better than the other for specific uses and perhaps the best-of-breed approach (rather than harmonization...) is needed when we come to realize our visions. Just my 2 cents... Thanks, Amnon. -- Amnon Shabo (Shvo), PhD Co-Chair Facilitator, HL7 Clinical Genomics SIG Co-Editor, CDA R2 (Clinical Document Architecture) Co-Editor, CCD (CDA-based CCR-Continuity of Care Record) Haifa Healthcare Life Sciences Standards Practice http://www.haifa.il.ibm.com/projects/software/hlss/index.html IBM Research Lab in Haifa Office: +972-4-8296358 Mobile: +972-54-4714070 Williamtfgoossen@ cs.com Sent by: To openehr-technical openehr-technical at openehr.org -bounces at openehr. cc org Subject Antw: Re: Antw: Re: AW: HL7 16/10/06 21:19templates/archetypes Please respond to For openEHR technical discussions openehr-technica l at openehr.org In een bericht met de datum 16-10-2006 13:34:27 West-Europa (zomertijd), schrijft gfrer at luna.nl: William, Since when is it a lie when one states his opinion? Read my other e-mail where I state more opinions and provide some arguments. Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of RD and real implementations. EN13606 EHRcom is factual NOT in its infancy, as you know. Gerard The lie is in the ONLY Simple: OpenEHR works and HL7 v3 works. ONLY is not an argument, it is just an expression of beliefs. William ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: AW: HL7 templates/archetypes
Williamtfgoossen at cs.com schreef: Good Point Ed, Until now the list of actual OpenEHR implementation I have actually seen working is 0 William, I told before on this list, English is not even my second language, but I do what I can to be understandable. --- Now to your Good Point, Ed (the famous G.P.E.) I don't think this is fair, I explain why I feel like that. Release 1.0 is just released this year, I am working with a group of people on a commercially implementation. At this moment (for business-reasons) I cannot go into further details, but we will within a few months. If you need an implementation, contact me, I will lead you further, I can get you to an implementation within a few months.. If you only want information, please wait for more press releases. The concepts are very new, the learning curve is steep, So don't expect a lot of implementations in short time, but, in my experience with complex software like this, there is a point of critical mass after things will really go fast. Also, I know about other implementations in beta phase. When people involved are willing to provide information on this, you will learn about it from them. I worked on HL7 implementations, I cannot say that it is a pleasure. I still work on code to create the messages Nictiz defined. They are very complicated, a lot of its complexity cannot be used at all because most of the providing GP-applications do not support that kind of data-constellations. So lots of definitions just exist in vain, as a kind of hobby for the designers. Also, I guess that the dutch GP-systems will need maybe three to five years to get an error-free partially implementation. When you see how long they needed to implement the much more simplier Edifact (medeur) message from the Erasmus university. They started at that time with 1500 errors in each Edifact message. Stupid errors, like sexe: Islam, religion: O-neg Blood type: male. They had lots of problems to distinguish the + and ' and other characters which have special meanings in Edifact. It took more then three years to let them prouce/implement edifact messages of an acceptable level of errors. I am not a genius, but I wrote a Medeur testing tool, a medeur-readable report generator and other medeur tooling in a few months, on my own, they are still in use.. Now they have to build a system for HL7, which is much much much more complicated as Edifact. (Medeur). I do not expect them to succeed to implement the HL7 v3 message on an acceptable level error-free level before 2010. Say, it will be 9 years after Nictiz started defining the PRICA-DMIM (primary care) (which also took 4 years and 50 million Euro, but being fair, it was not only the DMIM, also the SOAP headers and some more things had to be done. Maybe there were other DMIM's too they defined. I know one more, BEMO (medications)). So, At this moment there is no application in my knowledge which implements a trustworthy HL7 v3 Prica message-generation or -interpretation. On the other side I am very confident that before 2010 there will be also several systems in the Netherlands running OpenEhr. --- Politicians and people with not much knowledge of what is really happening keep on pointing to the Proof Of Concept which took place last summer, and try to gain some good hope from that. Many people have a wrong idea of what this PoF really was about (in GP-communications). The PoF did not test any GP System. It was really only a network-service-test, not a GP-information system-test. I know of a company which name I will not mention, which received, really a lot of money (was it 100.000 Euro) to receive a request for a HL7 message, and in reply send a message, which was in every detail before prepared (a simple Perl script of fifty lines could do the job). No life GP-information system was involved in this test, it was only an network SOAP test. OK, the SOAP headers are OK, now the GP systems. These are things you don't read in the newspapers, you don't hear talk about in management-meetings. Thanks Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/b35dd157/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes
Yes Bert, I agree with many of the problems. My point was: today I cannot go to a live implementation of a OpenEHR system. You support this. Today I can point you at least to 3 working systems that have HL7 v3 Care Provision as the founding principle and they run, although still in test environment. I do know one system in New Zealand based on HL7 v3 RIM which is fully operational. Of course we need to be patient. It is a difficult task! Good luck and yes I look forward to seeing it work and consider myself on the list of invitees to see the formal release. With respect to the dinosaur systems for GPs, stemming from the 80 ies, I agree, these have difficulties with HL7 v3, and they would have similar troubles with OpenEHR archetypes. My point is that you need to change to new desigs to make it work. Thanks for the feedback -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061017/5e5f4135/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes
William, I think a working system is not the only criteria to be met. As far as I understand, all the (formal) specification we have in HL7v3, CEN and other organisation have the goal to achieve open, transparent and (relative) easy maintainable care information systems. As far as I heard so far there are singe HL7 v3 systems working, but without any collaboration with other HLv3 systems... I haven't hear about working openEHR systems in this way either, but from system engineering point of view this is a matter of time. In other business sectors the openEHR engineering's method has been proven to work. Roel Stap From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: dinsdag 17 oktober 2006 8:16 To: openehr-technical at openehr.org Subject: Antw: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes Yes Bert, I agree with many of the problems. My point was: today I cannot go to a live implementation of a OpenEHR system. You support this. Today I can point you at least to 3 working systems that have HL7 v3 Care Provision as the founding principle and they run, although still in test environment. I do know one system in New Zealand based on HL7 v3 RIM which is fully operational. Of course we need to be patient. It is a difficult task! Good luck and yes I look forward to seeing it work and consider myself on the list of invitees to see the formal release. With respect to the dinosaur systems for GPs, stemming from the 80 ies, I agree, these have difficulties with HL7 v3, and they would have similar troubles with OpenEHR archetypes. My point is that you need to change to new desigs to make it work. Thanks for the feedback This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061017/21dc7203/attachment.html -- next part -- A non-text attachment was scrubbed... Name: Stap, R.E..vcf Type: text/x-vcard Size: 248 bytes Desc: Stap, R.E..vcf URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061017/21dc7203/attachment.vcf -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: AW: HL7 templates/archetypes
William E Hammond wrote: You assume the worst of me. It seems that looking at actual implementations of both 13606 and V3 will provide excellent experience data for both groups. I know V3 implementations, and did not know many 13606 implementations, altho I do know one system that has several implementations. So Bert, I would like your help. Ed, for some (unfortunately incomplete) information on openEHR implementations see http://www.openehr.org/projects/t_projects.htm There are another 4 or so systems that I directly know about based on openEHR. It is early days yet for everyone, but the implementation experience looks good at this point - archetype based templates, forms and queries are all starting to work properly. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes
Williamtfgoossen at cs.com wrote: Yes Bert, I agree with many of the problems. My point was: today I cannot go to a live implementation of a OpenEHR system. You support this. actually, you can. We'll give you the URL of the webservice interface whenever you want it;-) - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: AW: HL7 templates/archetypes
In een bericht met de datum 15-10-2006 23:54:28 West-Europa (zomertijd), schrijft gfrer at luna.nl: What might be possible in a way, is to transform from CEN to HL7 and back again when a R-MIM is used that is an agreed mapping of the CEN/tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the CEN EN13606 standard will contain such an R-MIM, is the expectation. Why is such an undertaking of mapping between EN13606 and HL7v3 interesting? Yes, I say this transformation is possible. Why interesting? We face multiple approaches and since sorting out the clinical stuf is more costly than transformations, we face a large reuse of models and reduction of overall development costs. Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible. Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support. Gerard, are we now in the stage that we have to ly? I agree that both implementations are still in infancy, but there is no way you can substantiate this. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/4df5ea33/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: AW: HL7 templates/archetypes
Williamtfgoossen at cs.com wrote: In een bericht met de datum 15-10-2006 23:54:28 West-Europa (zomertijd), schrijft gfrer at luna.nl: What might be possible in a way, is to transform from CEN to HL7 and back again when a R-MIM is used that is an agreed mapping of the CEN/tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the CEN EN13606 standard will contain such an R-MIM, is the expectation. Why is such an undertaking of mapping between EN13606 and HL7v3 interesting? Yes, I say this transformation is possible. Why interesting? We face multiple approaches and since sorting out the clinical stuf is more costly than transformations, we face a large reuse of models and reduction of overall development costs. William, one element I think are you underestimating the importance of is the dangers of a) excessive data transformation and b) bugs in software due to loose and/or over-complicated standards specifications. Either can cause patient safety issues, and ultimately injury or death; they already have, and will continue to do so. Data transformations are absolutely to be avoided as much as possible; they are however of course not totally avoidable. The main factor that aggravates the problems of data transformation is the semantic gap between the relevant formalisms. So while it is clearly good economics to re-use semantic models, the economic costs of data transformations, particularly poorly specified ones should not be ignored; they are the costs most related to patient safety in the health information infrastructure. I used to work in the control system industry, where the software controlled power stations, trains, gas pipelines and so on - places where bugs could cause injury, death and massive capital losses. We made sure there were no bugs in the software by clean clear design, and heavy use of version control, heavy reviewing, and disciplined unit and system testing. There were no data transformations of the kind I see people casually assuming in the healthcare environment. To be honest, the way I hear people speak about how the software will transform into this and that form all over the place, as if to suit the whims of modellers, standards politics etc, and with little regard for the consequences to patients - positively scares me. I hope I never end up in a hospital containing the solutions some people are speaking about today. And the runtime performance costs of transformation cannot be ignored either. Processing just prescription messages for a country of 60m people incurs serious costs of computing hardware and bandwidth. Complexity and excessive data transformation might keep some people amused and employed, but in my view, both are the enemies of safe computing, and in health, of patient safety. They both have to be minimised. openEHR is designed from the outset to do this, and to provide the needed semantics for health computing. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: AW: HL7 templates/archetypes
William, Since when is it a lie when one states his opinion? Read my other e-mail where I state more opinions and provide some arguments. Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of RD and real implementations. EN13606 EHRcom is factual NOT in its infancy, as you know. 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:40, Williamtfgoossen at cs.com wrote: Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible. Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support. Gerard, are we now in the stage that we have to ly? I agree that both implementations are still in infancy, but there is no way you can substantiate this. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/9b66ef38/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: AW: HL7 templates/archetypes
Gerard, It would help us to have the names and contact info for those implementations over many years. As you know there are also CDA and HL7 v3 implementations. I am trying to put together that list. Thank you for your support of these discussion. Ed |-+- | | Gerard Freriks| | | gfrer at luna.nl | | | Sent by: | | | openehr-technical-bounces@| | | openehr.org | | | | | | | | | 10/16/2006 07:31 AM | | | Please respond to For | | | openEHR technical | | | discussions | | | | |-+- --| | | | To: For openEHR technical discussions openehr-technical at openehr.org| | cc: | | Subject: Re: Antw: Re: AW: HL7 templates/archetypes | --| William, Since when is it a lie when one states his opinion? Read my other e-mail where I state more opinions and provide some arguments. Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of RD and real implementations. EN13606 EHRcom is factual NOT in its infancy, as you know. 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:40, Williamtfgoossen at cs.com wrote: Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible. Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support. Gerard, are we now in the stage that we have to ly? I agree that both implementations are still in infancy, but there is no way you can substantiate this. William ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: AW: HL7 templates/archetypes
In een bericht met de datum 16-10-2006 12:59:18 West-Europa (zomertijd), schrijft Thomas.Beale at OceanInformatics.biz: Hi Tom, Thanks for bringing in arguments here. I will respond in between the lines. William, one element I think are you underestimating the importance of is the dangers of a) excessive data transformation and b) bugs in software due to loose and/or over-complicated standards specifications. Either can cause patient safety issues, and ultimately injury or death; they already have, and will continue to do so. WG: I agree with excessive and bugs being problematic. That is why I prefer the 'more difficult' HL7 v3 approach currently because it tackles the more complicated approach, and then transformation of the specification! to OpenEHR is simpler and will cause no problems. I talk here about a clearly specified data set, cardinalities, vocab, code, you know the examples. Data transformations are absolutely to be avoided as much as possible; they are however of course not totally avoidable. The main factor that aggravates the problems of data transformation is the semantic gap between the relevant formalisms. WG: that is exactly why we are currently working within HL7 AND OpenEHR groups to come to one specification only and allow from that different implementations. So while it is clearly good economics to re-use semantic models, the economic costs of data transformations, particularly poorly specified ones should not be ignored; they are the costs most related to patient safety in the health information infrastructure. WG: exactly, hence the careful specification of the clinical content, and not datatransformations, but model transformations. I used to work in the control system industry, where the software controlled power stations, trains, gas pipelines and so on - places where bugs could cause injury, death and massive capital losses. We made sure there were no bugs in the software by clean clear design, and heavy use of version control, heavy reviewing, and disciplined unit and system testing. WG: agree with the process here, health care is lacking such scrutiny for software development. casually assuming in the healthcare environment. WG: I agree, I talk about the transformation of the data specification and where possible, the vocabs from one system to the other. There is a publication coming out soon on how to tranform from one classification to the other, where an in depth analysis is necessary. hear people speak about how the software will transform into this and that form all over the place, as if to suit the whims of modellers, standards politics etc, and with little regard for the consequences to patients - positively scares me. I hope I never end up in a hospital containing the solutions some people are speaking about today. WG: again, I agree that any standard specification should be done carefully, and I think that paying the most attention to the clinical definition and careful independent of technology modeling is the way to go here. This would than allow the different technologies to work and allows careful testing whether the content specification is met 100%. And the runtime performance costs of transformation cannot be ignored either. Processing just prescription messages for a country of 60m people incurs serious costs of computing hardware and bandwidth. WG: again, I talk about the transformation of the content specification, not the actual data of 60 M people on a continuous base, that would be ridiculous. However, messaging of the correctly specified data from one system to the other in case there is a need can be done safely in my opinion and experience. Complexity and excessive data transformation might keep some people amused and employed, but in my view, both are the enemies of safe computing, and in health, of patient safety. They both have to be minimised. openEHR is designed from the outset to do this, and to provide the needed semantics for health computing. WG: again: HL7 v3 is designed for safe exchange of carefully defined and standardised data items. Although I agree with your comments with respect to safety etc, I see no difference in meticulously defined standards for message or OpenEHR specification. Especially since on the concrete data item level we work with templates and archetypes in the same way. - thomas beale William Goossen -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/aa681230/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: AW: HL7 templates/archetypes
In een bericht met de datum 16-10-2006 13:34:27 West-Europa (zomertijd), schrijft gfrer at luna.nl: William, Since when is it a lie when one states his opinion? Read my other e-mail where I state more opinions and provide some arguments. Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of RD and real implementations. EN13606 EHRcom is factual NOT in its infancy, as you know. Gerard The lie is in the ONLY Simple: OpenEHR works and HL7 v3 works. ONLY is not an argument, it is just an expression of beliefs. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/7eded48c/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: AW: HL7 templates/archetypes
Good Point Ed, Until now the list of actual OpenEHR implementation I have actually seen working is 0 Reports in the scientific literature I have seen are 0 This is of course because I have not explicitly been looking for it, but I would like to have the 'proof' presented. Is this possible? William Goossen -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/b448babf/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: AW: HL7 templates/archetypes
You assume the worst of me. It seems that looking at actual implementations of both 13606 and V3 will provide excellent experience data for both groups. I know V3 implementations, and did not know many 13606 implementations, altho I do know one system that has several implementations. So Bert, I would like your help. Ed Hammond |-+- | | Bert Verhees | | | bert.verhees at rosa.nl| | | Sent by: | | | openehr-technical-bounces@| | | openehr.org | | | | | | | | | 10/16/2006 05:19 PM | | | Please respond to For | | | openEHR technical | | | discussions | | | | |-+- --| | | | To: For openEHR technical discussions openehr-technical at openehr.org| | cc: | | Subject: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes | --| Williamtfgoossen at cs.com schreef: Good Point Ed, Until now the list of actual OpenEHR implementation I have actually seen working is 0 William, I told before on this list, English is not even my second language, but I do what I can to be understandable. --- Now to your Good Point, Ed (the famous G.P.E.) I don't think this is fair, I explain why I feel like that. Release 1.0 is just released this year, I am working with a group of people on a commercially implementation. At this moment (for business-reasons) I cannot go into further details, but we will within a few months. If you need an implementation, contact me, I will lead you further, I can get you to an implementation within a few months.. If you only want information, please wait for more press releases. The concepts are very new, the learning curve is steep, So don't expect a lot of implementations in short time, but, in my experience with complex software like this, there is a point of critical mass after things will really go fast. Also, I know about other implementations in beta phase. When people involved are willing to provide information on this, you will learn about it from them. I worked on HL7 implementations, I cannot say that it is a pleasure. I still work on code to create the messages Nictiz defined. They are very complicated, a lot of its complexity cannot be used at all because most of the providing GP-applications do not support that kind of data-constellations. So lots of definitions just exist in vain, as a kind of hobby for the designers. Also, I guess that the dutch GP-systems will need maybe three to five years to get an error-free partially implementation. When you see how long they needed to implement the much more simplier Edifact (medeur) message from the Erasmus university. They started at that time with 1500 errors in each Edifact message. Stupid errors, like sexe: Islam, religion: O-neg Blood type: male. They had lots of problems to distinguish the + and ' and other characters which have special meanings in Edifact. It took more then three years to let them prouce/implement edifact messages of an acceptable level of errors. I am not a genius, but I wrote a Medeur testing tool, a medeur-readable report generator and other medeur tooling in a few months, on my own, they are still in use.. Now they have to build a system for HL7, which is much much much more complicated as Edifact. (Medeur). I do not expect them to succeed to implement the HL7 v3 message on an acceptable level error-free level before 2010. Say, it will be 9 years after Nictiz started defining the PRICA-DMIM (primary care) (which also took 4 years and 50 million Euro, but being fair, it was not only the DMIM, also the SOAP headers and some more things had to be done. Maybe there were other DMIM's too they defined. I know one more, BEMO (medications)). So, At this moment there is no application in my knowledge which implements a trustworthy HL7 v3 Prica message-generation or -interpretation
Antw: Re: AW: HL7 templates/archetypes
I very much agree with Tom that transformation even if desirable in some circumstances shall not be taken lightly and it is not going to be a piece of cake, possibly dangerous. Therefore strategies should focus on avoiding it. Cheers Gunnar - Original Message - From: Thomas Beale thomas.be...@oceaninformatics.biz To: For openEHR technical discussions openehr-technical at openehr.org Sent: Monday, October 16, 2006 12:43 PM Subject: Re: Antw: Re: AW: HL7 templates/archetypes Williamtfgoossen at cs.com wrote: In een bericht met de datum 15-10-2006 23:54:28 West-Europa (zomertijd), schrijft gfrer at luna.nl: What might be possible in a way, is to transform from CEN to HL7 and back again when a R-MIM is used that is an agreed mapping of the CEN/tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the CEN EN13606 standard will contain such an R-MIM, is the expectation. Why is such an undertaking of mapping between EN13606 and HL7v3 interesting? Yes, I say this transformation is possible. Why interesting? We face multiple approaches and since sorting out the clinical stuf is more costly than transformations, we face a large reuse of models and reduction of overall development costs. William, one element I think are you underestimating the importance of is the dangers of a) excessive data transformation and b) bugs in software due to loose and/or over-complicated standards specifications. Either can cause patient safety issues, and ultimately injury or death; they already have, and will continue to do so. Data transformations are absolutely to be avoided as much as possible; they are however of course not totally avoidable. The main factor that aggravates the problems of data transformation is the semantic gap between the relevant formalisms. So while it is clearly good economics to re-use semantic models, the economic costs of data transformations, particularly poorly specified ones should not be ignored; they are the costs most related to patient safety in the health information infrastructure. I used to work in the control system industry, where the software controlled power stations, trains, gas pipelines and so on - places where bugs could cause injury, death and massive capital losses. We made sure there were no bugs in the software by clean clear design, and heavy use of version control, heavy reviewing, and disciplined unit and system testing. There were no data transformations of the kind I see people casually assuming in the healthcare environment. To be honest, the way I hear people speak about how the software will transform into this and that form all over the place, as if to suit the whims of modellers, standards politics etc, and with little regard for the consequences to patients - positively scares me. I hope I never end up in a hospital containing the solutions some people are speaking about today. And the runtime performance costs of transformation cannot be ignored either. Processing just prescription messages for a country of 60m people incurs serious costs of computing hardware and bandwidth. Complexity and excessive data transformation might keep some people amused and employed, but in my view, both are the enemies of safe computing, and in health, of patient safety. They both have to be minimised. openEHR is designed from the outset to do this, and to provide the needed semantics for health computing. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
