Software in Medical Devices, by MD101 Consulting - Tag - IEC 60601-1Blog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearIEC 62366-1 becomes recognized by the FDAurn:md5:3effac067a845d68db20b7ff35f9fc762015-09-23T09:57:00+02:002015-09-25T08:41:57+02:00MitchStandardsCE MarkFDAIEC 60601-1IEC 62366<p>Long time no see. For those of you guys who have been following this blog for a long time.<br />
Today I have time to write a short article on the new version of IEC 62366 standard: IEC 62366-1:2105 <em>Application of usability engineering to medical devices</em>.</p> <p>It was first published by the IEC at the beginning of 2015. Then the FDA was quick to add it to its list of recognized standards. It was published in <a href="http://www.gpo.gov/fdsys/pkg/FR-2015-08-14/html/2015-19991.htm">the Federal Register in August 2015</a> and the old version was marked withdrawn.<br />
It looks like the FDA wasn’t happy with the previous version to be so prompt to add the new one and withdraw the old one (pure speculation of mine).<br /></p>
<h4>Difference between US and EU</h4>
<p>We are now in a situation where the FDA recognizes the IEC 62366-1:2015 while the European Commission still references the IEC 62366:2007 in the list of harmonized standards. Discrepancies between standards versions can be difficult to handle.<br />
For those of you who know the changes in versions of IEC 60601-1 <em>Medical electrical equipment - Part 1: General requirements for basic safety and essential performance</em>, you know the hassle it can be. Fortunately, the case is more simple with IEC 62366.<br />
<br />
If your company designs products to be sold on the US and European markets, you’d better choose IEC 62366-1 than the old version. Why? Because it’s probably easier to bring evidence that you’re compliant with European regulations with the new standard (namely essential requirements about usability) than to bring evidence that you’re compliant with US regulations with the old standard that was withdrawn.<br />
Add to this that IEC 62366-1 should be referenced in the list of harmonized standards sooner or later. Thus there’s really no use to continue applying IEC 62366:2007 for new designs.</p>
<h4>Consequence on IEC 60601-1-6</h4>
<p>Coming back to IEC 60601-1, the IEC 60601-1-6 <em>Part 1-6: General requirements for basic safety and essential performance – Collateral standard: Usability</em> references IEC 62366. It basically takes IEC 62366 as is and adds some changes on the scope of products and some requirements on instructions for use.<br />
Even if IEC 60601-1-6 references the old version of IEC 62366, it is easy to apply the changes required by IEC 60601-1-6 to IEC 62366-1:2015 hence the wording of IEC 62366 hasn't changed. Thus, there's once again no use to continue applying the old version of IEC 62366.</p>
<h4>IEC 62366:2007 is dead</h4>
<p>As a consequence you have now to rely on the new usability engineering process defined in the requirements of IEC 62366-1. It is not easy to implement as it brings new concepts: formative evaluation and summative evaluation.<br />
We already talked about that <a href="https://blog.cm-dm.com/post/2015/01/09/IEC/FDIS-62366-1-released-in-November-2014">in a previous article</a>. Just to say that if you’ve been waiting for the last moment to change your design procedures to be in line with IEC 62366-1, uh, now, it’s time.<br />
<br />
<br />
Edit: fixed dates of IEC 62366 thanks to remarks of <a href="http://www.dm-experts.fr">Denys Durand Viel of DM Experts</a>.</p>https://blog.cm-dm.com/post/2015/09/23/IEC-62366-1-becomes-recognized-by-the-FDA#comment-formhttps://blog.cm-dm.com/feed/atom/comments/174MD and IVD standards: IEC 60601-1 and IEC 61010-1, versus IEC 62304 - Part 2urn:md5:1015969fb57fc612d6f253fe9c1939182013-04-12T20:34:00+02:002013-04-12T20:38:36+02:00MitchStandardsIEC 60601-1IEC 61010-1IEC 62304risk management<p>In the <a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010">previous post</a>, 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.<br />
<br />
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.<br />
These instruments usually fall in the scope of IEC 61010-1. Let's see now the relationship between IEC 61010-1 and IEC 62304.</p> <h4>New Risks Section</h4>
<p>IEC 61010-1 3rd edition was published in 2010. We're still in the transition between the 2nd and the 3rd edition. IEC 61010-1 3rd edition will become mandatory in Europe by october 2013.<br />
<br />
A new section was added to the 3rd edition: <em>Section 17 Risk Assessment</em>, along with the informative Annex H. No risk management method is mandatory to address risks, but ISO 14971 is quoted in Annex H.<br />
That makes the IEC 61010-1 closer to what medical devices manufacturers know. While ISO 14971 is mandatory for manufacturers of IVD instruments, it is fairly likely that manufacturers of laboratory instruments for medical purpose address risks with ISO 14971.<br />
<br />
But that doesn't tell how to manage software.</p>
<h4>When software appears in risks</h4>
<p>Section 16 of the standard, titled <em>Hazards resulting from application</em>, requires to manage risks arising from software-based controls or ergonomics. And Section 17 requires to manage any other risks not addressed in the rest of the standard (including software, by extension). Here we are!<br />
<br />
What is the standard that requires to manage software risks with ISO 14971, and contains other specific requirements to manage risks of software fro medical purpose?<br />
IEC 62304, of course!<br />
<br />
So, section 16 and 17 of IEC 61010-1 3rd edition advocate for IEC 62304. Yet, it is applied on a voluntary basis by manufacturers which instruments are for medical purpose, other than MD and IVD.<br />
<br />
The diagram below represents the relationships between IEC 61010-1 and IEC 62304, inspired form the diagram shown in the <a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010">previous post</a>.<br />
<img src="https://blog.cm-dm.com/public/20-60601-1-62304-61010-1/.Slide3-trunc_m.jpg" alt="Software in Medical Devices - relationships between IEC 62304 and IEC 61010-1" style="display:block; margin:0 auto;" title="Software in Medical Devices - relationships between IEC 62304 and IEC 61010-1, Apr 2013" /></p>
<h4>On the IEC 62304 side</h4>
<p>IEC 62304 is more straightforward about IEC 61010-1. In Annex C, the sub-clause C.5 makes it clear about the relationship between both standards.<br />
<br />
It states that if IVD instruments <em>contain software that can lead to a HAZARD</em>, then <em>IEC 62304 must be taken into account</em>. A flowchart is given that helps manufacturers deciding wether IEC 62304 is required or not.<br />
<br />
Once again, this is an informative section of IEC 62304. Thus, it is applied by IVD and laboratory instruments manufacturers on a voluntary basis. It provides "food for thought", at the very least.</p>
<h4>Conclusion</h4>
<p>The relationship between IEC 60601-1 and IEC 62304, on the one hand, and IEC 61010-1 and IEC 62304, on the other hand, is not based on the same criteria:</p>
<ul>
<li>Hazards arising from software is the most important criteria to apply IEC 62304,</li>
<li>IEC 60601-1 adds the notion of software complexity in its informative section:
<ul>
<li>If software is very simple, then IEC 62304 is not necessary,</li>
<li>If software is complex enough to design a software architecture, IEC 62304 becomes mandatory,</li>
</ul></li>
<li>IEC 61010-1 requires a risk assessment process with:
<ul>
<li>Specific software hazards in Section 16,</li>
<li>General-purpose risk assessment in Section 17 (including software),</li>
<li>Thus making IEC 62304 relevant for instruments with a medical purpose.</li>
</ul></li>
</ul>
<p><br /></p>https://blog.cm-dm.com/post/2013/04/12/MD-and-IVD-standards%3A-IEC-60601-1-and-IEC-61010-1%2C-versus-IEC-62304-Part-2#comment-formhttps://blog.cm-dm.com/feed/atom/comments/93MD and IVD standards: IEC 60601-1 and IEC 61010-1, versus IEC 62304 - Part 1urn:md5:779855ead02084dc89c03225dc28de092013-04-05T16:50:00+02:002013-07-28T10:44:36+02:00MitchStandardsdevelopment processIEC 60601-1IEC 61010-1IEC 62304risk management<p>Manufacturers of medical devices often ask themselves the obvious question:<br />
<em>Is it mandatory to be compliant both with IEC 60601-1 and IEC 62304?</em>
<br />
<br />
Similarly, manufacturers of in vitro diagnosis devices ask themselves:<br />
<em>Are my devices in the scope of IEC 62304?</em>
<br />
<br />
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.<br />
<br />
Do MD and IVD that embed software, fall in the scope of IEC 62304?<br />
This is not so obvious.</p> <h4>Medical Devices - IEC 60601-1 and IEC 62304</h4>
<p>You probably have already seen this diagram:<br />
<img src="https://blog.cm-dm.com/public/20-60601-1-62304-61010-1/.Slide1-trunc_m.jpg" alt="Software in Medical Devices - relationships between IEC 62304 and IEC 60601-1" style="display:block; margin:0 auto;" title="Software in Medical Devices - relationships between IEC 62304 and IEC 60601-1, Apr 2013" />
<br />
It comes from annex C.1 of IEC 62304 standard. It aims at explaining the relationships between IEC 62304, software design, and other standards.<br />
It tells that both IEC 60601-1 and IEC 62304 influence the design of software medical devices.<br />
For sure, both standards are about software design:</p>
<ul>
<li>IEC 62304 is all about software lifecycle,</li>
<li>Section 14 of IEC 60601-1 3rd edition is about Programmable Electronic Medical Systems (PEMS).<sup>[<a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010#pnote-92-1" id="rev-pnote-92-1">1</a>]</sup></li>
</ul>
<h5>Section H of IEC 60601-1</h5>
<p>Having a quick look at section 14 of IEC 60601-1, you will see that it's pretty much like IEC 62304. It contains sub-sections about software design, risk management, problems resolutions, and so on. But, at the same time, it references IEC 62304 for software development.<br />
<br />
So, when is it enough to be compliant with IEC 60601-1 and when is IEC 62304 mandatory?<br />
<br />
There are two interesting diagrams in IEC 60601-1: Figures H.1 and H.2 in annex H (an informative annex), which are, uh, very informative.<br />
<img src="https://blog.cm-dm.com/public/20-60601-1-62304-61010-1/.Slide2-trunc_m.jpg" alt="Software in Medical Devices - PEMS decomposition into hardware and software subsystems" style="display:block; margin:0 auto;" title="Software in Medical Devices - PEMS decomposition into hardware and software subsystems, Apr 2013" /><br />
They more or less tell that IEC 60601-1 "sees" software as black boxes (<em>components</em> in Annex H) that are designed and integrated during the PEMS development lifecycle.</p>
<h5>Software architecture: the big difference</h5>
<p><strong>If it is necessary</strong> to split software into software elements and software units, to show how:</p>
<ol>
<li>system requirements are translated in software requirements,</li>
<li>risks mitigation actions assigned to software, are translated in software requirements,</li>
<li>software requirements are allocated to software elements or software units,</li>
<li>software interfaces are implemented by inner software elements,</li>
<li>unit tests and software (not system) integration tests are necessary to demonstrate that:
<ol>
<li>software units and elements work unitary,</li>
<li>software requirements (including risks mitigations) are fulfilled,</li>
<li>software units and elements work integrated together,</li>
<li>software interfaces work with the surrounding system,</li>
</ol></li>
</ol>
<p><strong>Then</strong> IEC 62304 is mandatory.<br />
<br />
<strong>On the contrary, if it is only necessary</strong> to address software as a black box, to show how:</p>
<ol>
<li>system requirements are translated in software requirements,</li>
<li>risks mitigation actions assigned to software, are translated in software requirements,</li>
<li>software interfaces are implemented,</li>
<li>tests of the software entity as a black box demonstrate that software requirements (including risks mitigations) are fulfilled,</li>
</ol>
<p><strong>Then</strong> IEC 62304 shouldn't be mandatory and it should be possible to apply IEC 60601-1 standard alone.<br />
<br />
So, <strong>the big difference between IEC 60601-1 and IEC 62304 is the work of software (not system) architectural design and software (not system) integration</strong>.<br />
IEC 62304 ensures that this work is consistent by reviews and traceability between requirements, risks mitigation actions and tests.<br />
If you have both standards, have a look at Figure C.2 of IEC 62304 and compare it to Figure H.2 of IEC 60601-1 to see the difference.</p>
<h4>Some examples</h4>
<h5>FPGA, ASICs and HDL</h5>
<p>Quick answer: apply IEC 60601-1 only.<br />
Although hardware description languages can be seen as source code prone to error, they're not software.<br /></p>
<h5>FPGA, ASICS, plus a tiny C (or other language) program</h5>
<p>Quick answer: apply IEC 60601-1 only.<br />
There's possibly a tiny C program (or another language) limited to a small source file, running on the hardware. Both elements (hardware + software) can be seen as a black box. They don't require software architectural design.<br />
There can be a phase of tests of hardware alone, followed by unitary tests of hardware + software. But tests of software + hardware integrated (seen as a black box) are enough to demonstrate that requirements are fulfilled by the component.</p>
<h5>System on a Chip (SoC), Micro-controllers and C (or else) programs</h5>
<p>Quick answer: apply IEC 60601-1 if program is tiny enough, otherwise apply IEC 62304.<br />
If hardware is big enough to have a program running on it, and if the source code of the program is more that one source file, then we have a borderline case.<br />
It's up to the software and hardware designers to decide if IEC 62304 is applicable or not. It depends, once again, on the complexity of software. To give a help, if the answer to one of these questions is "Yes":</p>
<ul>
<li>Is it relevant to split the software component into smaller components to show how requirements are allocated?</li>
<li>Is it relevant to split the software component into smaller components to show how risks mitigation actions are allocated?</li>
<li>Is it relevant to split the software component into smaller components to show how requirements about software interfaces are allocated?</li>
</ul>
<p>Then IEC 62304 is probably yours.</p>
<h5>Everything of higher complexity</h5>
<p>Quick answer: apply IEC 62304.<br />
If the answer to one of the above questions is frankly yes, if there are dozens of software requirements, if your software requires more than one person to design it, or if your thumb tells you to do so (you'd rather need experience), then IEC 62304 is yours.</p>
<h4>To go further</h4>
<p>Deciding whether or not it is necessary to apply IEC 62304 + IEC 60601-1 or IEC 60601-1 alone has a lot of consequences on the amount of work to do. IEC 62304 requires many processes and is rather time-consuming.<br />
If you're still doubtful and want to sell in the US, read also the guidances on software made by the FDA to see if what they recommend is relevant for your case. I gathered the links on these guidances in <a href="https://blog.cm-dm.com/pages/The-essential-list-of-guidances-for-software-medical-devices#FDA">my essential list of guidances for software medical devices</a>. At top priority, see on this page the link to the guidance about General Principles of Software Validation.
<br />
<br />
In <a href="https://blog.cm-dm.com/post/2013/04/12/MD-and-IVD-standards%3A-IEC-60601-1-and-IEC-61010-1%2C-versus-IEC-62304-Part-2">the next article</a>, we'll ask the same question about IVD, with IEC 61010-1 and IEC 62304.</p>
<div class="footnotes"><h4 class="footnotes-title">Note</h4>
<p>[<a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010#rev-pnote-92-1" id="pnote-92-1">1</a>] Note: Section 14 of IEC 60601-1 3rd edition is the former IEC 60601-1-4 collateral standard of IEC 60601-1 2nd edition.</p></div>
https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010#comment-formhttps://blog.cm-dm.com/feed/atom/comments/92ISO and IEC standards for software in medical devices in a nutshellurn:md5:f7c78fe6f8dd4f464a322bb0664e063f2011-11-01T23:00:00+01:002022-01-14T15:09:01+01:00MitchStandardsIEC 60601-1IEC 62304IEC 62366ISO 13485ISO 14971<p>Here is a short description of ISO and IEC standards related to software and medical devices.</p>
<p>The starting point is legal. Government agencies give the authorizations to manufacturers to sell their devices. These agencies rely on standards to ensure that the device was designed and manufactured in a good and safe way. Given these regulations, medical device manufacturers have to adhere to these standards. Full stop.<br />
<br />
Let's see what these standards are.</p> <h4>General standards</h4>
<p>Two ISO standards are of high importance for software medical devices: <strong>ISO 13485</strong> and <strong>ISO 14971</strong>. They can be seen as the topmost standards for medical devices. They are very generic and apply to every medical device, from the simplest plaster to the most complex surgical robot. As they are so generic, they don’t give a clue about software. Other standards do.</p>
<h4>Specific standards</h4>
<p>The main standard about software in medical devices are:</p>
<ul>
<li><strong>IEC 62304</strong>. It deals with the software lifecycle, i.e. almost everything about what software engineers do. Three other standards apply to software:</li>
<li><strong>IEC 60601-1</strong> is applicable to embedded software in a hardware medical device,</li>
<li><strong>IEC 82304-1</strong> is applicable to standalone software, also known as Software as a Medical Device (SaMD),</li>
<li><strong>IEC 81001-5-1</strong> adds requirements about cybersecurity,</li>
<li><strong>IEC 62366-1</strong> adds requirements about man-machine interface ergonomics.</li>
</ul>
<p><br />
<strong>IEC 62304 is THE standard for software in medical devices</strong>.<br />
<br />
If you are someone from quality assurance who knows ISO 13485 and ISO 14971, and you read IEC 62304, you will be lost at first. On the contrary, if you are someone from computer engineering who knows what software lifecycle is, and you read IEC 62304, you won’t feel comfortable with a few paragraphs about concepts you haven’t seen before.<br />
<br />
IEC 62304 requires the knowledge of two worlds: the computer engineering industry, where people don’t give a clue of CAPA, vigilance and so on, and the medical device industry, where people consider software as a very convenient thing but don’t want to know how it is done.<br />
<br />
<em>Please, don’t get offended if you belong to one of these people, I caricature the situation! No medical device with software would work or would be certified if nobody had made the step to understand others’ job.</em><br />
<br />
<strong>IEC 60601-1</strong> is a standard about <strong>electro-medical devices</strong>. Medical devices with embedded software are included in this category, as chips containing the software are powered by electricity. They are called PEMS for “Programmable Electrical Medical Devices”.<br />
Only section 14 of the standard deals with software. It is fortunately a very small part of this standard, which contains tons of instructions. <strong>Section 14 gives requirements about hardware and software interfaces, especially network interfaces</strong>.<br />
In the past, when IEC 62304 didn’t exist, only IEC 60601-1 dealt with software. But as software became more prominent in PEMS, it was decided to add a standard only about software. It makes sense: software development is a very different way of doing things compared to other industries. There are often a lot of requirements to implement in design (sometimes thousands) and there is no production (I mean manufacturing).<br />
<br />
<strong>IEC 82304-1</strong> is a standard about <strong>SaMD</strong>. It is applicable to medical device software, which runs on a general-purpose hardware, like a PC, a smartphone or a tablet. It gives additional requirements on the lifecycle of standalone software, which are not present in IEC 62304. IEC 82304-1 also contains requirements on the content of the instructions for use and the monitoring activities to perform when the software is on the market.<br />
<br />
<strong>IEC 81001-5-1</strong> is about <strong>cybersecurity</strong>. It adds requirements on how to make secure software, on top of IEC 62304. It is quite a challenging standard for most of medical software editors. At the date of redaction of this post (2022), this standard is brand new and almost no editor has the capabilities internally to implement it without recruiting people with security background.<br />
<br />
<strong>IEC 62366-1</strong> is about <strong>ergonomics</strong> and the interaction of the user with the device. Ergonomics shall be considered for every medical device (it is a “cousin” of ISO 60601-1-6, another standard for electrical devices). Implementing this standard for software requires the same method as other devices. The good practice of software industry is to keep track of usability requirements with traceability matrixes between ergonomics and software design documents, as for other software requirements. A bit like cybersecurity, it also requires specialists on the field of usability engineering to correctly implement this standard.<br />
<br /></p>
<h4>Summary</h4>
<p>To have a global view of medical devices with software, people should know 6 standards: ISO 13485 and ISO 14971 on one side, IEC 62304, IEC 60601-1, IEC 82304-1 and IEC 62366-1, on the other side. Add to that IEC 81001-5-1 about cybersecurity as at 7th standard.<br />
<br />
The table below summarises the standards around software for medical devices and the responsibilities of people, from the point of view of a software project manager.<br /></p>
<table border="1" style="border-width: 2px; border-color: #CCCCCC; border-style: solid;" rules="all" frame="void">
<tbody>
<tr valign="middle" style="background-color: #25b7b3;">
<td valign="middle"><span style="color: #FFFFFF;">Standard</span></td>
<td valign="middle"><span style="color: #FFFFFF;">What is it about?</span></td>
<td valign="middle"><span style="color: #FFFFFF;">Who shall master it?</span></td>
<td valign="middle"><span style="color: #FFFFFF;">Who shall know it?</span></td>
</tr>
<tr style="background-color: #F9F9F9;">
<td><span>ISO 13485</span></td>
<td><span>Quality System for medical devices industry</span></td>
<td>
<p><span>Quality Manager.</span></p>
</td>
<td>
<p><span>Software project manager:<br/>clauses about design control, change control, customer claims, CAPA…
</span></p>
</td>
</tr>
<tr style="background-color: #E9E9E9;">
<td><span>ISO 14971</span></td>
<td><span>Risk Management for medical devices</span></td>
<td>
<p><span>Quality Manager.</span></p>
</td>
<td><span>Software project manager</span></td>
</tr>
<tr style="background-color: #F9F9F9;">
<td><span>IEC 62304</span></td>
<td><span>Software lifecycle for medical devices</span></td>
<td>
<p><span>Software project manager.</span></p>
</td>
<td><span>Quality Manager</span></td>
</tr>
<tr style="background-color: #E9E9E9;">
<td><span>IEC 81001‑5‑1</span></td>
<td><span>Cybersecurity in medical devices</span></td>
<td>
<p><span>Software project manager and software security specialist</span></p>
</td>
<td><span>Quality Manager</span></td>
</tr>
<tr style="background-color: #F9F9F9;">
<td><span>IEC 60601‑1</span></td>
<td><span>Programmable electrical medical systems (PEMS) in medical devices</span></td>
<td>
<p><span>Software project manager (for section 14)</span></p>
</td>
<td><span>Quality Manager</span></td>
</tr>
<tr style="background-color: #E9E9E9;">
<td><span>IEC 82304‑1</span></td>
<td><span>Software as medical devices (SaMD)</span></td>
<td>
<p><span>Software project manager</span></p>
</td>
<td><span>Quality Manager</span></td>
</tr>
<tr style="background-color: #F9F9F9;">
<td><span>IEC 62366‑1</td>
<td><span>Usability in medical devices</span></td>
<td>
<p><span>Software project manager and usability engineering specialist</span></p>
</td>
<td><span>Quality Manager</span></td>
</tr>
</tbody>
</table>
<p><br />
The good implementation of all the quality system is always the responsibility of the direction. The Quality Manager’s role is to ensure that all standards are well applied by people who should know them. What I want to put in emphasis is the fact that is it the software project manager’s role to implement the standards about software, with the help of the quality manager. The quality manager has a broader view of the device, in its conception (non-software parts) and in its lifecycle (other phases of the life of the medical device).<br />
<br />
<br />
<br />
As a conclusion, if you design software, <strong>begin with IEC 62304</strong>, that's your most important standard. <strong>Continue with ISO 13485 and ISO 14971</strong>, with explanations of your quality manager, who knows how to deal with them better than anyone in your company. When you're comfortable with IEC 62304, <strong>continue with IEC 81001-5-1</strong>, security matters. Then <strong>continue with IEC 60601-1 section 14 or IEC 82304-1</strong>. And <strong>end with IEC 62366-1</strong>.<br />
<br />
If you're quality manager, take the help of a software project manager to explain you what's at stakes inside IEC 62304 and other standards. Your main goal remains, of course, managing the two ISO standards at the company level.<br />
<br />
<br />
<br />
First version on November 1st 2011<br />
<strong>Updated on January 2022</strong><br />
Reason: added IEC 82304-1 and cybersecurity, not present in 2011.<br />
Fixed wording.<br />
Removed dead links.</p>https://blog.cm-dm.com/post/2011/11/01/ISO-and-IEC-standards-explained-to-software-engineers-and-quality-managers#comment-formhttps://blog.cm-dm.com/feed/atom/comments/50