David Forslund wrote: > I've seen no real > effort in the open source community to embrace interoperability. > Certainly interoperability has > been opposed by much of industry until recently, but there is no good > reason for the open source community to not embrace it.
Dave, interoperability, although good in theory, is not an end in itself. Thus you have to ask the question: in the settings in which open source health information systems are or are likely to be deployed, what are the "business drivers" or the "business case" for interoperability, and what sort of interoperability? Thus, although there is indeed no good reason not to embrace interoperability, there may be, in many open source deployment settings, no good reason to embrace it, either, given that supporting interoperability is not without some cost. For example, the COAS specs document is 260 pages long, but if you go to the "Interoperation" chapter in it, it refers you to four other CORBA specifications, each also several hundred pages long, which need to be assimilated first. So that's a thousand pages. And that's even before one works out how to implement all this. That's the cost. So unless there are strong reasons to do this, in the always-resource-constrained world of open source development, it is no wonder it is hardly ever implemented. > Sending HL7 messages over SMTP encrypted email is a wonderful idea for > someone who is trying to get the most amount of money for support from a > customer, but has little to do with building truly distributed systems. Tell that to the people using encrypted SMTP mail. I suppose it means what one means by "truly distributed systems". > I think that one should avoid asynchronous, time-delayed coordination of > updates to the same record in multiple locations. What we have done > in COAS is to basically provide versioning of a record so > that all versions are available. That skirts the issue of coming up with the currently definitive version of a record for analysis purposes, but doesn't solve it. Which version should be used when analysing the data? > The B-Safer web application in OpenEMed was used in a > distributed environment. We had very heterogeneous feeds (available in > the clients/translate directory) from a variety of data sources > (no two alike). Users of the data had views that > were potentially different for each site. Differing views are what need to be avoided (at least eventually, when all nodes in a network have caught up with each other). > It does appear that programming languages seem to be the biggest barrier > for this particular > open source community. Some like Java, some like Python, some like PHP, > etc. That was > the value of the IDL used in COAS, because it is language independent > and really quite easy to read as an interface (as opposed to trying to > read WSDL). If I type "python IDL" into Google, I get hits for Python and IDL, the matrix language (like Matlab), but not IDL as in COAS. In other words, CORBA support is not exactly mainstream, or even a well-supported niche. Neither is openEHR (yet, maybe some day). > It is important > for interoperability to have interfaces specified in a language-neutral > way, so that, in fact, > Python built systems can interoperate with Java, etc. Well, it depends what the aim is. If clinic A simply needs to share data with clinics B and C, and none of them currently have information systems, then installing the same software in all of them and using less general means to share data between those clinics may be the easiest path to take. Yes, that's short-sighted, but in many places it is important to walk before you can run. In any case, systems are not set in stone - all information systems have a limited life span and it is wrong to forgo an adequate but sub-optimal system now while waiting for a perfect system tomorrow. With open source, you can largely have both. If the aim is to drop software into the midst of a modern large hospital in a developed country, then what you say is correct. Tim C
