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" <[email protected]> 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
