On Sun, 2003-12-28 at 13:28, Thomas Beale wrote:yes, of course this is a more modern approach; it's the basis of more serious HL7 architectures and products (like Oracle's Health Transaction Base for example - a big centralised message switch).
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.
right...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.
- thomas
