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 26 April 2013
By Mitch on Friday 26 April 2013, 14:39 - Standards
Want to see latest news about IEC 62304 2nd Edition?
Have a look at this thread on Elsmar Cove Forum: Update on IEC 62304 revision.
This thread contains an interesting discussion about the topics that are being amended in IEC 62304 by IEC working group:
- Safety classes,
- Legacy software.
Note: for those who don't know Elsmar Cove forum, it's probably the best forum about quality management and standards.
EDIT: elsmar cove forums is dead, see RIP elsmar cove.
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 8 March 2013
By Mitch on Friday 8 March 2013, 14:09 - Standards
We've seen in the two previous posts several solutions on how to treat legacy software according to IEC 62304.
But there is nothing equivalent to this discussion in IEC 62304. The standard is silent about these situations.
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.
Monday 21 January 2013
By Mitch on Monday 21 January 2013, 15:34 - Standards
In the last two posts, we've seen what a software unit is, and when to do software detailed design, according to IEC 62304 and FDA Guidances.
Friday 18 January 2013
By Mitch on Friday 18 January 2013, 15:45 - Standards
In my last post, I explained what criteria should be taken to define the level of details of software units in a software design. This activity is not mandatory for all levels of risk of software in medical devices, though, according to IEC 62304.
Friday 11 January 2013
By Mitch on Friday 11 January 2013, 14:08 - Standards
IEC 62304 requires to split architecture of class C (mission critical) software into software items and software units. Software units are software items that can't be split into sub-items, according to the standard. Okay. But how to decide that an item can't be split into sub-items, and is a unit?
Friday 9 November 2012
By Mitch on Friday 9 November 2012, 14:06 - Misc
Endeavour Agile ALM is an Open-Source solution for Agile project and resource management.
Friday 2 November 2012
By Mitch on Friday 2 November 2012, 14:11 - Processes
Following the article about software verification, let's see what software validation is.
Friday 26 October 2012
By Mitch on Friday 26 October 2012, 14:09 - Processes
Many people make the confusion between verification and validation. There is no exception for software! I'd even say that the confusion is even worse for standalone software.
Let's see first the definition of verification and validation. I borrowed these definitions from the FDA website:
- Verification is confirming that design output meets the design input requirements,
- Validation is ensuring that the device conforms to defined user needs and intended uses.
OK, this remains theoretical. How to do that with software medical devices?
In this article I focus on verification and will focus on validation in the next article: What is software validation.
Friday 28 September 2012
By Mitch on Friday 28 September 2012, 12:10 - Misc
In two previous articles, I talked about the differences of bugs, software failures, and risks.
I left the discussion unfinished about the probability of occurence of a software failure or a defect.
I think that assessing the probability of occurence of a software failure is a hot subject. I've already seen many contradictory comments on this subject. It's also a hot subject for software manufacturers that are not well used to risk assessment.
Friday 6 July 2012
By Mitch on Friday 6 July 2012, 13:17 - Processes
Are agile methods compatible with the constraints of development set by IEC
62304 standard of class C software?
series of three posts about agile methods and risks analysis. I focus in
this post on IEC 62304 class C critical software.
Saturday 23 June 2012
By Mitch on Saturday 23 June 2012, 16:40 - Processes
We've seen in my last post that it's possible to have agile development methods combined with a risk management process. To be compliant with ISO 14971 standard, a risk management plan that describes this process along iterations, has to be written. And a risk assessment report has to be created in iteration 0 and updated in every iteration, by following the risk management process like the one found in figure 1 or figure B.1 of ISO 14971 standard.
Sunday 17 June 2012
By Mitch on Sunday 17 June 2012, 18:29 - Processes
This post is the continuation of the post of last week.
We've seen in that post that fixing bugs during software maintenance is like a small chunk of design, excepted that software specifications do not change. Therefore risk management process when fixing bugs is very close to risk management process during design, without the initial assessment of risks at the beginning of the software development cycle.
Saturday 9 June 2012
By Mitch on Saturday 9 June 2012, 16:45 - Processes
This post comes after a series of three posts where I exposed my thoughts about development of software medical devices with agile methods.
These posts were focussed on software development. Risk management deserves its own series of posts. Here is the first of three.
Saturday 2 June 2012
By Mitch on Saturday 2 June 2012, 09:45 - Processes
In my previous post, I explained how to adapt agile methods to IEC 62304. I finish this series of 3 posts with some advices about the organization of an iteration and the software development team.