Medical Device Software Document released version (article 5.8.4)

L

Lola Parra

#1
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.
 
Elsmar Forum Sponsor
I

isoalchemist

#2
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

Staff member
Super Moderator
#3
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.
 
L

Lola Parra

#4
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
 

Attachments

c.mitch

Quite Involved in Discussions
#5
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.
 
Last edited:
L

Lola Parra

#6
:bigwave: 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

Quite Involved in Discussions
#7
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

Involved In Discussions
#8
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.
 
Thread starter Similar threads Forum Replies Date
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 2
Z Software Library - could it be a medical device? ISO 13485:2016 - Medical Device Quality Management Systems 5
M Informational TGA – Submissions received: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 1
D Requirements for the dimensions / color of medical device labels - Software as a Medical Device IEC 62304 - Medical Device Software Life Cycle Processes 2
D Software as an accessory to a Class I medical device EU Medical Device Regulations 4
R Medical device software without user interface Other Medical Device and Orthopedic Related Topics 3
R Validation of Medical Device Hardware containing Software - How many to Validate ISO 13485:2016 - Medical Device Quality Management Systems 1
Ed Panek Rule 11 Question - CE approvals for software as well as the medical device EU Medical Device Regulations 6
D IEC 60601 for a Software only Medical Device? IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
S Software Release Note - Class A stand alone software medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
M Professional Use Medical Software French Labeling for Canada -- Not Considered Medical Device Canada Medical Device Regulations 2
S Medical Device Software Distribution for a CE-marked medical device via a USB memory stick EU Medical Device Regulations 8
M Informational TGA – Webinar: An update on the consultation for the Regulation of Software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
J Qualification of a Software as a Medical Device (SaMD) guidance under MDR EU Medical Device Regulations 9
P Software requirement and design specifications - Medical device contains both hardware and software IEC 62304 - Medical Device Software Life Cycle Processes 2
M Informational TGA Consultation: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
N Medical Device Accessory Classification - Software as a Medical Device Other Medical Device Regulations World-Wide 5
R SaMD - Software as a Medical Device - Software change control form ISO 13485:2016 - Medical Device Quality Management Systems 3
G EU MDR 2017/745 Rule 11 interpretation - Re-classification of a Software as Medical Device Other Medical Device Related Standards 0
M Medical Device News TGA – Regulation of Software as a Medical Device Medical Device and FDA Regulations and Standards News 0
S Two Questions about Medical Device Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
K Medical Device Software Update in Field of AIMD IEC 62304 - Medical Device Software Life Cycle Processes 1
M Medical Device News Health Canada - Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Record of Proceedings – January 26, 2018 Canada Medical Device Regulations 0
R Online / Cloud Based Software as Medical Device EU Medical Device Regulations 8
S DMR (Device Master Record) for Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 3
S Labelling in Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 8
S What is considered the complete software medical device? Medical Information Technology, Medical Software and Health Informatics 6
JoCam Medical Device Software - Apps which can control medical devices EU Medical Device Regulations 13
L Software Medical Device - 7.3.8 - Design and Development Transfer ISO 13485:2016 - Medical Device Quality Management Systems 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
K Registering a Software medical device (SaMD) in China China Medical Device Regulations 5
N Medical Device Software - Switch from Waterfall to Agile methodology Medical Information Technology, Medical Software and Health Informatics 4
V Software medical device labelling EU Medical Device Regulations 5
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
S If a piece of software receives approval as part of a medical device system Canada Medical Device Regulations 5
C Controlling Software Versions that are part of a medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
S Cloud-Based Stand Alone Software - Software Medical Device (Class II) US Food and Drug Administration (FDA) 2
Q QMS Software for Startup Medical Device Company Other Medical Device and Orthopedic Related Topics 7
B CQC oversight of Medical device software? EU Medical Device Regulations 3
H Identifying Guidance on Medical Device Software Level of Concern for the EU EU Medical Device Regulations 2
B Is IEC TR 80002-1:2009 applicable to stand-alone medical device software? ISO 14971 - Medical Device Risk Management 1
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
T Are internally found Medical Device Software "Bugs" Complaints? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
K 510k "Premarket" Submission for Existing Class II Software Medical Device US Food and Drug Administration (FDA) 3
P UDI Registration - Class II Medical Device Software Other US Medical Device Regulations 9

Similar threads

Top Bottom