Usability is a requirement, which has been present in regulations since a long time. It stems from the assessment of user error as a hazardous situation. It is supported by the publication AAMI HE75 standard, FDA guidances, and the publication of IEC 62366 in 2008 followed by IEC 62366-1:2015.
Although usability engineering is a requirement for the design of medical devices, most of people designing software are not familiar with this process. This article is an application of the process described in IEC 62366-1 to software design.

European Regulation 2016/679, aka GDPR, will be fully in force in May 2018. Everybody knowns that we have something to do to be compliant since it has been published. And everybody is getting awake only two months before the full application. So do I.

Here is a quick follow-up of the new version of the FDA Guidance titled Medical Device Accessories – Describing Accessories and Classification Pathways, published in December 2017. This comes a bit in parallel to the Section 3060 guidance described in the previous post on the 21st Century Cures Act.

Since the last blog post on US FDA guidance on software classification, things evolved quickly with the FDA. We know where they want to go with software as medical device, but not exactly how they will implement it.
Let's do a review of what has been done since the publication of the 21st Century Cures Act.

A reader of the post on IEC 62304 Amd1 2015 noticed in the comments that the sentence in section 4.3.a was removed:

If the HAZARD could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent.

Don't be too quick to scratch the 100 percent thing!

The dreadful 100 percent is still present in the informative Annex B.4.3.

Even if it is no more in the normative part, you shall continue to bear in mind this assumption when assessing software risks. The underlying concept is that it's not possible to assess probability of software failure, thus the worst case shall be considered.
This is the state-of-the-art, present in ISO 14971, in IEC 80002-1, in IEC 62304, and in the FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices.

If you are a regular visitor of this blog, you noticed that almost three months elapsed between the last two articles on cybersecurity.
That's not what I planned.

The time dedicated to this blog was totally swallowed by the other facets of my job. Namely filling the gap between the current level of compliance of manufacturers, and the new expectations of notified bodies and regulatory authorities in the European Union. The bar has been raised!

Happy New Year!

After a long interruption, we continue this series on cybersecurity in medical devices with a review of stakeholders involved or concerned by cybersecurity requirements, and the consequences on architectural choices.

The FDA released a guidance on clinical evaluation of standalone software medical device (a.k.a SAMD) in October 2016. This guidance is the same text and has the same presentation as the International Medical Device Regulatory Forum (IMDRF) guidance on SAMD clinical evaluation published in August 2016.

IEC 82304-1:2016, the missing link on standalone medical device software validation has been published!
See the official version on IEC webstore, and comments made on the FDIS (the final version shouldn't have changed).

We begin today a series of posts on cybersecurity in medical devices. Cybersecurity was not a subject before the advent of computerized medical devices. Now that every manufacturer wants its connected medical device, cybersecurity matters!
Let's start with the regulations.

We've seen in the previous article the revolution in the regulatory classification brought by the new rule 10a for standalone software.
Let's see now the other changes. These changes are relevant for all software: standalone, embedded, device or accessory.
They're not as big as the new rule 10a, but they will deserve a significant amount of man-hours and documentation.