Showing posts with label Medical Devices. Show all posts
Showing posts with label Medical Devices. Show all posts

Monday, September 12, 2011

Do you work in the Medical Device field? You won't after 2013 due to this new Tax.

The Advanced Medical Technology Association (AdvaMed)   released a report late last week (Sept. 7th 2011) on how 43,000 jobs in the "Medical Device" field are going to be lost due to yet an other new Tax.

Here is the full report: Employment Effects of the New Excise Tax on the Medical Device Industry.pdf by Diana Furchtgott-Roth and Harold Furchtgott-Roth.

"Medical Device" as defined by the IRS are covered in USC TITLE 26 - Subtitle D - CHAPTER 32 - Subchapter E - § 4191. Section D of Exemptions is the problematic portion to those of us doing Embedded Medical Devices:
"any other medical device determined by the Secretary [of the Treasury] to be of a type which is generally purchased by the general public at retail for individual use."
So now we don't have a doctor nor a person familiar with Embedded System Medical Devices deciding which devices will get a %2.3 excise tax, that will cause Medical Device manufacturers to send yet more jobs overseas to avoid paying the tax, at the Embedded Communities expense.

If you work in the Medical Device field, it is probably time to get your resume in order. I'm going to be polishing up mine, because there is no way to tell what clueless bureaucrat will consider a Medical Device...




Sunday, September 5, 2010

Frama-C to prove formal properties for critical software.

I just came across a project, which has been around for a couple of years, that looks like it could be very useful: Frama-C. Frama-C stands for Framework for Modular Analysis of C programs.

Frama-C is intended to be an extensible static analyzer, that can prove formal properties for critical software. Frama-C does static analysis, dead code removal, security checks, and other functions depending on which plug-ins are used.

Armand, one of the project participants, is working on implementing the MISRA-C 2004 rules for the static analyzer.

Trying out Frama-C: analyzing a simple C program.

Sunday, July 25, 2010

"Killed by Code: Software Transparency in Implantable Medical Devices"

The Software Freedom Law Center (SFLC) has recently, July 21, 2010, published an interesting paper: Killed by Code: Software Transparency in Implantable Medical Devices.


SFLC makes a case for why Safety Critical systems should all have their source code available for public review.  They are promoting Free and Open Source Software (FOSS) be mandated for medical devices, and all devices in general; myself I want to see Toyota's source code to look for the race condition [unfortunate terminology in this case] of unintended acceleration that I believe exists.


I covered the issues related to the FDA's promotion of FOSS in medical devices previously: FDA says commercial software kills, but Open Source won't? and 200,000 Infusion Pumps ordered destroyed by FDA, due to software defects and other problems.


Philosophically I agree with SFLC's position, and in Utopia it would work out well that all devices have Free Open Source Code.  However in the real world of cooperate greed where only the bottom line of next quarter is all that maters, I do not see medical device manufactures, or automotive manufactures, giving up what they would consider 'Trade Secrets' so that their competition could use them.  A more workable solution would be an independent auditing agency, which still must be held to the highest standards to prevent such things as cooperate kickbacks.  Nor would we want the agency to be funded by the people that are having their code audited.


Also just because a project is FOSS does not mean it is secure.  One only has to take a look at the recent events of the Unreal IRC Server Project.



"We found out that the Unreal3.2.8.1.tar.gz file on our mirrors has been replaced quite a while ago with a version with a backdoor (Trojan) in it.".


This incident demonstrates that the entire chain of custody from the Source Code to the code on the device must be traceable, so that the code that is really being run, is the code that came from the legitimate sources of the project.


Unreal had this to say about addressing the issue, to give some ideas of what needs to be done:


Posted by Syzop on June 14, 2010, 3:36 pm EDT

After receiving many questions of what we are doing with regards to the hack incident, here's my reply:


First, we now PGP/GPG sign releases. Our GPG key is releases@unrealircd.com (0x9FF03937). When downloading UnrealIRCd you will be given instructions on how to verify the integrity of the file.


Second, we're now isolating/shielding the main site from the rest, and making parts unmodifiable, to prevent catastrophes in case of a break-in.


Third, we added several methods of detection when files and other data is modified.


Fourth, we'll only serve the files from the main site for now. While the mirror admins did not have any blame in this, it does mean we only have to protect our own site(s).


And finally we did some other things which I won't mention here.


In short: we've really tightened security since the break-in to make sure this will never ever happen again. As you may understand, we really can't afford a repeat of this incident.


On an unrelated side note, I find the claims in various media that this security incident indicates that Linux and Open Source cannot be trusted and that Microsoft and closed-software is better really silly. It lacks any foundation. A hacker, once in, could just as easily have inserted the backdoor in Windows software. In fact, it is *THANKS* to it being Open Source that this backdoor got noticed, though - I fully agree - much too late.


Hash Deep is helpful to find development files that have changed unintentionally, due to either simple disk corruption or malicious intent.  On Embedded Devices themselves I run CRC checks of the code.  SRecord is a big help in this area.



Returning back to SLFC's paper.  SFLC points to the case of Riegel v. Medtroni in February 2008, stating:




"Since the FDA is a federal agency, its authority supersedes state law. Based on the concept of preemption, the Supreme Court held that damages actions permitted under state tort law could not be filed against device manufacturers deemed to be in compliance with the FDA, even in the event of gross negligence."...


"It is clear that medical device manufacturers have responsibilities that extend far beyond FDA approval and that many companies have failed to meet their obligations," William H. Maisel said in recent congressional testimony on the Medical Device Reform bill.50 "Yet, the U.S. Supreme Court ruled in their February 2008 decision, Riegel v. Medtronic, that manufacturers could not be sued under state law by patients harmed by product defects from FDA-approved medical devices ... . [C]onsumers are unable to seek compensation from manufacturers for their injuries, lost wages, or health expenses. Most importantly, the Riegel decision eliminates an important consumer safeguard - the threat of manufacturer liability - and will lead to less safe medical devices and an increased number of patient injuries."



Here is part of that actual US Supreme Court Decision, that I took from Cornell:



"The Riegels contend that the duties underlying negligence, strict-liability, and implied-warranty claims are not pre-empted even if they impose " 'requirements,' " because general common-law duties are not requirements maintained " 'with respect to devices.' " Brief for Petitioner 34-36. Again, a majority of this Court suggested otherwise in Lohr. See 518 U. S., at 504-505 (opinion of Breyer, J.); id., at 514 (opinion of O'Connor, J., joined by Rehnquist, C. J., and Scalia and Thomas, JJ.).6 And with good reason. The language of the statute does not bear the Riegels' reading. The MDA provides that no State "may establish or continue in effect with respect to a device ... any requirement" relating to safety or effectiveness that is different from, or in addition to, federal requirements. §360k(a) (emphasis added). The Riegels' suit depends upon New York's "continu[ing] in effect" general tort duties "with respect to " Medtronic's catheter. Nothing in the statutory text suggests that the pre-empted state requirement must apply only to the relevant device, or only to medical devices and not to all products and all actions in general." --- Justice Scalia, Opinion of the Court; RIEGEL v. MEDTRONIC, INC. (No. 06-179)
451 F. 3d 104, affirmed.



Not being a lawyer, it seems to me that the Court just gave medical device manufactures a free pass to make defective products because there is no longer a threat of liability?  We have all seen the End User Licenses Agreements (EULA) for software that all say, using lots of Lawyer Weasel Words, "No mater what this software does to you and yours.  It is not our fault.  To bad for you."  Is this where hardware is now?