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.

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.   

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.   

Medical Devices, Life Savers

By Nikhil Chauhan

There's no doubt, medical devices are saving the most precious elements of nature - people's lives. The World Health Organization's video below highlights the importance of medical devices to health care.  Medical devices need to be secure and safe. My colleague Santhosh elaborated in a recent blog post on how FDA's 510(k) process is under scrutiny amidst the growing medical device recalls. 

FDA recognizes IEC 62304 that acts as a fantastic framework for the device vendors to develop, maintain and validate the medical device software. In order to focus on their differentiators, the device vendors rely on commercial off the shelf software. This third party software is categorized under SOUP (Software Of Unknown Provenance) of IEC 62304. So, device vendors include SOUP compliance requirements while dealing with software vendors such as Wind River Systems. Ken Herold elaborated on this in a recent blog post.

Amidst all this, the medical device manufacturers face four key challenges:

1. Quality and Cost - device is robust, installs easily, and is cost competitive. 
2. Compliance and Safety - built on platform that enables safety and provides risk mitigation, is ready for the approval process and complies with local regulations. 
3. Reliability - ensure that device does not become unavailable because of vulnerabilities.
4. Security - malicious attacks must not extract unauthorized device data. Not even the human body is immune from  hackers.

As Bill Graham pointed out in his recent blog post, the release of Wind River Platform for Medical Devices is significant news. The Platform hits the nail on the head by addressing all of the above mentioned challenges along with reducing time to market.

More information about Wind River Platform for Medical Devices is available here: http://www.windriver.com/announces/platform-for-medical-devices/

Strengthening Security for Connected Medical Devices

By Santhosh Nair

Three years ago an article in the New England Journal of Medicine reported that computer hackers could gain wireless access to implanted pacemakers and shut them off, or reprogram defibrillators to deliver fatal jolts of electricity. This generated an avalanche of press worldwide about the hidden risks of medical devices, followed by requisite hand-wringing from politicians and promises of stiffer regulations. For this and other reasons, makers of medical devices have been steadily increasing their focus on security. They realize that the threat is far broader than a hacked ICD. Embedded software is part of everything from CT scanners to imaging systems to intensive-care ventilators. And the fact is, the rapid growth in the number, the intelligence, and the interconnectedness of medical devices has created an upward spiral in security threats. 

Just a few examples:

● Diagnostics, therapy, and imaging devices are connected in the Hospital Imaging System (HIS), and a vulnerability in any one device puts the entire HIS at higher risk.

● In the United States, hackers have been able to glean personal patient data by eavesdropping on signals from wireless radios embedded in implants. 

● Security experts are worried that hackers might go after the medical devices designed to deliver medicine. In 2010, Dr. Tadayoshi Kohno and William Maisel of the Cardiovascular Institute of Beth Israel Deaconess Medical Center in Boston called for the FDA to regulate and work with medical device manufacturers to stop potential security breaches in a wide range of wireless devices.

● In Australia, the computer dispatch system for an ambulance service was infected by a virus, forcing staff to shut it down. As a result, health officials had to revert to coordinating the state’s paramedics and ambulances via a manual paper-based system—putting lives at risk.

Equally alarming, security exploits are being perpetrated by a new breed of hackers. It’s not just smart kids trying to breach a firewall for sport anymore. Professional, well-funded groups—including organized crime, government agencies, and terrorist cells—are attempting to crack into secure networks, access sensitive information, and alter the behavior of critical systems, causing physical harm to equipment and potentially putting lives at risk.

These security concerns have resulted in the formation of the Medical Device Innovation, Safety and Security Consortium (MDISS), a non-profit organization created earlier this year which aims to advance computer risk management practices.  The consortium is focused on optimizing the relationship between the quality of healthcare and the process of assessing and ensuring that devices and systems are secure.

For the developers of medical devices, two things have become crystal clear: first, tackling the emerging security challenges is an urgent imperative; and second, solving security issues can create significant competitive advantages. 

That is why medical device developers are now taking a more holistic approach to device security. Development teams are considering security issues at every layer of the development stack: the hardware platform, the virtualization technology, the operating system, the network stack or other communications middleware, the packets of data being sent across the network, and the applications.

By taking a platform perspective to security, and by harnessing the efficiencies of cyber-security-certified components, medical device developers can cut development costs and timeframes while actually decreasing overall security risks. That signals more than a paradigm shift for embedded developers—it’s a true transformation that will result in more secure medical devices and stronger financial results for development firms and the healthcare industry.

Highlights and hot topics from the Medical Devices Summit

By Santhosh Nair

There were a lot of great takeaways from the Medical Devices Summit that I attended last week in San Diego.  Wind River solutions architect Pete MacKay gave an excellent presentation about medical devices design, cloud and Android that was very well received and Intel ECG presented on embedded security and isolation/protection in medical device design.  Wind River had a booth where Michel Chabroux and Gabriel Quiroz showcased our Atlantis platform for connected medical devices - they demonstrated data traversing from an edge device (a weighing scale), all the way through the aggregator device to the final application.

Throughout the event, the topic that seemed to be on everyone’s mind was compliance.  Not surprisingly, conversations around regulations and compliance overshadowed many of the technology discussions.   Most of these talks centered on how to manage risk in your development process, the importance of having excellent design controls in place, managing suppliers and variance in your supply chain logistics, and how to navigate the regulatory maze and not get caught up in the trivia. 

Medical device manufacturers are focused on managing risk for creating safe and effective devices for the market. Having a solid risk management process, deploying tools and workshops to iron out the risks in product design, development and safety, and mitigating risk are critical to getting a device approved for the market. You may even get to market, but a lack of solid processes and structure will not keep you there for long. So what does that mean for suppliers of software and services?  They need to invest in processes and compliance that help ease the customers’ pain -- this means having a solid software development process and having the ability to provide traceability and artifacts for the software that they provide. 

Overall, a key takeaway from the show is that having a solid compliance story is essential to being a credible player in the industry. In fact, Wind River is doing a lot on the compliance front.  So, stay tuned for more compliance-related breakthroughs for our various platforms – as well as compelling compliance collaborations to develop assurance cases for medical devices.  It’s an exciting time to be in the medical space!