Medical Device Software Document released version (article 5.8.4)

[Lola Parra]

Hello:

I have a question, my company is in the process of get the CE mark for a medical device IIa class according with directive 93/42/ECC. We include at the device an own software for refraction measuring.

Our software is class A according with IEC 62304, so, we need to incorporate the document released versions. But I have a doubt about how to organize the semantic of number versioning.

We start the software with 1.0.0 version, of course, but with time, some different projects have emerged, it means, with the base at 1.0.0 version we have created some different versions of the same software for custom properties, depends on clients.

For example, for client 1 we use a 1.1.0, and for client 2 we use 1.2.0, but I don't know exactly if it is correct, and the most important thing is we need to include for documentation of IEC 62304 the article 5.8.4 Document released version, and I don't know if correct the kind of numeration and how it is made the document.

Can anyone help me, please? Thank you a lot.

 

[isoalchemist]

We had a similar issue where the core functionality would be the same, but branding or other non-functional customization would occur. We took the approach of 1.0.0-xxx indicating that it was in reality the core 1.0.0 product.

We considered moving the customization up, but we believed we would lose traceability of what product we really started with if we had to make minor updates in the core product.

I'm not convinced a single good approach exists. Traceability and being able to show the verification and validation of changes really drive it based on the product.

 

[yodon]

It would probably be good for you to take a step back and consider why such requirements exist.

Here's one scenario (there are others). Let's say, in your case, that a problem is identified in 1.1.0 and after you analyze it, you realize it's also applicable to 1.2.0. You need to roll the fix out in both places so you need to know where to do that. If your 1.1.0 and 1.2.0 diverge considerably, that's going to be an unholy mess in a hurry.

So you need a plan on how to manage the software to ensure that everything is readily identifiable and you can manage changes in a controlled fashion, ensuring that everyone gets updates, as appropriate.

A well-defined architecture is one way: isolate the customizations. If it's branding like the case isoalchemist mentions, it may be as simple as using build-time options (e.g., #defines).

Typically, all "core" functionality is maintained on the "trunk" of the configuration tree and you can spin off customizations as branches. It's always advisable to minimize the number of branches so having a plan to merge the branches back to the trunk is certainly preferred.

Get your developer leads / architects involved to determine a good solution. Consider various use cases in having to maintain multiple configurations. Should be a rousing discussion. Configuration management and configuration identification discussions can get feisty.

 

[Lola Parra]

Hello:

I was talking with my boss, and we think maybe the best option until now is keep a versioning like:

<major>.<minor>.<revision>.<build>

where "minor" is a different number for a different client.

But for our future version 3.0.0.0 we think that the best option is create a software with all the possibilities that we will decide that maybe our clients are interested, and depends which features the client wants, simply disable or enable this features, but the core of the software always will be the same.

But is easier to think in this, that to programming it, but maybe is a good solution to avoid the mess when a mistake or problem appears.

About the document of IEC 62304, 5.8.4 can we use this kind of template (attached) ?

Thanks

 

[c.mitch]

Yes you can!
(I wrote this template )
The purpose of this template is to bring evidence that requirements of 5.8 section are fulfilled.
It's the ID of software release. Fill the template when you release a new version, alpha, beta or final.

 

[Lola Parra]

Hello, thank you a lot for this template. Only one more question.

When you prepare the necessary documentation for IEC 62304, and include this kind of template for versioning part. If we have some released version, we need a different file for each version or I can use the same file to indicate all the published version? Even the future version (we working right now, but no released) ?

Thank you again, c.mitch.

 

[c.mitch]

we need a different file for each version or I can use the same file to indicate all the published version

You can choose your own documentation numbering policy. It is more simple to have the same document updated for each new version. Example: doc #1234 v1 for software v1.0 doc #1234 v2 for software v1.1 and so on.

Even the future version (we working right now, but no released) ?

Generaly speaking, the document is only for releases (5.8 of iec 62304 is release). But you may use it for beta or alpha versions if such versions are delivered outside the company for, say, testing purposes.

 

[kreid]

I have experience of one piece of software that has one part number (and version) with all possible functions in it. The different functions are not all used by all of the customers and can then be sold separately using licensing.

That way all of the core product and all of the additional functions are represented by one configuration number. This keeps the maintenance and bug fixing simple (as mentioned by Yodon above). But does mean you have to do some work around the licensing process V&V.