7 ms·

Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even t

Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.

beambot 10y ago
With or without a warrant...? EDIT: Not sure what's up w/ the downvotes. There are well-established ways for regulatory agencies (whether FDA, FCC, etc) to obtain firmware for devices -- and it almost always involves a warrant under extraneous circumstances -vs- proactively receiving proprietary code.
- ben_jones 10y ago
  What if they had to subpoena a tomato grown in a field next to the toxic waste dump? What if they opted not to examine that tomato because they didn't have the resources to issue, process, and support, the lengthy bureaucratic process involved in such things?
  - beambot 10y ago
    Who owns the tomato? Who owns the land that the tomato is grown on? You can't just willy nilly confiscate other's property...
    - ben_jones 10y ago
      But the government can and should have the right to inspect a tomato (not necessarily a specific tomato) if all the tomatoes in that field are slated to go direct to consumers, right? Similarly, what about testing for drug quality? You could even extrapolate it out to the SEC's right to examine a private financial transaction in order to determine legality. Or the IRS's right to inspect one's taxes to determine compliance. Point is (IMO) there is a need put on government by society to bypass some of our "Inalienable" rights. In most cases this societal decision is necessary and makes sense, and I'm arguing that code inspection of life-critical systems is a reasonable example of such a case.
  - throwanem 10y ago
    To extend the metaphor, if the farm that grew the tomato is selling them to people to eat, I don't see that a subpoena is or should be required. But it breaks down anyway, because a tomato's source code is right there in it, with no opaque binary blobs to worry about trying to decompile.
    - TeMPOraL 10y ago
      Nitpick, but what you call tomato's "source code" actually is an opaque binary (or rather, quaternary) blob.
- pdabbadabba 10y ago
  I believe the downvotes are because the FDA has to approve medical devices before they are marketed, and GP was referring to the possibility that the FDA would review the source code in connection with device approval. (It reviews most other aspects of the device's functioning, after all.) Definitely no warrant required in that context.
tdicola 10y ago
Does the FDA have the knowledge and experts to really understand if the firmware is good or bad though?
- function_seven 10y ago
  That's a tough one to answer. The cynic in me says probably not. That they're so focused on pharmaceuticals and "analog" medical devices that they haven't developed those capabilities. But I also know that the FDA is a massive organization, and there's no reason they couldn't hire for this specific purpose. But then the cynic says that government pay grades may not be up to snuff. See the HCA rollout and subsequent rewrite. Sorry, that was a long way of writing, "I don't know".
  - grogenaut 10y ago
    There have been medical devices external to the body for a long time. Therac 25 (1982) is world wide web (1989). Airplanes were first flight controlled by computer in 1958, and commercially in the concorde in 1969. Think about that for a minute. There has been an official government review process for safety of computer controlled airplanes since the 70s, and a good decade for medical devices (likely earlier) 10 years earlier than the WWW existed. I think it's kind of funny that you'd think that you were doing it better than production life critical systems THAT CAN ACTUALLY KILL PEOPLE that have been around at least ten if not 30 years longer than the tech you likely (sorry assumption) base your career around.
    - throwanem 10y ago
      Uh, did you really just cite Therac 25 in favor of safety review? You do know that was the one that had a bug which slipped past review and killed some people, right? Your overall point is well taken, but maybe put a little more thought into the examples you pick to support it...
      - grogenaut 10y ago
        I cited it as a thing that killed people and caused an industry overhaul in how things were reviewed... Remember that toyota just was forced to do somthing like this only a few years ago. I'd say the FDA has been cognizant of life threatening code for a lot longer.
refurb 10y ago
A google search turned up "General Principles of Software Validation; Final Guidance for Industry and FDA Staff"[1] My understanding is that they don't review the code, but they do review all of the validation that goes into making sure the code does what it should. [1]http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281.htm http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281...
vacri 10y ago
I used to work at a diagnostic medical equipment company. Rules were slightly different for us (diagnostic rather than therapeutic = lower bar) and we had FDA audits. They were basically making sure we had written down our processes to an adequate degree, and checking that we actually followed what we wrote down. They most definitely were not doing code audits (which isn't their job or area of expertise).
- jordigh 10y ago
  > and checking that we actually followed what we wrote down We never got that. For the most part, checking that we followed what we wrote down involved reading more documents that said that we did what we wrote down. The auditors weren't even allowed to walk around freely in our office, nor even be left alone without supervision, and we were all carefully coached on how to answer interviews with non-compromising responses. "I do what the SOP says. I cannot quite recall at the moment, but if you let me refresh my memory by reading the SOP, I will gladly clear it up for you." It's just smoke and mirrors to pretend like important testing took place. Probably also to make sure whom to blame when things go bad. Some testing does frequently happen, between the document writing about the testing.
  - vacri 10y ago
    Our FDA inspector hung around the QA manager and staff, didn't go into R&D much at all, and spent some time on the factory floor checking processes. I guess that they function as regular police do - the actual experience is less than ideal and leaves a lot to be desired, but without any at all, the world would be horrible.
icegreentea 10y ago
In general, you do not submit source code for review - just all your procedures and results for testing. In normal auditing, they will not inspect your source code - they may inspect everything around your source code (what you procedures for changes are, how you do your testing, etc etc). However, I believe there's a general understanding that if you fuck up, your source code will be open to inspection - along with everything else. Cause you'll either voluntarily surrender it in hopes of getting on the FDA's good side, or cause they'll subpoena cause you killed someone.
- jordigh 10y ago
  > However, I believe there's a general understanding that if you fuck up, your source code will be open to inspection Hold it right there, Karl Marx. We can't just be giving the proletariat access to the means of software production because of one little boo-boo. That could totally bankrupt a company and would be a theft of IP. Rest assured that the proper procedures will be followed and the flaws corrected, but under no circumstances can we take the lawful property of entrepreneurs and daring businessmen.
jordigh 10y ago
I know. Nope. The FDA probably doesn't even know what source code is. They have vague regulations on how medical devices should be tested, which by tradition has been interpreted in a particular way to mean certain kinds of documents have to be prepared. There are auditors that check that those documents are written. Nobody checks that what the documents say about the software is in fact true because neither those writing the regulations nor those auditing the documents really know anything about computers.
- seehafer 10y ago
  As someone who has been on the receiving end of several FDA audits, I would really like to know on what basis you're saying all of this, because everything in my 10 years of experience of doing this is contrary to what you've said.
  - jordigh 10y ago
    Maybe we worked in different fields? I only did 3 years, only received one FDA audit, but many other audits from pharmaceutical companies. I was in the more diagnostic side, not therapeutic, although we did have some safety checks where we had to quickly raise an alarm if our analysis showed a potential medical emergency. Did the FDA actually check your software or just your documentation? Did the auditors very carefully grill you or just languidly ticked off boxes on a form? Did you find the process of writing documentation instrumental in ensuring that your software was carefully tested? Did you ensure that your tests were reproducible and comprehensive? None of these things were done very carefully in our case. My superiors were very insistent on the documentation and were quite proud of the quality of our software but they mostly never had any interaction with it and had no real idea of what we did for software validation. They were more concerned with making sure signatures and dates were correct and that our documentation didn't make us look bad. I think the audits must look more impressive when you're in charge, but as the one actually writing the software I was thinking... that's it? The FDA doesn't really give a damn about what I really worked on, do they?
    - seehafer 10y ago

Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.

beambot 10y ago

With or without a warrant...? EDIT: Not sure what's up w/ the downvotes. There are well-established ways for regulatory agencies (whether FDA, FCC, etc) to obtain firmware for devices -- and it almost always involves a warrant under extraneous circumstances -vs- proactively receiving proprietary code.

ben_jones 10y ago
What if they had to subpoena a tomato grown in a field next to the toxic waste dump? What if they opted not to examine that tomato because they didn't have the resources to issue, process, and support, the lengthy bureaucratic process involved in such things?
- beambot 10y ago
  Who owns the tomato? Who owns the land that the tomato is grown on? You can't just willy nilly confiscate other's property...
  - ben_jones 10y ago
    But the government can and should have the right to inspect a tomato (not necessarily a specific tomato) if all the tomatoes in that field are slated to go direct to consumers, right? Similarly, what about testing for drug quality? You could even extrapolate it out to the SEC's right to examine a private financial transaction in order to determine legality. Or the IRS's right to inspect one's taxes to determine compliance. Point is (IMO) there is a need put on government by society to bypass some of our "Inalienable" rights. In most cases this societal decision is necessary and makes sense, and I'm arguing that code inspection of life-critical systems is a reasonable example of such a case.
- throwanem 10y ago
  To extend the metaphor, if the farm that grew the tomato is selling them to people to eat, I don't see that a subpoena is or should be required. But it breaks down anyway, because a tomato's source code is right there in it, with no opaque binary blobs to worry about trying to decompile.
  - TeMPOraL 10y ago
    Nitpick, but what you call tomato's "source code" actually is an opaque binary (or rather, quaternary) blob.
pdabbadabba 10y ago
I believe the downvotes are because the FDA has to approve medical devices before they are marketed, and GP was referring to the possibility that the FDA would review the source code in connection with device approval. (It reviews most other aspects of the device's functioning, after all.) Definitely no warrant required in that context.

tdicola 10y ago

Does the FDA have the knowledge and experts to really understand if the firmware is good or bad though?

function_seven 10y ago
That's a tough one to answer. The cynic in me says probably not. That they're so focused on pharmaceuticals and "analog" medical devices that they haven't developed those capabilities. But I also know that the FDA is a massive organization, and there's no reason they couldn't hire for this specific purpose. But then the cynic says that government pay grades may not be up to snuff. See the HCA rollout and subsequent rewrite. Sorry, that was a long way of writing, "I don't know".
- grogenaut 10y ago
  There have been medical devices external to the body for a long time. Therac 25 (1982) is world wide web (1989). Airplanes were first flight controlled by computer in 1958, and commercially in the concorde in 1969. Think about that for a minute. There has been an official government review process for safety of computer controlled airplanes since the 70s, and a good decade for medical devices (likely earlier) 10 years earlier than the WWW existed. I think it's kind of funny that you'd think that you were doing it better than production life critical systems THAT CAN ACTUALLY KILL PEOPLE that have been around at least ten if not 30 years longer than the tech you likely (sorry assumption) base your career around.
  - throwanem 10y ago
    Uh, did you really just cite Therac 25 in favor of safety review? You do know that was the one that had a bug which slipped past review and killed some people, right? Your overall point is well taken, but maybe put a little more thought into the examples you pick to support it...
    - grogenaut 10y ago
      I cited it as a thing that killed people and caused an industry overhaul in how things were reviewed... Remember that toyota just was forced to do somthing like this only a few years ago. I'd say the FDA has been cognizant of life threatening code for a lot longer.

refurb 10y ago

A google search turned up "General Principles of Software Validation; Final Guidance for Industry and FDA Staff"[1] My understanding is that they don't review the code, but they do review all of the validation that goes into making sure the code does what it should. [1]http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281.htm http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281...

vacri 10y ago

I used to work at a diagnostic medical equipment company. Rules were slightly different for us (diagnostic rather than therapeutic = lower bar) and we had FDA audits. They were basically making sure we had written down our processes to an adequate degree, and checking that we actually followed what we wrote down. They most definitely were not doing code audits (which isn't their job or area of expertise).

jordigh 10y ago
> and checking that we actually followed what we wrote down We never got that. For the most part, checking that we followed what we wrote down involved reading more documents that said that we did what we wrote down. The auditors weren't even allowed to walk around freely in our office, nor even be left alone without supervision, and we were all carefully coached on how to answer interviews with non-compromising responses. "I do what the SOP says. I cannot quite recall at the moment, but if you let me refresh my memory by reading the SOP, I will gladly clear it up for you." It's just smoke and mirrors to pretend like important testing took place. Probably also to make sure whom to blame when things go bad. Some testing does frequently happen, between the document writing about the testing.
- vacri 10y ago
  Our FDA inspector hung around the QA manager and staff, didn't go into R&D much at all, and spent some time on the factory floor checking processes. I guess that they function as regular police do - the actual experience is less than ideal and leaves a lot to be desired, but without any at all, the world would be horrible.

icegreentea 10y ago

In general, you do not submit source code for review - just all your procedures and results for testing. In normal auditing, they will not inspect your source code - they may inspect everything around your source code (what you procedures for changes are, how you do your testing, etc etc). However, I believe there's a general understanding that if you fuck up, your source code will be open to inspection - along with everything else. Cause you'll either voluntarily surrender it in hopes of getting on the FDA's good side, or cause they'll subpoena cause you killed someone.

jordigh 10y ago
> However, I believe there's a general understanding that if you fuck up, your source code will be open to inspection Hold it right there, Karl Marx. We can't just be giving the proletariat access to the means of software production because of one little boo-boo. That could totally bankrupt a company and would be a theft of IP. Rest assured that the proper procedures will be followed and the flaws corrected, but under no circumstances can we take the lawful property of entrepreneurs and daring businessmen.

jordigh 10y ago

I know. Nope. The FDA probably doesn't even know what source code is. They have vague regulations on how medical devices should be tested, which by tradition has been interpreted in a particular way to mean certain kinds of documents have to be prepared. There are auditors that check that those documents are written. Nobody checks that what the documents say about the software is in fact true because neither those writing the regulations nor those auditing the documents really know anything about computers.

seehafer 10y ago
As someone who has been on the receiving end of several FDA audits, I would really like to know on what basis you're saying all of this, because everything in my 10 years of experience of doing this is contrary to what you've said.
- jordigh 10y ago
  Maybe we worked in different fields? I only did 3 years, only received one FDA audit, but many other audits from pharmaceutical companies. I was in the more diagnostic side, not therapeutic, although we did have some safety checks where we had to quickly raise an alarm if our analysis showed a potential medical emergency. Did the FDA actually check your software or just your documentation? Did the auditors very carefully grill you or just languidly ticked off boxes on a form? Did you find the process of writing documentation instrumental in ensuring that your software was carefully tested? Did you ensure that your tests were reproducible and comprehensive? None of these things were done very carefully in our case. My superiors were very insistent on the documentation and were quite proud of the quality of our software but they mostly never had any interaction with it and had no real idea of what we did for software validation. They were more concerned with making sure signatures and dates were correct and that our documentation didn't make us look bad. I think the audits must look more impressive when you're in charge, but as the one actually writing the software I was thinking... that's it? The FDA doesn't really give a damn about what I really worked on, do they?
  - seehafer 10y ago