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
