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
