Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Tag - development process

Entries feed - Comments feed

Friday, 30 November 2012

En route to Software Verification: one goal, many methods - part 1

Software verification is easy to define: to demonstrate that software works as it was specified (and without bugs!). But there's not a unique way to do it.
Let's see what methods we have in hands to verify software.

Continue reading...

Friday, 16 November 2012

V&V: verification & validation, doing it right.

Writing about V&V in two previous posts, I had a lot of comments from people on a well-known social network. They made corrections to my view of V&V and brought their own definitions.
Here is an excerpt of their comments.

Continue reading...

Friday, 9 November 2012

Endeavour Agile ALM

Endeavour Agile ALM is an Open-Source solution for Agile project and resource management.

Continue reading...

Friday, 2 November 2012

What is software validation?

Following the article about software verification, let's see what software validation is.

Continue reading...

Friday, 26 October 2012

What is software verification?

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.

Continue reading...

Friday, 3 August 2012

How to use templates with agile methods?

All templates I have written are listed in my templates repository page. I already explained in that page and some other articles how to use them with waterfall development process.
But their use is not obvious with agile methods. Here are a few explanations.

Continue reading...

Friday, 27 July 2012

Template: All-in-one

Here is a new template: the all-in-one template for software development process.
It is made for simple software development project where everything can be put in only one document. Especially, there is room for only one verification phase in the template. this is a deliberate situation. If you plan to have more than a single phase of verification, you should use other templates (link on template repository page below at the end of this post).
It contains simple and reduced parts of:

  1. Project management plan,
  2. Software Requirements Specifications,
  3. System Architecture Document,
  4. Software Tests Plan, Description and Report.

It doesn't contain the risk management data. They shall remain in the dedicated templates: Risk management plan and Risk analysis report.

More templates on my templates repository page.

Please, feel free to give me feedback on my e-mail

I share this template with the conditions of CC-BY-NC-ND license.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.

Friday, 6 July 2012

Class C software and agile methods

Are agile methods compatible with the constraints of development set by IEC 62304 standard of class C software?
After a series of three posts about agile methods and risks analysis. I focus in this post on IEC 62304 class C critical software.

Continue reading...

Saturday, 23 June 2012

How to combine risk management process with agile software development? - Part 3

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.

Continue reading...

Sunday, 17 June 2012

How to combine risk management process with agile software development? - Part 2

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.

Continue reading...

Saturday, 9 June 2012

How to combine risk management process with agile software development? - Part 1

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.

Continue reading...

Saturday, 2 June 2012

How to develop medical device software with agile methods? - Part 3

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.

Continue reading...

Wednesday, 16 May 2012

How to develop medical device software with agile methods? - Part 2

In my previous post, I explained how I tweaked the waterfall model to obtain something close to agile methods. But still not agile, actually...

Continue reading...

Saturday, 12 May 2012

How to develop medical device software with agile methods? - Part 1

IEC 62304 is the standard to apply for software in medical devices. It is not bound to any software development method or model. Though not explicit, using the waterfall development model is the most straighforward way to apply this standard.
The waterfall model has become old fashioned to the eyes of most of software developers, with the emergence of agile methods. Agile methods are so popular now that everydody wonders how to apply IEC 62304 with agile methods.

An AAMI/CDV-1 TIR(SW1) - Guidance on the use of agile practices in the development of medical device software exists about this subject. But it is still a draft and only members of AAMI have access to it.

So, how to use agile methods and still be compliant with IEC 62304?
Here are my thoughts about these questionings!

Continue reading...

Friday, 11 May 2012

How to deal with ISO 13485 in a software company?

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.

Continue reading...

Wednesday, 29 February 2012

Templates: software development plan and software configuration management plan

Here are the Software Development Plan Template and the Software Configuration Management Plan Template

These templates are technical ones. But they are closely linked to project management hence they contain sections about reponsibilities.

Continue reading...

Wednesday, 4 January 2012

Software development subcontractors: How to manage your Customer

Congratulations! You have signed a contract with a medical devices manufacturer. They don't have a very good knowledge of software. They rely on you to develop something brand new on a smartphone. The application they want to develop will bring new functionalities to doctors and let them do their jobs faster. Your customer chose you because you are the specialist of software on every OS’es on smartphones. You ensured him that your company can be in conformity with IEC 62304 standard. To that purpose, you modified and added the necessary procedures and forms to your quality system. You have one year to develop the application, which fits their desires … and the medical devices standards!

Continue reading...

Monday, 12 December 2011

How to externalize software development for a medical device?

Case example

You are a medical device company and you want to replace your old products by “smart” ones. Your competitors are doing it and you customers want them. “Smart” means something like an tiny computer (its amazing how small they are), with an operating system and big software. For electronic stuff, you have your own engineers or you have your subcontractors, which you have been working for 20 years with. They knew how to design embedded software on microchips. But they don’t know how to design software of higher level, with intelligent behaviour and complex algorithms.

Continue reading...

Friday, 18 November 2011

Software Medical Devices. How to obtain market homologation?

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.

Continue reading...

Friday, 4 November 2011

5 recommendations to engineers developing medical device software

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.

Continue reading...

page 2 of 2 -