hi > If compliance to a standard does not guarantee interoperabilty with everything > alse that complies to the standard, then what exactly is being standardised?
My point of view is simple. I do this for a living - apply these standards to make interoperability happen. Without healthcare standards, I must choose some lower level standards, such as xml, figure out my own data and process models, agree with someone else, and implement. Using HL7 v2, v3, or archetypes/templates gives me a pre-existing language and process model, a set of shared assumptions, and also allows me to share existing code and information models across different interoperability implementations. So they are all interoperability framework standards, rather than interoperability standards - a lot like the W3C standards; http, html, soap, xml etc, these are interoperability frameworks. I think that what we are doing in health stands up well when compared with W3C and OMG. > These problems arise mainly through the industry's failure to address these > three criteria, which necessarily introduce concepts of formal definition and > proof that have been beyond the capability, and even comprehension, of most IT > systems suppliers and their customers. so, why complain? the users buy what the users want. It's like complaining about insecure software. Give a user a choice of a $100 package and a $10000 equivalent that is more secure. Which are they going to choose? Yet people see this problem as a supplier side problem. I don't understand why. > On the contrary. A standard that's defined by an implementation guarantees > interoperability among the users of that implementation. That's how MS won its > market share. I'm not convinced that such a standard is actually a better outcome; it's still going to be shot through with technical flaws, and probably no process for managing it which is not subject to commercial corruption. >>> But I was of the impression that that was not the intention of the >> international >>> health care community. >> in as much as such a diverse group can be said to have an intention, it >> wanders >> somewhere between cheap, flexible, and interoperable. But you can only have >> two >> of those three. > > Can you demonstrate that these three properties are necessarily mutually > incompatible? And, if it is indeed so, which of them would you advocate > prioritising in the domain of healthcare? I'm not sure that I can demonstrate it. It's a truism I adapted from Martin Fowler, though he probably got it from "Fast, cheap, or good; you can have any two". My experience is strongly in support of this; there is an inherent tension between interoperability - being standard, doing things the common way - and offering a product that delivers features that the users want. You can over engineer to try and do both, but it takes a huge amount of extra work. So I think you can't have all three. As for which I advocate, I'm just a jumped up programmer who makes my living doing interoperability for customers, so naturally I don't recommend cheap ;-) But the reality is that there's only a given amount of money to spend on healthcare, however it's organised, and given the amount of waste involved in any human endeavour, cost will always be first and last. And, err, try doing sales where you say to a customer, "well, we can't actually solve your business problem because HL7 doesn't support it." I can assure you, that doesn't help you land the sale. I am in favour of open source, of course, I believe it offers the best mix of the three, but it's frustratingly hard to make things align. I'm still living in hope that the various open source initiatives can come together productively Grahame CTO Kestral Computing co-chair Infrastructure & Messaging TC (HL7) editor - HL7 datatypes & templates specifications Project Lead - Eclipse Open Healthcare Foundation
