On Sun, 2003-12-28 at 13:28, Thomas Beale wrote: > Tim Churches wrote: > > >On Sun, 2003-12-28 at 11:47, Thomas Beale wrote: > > > > > >>well, actually, even though HL7v2 had a mania of translators all over > >>the place, and at great cost, it did succeed quite well. Where it > >>succeeded best (to my knowledge) was in environments where translators > >>were eliminated; i.e in New Zealand, where everyone uses exactly the > >>same HL7 software, and to a lesser extent in Australia, where HL7v2 > >>messages are standardised for he whole country. > >> > >> > > > >Um, every hospital installation of HL7 in Australia of which I am aware > >relies completely on the presence of an HL7 translation facility such as > >STC DataGate/eGate (see > >http://www.stc.com/products/ICAN_productsEgate.asp ) for its success. > >And on a small army of software engineers, steeped in arcane HL7 > >knowledge, who look after the care and feeding of the HL7 translation > >facility... > > > > > > > that's not what I meant by "translator" - the main purpose of most HL7 > interfaceware is to convert some other format to/from HL7 ( that's what > HL7 messaging is about, of course ); what I was talking about was the > translators needed to make different varieties of HL7 software talk to > each other - i.e. software that supposedly is already talking HL7 > messages.
The latter is what what I was talking about too - HL7-to-HL7 translation. Many applications "speak" HL7, but they need an HL7 interface engine and team of minders to allow them to talk to each other, in practice. Indeed, system architects hate point-to-point HL7 interfaces - they actively prefer everything going through an HL7 hub, with some form of translation de rigeur within the hub. > This is the basis of Wes Rishel's quote that "once you have > seen one HL7 implementation you've seen ...one HL7 implementation". The > need for the former kind of data translation - legacy data to/from a > target format - never goes away; the only question is whether you go for > the ad hoc point to point approach (N^2 cost; or worse, since it's > unplanned - often the same A-B transformations are solved more than once > in different places or comapnies) or point - common standard approach > (N*1 cost). It is usually considered cheaper to undertake the translation in an HL7 hub, rather than requiring each application vendor to "fix" their particular HL7 implementation. > Also, when I used the word "success", I meant in terms of what a judge > of the overall health system would conclude, not what a vendor company > would define as success; as we all know, vendors thrive on > non-interoperability and translation of data. But in terms of running a > health computing infrastructure for a company, it's a vast waste of money. HL7 2.x, as it is actually practiced, is definitely better than having no standards at all, but it is a long way from what should be achievable, given more completely specified standards. HL7 3.x should help a lot, as might openEHR archetypes, but HL7 2.x and its associated converters are well entrenched and it will take many years to replace them with something better. That doesn't mean we shouldn't try - particularly in "green field" sites or domains or when embarking on new software projects. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
