Open Healthcare Framework

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.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home