In The Case for Open Source Healthcare IT John Zaleski uses the VistA open source software as a model for improving the medical device data gathering in order to produce a "more robust end product". On the whole, I could not agree more. Achieving this in such a diverse and fragmented community would be a real challenge, but it may indeed be a worthwhile path to pursue.
There was one item I'd like to comment on:
The challenge is, of course, regarding regulatory management of open source frameworks. To a large degree open source software is anathema to the FDA regulatory process–and it relates to control and management of access.
OSS detested or loathed by the FDA? I don't think so. The open source framework itself would not be subject to regulatory control. The FDA does not really care where any specific software component comes from. Also, security and access management are certainly important, but I'm not sure of their applicability at the device connectivity level.
The FDA cares about intended use, efficacy, and safety of medical devices. All FDA regulated software is subject to the same design controls (§820.30) -- design, risk analysis, verification, validation, etc. I.e. any company that included these open source software components would ultimately be responsible for proving these processes are followed.
Shahid N Shah's OSCon 2011 Talk: The implications of open source technologies in safety critical medical device platforms does a good job of detailing these points (Will the FDA accept open source in safety-critical system? Yes!) as well as presenting an OSS connectivity software architecture.
Your blog article mentions that the FDA is concerned about “intended use, efficacy, and safety of medical devices”. But, is the FDA concerned about my right to privacy when it comes to EMRs being used? I don’t think so, as the U.S. government doesn’t seem to care if I or my doctor want to use EMRs at all. Epic Systems could turn out to be the nation-wide EMR, as this article reports on: http://freedomist.com/2011/10/stealing-your-medical-records-for-profit-and-political-gain-the-epic-systems-scandal/
“any company that included these open source software components would ultimately be responsible for proving these processes are followed.”
Good point. At the end of the day guidelines set down by the FDA have to followed and accounted for. It doesn’t matter what the technology is.
Pingback: Open Source Medical Device Connectivity | Bob on Medical Device … « Epic Systems « Top Conservatives on Twitter
In the case of open source medical device connectivity the challenge is to really create a community which really shares implementations for the different medical devices monitors so before the regulatory problem we have to really have an OS medical device community. There are some companies with a business model focused on solving this issue (CapsuleTech, Nuvon) you may look the vendor list these two companies comply with. Maybe I am wrong and there are some communities out there working on this if so please let me know…
I appreciate the reference and the discussion. To make it clear at the start, I am supportive of the use of open standards, open architectures, and open source software frameworks wherever possible. I believe there is ample evidence from other fields (aerospace, for instance) that shows the common use of open architectures and frameworks is indeed the way to go. My blog post was intended, rather, to illustrate a systemic issue in the field. As a medical device interoperability practitioner and an individual who has led the development of FDA-cleared (class I & II) interoperability products I am simply reporting on my experiences over the past decade. Perhaps the tides are turning. Yet, practically speaking, the use of open software in the development of FDA-cleared products has, to some degree, been accommodated by taking an existing build and tailoring it for targeted use in a specific product, applying the same design controls to it as privately developed software subject to design controls (much in the way that off-the-shelf software is incorporated into a larger product offering). Once done, the new build is no longer accessible to “public” change, and should not be for reasons of safety and efficacy. The idea of providing public access to open-source software once the design control has gone into effect on a private product is, quite frankly, not done. I am aware of and have developed products that have used open-source software. A specific build is employed of that software and then that buld, source code and libraries, is saved off for use by the end product and maintained under design and change control. This is what is normally done. However, I believe what needs to be expressed more clearly, particularly in your article, is that the idea of employing a software framework that is generally available for public access as part of a cleared product is not the case. For instance, it would not be reasonable to include a generally accessible piece of software in the build of a defibrillator in which that software can be modified or have software libraries adjusted by the public without properly controlled testing and without understanding the pedigree of the changes or, for that matter, the individuals making the changes. This is what I was talking about in terms of the FDA “detesting” the use of open source software. If, however, a software build can be saved off and quality system requirements with design controls can be applied, then that is fine.
Pingback: The Case for Open Source Healthcare IT - John R. Zaleski, PhD, CPHIMS