To content | To menu | To search
Explanations on standards, howto's
My own experience on implementation of standards
Friday 31 May 2013
By Mitch on Friday 31 May 2013, 15:06
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
We've seen in 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
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
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:
Enjoy.
Note: for those who don't know Elsmar Cove forum, it's probably the best forum about quality management and standards.
Friday 19 April 2013
By Mitch on Friday 19 April 2013, 16:44
The FAQ related to the Implementation of EN 62304 with respect to MDD 93/42/EEC was released by Team NB, the association of Notified Bodies.
You'll find in this FAQ many hot subjects I already mentioned in this blog:
This FAQ shows that the state-of-the-art is still evolving. But I think that it has reached a point of consistency and stability. Many questions in the FAQ hadn't clear answers one or two years back.
Keep going!
Friday 12 April 2013
By Mitch on Friday 12 April 2013, 20:34
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
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
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
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
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
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
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
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 19 October 2012
By Mitch on Friday 19 October 2012, 04:32
Let's continue a former post about dealing with ISO 13485 in a software company. ISO 13485 and ISO 14971 are a bit like sister standards. You can't implement one without the other!
But how to deal with ISO 14971 in a software company, actually?
Friday 11 May 2012
By Mitch on Friday 11 May 2012, 19:23
Reading the ISO 13485 standard doesn't helped me knowing how to manage the lifecycle of software medical devices. The QMS of a software company has to be adapted to be in conformity with ISO 13485.
Saturday 14 April 2012
By Mitch on Saturday 14 April 2012, 23:35
IEC 62304 defines three safety classes for software:
Here comes the eternal question: Which class my software belongs to?
Friday 9 March 2012
By Mitch on Friday 9 March 2012, 13:45
Don't worry, I'm not going to talk about money and quantitative easing! I let people with better knowledge in economics (that makes a lot of people!) do that.
When I talk about inflation, I mean the inflation of software medical devices in their number and variety, which creates a collateral inflation in the number of regulations, guidances, standards, and the like.
This post is the first of a series of three. In this first post, I focus on the inflation of standards. The next one will be on the inflation of regulations and the last one on the inflation of medical devices.
Monday 30 January 2012
By Mitch on Monday 30 January 2012, 03:17
This article was moved Here.
Friday 18 November 2011
By Mitch on Friday 18 November 2011, 18:10
The homologation of a medical device is a complex task and can become a nightmare with devices with a high level of risk. It involves many standards and regulations, different from one country to another: FDA in the USA, CE Mark in Europe, CMDCAS in Canada, KFDA in South Korea, and so on …
Fortunately, most of these regulations have common requirements and rely on ISO standards, the most important standards being ISO 13485 and ISO 14971. If you meet the requirements of these standards, you increase your chances of passing the homologations for the devices with low risk. For devices with high risk, these standards are (almost) mandatory.
Friday 4 November 2011
By Mitch on Friday 4 November 2011, 13:21
A lot of standards and regulations exist about medical devices: how to design, to produce, to sell, to monitor their use … Everything about each step in the life of devices, from the initial idea 10 years before selling anything, to the archiving of records 10 years after the last item has been sold. A lot of specific standards or guidances on how applying medical devices standards exist about software. That’s the consequence of software being very specific (I should say peculiar), compared to other components in medical devices. Conception is the most critical part in the lifecycle of software. Software is never 100% finished, user always want enhancements and modifications.
From my own experience in the field, I gathered 5 basic recommendations you should follow.
« previous entries - page 1 of 2