Subject: Re: open source medical software
From: Benjamin Rossen <b.rossen@onsnet.nu>
Date: Fri, 28 Jan 2005 16:04:14 +0100

Donnal Walter

I don't thing that a consortium is going to give you what you are looking for, 
and it has a built in flaw; the larger you make the consortium, the more it 
shall start to resemble the Open Source Community. And if you don make it 
large, it won't achieve your aims. 

Randall Burns' suggestion that you use a "toy database" is not such a bad 
idea, although I would refine it as follows. Make it a generic data base. 

Why not do a complete architectural modelling analysis of your software, 
(start at the MDA level) and brainstorm with people (possibly on a mailing 
list) about the applications for a system which makes a diagnosis, monitors 
the condition of a subject, assess risks inherent in all known options, and 
controls or recommends action. Let the Open Source Community find these 
applications for you. These applications would include more things that I 
have already suggested; 
(1) Salmon Farming / Dog Breeding / Cattle Rearing 
(2) Engine Maintenance / Railway Safety Monitoring 
(3) Teachers making decisions based on the progress of their students? ... to 
give or not to give extra coaching,  to pass or fail into the next class, and 
so on.
(4) Criminal lawyers wanting to assess the risks associated with getting a 
dubious witness on the stand? 

Some years ago I published a paper (Nederlands Juristenblad) on the use of 
Bayesian estimation algorithms to assess the probative value of certain 
diagnostic tests (having presented the argument as expert witness to the 
Supreme Court - Hoge Raad - earlier in the year; I had been hired by the 
defense to prepare the material). Later, in a discussion with one of Europe's 
prominant experts on computer security, Marcus Holthaus, I discovered that he 
was using the same algorithms to make security decisions in computer 
networks. As you may know, spam filters also use Bayesian estimation to 
decide whether to pass or reject e-mail. No doubt your software does the same 
- I cannot imagine that it doesn't. If you are not using the term Bayesian 
estimation, then you are probably talking about risk adjustment against known 
base rates, which is the same thing. I am confident that your software has 
huge potential as a generic engine. 

Now, it might not be completely obvious to you which applications can use your 
software. That is not a problem. You don't have to come with all the possible 
fields of application. Once the software is in the Open Source Domain, these 
things shall be added by the community, and the power of your package shall 
grow. It shall undergo a sort of adaptive radiation in the virtual ecology of 
all possible decision making niches (although without forking if the software 
architecture makes it possible to add specialized modules to meet these 
needs). 

It should be possible to grant the Open Source License, if the license of "the 
software as such" satisfies the OSD. The fact that a non-physician may not 
use it to perform physicians' professional duties must surely be enforced by 
something other than the software license. It is illegal for a non-physician 
to perform a physicians task. That is the law. There is no need to put that 
restriction in the software license. Perhaps a footnote could be used to draw 
the user's attention to the fact that the normal use of the software in 
medical practice requires the user to be a licensed physician. 

And if Richard Schilling is correct, you have nothing to fear from the FDA. 

Pardon my arrogance for suggesting what you should do with your software. It 
is merely a suggestion, and you are free to do what you like. But this is it: 

(1) Change your definition of the project, and make it a generic decision 
making tool. 
(2) Avoid consortia, and give it the widest possible developer base and an OSD 
license. 
(3) Make it your project policy to find as many fields of application as you 
can (which shall attract a larger body of developers and a larger community 
of users).
(4) Re-asses the question of whether you want to keep the specific components 
for the medical applications closed. I think you shall find that it is not 
necessary, and if you decide that it is necessary you can follow Richard 
Schelling's suggestion to distribute it through professional networks only. 
Perhaps asking the FDA for their opinion on the matter is also the best 
policy. 

I hope this has been helpful. 

Benjamin Rossen 


On Friday 28 January 2005 13:10, Donnal Walter wrote:
> A few weeks ago, in another thread (and for entirely different
> reasons) someone suggested setting up a consortium of users who
> agree to share their modifications rather than making the code
> entirely open-cource. 
> 
> On the other hand, I have not yet given up on the open-source
> dream. I can see that the licensing issues are mostly orthogonal to
> the FDA requirements (although perhaps not entirely so).
> 
> Donnal Walter, M.D.
> Arkansas Children's Hospital
>  
>