open source medical software

[Donnal Walter]

--- Benjamin Rossen <b.rossen at onsnet.nu> wrote:
> (1) Donnal Walter would not like the software to be defined
> as a medical device because of the difficulties that this
> would entail with respect to the FDA review. (Do I understand
> this correctly?)

Yes, that is mostly right. We don't have a particular problem with
the FDA looking over our shoulders, so to speak, but (1) we don't
want any more red tape than is necessary, and (2) one of the
mantras of open source development is "release early, release
often", which would make close FDA oversight a real burden.

> (2) The software is is exempt because "licensed practitioners,
> including physicians, dentists, and optometrists, who
> manufacture or otherwise alter devices solely for use in their
> own practice." [Code of Federal Regulations 21 CFR] and Donnal
> Walter would like to make sure that it remains exempt by 
> restricting its use in the license.

That was just an idea we entertained briefly, but I can see that it
wasn't viable.
 
> (3) Can it still be licensed under the OSD if (2) is satisfied? 
> 
> The answer to question three was given by Richard Schilling,

(among others)

> and it is 'no', because the OSD requires that there be no
> restrictions for field of use or groups of people. (Do I
> understand that right?)

That is the way I understood it.
 
> That brings us back to the second issue. Is it necessary to use
> this ploy to avoid FDA review. I wonder if this ploy is a good
> one anyway...

Yes. Now, I wonder too. :-) Several people have suggested that it
is not necessary. In any case, by itself, it probably wouldn't work
for many different reasons.

> after all if you make a license saying that only licensed
> practitioners, including physicians, dentists, and optometrists
> and so on may use the software, would not such a license become
> the proverbial red flag for the FDA?
> And since the software would be altered by known and unknown
> opensource contributors, it would no longer be something
> manufactured or otherwise altered solely for use in the private
> practice by the physicians concerned. It would be out of 
> control. It would be on the web. So, there must be another
> way of getting around this problem.

Which makes the idea of a consortium slightly more palatable.
 
> There are many possible uses for this kind of software. Surely
> it is interesting for veterinary practitioners, agricultural
> scientists, animal breeders and as I mentioned elsewhere,
> academics engaged in the study of medical decision making,
> and so on. Is the software was only useful for keeping track
> of patient information and to calculate parameters used in 
> medical decision making, drug dosing and so on?

Actually the software consists of two projects. One is strictly a
framework for custom application development. This part can remain
open source without any difficulty. The FDA would have no interest
in it except as it is used to create custom clinical software.

The second part of the project is currently specific for newborn
special care. It could be modified to make it appropriate for other
areas of pediatrics, but at the moment it is fairly specialized.

> Can it be altered to keep track of salmon weight, age and
> growth rate to calculate parameters in food allocation and
> similar.

Hmmm. Hadn't thought of that. ;-)

> Perhaps by adding defining the parameters differently the
> software is can become an tool for much more general use.
> How much would have to be added / changed to make it useful
> for keeping track of diesel engine parameters and maintenance
> decision making, lubricant delivery and so on. After all, at a
> the meta-system modelling level, the program structures for
> these applications is going to be the same. The principles of
> testing theory, risk assessment and decision making are the
> same irrespective of which field you apply them.

As I said above, the development framework is generic and presents
no problem. The clinical applications on top of this framework are
quite specialized.
  
> Thinking in generic terms has often helped me to make much better
> systems, which would be a side benefit of doing this. Separate
> the layers of: 
> (1) Object Definition (patient/salmon farm/diesel engine
>     or what ever)
> (2) Measurement / Diagnosis /Testing
> (3) Maintenance / Treatment 
> (4) Monitoring  ... and so on. 
> 
> So, perhaps a better strategy is to redefine the software as a
> generic decision making tool, which can be configured by
> licensed practitioners, including physicians, dentists, and
> optometrists in their own practices for medial purposes, but
> can also be configured by other users for their purposes. Now
> this solves two problems. 
> (1) Generic decision making software is not interesting to the
> FDA
> (2) Generic decision making software can be licensed under the
> OSD

Yes, we have layered the software as much as we can, and the more
generic layer is not of concern. But at some point the value of the
software is related to domain-specific knowledge, and this is what
the FDA might have an interest in. 

> But even this may not be necessary, for as Richard Schilling has
> said, the FDA would apply the exemption irrespective of what
> is written in the license. (Do I understand that correctly?)

That is how I understood it too. The license terms likely won't
change how the FDA views the software, unless the license is a
consortium license rather than open source.

> Now it might be interesting to examine another assumption.
> What if the FDA decided that the software is a medical device
> because of the ability to configure it for medical decision
> making applications. Is that indeed such a terrible thing?
> What are the arguments for getting it licensed as a medical 
> device? What are the arguments against?

This is typically a long and arduous process. I don't know if it
has to be, but typically it is a real headache. If we were a
commercial software company it would be worth the hassle, but our
primary concern is taking care of patients.

Furthermore, as I mentioned above, having to go through the
approval process every time a modification is made would kill any
open-source development.

Regards,
Donnal Walter
Arkansas Children's Hospital