Open Healthcare Framework

Saturday, April 22, 2006

U.S. House of Representatives Testimony: "Make Selection of Open Source Software the Default Mode for Federal Funds"

Though this testimony does not come from the OHF project, it benefits the healthcare FOSS ecosystem.

Open source software is less well developed in health care than for some other enterprises, but open source software solutions for health care are now rapidly evolving.

In this vein, I urge the Committee to consider making open source software the first consideration in selecting any new software purchased with federal funds. This should be the case across the federal government – for health care and non-health care federal procurement alike. This requirement should apply to software purchases made by all federal agencies and purchases made by state and local governments and private parties using federal funds (including research funds)...


This public-private partnership might be envisioned to function like the Eclipse Foundation currently does in advancing "the creation, evolution, promotion and support of the Eclipse Platform" and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services. Eclipse is a software platform that IBM released into open source in 2004...


Discussions regarding this testimony may be found at LinuxMedNews and the The Healthcare IT Guy. I agree to some of the claims, especially to the ones regarding ROI.

How this testimony relates to OHF?
Considering that the testimony came from the VistA community, how may it relate to Grahames latest post about relationships with other open source initiatives?

Friday, April 14, 2006

Scope of OHF and other open source initiatives

Of the many open questions around OHF, there's 2 that are closely intertwined and will be a source of a great deal of contention on an ongoing basis. The first is what the scope of OHF is, and the second concerns relationships with other open source initiatives.

"Healthcare" is a rather open concept. It covers things such as financial arrangements for the provision of medical care, record keeping, hospital administration, government policy, and medical research, and more. None of these areas have a clear dividing line where the functionality that belongs with healthcare stops, and where other domains take over. So in addition to internal questions about the scope of OHF, there is also boundary questions with other domains.

The initial focus of OHF was on the kind of information systems that are supported by standards bodies such as HL7, OMG, OACIS, CEN, ISO and other collaboration bodies such as IHE and HIMSS. But at the recent FTF meeting, we adopted a public health modelling framework as a component of OHF, signalling that we do not believe that the scope of OHF is limited to the initial focus.

With regard to the second question, in addition to boundary problems, there's a number of existing open source initiatives that exist in the domain that is clearly within the OHF domain of interest. For each of these open source initiatives, OHF must figure out where is stands with regard to them. There's a number of possible answers, including that OHF ignores their existence, through to OHF acquiring their assets by a friendly donation/takeover.

A number of existing open source initiatives have been proposed as candidates for the combination of donation/takeover by OHF. And with some of the candidates, discussions are still ongoing. Any existing open source initiative consists of a body of code and a community. Both will have their strengths and weaknesses. For OHF to "acquire" their codebase, the merger of the communities must not only make sense, it has to obviously required to the existing community. In addition, there must be a way to migrate the existing code to the EPL license. Generally, neither of these conditions will be met, and the more successful an existing
open source initiative is, the less likely that the community conditions will be met.

But with most of the existing open source candidates, some of whom have been suggested as candidates for being swallowed by OHF (however it's initially proposed, that's generally what the outcome would be), such as pixelmed, the HL7 JavaSig, caBIG, and openmed, OHF should seek to collaborate with them, with their existing communities in place.

One of the most important things here is licensing. The mantra of eclipse is to build a source base that any user, with a single individual hobbyist, or a large corporation, can make use of the eclipse source with confidence. Due to the nature of things, this means that the license is weighted to the lawyers from a large corporation, and there's an ironclad set of rules about which licenses OHF can depend on. This will guide our interactions with these other initiatives. And in some cases, this will drive us to duplicate existing work, where the work exists under an unsuitable license. We'd rather not do this, but we may have no choice.

But there's a bigger problem that licensing - it's bandwidth. There's so much going on, the OHF needs to keep track of, and we just can't do it. We need to keep up with what's going on in Java, in Eclipse, in open source healthcare, the healthcare standards organisations (which seems to be all of them at the moment), and the corporate healthcare space. It's too much.

So what I'm doing is starting a wiki page where we can keep track of these things. Please come and contribute on our wiki at http://wiki.eclipse.org/index.php/OHF_Relationship_Management.