Tag Archives: medical devices

Killed by code – back to the future

Risk management, Risk mitigation, Software security, , , ,

Back in 2011, I thought it’s only a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device).

Fast forward to Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.

At risk:

  • Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

I’ve been talking to our medical device customers about mobile security of implanted devices for over 4 years now.

I  gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 ago and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.

But – ICD are the edge, the corner case of mobile medical devices.  If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.

Mobile medical devices are becoming a pervasive part of the Internet of things; a space of  devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.

There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)

The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that:

  • are intended to be used as an accessory to a regulated medical device, or
  • transform a mobile platform into a regulated medical device.

Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document  provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix A, Appendix B and Appendix C.

Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York  that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of  an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.

Killed by code – mobile medical devices

Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:

Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:

  • Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
  • Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
  • Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
  • Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.

At  Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.

Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).

The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of  the threat by industry groups like The Advanced Medical Technology Association is not constructive.

Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses”  this is a strident wakeup call to medical device vendors  to  implement more robust protocols  and tighten up software security of their devices.

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
Information Security Best Practices

What is more important – patient safety or hospital IT?

Data leakage, Information security, Software security, , , , , , , ,

What is more important – patient safety or the health of the enterprise hospital Windows network?  What is more important – writing secure code or installing an anti-virus?

A threat analysis was performed on a medical device used in intensive care units.  The threat analysis used the PTA (Practical threat analysis) methodology.

Our analysis considered threats to three assets: medical device availability, the hospital enterprise network and patient confidentiality/HIPAA compliance. Following the threat analysis, a prioritized plan of security countermeasures was built and implemented including the issue of propagation of viruses and malware into the hospital network (See Section III below).

Installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate more severe threats – ePHI leakage, software defects and USB access.

A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by medical device vendors and customers to model changes in risk profile as technology and operating environment evolve. The threat modelling software can be downloaded here.

Continue reading →

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
Federal Healthcare Chart

The chasm between FDA regulatory and cyber security

Compliance, Information security, medical device security, ,

 

When a Risk Analysis is not a Risk analysis

Superficially at least, there is not a lot of difference between a threat analysis that is part of a software/hardware security assessment and a risk analysis (or hazard analysis) that is performed by a medical device company as part of their submission to the FDA.    In the past 2 years, FDA added  guidance for cybersecurity for medical devices and the format and language of the guidance is fairly similar.

The problem is that hazard analysis talks about patient safety and relates to the device itself as a potential attacker whereas software  security talks about confidentiality of patient data, integrity of the code and its data and credentials and system availability and relates to the device as a black box.

So in fact – medical device risk analysis and cyber security assessments are 2 totally different animals.

Some of my best friends work in medical device regulatory affairs. I admire what they do and I like (almost) all of them on a personal basis.

But – over the past year, I have been developing a feeling of deep angst that there an impossible-to-cross chasm of misunderstanding and philosophy that exists between medical device regulatory people and medical device security analysts like me.

But I can no longer deny that even at their best – regulatory affairs folks will never get security.

Why do I say this?   First of all – the empirical data tells me this.  I  interface with several dozen regulatory professionals at our medical device security clients in Israel and the best of them grasp at understanding security.  The worst cases hang on to their document version controls for dear life and claim earnestly even as they are hacked that they cannot modify their device description because their QA process needs several weeks to approve a 3 line bug fix. (This is a true story).

We intend to implement encryption of EPHI in our database running on a cloud server since encryption uses check sums and check sums ensure integrity of the data and help protect patient safety.
True quote from a device description of a mobile medical device that stores data in the cloud…the names have been concealed to protect the innocent.  I did not make this up.

The chasm between FDA regulatory and cyber security

The second reason I believe that there is an impossible-to-cross chasm between medical FDA device regulatory people and medical device security is much more fundamental.

Systems like mobile medical devices live in the adversarial environment of the Internet and mobile devices. Unlike traditional engineering domains like bridge-building that are well understood and deal with winds that obey rules of physics and always blow sideways; security threats do not play by set rules. Imagine a wind that blows up and down and then digs underground to attack bridge pylons from 50m below earth and you begin to understand what we mean when we say “adversarial environment”.

General classes of attacks include elevation of privilege, remote code execution, denial of service and exploits of vulnerable application interfaces and network ports. For example:

  • Attacker that steals personal data from the cloud by exploiting operating system bugs that allow elevation of privilege.  Zero-days that were unknown when your QA people did V&V.
  • Attacker that exploits vulnerabilities in directory services that could allow denial of service. What ?  We’re using directory services???
  • Attacker that tempts users to download malicious mobile code that exploit mobile APIs in order to steal personal data. What?  This is just an app to measure blood sugar – why would a patient click on an add that injects malicious code into our code while he was taking a picture of a strip to measure blood sugar??

We talk about an attacker in an abstract sense, but we don’t know what resources she has, when she will attack or what goals she has. Technology changes rapidly; a system released 2 years ago may have bugs that she will exploit today. Our only recourse is to be paranoid and think like an attacker.

Thinking like attackers not like regulators

By being extremely paranoid and thinking like attackers, medical device security requires us to systematically consider threat models of attacks, attack vectors, assets at risk, their vulnerabilities and appropriate security countermeasures for prevention, detection and response.

While this approach is not a “silver bullet” it lends structure to our paranoia and helps us do our job even as the rules change.

And this where the chasm begins.   The rules change.   There is no QA process. There are no rules.   We are not using IEEE software engineering standards from 40 years ago.  They are useless for us.

Dorothy – we are not in Kansas anymore. And we are definitely not in Washington DC in a regulatory consulting firm of high-priced lawyers.

 

 

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
dilbert Data Security

3 things a medical device vendor must do for security incident response

Compliance, Data leakage, medical device security, , , , ,

You are VP R&D or CEO or regulatory and compliance officer at a medical device company.

Your medical devices measure something (blood sugar, urine analysis, facial anomalies, you name it…). The medical device interfaces to a mobile app that provides a User Interface and transfers patient data to a cloud application using RESTful services over HTTPS.

Sound familiar?

The Medical device-Mobile app-Cloud storage triad is a common architecture today for many diagnostic, personal well-being and remote patient monitoring indications.

We have numerous clients with the Medical device-Mobile app-Cloud storage system architecture and we help them address 4 key security issue –

  1. How to ensure that personal data and user authentication data is not stolen from the mobile medical app,
  2. How to ensure that the mobile medical app is not used as an attack pivot to attack other medical device users and cloud servers,
  3. How to comply with the HIPAA Security Rule and ensure that health data transferred to the cloud is not breached by attackers who are more than interested in trafficking in your users’ personal health data,
  4. How to execute effective security incident response and remediation – its a HIPAA standard but above all – a basic tenet for information security management.

How effective is your security incident response?

The recent SANS Survey on Security Incident Response covers the challenges faced by incident response teams today—the types of attacks they detect, what security countermeasures they’ve deployed, and their perceived effectiveness and obstacles to incident handling.

Perceived effectiveness is a good way of putting it – because the SANS Survey on Security Incident Response report has some weaknesses.

First – the survey that is dominated by large companies: over 50% of the respondents work for companies with more than 5,000 employees and fully 26% work for companies with more than 20,000 employees.    Small companies with less than 100 employees – which cover almost all medical device companies are underrepresented in the data.

Second – the SANS survey attempts, unsuccessfully, to reconcile reports by the companies they interviewed that they respond and remediate  incidents within 24 hours(!) with reports by the PCI (Payment Card Industry) DSS (Data security standard) Association that retail merchants take over 6 months to respond.       This gap is difficult to understand – although it suggests considerable variance in the way companies define incident response and perhaps a good deal of wishful thinking, back-patting and CYA.

Since most medical device companies have less than 100 employees – it is unclear if the SANS findings (which are skewed to large IT security and compliance organizations) are in fact relevant at all to a medical device industry that is moving rapidly to the medical device-App-Cloud paradigm.

3 things a medical device vendor must have for effective incident response

  1. Establish an IRT.  (Contact us and we will be happy to help you set up an IRT and train them on effective procedure and tools).  Make sure that the IRT trains and conducts simulations every 3-6 months and above all make sure that someone is home to answer the call when it comes.
  2. Lead from the front. Ensure that the head of IRT reports to the CEO.   In security incident response, management needs to up front and not lead from behind.
  3. Detect in real time. Our key concern is cloud server security.    Our recommendation is to install OSSEC on your cloud servers. OSSEC sends alerts to a central server where analysis and notification can occur even if the medical device cloud server goes down or is compromised.
Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
skin mounted medical devices

On Shoshin and Software Security

Data leakage, Information security, medical device security,

I am an independent software security consultant specializing in medical device security and HIPAA compliance in Israel.   I use the state-of-the art PTA – Practical Threat Analysis tool to perform quantitative threat analysis and produce  a bespoke, cost-effective security portfolio for my customers that fits their medical device technology.

There are over 700 medical device companies in Israel – all doing totally cool and innovative things from My Dario (diabetes management), to Syneron (medical esthetics),  to FDNA (facial dysmorphology  novel analysis at your fingertips) to Intendu (Brain Rehabilitation).

This is a great niche for me because I get to do totally cool projects and  work with a lot of really smart people at Israeli medical device vendors helping them implement cost-effective  security and privacy compliance + it’s fun learning all the time.

One thing I have learned is that there is very little connection between FDA medical device risk assessments and a software security risk assessments.   This somewhat counter-intuitive for people who come from the QA and RA (regulatory assurance) areas.

Security is an adversarial environment very unlike FDA regulatory oversight.

FDA medical device regulatory oversight is about complying in a reliable way with standard operating procedures and software standards.

FDA believes that conformance with guidance documents, when combined with the general controls of the Act, will provide reasonable assurance of safety and effectiveness…

FDA recognizes several software consensus standards. A declaration of conformity to these standards, in part or whole, may be used to show the manufacturer has verified and validated pertinent specifications of the design controls. The consensus standards are:

  • ISO/IEC 12207:1995 Information Technology – Software Life Cycle Processes
  • IEEE/EIA 12207.O-1996 Industry Implementation of International Standard ISO/IEC12207:1995 (ISO/IEC 12207) Standard for Information Technology – Software Life Cycle Processes

Barry Boehm succinctly expressed the difference between Verification and validation:

Verification: Are we building the product right?

Validation: Are we building the right product?

Building the right product right is no more a guarantee of security than Apple guaranteeing you that your Mac Book  Pro  will not be stolen off an airport scanner.

Medical device security is about attackers and totally unpredictable behavior

Medical device security is about anticipating  the weakest link in a system that can be exploited by an attacker who will do totally unpredictable things that were inconceivable last year by other hackers, let alone 20 years ago by an ISO standards body.

You cannot manage unpredictable behavior (think about a 2 year old) although you can develop the means for anticipating threats and responding quickly and in a focused way even when sleep-deprived and caffeine-enriched.

The dark side of security is often hubris and FUD.

For security consultants, there is often an overwhelming temptation to show clients how dangerous their security vulnerabilities are and use that as a lever to sell products and services.   I’ve talked about hubris and FUD here and here and here and here and here.   A good example of exploiting clients with security FUD are the specialty HIPAA-compliant hosting providers like Firehost that are masters of providing expensive services to clients that may or may not really need them.

However, I believe that intimidation is not necessarily a strategy guaranteed to win valuable long-term business with clients.

Instead of saying – “that is a really bad idea, and you will get hacked and destroy your reputation before your QA and RA departments get back from lunch“,  it is better to take a more nuanced approach like:

“I see that you are transferring credentials in plain-text to your server in the cloud.   What do you think about the implications of that?“.   Getting a client to think like an attacker is better than dazzling and intimidating them which may result in  the client doing nothing, hunkering down into his current systems or if the client has money – going off and spending it badly.

How did I reach this amazing (slow drum roll…) insight?

About 3 years ago I read a book called Search Inside Yourself and I learned an idea called – “Don’t take action, let action take you“.    I try to apply this approach with clients as a way of helping them learn themselves and as a way of avoiding unnecessary conflict.  The next step in my personal evolution was getting acquainted with a Zen Buddhist concept  called Shoshin:

Shoshin (初心) means “beginner’s mind”. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

Shoshin means doing the exact OPPOSITE of what you (the high-powered, all-knowing, medical device security consultant) would normally do in the course of a security threat assessment:

  1. Let go of the need to add value – you do not have to provide novel security countermeasures all the time. Sometimes, doing the basics very well (like hashing and salting passwords) is all the value the client needs.
  2. Let go of the need to win every argument – you do not have to show the client why their RA (regulatory assurance) manager is making fatal mistakes in database encryption after she took some bad advice from Dr. Google.
  3. Ask the client to tell you more – ask what led them to a particular design decision.  You may learn something about their system design alternatives and engineering constraints. This will help you design some neat security countermeasures for their medical device and save them some money.
  4. Assume you are an idiot –  this is a corollary of not taking action.   By assuming you are an idiot, you disable your ego for a few moments and you get into a position of accepting new information  which in the end, may help you anticipate some threats and ultimately take your client out of potentially dangerous adversarial threat scenario.

Thank you to James Clear for his insightful post – Shoshin: This Zen Concept Will Help You Stop Being a Slave to Old Behaviors and Beliefs

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
skin mounted medical devices

Shock therapy for medical device malware

Risk management, Software security, , , ,

Israel has over 700 medical device vendors.  Sometimes it seems like half of them are attaching to the cloud and the other are developing mobile apps for all kinds of crazy, innovative applications like Healthy.io ( Visual Input Turned Into Powerful Medical Insight – translation: an app that lets you do urine analysis using your smart phone).

But – let’s not forget that many Medical devices  such as bedside monitors, MRI, nuclear medicine and  catheterization devices all reside on today’s hospital enterprise network.

An enterprise hospital network is a dangerous place.

Medical devices based on Microsoft Windows  can be extremely vulnerable to attack from hackers and malware who penetrate the hospital network and exploit typical vulnerabilities such as default passwords.

More importantly – medical devices that are attached to a hospital network are a significant threat to the hospital network itself since they may propagate malware back into the network.

While a thorough software security assessment of the medical device and appropriate hardening of the operating system and user-space code is the best way to secure a medical device in a hostile hospital network – this is not usually an option for the hospital once the medical device is installed.

Taking a page out of side-channel attacks and using the technique to detect malware, University of Michigan researchers have developed WattsUpDoc, a system designed to detect malware on medical devices by noting small changes in their power consumption.

The researchers say the technology could give hospitals a quick way to identify medical devices with significant vulnerabilities.

The researchers tested WattsUpDoc on an industrial-control workstation and on a compounder, which is used to mix drugs.

The malware detector first learned the devices’ normal power-consumption patterns. Then it tested machines that had been intentionally infected with malware. The system was able to detect abnormal activity more than 94 percent of the time when it had been trained to recognize the malware, and up to 91 percent of the time with previously unknown malware. The researchers say the technology could alert hospital IT administrators that something is wrong, even if the exact virus is never identified.

For the full article see WattsUpDoc

 

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow

The death of the anti-virus

Compliance, Information security, , ,
Does anti-virus really protect your data?

 

Additional security controls do not necessarily reduce risk.

Installing more security products is never a free lunch and tends to increase the total system risk and cost of ownership, as a result of the interaction between the elements.

We use the quantitative threat analysis tool – PTA that enables any business  to build a quantitative risk model and construct an economically-justified, cost-effective set of countermeasures that reduces risk in your and your customers’ business environment.

Like everything else in life, security is an exercise in alternatives.

But – do you choose the right one?

Many firms see the information security issue as mainly an exercise permissions and identity management (IDM). However, it is clear from conversations with two of our large telecom customers that (a) IDM is worthless against threats of trusted insiders with appropriate privileges and (b) Since the IDM systems requires so much customization (as much as 90% in a large enterprise network) it actually contributes additional vulnerabilities instead of lowering overall system risk.

The result of providing inappropriate countermeasures to threats, is that your cost of attacks and ownership go up, instead of your risk going down. This is as true for a personal workstation as it is for a large enterprise network.

The question from a security perspective of an individual user is pretty easy to answer. Install a decent personal firewall (not Windows and please stay away from Symantec) and be careful.

For a business, the question is harder to answer because it is a rare company that has such deep pockets they can afford to purchase and install every security product recommended by their integrator and implement and enforce all the best-practice controls recommended by their accountants.

An approach we like is taking standards-based risk assessment and implementing controls that are a good fit to the business.

We use the quantitative threat analysis tool – PTA that enables any business  to build a quantitative risk model and construct an economically-justified, cost-effective set of countermeasures that reduces risk in their and their customers’ business environment.

More importantly, a company can execute a “gentle” implementation plan of controls concomitant with its budget instead of an all-or-nothing compliance checklist implementation that may cost mega-bucks.

And in this economy – fewer and fewer businesses have the big bucks to spend on security and compliance.

Software Associates specializes in helping medical device vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments in the best and most cost-effective way for your business and pocketbook.

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
risk-driven medical device security

Why anti-virus doesn’t work for medical devices

medical device security

Are you checking off medical device security in your hospital with anti-virus:  falling for security theater; feeling secure and enjoying the show,  but in fact being less secure?

A medical device is not an office PC

The most commong security countermeasure in use today is anti-virus software for Windows-based workstations  to protect the Windows PC from malicious software from removable devices, email, and Web channels. ( I will refrain from religious debate on Mac vs. Windows vs. Linux).

However – the traditional consumer/IT enterprise anti-virus is  not an effective security countermeasure for medical devices in a hospital.

The majority of medical devices on a hospital network don’t have network connectivity.

Without network connectivity, ongoing update of AV software and signatures is impractical for the medical device vendor since it require regression testing and update of  units in the field.

Without network connectivity, the devices cannot be managed by a central system like McAfee ePO and in a best case  run outdated engine and AV signatures. In these cases the anti-virus is worthless, and the result is security theater: feeling secure and enjoying the show,  but in fact being less secure. Without central endpoint  or network monitoring we do not even know if the medical device was infected.

What do hospitals and medical device vendors do?

It depends.

Some hospitals are sticky about a particular AV package and as a result big device vendors like GE have gone to the trouble to validate all major AV vendors on their networked devices. 

Other hospitals take a more calculated and risk-driven approach with their medical device vendors and evaluate the threats and vulnerabilities.

A risk-driven approach, based on achieving cost-effective medical device security is precisely what the FDA requires in it’s latest draft guidance for medical device cyber security

However, the business case for a customized security countermeasure portfolio for each medical device vendor is weak to say the least and it is a fair assumption that both medical device vendors and hospital security and compliance groups  prefer a vendor-neutral standards-based solution for preventing malicious software that attacks the medical device on their hospital network.

While an anti-virus is standard, it is not vendor-neutral and even when installed it is probably worthless since the medical device doesn’t have network connectivity.

In broad terms – there are 2 key use cases for medical device security:

Embedded medical devices such as bedside monitors

An embedded medical device vendor may select Linux (for example Debian or Ubuntu) as the target operating system and by deactivating USB access and controlling the code carefully – may create a secure medical device which is extremely hardened to Windows-based  malicious software. In this case – medical device security doesn’t require an anti-virus.

System level medical devices such as MRI that run Windows

These are many larger Windows-based medical devices that integrate a large software application with special hardware and integrated  interfaces to other systems on the hospital network (such as PACS) – examples are MRI.

A medical device that runs Windows will definitely need to deal with threats of malicious software attacking the medical device via USB and launching an attack on the hospital network – attacking patient privacy and availability of resources such as PACS servers.  

Manual anti-virus updates are a threat to medical devices

Since the device doesn’t have Internet or enterprise hospital network access, IT administration will need to manually update the devices’ anti-virus engine and signature file using removable media – which creates an additional vulnerability of a infected Flash disk devices infecting the device and propagating malicious software back into the hospital network. So – manual updates are a bad idea.

Summary

Effective protection against malicious software in medical devices should work without requiring centralized network connectivity (unrealistic for the hospital) and installation of anti-virus agents (unrealistic for the medical device).

If you are developing an embedded device – you are better off with Linux.  

If you unfortunately are stuck with a Windows-based system – you will need to find a non anti-virus solution whether application white listing or future solutions such as WattsUpDoc.

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
risk-driven medical device security

Health Information Technology Patient Safety Action & Surveillance Plan

Risk management, , , ,

This is a quick update on two new documents released by the HHS and the IMDRF:

 Health Information Technology Patient Safety Action & Surveillance Plan

The US Department of Health and Human Services published on July 2, 2013 the Health Information Technology Patient Safety Action & Surveillance Plan. The FDA belongs to the HHS.

The plan defines several types of action in three categories: Learn, Improve, Lead.

·       Learn – focuses primarily on monitoring of safety of Health IT in the field.

·       Improve – includes investigating adverse events and taking corrective action. Also included are setting safety priorities and incorporating safety into certification criteria for Health IT.

·       Lead – encourages the private sector leadership for Health IT Safety and develops a risk-based regulatory framework for Health IT.

The plan is found at http://www.healthit.gov/sites/default/files/safety_plan_master.pdf .

 Standalone Medical Device Software: Key Definitions

The International Medical Device Regulators Forum, a medical device-focused regulators-only successor group to the Global Harmonization Task Force (GHTF), has released a new document for consultation regarding the definition of standalone software used for medical purposes.

The document, Standalone Medical Device Software: Key Definitions, was released on 1 July 2013 and is being coordinated by the FDA.

As the document explains, “Software for medical purposes is becoming increasingly important and … can appear in many forms and on many computing platforms.” For example, some software is embedded into a type of medical device, while others are sold as stand-alone software meant to work on a variety of devices (e.g. mobile devices) or settings (e.g. cloud-based computing or local networks).

A major issue with respect to regulators is the fast pace at which the technology is progressing. Accordingly, this leads to problems in understanding what is required and what is expected (note: what is required is not necessarily what is expected and what is expected is not necessarily what is required).

The document provides a detailed analysis and definition of standalone medical device software (SMDS). According to the IMDRF, medical device software – which is defined as a medical device — “may include but are not limited to” the following characteristics:

·       capable of running on general purpose (non-medical purpose) computing platforms

·       not necessary for a hardware medical device to achieve its intended medical purpose

·       may be used in combination (e.g., as a module) with other devices

·       may be interfaced with other medical devices, including hardware medical devices and other standalone medical devices software

Software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS.

The document is found at http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-sskd-130701.pdf.

If there are any questions, please contact us.

 

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow
epidermal electronics

Software in Medical Devices – Update

Compliance, Risk Assessment, Risk management, Risk mitigation, Software security

We have previously written about various aspects of the software development process, especially, the verification and validation activities in implanted and invasive medical devices.

Here is  an update on what is happening in the regulatory arena and how the regulatory groups are checking up on what we are doing.

Software Recalls 2012

The estimate for software recalls by the FDA for 2012 is 173. The software recalls for 2011 were 177 and for 2010 were 76. So far there are quite a few software recalls in 2013.

There are a number of new guidances and standards released and soon to be released – it’s worth getting up to speed if you are developing software for medical devices and concerned about reliability and software security:

  1. 21 CFR 880.6310, Medical Device Data Systems, FDA – released. This standard relates to hardware or software products that transfer, store,convert formats, and display medical device data. This application can be defined as a medical device which is a Class I device instead of the classification of your system. It has been used by a number of companies to define gateways between systems.
  2. ISO 82304-1, Healthcare Software Systems – Part 1: General Requirements For Product Safety – to be released maybe later this year. There is a draft copy out. This relates to medical devices that are only software. 
  3. MEDDEV 2.1/16, January 2012 – Guidelines on the qualification and classification of standalone software used in healthcare within the Regulatory framework of medical devices 4) ISO/IEC TIR 80002-1:2009, Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software – refers to the risk analysis on the software. This is an interesting aspect as we tend to analyze the risks on a system level.  If you have any questions please contact us. 
  4. ISO/IEC TR 80002-02, Medical device software – Part 2: Validation of software for regulated processes – to be released maybe later this year. This refers to software used in the all other aspects in the organization. 
  5. IEC 80001-1:2010, Application of Risk Management for IT Network incorporating Medical Devices – This is the risk management doctrine for hospitals, etc. employing medical devices on the network. If you supply your system to a hospital, you may be requested to let the hospital know if you are 8001 compliant. Once we know more on this, we’ll update you. 
  6. AAMI TIR45:2012, Guidance on the use of agile practices in the development of medical device software – This is a technical report from the AAMI on the use of Agile in the software development.
  7. AAMI/ANSI SW87:2012, Application of Quality Management System concepts to Medical Device Data Systems (MDDS) – provides guidance for Application of Quality Management System concepts to Medical Device Data Systems (MDDS) 
  8.  AAMI TIR on Guidance on Health Software Safety and Assurance – future release
  9.  AAMI TIR on Classification of defects contributing to unacceptable risk in health software – future release

Click here to download the full article on FDA standards and guidance and software in medical devices  Software Update 020613

Courtesy of my colleague Mike Zeevi

Tell your friends and colleagues about us. Thanks!
Share this
Email, RSS Follow