Medical

Healthcare and the 'Internet of Things'

By Santhosh Nair

The healthcare industry is embracing the 'Internet of Things.' From the advent of mHealth, to healthcare personnel bringing their own devices into the hospitals, to consolidations that are happening up and down the value chain, the healthcare industry is finally embracing its version of the Internet. It’s a topic that I discussed recently in a Q&A session with Intel Embedded Community. 

With the ability to provide affordable care to the masses topping the lists of political and socioeconomic agendas globally, we need to make a lot more progress on this front.  Here are some on why we're still not where we need to be in terms of the global adoption and institutionalization of these concepts.

The first issue is infrastructure. Despite the advent of wireless technologies and the commoditization of electronics, the adoption rate has been extremely low in the healthcare space.  Machine-to-Machine (M2M) connectivity is the building block for interoperability in healthcare. If you ask the device manufacturers, most of these standards are already implemented. The challenge is the variations in implementation and the network effects that are taking place – there is almost no incentive for a device manufacturer to invest in an infrastructure that doesn’t yield the benefit.

The second issue is the life cycle costs. If you look at imaging systems, thousands of systems are introduced into the market every year. Therapeutic life-sustaining devices like infusion systems and defibrillators have an installed base of hundreds of thousands or even millions. Yet, a new design (big iron) happens every 10-15 years. The regulatory climate around these devices makes the manufacturers very cautious in introducing change and failure could be extremely costly. In addition, innovation is not happening at the software level so that the device is future proofed. Compare this with something like iPad/iTunes/Apps upgrades. Most get an upgrade once a week, and may not even know about it. With healthcare systems, annual upgrades are a luxury for most of these device classes, and the cost of these upgrades is prohibitive, since most of it is tied to hardware upgrades.

The final issue is trust. An industry will not adopt any technology that it doesn’t trust. This is the primary the reason why there is physical human interaction connected to mundane tasks like billing, orders, scheduling, etc. in a hospital. This is not just unique to healthcare, but is applicable to other sectors like aviation, energy, and transportation.  Now take banking for instance -- gone are the days when people went to banks for basic transactions. It is now done over the Internet or via an ATM machine. The financial industry has automated most of the mundane tasks, while saving costs on expensive resources (like personnel) to value added activities like relationship management, and complex transactions. They have done this successfully via an outstanding implementation of security – adopting a design for security across their system. 

These examples demonstrate the great divide between consumer-driven enterprise systems and industry-driven embedded systems. While the enterprise has flourished and matured over the last 20 years of the Internet revolution, embedded devices continued to be homegrown and crafted. A lot of the maturity and ubiquity of enterprise and consumer systems have not yet permeated into the embedded world.

But now the healthcare industry has come to an inflection point, where there is no choice but to adopt some of the advancements of the consumer infrastructure. And there are signs that the industry is moving in that direction, i.e., GE talking about industrial internet, Cisco talking about Internet of Things, IBM talking about Smart Planet. At the grassroots level, silicon vendors are building a lot of M2M technology at the source so as to make it easier to develop sensor-based technologies.

It's definitely an exciting time to be a part of this industry and to be contributing to the advancements in this space with solutions like the Wind River Intelligent Device Platform, which is designed to resolve all of this ambiguity and make it easier for the healthcare industry to embrace the infrastructure.  I look forward for what’s to come.

For additional information from Wind River, visit us on Facebook.

Medical Device Security

By Jeff Fortin

A recent study published by GAO caused quite a bit of uproar over medical device security. The GAO declared in its report [read more] that the FDA has not put enough oversight in the premarket approval (PMA) of certain medical devices that are susceptible to threats. In the report the GEO referred to an experiment described in the 2008 IEEE Symposium on Security and Privacy. The experiment was conducted by a number of experts in security, medicine and engineering. They demonstrated the potential for a hacker to expose patient information as well as interfere with the correct operation of a medical device. The FDA has agreed to the GAOs insights – however pointed out that there have been no real world threats that have been reported to date.  According to the FDA, it did consider unintentional threats for information security, but did not consider information security risks from intentional threats until recently. In summary, the HHS – governing body for the FDA, concurred with the GAO recommendations and have initiated activity in this direction.  Medical device manufacturers must take the threat of security seriously.

Of all medical devices, devices that are implantable, portable or used in a home health scenario represent a growing concern for security and information privacy. I refer to these classes of devices as embedded medical devices. Developers and manufacturers of embedded medical devices are increasingly exposed to security risks as these devices become more complex and also connected to open networks. The good news is that in responding to this threat they need not operate in a vacuum nor do they need to re-invent the wheel. Best practices exist in other industries that can be leveraged by medical device manufactures. Of them the most straightforward is to design your products with security in mind. In other words, design for security. Here are a few things to think about when you design your medical devices.

Pre-market: Design for safety and security

Step 1: conduct an end to end threat assessment. Identify the threats, evaluate the impact of the test not only from the point of view of the manufacturer but also the end user and the ecosystem in which the device gets deployed.

Step 2: Develop an advanced system design for security. This may involve defining the workflows, partitioning the safety-critical function from non-critical functions, keeping the basic functionality alive in case of an emergency et al.

Step 3: Select the proper run time platform: Leverage technology such as a secure OS, embedded virtualization, and interoperable middleware. Also be sure to follow best practices regarding run-time and network configuration to improve the integrity of your design.

Step 4: Select proper tools and testing infrastructure for securing the systems

• Create a software development plan following an established software development methodology (examples: IEC 62304, IEEE/EIA 12207)
• Requirements analysis and traceablility
  • Requirements should include
    • Security manual including Standard Operating Procedures with a  method for updating
    • Risk mitigation requirements as identified in the End to End Threat Assessment
• Test Plan and Test Case Repository (Wind River Test Management)
  • Include vulnerability testing to validate risk mitigation requirements
• Identify data needed from the test results to support 3^rd party reporting
• Test Framework to help identify potentially malicious code
• Test mechanism to simulate hacker attacks
• Industry standard Fuzz testing to ensure protocol robustness

Production: Validate the system and ensure the right software is loaded into the system with no malware.

• Validation and authentication is a relatively new domain for certain medical devices. Methods used in the IT space tend to assume a reliable, cheap and nearly permanent connection to the end device. Such assumptions are not always possible for medical devices that are either implantable, portable or used in a home health scenario. But there is technology available that could help here. Authentication services for access to the device as well as secure updates and secure boot technology are available for these types of devices. For instance in the upcoming release of IDP 1.0, Wind River will be including a Secure Boot feature that will leverage the root of trust and the Trusted Platform Module (TPM) to ensure that the software on the device is authorized by the manufacturer.

Post-Market:

• Secure your applications. Lock down your applications to prevent unintended data access or  denial of service. McAfee provides excellent guidance as to how to qualify the applications that run on your product so as to prevent intrusion.
• Adopt a comprehensive life-cycle support process. Security is a constantly evolving problem. Include security updates in the lifecycle management of your device. The current published practices on this topic such as IEC 80001-1:2010 generally only address enterprise applications but Wind River has been helping companies deploy secure embedded devices for decades and can help your company do the same.

Waiting for the adverse event to happen and reacting to security afterwards may be very costly. Think Stuxnet and how it is changed the way the energy sector looks at security. We can be proactive and design for security in medical devices. While designing security consider both the enterprise and the embedded aspects of security. The embedded security part is often overlooked and can seriously undermine the efforts in locking enterprise security at the back office and servers. After all, information (data) originates at the embedded devices and the integrity of this data determines all the workflows that follow it.

 

For additional information from Wind River, visit us on Facebook.

Connected Health: Optimism on the Horizon

By Santhosh Nair

There are telling signs that mHealth is rapidly moving up the adoption curve. 

Earlier this year, Fuld & Company, a pioneer strategy consulting firm, conducted a national war gaming contest where leading business schools stress tested m-Health strategies of companies – ranging from large companies such as GE and Medtronic, to startups like Independa.

A few of the key takeaways from the exercise were:

• Mergers, alliances and licensing agreements are inevitable – the partner ecosystem is very important
• The value is in data integration, not killer applications
• A back office service industry will emerge as a new service model
• User centered design is the key to success

We are seeing the forces in motion already with the recent influx of venture capital in mHealth. Healthcare venture funding was up 75% in the first quarter of 2012 compared to the same period last year.  Some of the recent investments include: Khosla Ventures’ $10.5M investment in AliveCor, an Oklahoma based startup that makes an iPhone based ECG app – as well as its $1M investment in CellScope, a smartphone based Otoscope. Misfit Wearable, a wearable devices startup co-founded by former Apple CEO John Scully, raising $7.6M in capital.  In addition, the $100M West Health Investment Fund has been active in investing in companies that have cutting edge healthcare technologies and services.

mHealth adoption requires companies to take a hard look at their core strategy. Interoperability, safety, security, standards and agility are keys to success in the connected health ecosystem. Products need to be designed to work well with other products, and they must be designed to be safe and effective. These products need to be secure - hence the need for DFS (design for safety/security). The design should incorporate standard off-the-shelf components so that devices can easily plug and play into the grid of connected health. Finally, companies need to focus on their core competencies, as organic growth will only happen through focus – and they must be nimble and adapt to an evolving ecosystem.

Healthcare companies that are incumbent players should start designing products that integrate with the lifestyles of the people they are designed to serve, such as the home health market. Because the value chain will get complicated with a larger number of alliance partners, it is critical to invest adequate time and resources into picking credible partners that can build components better and faster than you can. New entrants and/or startups should remember that it is not an "us vs. them" scenario, cooperation and partnerships are the secret weapon to entry.

Business in 2012 and beyond will be done more through collaboration and partnerships. Companies that don’t play well with others may get left behind in the game, no matter how big they are. Together, we can improve the quality of lives of those around us.

 

For additional information from Wind River, visit us on Facebook.

 

Open source in Medical Devices: Part of the Cure or Part of the Disease?

By Ido Sarig

The Economist recently published a very interesting article on the merits of open source in medical device development, which raises some questions and sparks an important discussion. 

In general, it is more common to see open source adoption in non-regulated industries. However, we are seeing it more and more in regulated industries primarily because it encourages rapid innovation at far lower costs.  That said, it is important to caution those in the regulated industries (aerospace & defense, medical, industrial automation, energy, automotive) towards embracing open source concepts without investing in lifecycle management tools to support the building of safe and effective devices.  [Proprietary software on the other hand, is a better fit for companies that design devices in environments where changes are few and far in between. Proprietary software also enables better control of the ecosystem, the lower the stack you go.]

As the Economist puts it, “exposing a design results in safe products.”  Maybe…Designing a device or ecosystem with safety in mind, results in safer products, hence the need for “design for safety.”  The FDA mandates a safe and effective design for any devices that gets approved in the US market -- this requires companies to have better control of their ecosystem.  Done proactively, this is an efficient method for product development; however, done reactively, companies incur a lot of costs and overheads trying to make open source fit.

The basic premise of the Economist article, and apparently the FDA’s thinking is that the more eyes on the code, the more bugs will be detected. But that premise is questionable.  A recent study commissioned by the U.S. Department of Homeland Security’s Scan project found that “Where codebases were of similar size, open source code quality was pretty much on par with proprietary code quality.”  For example, the open-source Linux codebase, which is about 7 million lines of code averaged 0.62 per 1000 lines of code (KLOC), while proprietary code bases that averaged around 7.5 million lines of code had 0.64 defects per KLOC. So it seems that in large, complex code bases, such as medical devices, open source is not a panacea, and rigorous testing still has to be performed. One of the most challenging aspects of thoroughly testing medical devices is testing all the error handling code and the exception handling code. This code often makes up 50% or more of the overall code in embedded software, yet is the least tested- because the error conditions themselves are difficult to set up or simulate.

With Wind River Test Management’s Sensorpoint technology, one can easily inject faults directly into fully optimized, production-ready code as part of the test process, making it easier to achieve the complete code coverage required by the FDA for regulatory approval.  In fact, one of our customers was able to reduce the amount of time required to get their latest ultrasonic surgical  knife approved for use by the FDA by 15%, using Test Management’s Sensorpoints.

Another risk factor associated with open source is the fact that contributions come from multiple sources, whose identity is not fully known, exposing the device to the possibility that malware may be incorporated into the code base. As we’ve seen, having the code base exposed to more eyes does not, in and of itself guarantee lower defect rates, so it stands to reason that it does not dramatically reduce the incidence of security flaws.  The problem is exacerbated by the fact that open source libraries are often download from a repository that does not have the latest version of the components.  Research by Sonatype and Aspect Security released earlier this year, confirms this:  looking at the most popular open source Java frameworks and security libraries, they found that 26 percent had known vulnerabilities, and 41 percent were older versions of the components.  Testing for security, incorporating techniques such as Fuzz testing, can help reduce that risk. With Fuzz testing incorporated into Wind River Test Management, even non-security testing professionals can make security testing a part of their normal QA routine.

The bottom line is that enabling open source with industry-leading embedded lifecycle tools will be a happy medium for companies that don’t want to be left behind in technology advances during the life of their devices. If we can extend better healthcare to the masses through affordable open source platforms, we are all for it. Do connect with us to have a discussion on how embedded devices can embrace open source strategies by the right adoption of tools and processes.

How Are You Reducing Radiation?

By Pete MacKay

A few years back the FDA launched an initiative aimed at reducing radiation exposure in patients undergoing CT scans.  Clearly there are concerns with exposing the human body to ionizing radiation, and due to the prevalence and popularity of these imaging techniques the FDA feels they are in a position to ensure proactive steps are taken to minimize exposure.  They cite studies done in 2009 showing this total exposure to have nearly doubled in two decades in the US population.

Several factors come into play with cause and effect here, and the FDA is exploring several different perspectives.  Preventative measures start with educating patients, clinicians, and technicians, and altering approaches to therapy planning and the decision process around imaging studies.  The emergence of highly connected health enterprises (and society in general) enables a proposal to track cumulative dosage using tools like a national dosage registry and a patient medical imaging record – who knows, maybe just like Fido runs around with a chip in his neck we might all someday be implanted with a dosimeter along with our medical record?  Kidding aside, the obvious place to start with dosage reduction is with the device manufacturers themselves.

Not to carbon-date myself but I started in image processing back when an ALU was a very large (and warm) chip and processing functions comprised entire boards.  We needed big racks to accomplish a fraction of what’s now done in DSPs, GPUs, or even just coprocessor pipelines.  When I later worked for ADAC Laboratories in Milpitas, California – pioneers in nuclear medicine – I remember developing a network proxy (largely on my own time) for some of the embedded functionality of the piece I was working on.  We were building a transmissive system where a patient is radiated by a shuttered source on a robotic arm opposite sensors, and this prototype development took place in a lead-lined “safe” room.  I wrote code to run this machine from my desk so I wouldn’t have to spend time near the radiation.  One of our consultants chided me for this; he grabbed a Geiger counter and took four readings, the first two in the “safe” room with a barium source shuttered and un-shuttered, the next at my desk, and the last one in the parking lot outside.  Imagine my surprise to learn I did all that work only to find the lowest exposure was actually inside the safe room – even with a glowing source!

Fast forward to today… medical imaging device manufacturers are meeting dosage reduction goals with more sophisticated image processing algorithms that require massive processing power.  Engineering organizations now face cost reduction, tightened schedule expectations, and the demands of building extremely powerful yet flexible hardware/software architectures in a highly regulated environment.  Wind River can help meet these challenges with a range of integrated tools from Workbench to Wind River Test Management, performance-tuned compilers and libraries, advanced multi-core and virtualization technologies like Wind River Hypervisor, and systems expertise from Wind River Professional Services.  Wind River has helped manufacturers get all classes of medical devices approved for nearly the past three decades, and we can help meet radiation reduction imperatives in this one now.

 

For additional information from Wind River, visit us on Facebook.

Medical Device Interoperability: Collaboration is the New Competition in the Connected Health Ecosystem

By Santhosh Nair

A hospital is one of the most complex ecosystems that exist today. Nowhere else exists a more diverse array of players, devices and standards as a hospital. Information must flow seamlessly through the hospital ecosystem, and this needs to be sustained through the life of the patient, for treatment and care to happen in a meaningful manner. The bar for safe and effective use of devices is very high, which is why so few devices make it to market – and why many devices fail after market.

Enter medical device interoperability.  This week I spoke at the Medical Device Summit in Boston on the topic of interoperability, and it is clear that it is a very hot topic in the healthcare segment right now.

There are many definitions of medical device interoperability, but I define it as the ability of medical devices and healthcare systems to interact seamlessly with each other in order to enable better healthcare outcomes. Achieving interoperability requires: the adoption of standards, being safe, secure and connected across the ecosystem of the hospital and home, seamless integration of information through healthcare and telecom networks, and reducing the variability in workflows for treatment so as to enable a positive health outcome at the most optimal cost.

Interoperability is critical in the medical segment, but the industry has been slow to embrace it.  We live in a connected world, where data is ubiquitous; interoperability is table stakes in every other industry except healthcare. If planes, trains and automobiles can meaningfully interact and operate safely within their respective infrastructure, why can’t medical devices? Lack of interoperability is translating into skyrocketing costs and complexity in the medical industry, and is a huge roadblock to innovation in medicine.

In order to understand the barriers for interoperability, we need to look at the forces at play here. In order to ensure interoperability, three market forces need to come together.

1. Enforcement: Regulators, healthcare delivery organizations and standards organizations must collaborate to increase the pressure on complying with the standards.
2. Incentives: We need to devise an incentive system where a device manufacturer benefits from designing an interoperable system that works well with others. Let’s face it, this industry is an oligopoly and is extremely competitive. By its very nature, there is no incentive for one device manufacturer to connect well with another. Hence, the very system needs to be redesigned so as to nudge the device manufacturer to be interoperable. Interoperability is not where innovation happens, innovation happens at the application layers and that is where the value lies for device manufacturers.
3. Vertical Integration: Because of the history of this industry, many of the players are vertically integrated. This causes inefficiencies and raises the costs for these manufacturers. For interoperability to be successful, it needs to be pushed down a level in system design. Once standards are defined, there is no creativity involved in implementing them – because they can be bought from an off-the-shelf supplier of standards (think TCP/IP stacks, nobody writes their own any more).

These three forces need to come together to tilt the balance in the right direction. Device manufacturers need to put more onus on their suppliers to build interoperability standards as plugins that they can adopt, as opposed to developing them in-house. This will reduce variability and allow manufacturers to focus on applications they can build around connected devices. It is important to work with suppliers that can offer support with evolving interoperability requirements throughout the lifecycle of a product.

Wind River is working with an organization that is developing these standards and we hope to make this available as part of our standard medical middleware stack.  Lots of exciting developments to come – I’ll keep you posted!

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

IEC 62304, EN 62304...Confused?

 By Nikhil Chauhan

The requirements of IEC 62304 and EN 62304 are identical.  Both, IEC 62304 and EN 62304, share the same genealogy and are well recognized software life cycle standards. The only difference is that they are promoted by two different standardization bodies. IEC (International Electrotechnical Commission) and CENELEC adopted the same standard concurrently.

IEC 62304 is a worldwide recognized standard from IEC that defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes.

EN 62304 is promoted by CENELEC, the European committee for Electrotechnical Standardization which is officially recognized by the European Commission. According to Cenelec’s site, “CENELEC makes sure that the majority of its Standards are identical to the Standards developed by the IEC, the International Electrotechnical Commission. This is achieved thanks to the intense cooperation between both organizations, laid down in the Dresden Agreement, and through the participation of CENELEC members directly in IEC work.” The site also states, “In overall terms, 79% of CENELEC Standards are identical to or based upon IEC’s.” Per the description here, EN 62304 referenced IEC 62304 and also defines the life cycle requirements for medical device software. Just like IEC 62304, the set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes.

Conformance to either/both provides the evidence of having a software development process in place, and fulfills part of requirements of FDA’s 21 CFR 820.50 quality system regulation as well as the Medical Device Directive 93/42/EEC.

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.   

The Future of the World ‘Wired’ Mind?

By Pete MacKay

I never thought neurophysiology could be made so interesting – or blended with philosophy for that matter – but this is what author Michael Chorost does in his book World Wide Mind.  Recently one of our Project Managers forwarded a link to an interesting PBS News Hour piece pondering “Will ‘Bionic Bodies’ Offer High-Tech Hope to the Disabled?”.  The clip covered the exoskeleton from Berkeley Bionics, coincidentally featuring John Fogelin, former CTO of Wind River and an original author of the VxWorks RTOS.  It also featured one of my personal heroes, Dean Kamen, as well as an interview with writer and cochlear implant recipient Chorost, who discussed his latest book, World Wide Mind.

Because Sudoku only entertains so much, I dove into World Wide Mind on my flight over to the Medica show in Dusseldorf.  In it Chorost forms the hypothetical scenario where our minds are connected in mesh networks allowing us to communicate (somewhat) freely.  He lays his foundation on the concept of ‘telempathy’ rather than telepathy: “the apprehension of another person’s feelings rather than thoughts. “I suppose this perspective is shaped by experience with the computer already attached to his head; as he describes, cochlear implants don’t allow him to hear words but rather feel nerve stimuli that he had to learn to interpret into context to enable communication.

I found this book engaging because Chorost weaves together interesting hypothetical scenarios, fascinating research and discoveries taking place in labs today, and philosophical debate around privacy and security concerns with these possibilities.  Meanwhile he opens windows into personal life experiences and challenges, revealing intimate detail in order to relate connections of photons and electrons to those of mind and heart; synapse with sentiment, stimulus with subjectivity. 

Being patterned into a technologist through my youth and subsequent career, it is this intersection of science and humanity that I found refreshing.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.   

Hacking Insulin Pumps for Fun and Profit

By Ido Sarig

Last month, I had the opportunity to take part in the Amphion Medical Forum in Minneapolis, where the theme was security challenges facing Medical devices. Amphion is a forum that brings together thought leaders from academia, business, government and technology, which was founded to provide a medium for these visionaries to define solutions to some of the issues, such as safety and security, which affect the new interconnected economy, the “internet of things”.

I participated in a panel that discussed the challenges and risks posted by the latest generation of wireless medical devices, and how proper Fuzz Testing, such as the capability offered by Wind River Test Management in conjunction with our partner Codenomicon, can help alleviate some of that risk.

What really grabbed my attention was the opening session which consisted of a demo of hacking someone's Insulin Pump. It recounted a session given by Jay Radcliffe at this year’s Black Hat conference in Las Vegas. It was an enlightening session showing how vulnerable medical devices are to remote attacks carried out wirelessly, and honed in on the fact that device manufactures have to address two conflicting design goals  - ease of use and security. Features added to facilitate programming and updates of the software, such as wireless communication and remote controls, open up new attack vectors which utilize these interfaces, and enable hackers to penetrate the system using venues previously unavailable to them.

But as interesting as this presentation was, a lingering question hung in the air - Why would anyone want to hack an insulin pump? And if no-one has an incentive to do this, perhaps we should not be concerned about these security vulnerabilities?

Radcliffe did it for what could possibly be termed “fun”- he is a security researcher, with both a professional interest in seeing if it could be done, as well as personal interest – as he has such a pump implanted in his body. But could somebody attempt to do something like this for financial gain? Sadly, the answer is yes. There are several such scenarios – starting with the ominous blackmail scenario: An unethical hacker could find such an exploit, and then blackmail the manufacturer, asking for huge sums of money in exchange for divulging the exploit’s details and keeping quiet about it. Or he could sell the exploit to a competing company, figuring out they would want to publicize a vulnerability in their competitor’s devices. But it doesn’t even have to be that sinister to work. Suppose an unethical hacker finds vulnerability in a device made by a public company. All they have to do is sell short that company’s stock, then publicize the vulnerability and wait for the inevitable stock price decline that comes after the media frenzy, to make a pile of cash.

The bottom line is that neglecting to thoroughly test your medical device for security vulnerabilities,  thinking that no one will go through the effort required to hack for lack of incentive it is just plain wrong. If there is money to be made – and there clearly is – someone will do it.

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.   

Linux in Medical Devices

By Ken Herold

Linux is the operating system of choice for a wide range of medical devices, from vital sign monitors to hospital bedside “infotainment” systems to complex imaging and scanning equipment. Yet not all Linux is alike. Because patients’ lives may be in the balance, software used in medical devices must meet stringent regulatory guidelines to assure that it will perform as promised, and the provider must be able to pass audits of its development methodologies. Trying to cobble together solutions from pure Linux without commercial support puts the burdens of testing, validation, documentation and compliance on the device manufacturers and their developers – an onerous, time consuming and complex process that can turn “free” Linux into a very costly proposition.

There are, of course, commercial vendors of Linux who provide value-added, stabilized versions of the open source software, along with board support packages. Service, support and documentation levels, however, vary widely among them.  Some chip vendors provide software solely to drive processor sales and with many vendors, the relationship ends with the sale.

The Advantages – and Challenges – of Open Source

As an operating system, Linux has all of the advantages that open source presents. It’s free and can be modified and redistributed under the GNU General Public License (GPL). It has been widely adopted and embraced by thousands of developers. As a result, it’s easy to find developers who use it frequently and know it intimately. Linux also enjoys the support of all major hardware manufacturers and runs on virtually any processor. On top of that, it has a large ecosystem of board and software providers that use proven toolchains. And it is known for exceptional graphics support, including popular frameworks such as Qt and Android – important for device screens that require clarity and legibility.

For all its advantages, however, using Linux in a medical device also poses a number of challenges.

Any medical device marketed in the United States is regulated by the Center for Device and Radiological Health (CDRH), a branch of the Food and Drug Administration (FDA). Whether or not the device maker is claiming compliance to the medical device software standard IEC 62304, they must follow several FDA guidance documents.  Accordingly, Linux should be treated as Software of Unknown Provenance (SOUP) or Off-the-Shelf (OTS) software.  The FDA also makes it clear the burden of ensuring safe and reliable performance does not end with product launch. When evaluating operating systems, planning for bug fixes and security updates for the entire lifecycle of the product is mandatory.

Regulatory Perspective for Premarket Submissions

Medical devices and their components must undergo a hazard analysis, typically performed by the manufacturer. The purpose is not to try and predict a likelihood of failure, but to analyze the effect on the patient in the event of failure. The content for documentation of OTS software depends on the results of the hazard analysis performed. There are two levels of documentation, “basic” and “special”. 

To oversimplify the “Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices,” the more stringent “special” level may require an audit to establish:

• Assurance of development process: the vendor can demonstrate a proven, repeatable development process that adheres to best practices.
• Assurance of V & V for Linux: the vendor has performed verification and validation in accordance with accepted industry standards, and the results meet the manufacturer’s requirements.
• Maintenance and support plan for lifecycle (upgrades, bug fixes, patches): the vendor should have an ongoing maintenance and support plan, and offer the option of an extended support agreement if the projected life cycle of the product is longer than standard support for that release of Linux.

Choosing a commercial Linux vendor that can satisfy these requirements is essential.  The vendor must be able to supply the right level of documentation. As the FDA recommends, the device maker should not hesitate to conduct an audit if there is any concern about the vendor’s development methodology.

Wind River Linux has been subjected to a number of such audits and completed them all successfully. 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.