Tag - risk management
- Comments feed
Friday 6 July 2018
By Mitch on Friday 6 July 2018, 13:41 - Processes
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.
Friday 5 February 2016
By Mitch on Friday 5 February 2016, 13:45 - Regulations
Friday 29 January 2016
By Mitch on Friday 29 January 2016, 14:30 - Regulations
The FDA released one week ago a new draft guidance on Postmarket Management of Cybersecurity in Medical Devices.
This guidance is the sister of the guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices released in 2014. Both guidances address cybersecurity at different steps of software lifecycle: the 2014 guidance is about cybersecurity during design and development, the 2016 draft guidance is about cybersecurity during post-market surveillance.
Friday 9 January 2015
By Mitch on Friday 9 January 2015, 14:16 - Standards
The FDIS (final draft version) of IEC 62366-1 was released in November 2014. This version, also known as IEC 62366 2nd edition, is on the right track to be officially released in Q1 2015. It will supersede the IEC 62366:2007 + Amendment 1:2014.
Friday 21 November 2014
By Mitch on Friday 21 November 2014, 12:46 - Regulations
At last! The FDA has published last October a guidance about cybersecurity that matters!
Not that the guidance previously published about Off-the-shelf software cybersecurity wasn’t worth reading it (Guidance to Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software), but its scope was more than reduced.
Friday 28 March 2014
By Mitch on Friday 28 March 2014, 12:50 - Processes
We saw in the last post how to validate a software development tool. But we saw also that validating a compiler this way is not a satisfactory task.
Then: Why, when, and how to validate a compiler?
Friday 14 March 2014
By Mitch on Friday 14 March 2014, 13:26 - Processes
Validating the compiler used in software development is a recurring issue. To what extent a compiler should be validated, when, how and why?
In the same vein, we can extend the question of validation to all tools used in the software development environment: integrated development environment, configuration management tools, compiler (and linker), automated test tools.
Friday 17 January 2014
By Mitch on Friday 17 January 2014, 12:36 - Regulations
In the last article, we saw the concerns about the reliability of wireless connections and how to handle them.
Today, we are going to have a look at something quite important for mobile platforms: usability and humans factors engineering (HFE).
Friday 4 October 2013
By Mitch on Friday 4 October 2013, 13:24 - Templates
Risk matrixes are a useful way to show graphically the ranges in which risks are acceptable, tolerable and unacceptable. Here is an excel sheet that automates the computation of ranges.
Friday 20 September 2013
By Mitch on Friday 20 September 2013, 13:23 - Templates
Here is an update of Risk Management Plan and Risk Analysis Report templates.
Friday 28 June 2013
By Mitch on Friday 28 June 2013, 14:28 - Standards
This is today the last article of this series about SOUP.
SOUP is a concept that we find elsewhere than in the IEC 62304 standard. Namely in the FDA guidances.
Friday 14 June 2013
By Mitch on Friday 14 June 2013, 13:43 - Standards
After having discussed about open-source software in the last post, we continue today this series about SOUP with the case of standalone software.
Friday 7 June 2013
By Mitch on Friday 7 June 2013, 13:52 - Standards
After having discussed about frameworks and runtimes in the last article, we continue today this series about SOUP with the case of open-source software.
Friday 31 May 2013
By Mitch on Friday 31 May 2013, 15:06 - Standards
We saw in the first article of this series, what is a SOUP and what is not a SOUP, according to IEC 62304.
Then we continued in the second article by having a look at OS's and drivers.
Let's now see how to deal with runtimes.
Friday 24 May 2013
By Mitch on Friday 24 May 2013, 14:03 - Standards
We've seen in the last article, what is a SOUP and what is not a SOUP, according to IEC 62304.
We've also seen that a lot of 3rd party software are SOUPs, to begin with OS, drivers, runtimes, Just-In-Time (JIT) compilers and frameworks.
How to deal with those to be compliant with IEC 62304?
Friday 17 May 2013
By Mitch on Friday 17 May 2013, 14:21 - Standards
No need to reinvent the wheel when developing software. Everybody uses software made by 3rd parties, to begin with the operating system and general purpose libraries.
IEC 62304 has specific requirements about 3rd party software. What are these requirements and how do they affect software development and maintenance?
Friday 12 April 2013
By Mitch on Friday 12 April 2013, 20:34 - Standards
In the previous post, we've seen when it's mandatory to be compliant both with IEC 60601-1 and IEC 62304, and when IEC 60601-1 alone is enough.
But some manufacturers don't apply IEC 60601-1, mainly because their devices are not in contact with the patient or cannot be qualified are medical devices. We find in these categories in-vitro diagnosis instruments and laboratory instruments.
These instruments usually fall in the scope of IEC 61010-1. Let's see now the relationship between IEC 61010-1 and IEC 62304.
Friday 5 April 2013
By Mitch on Friday 5 April 2013, 16:50 - Standards
Manufacturers of medical devices often ask themselves the obvious question:
Is it mandatory to be compliant both with IEC 60601-1 and IEC 62304?
Similarly, manufacturers of in vitro diagnosis devices ask themselves:
Are my devices in the scope of IEC 62304?
Obviously, medical devices (MD) with electric or electronic components are in the scope of IEC 60601-1. And in-vitro diagnosis devices (IVD) with electric or electronic components are in the scope of IEC 61010-1.
Do MD and IVD that embed software, fall in the scope of IEC 62304?
This is not so obvious.
Friday 1 March 2013
By Mitch on Friday 1 March 2013, 14:31 - Standards
We've seen in the last post how to manage changes in legacy software. Let's see it from another point of view: the type of legacy software.
Friday 22 February 2013
By Mitch on Friday 22 February 2013, 14:09 - Standards
Most of medical devices manufacturers have legacy software that was not designed according to IEC 62304. The devices that embed legacy software were once verified and validated. These devices and their software work well and no major adverse event were raised by software issues.
But one day, the manufacturer decides that it's time to bring that legacy software into line with IEC 62304, to align the technical file of that software (or the contribution of software to technical file content) with up-to-date standard or regulatory requirements.