Software in Medical Devices, by MD101 Consulting - StandardsBlog 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 81001-5-1 Right Here Right Nowurn:md5:cd5939e387b1c296a2b7e100844c81082024-02-23T14:21:00+01:002024-03-04T12:46:45+01:00MitchStandardsCybersecurityIEC 81001-5-1<p>IEC 81001-5-1 is now the standard for cybersecurity in medical devices. But is this standard asking too much for?</p> <h4>Impact of the standard</h4>
<p>IEC 81001-5-1 requires to unroll a full set of cyber activities throughout the software life cycle and more precisely the software development lifecycle. This can represent quite an overhead, on top of existing IEC 62304 provisions.</p>
<h5>Cyber design</h5>
<p>Firstly, at design, the steps required by IEC 81001-5-1 supplement those of IEC 62304:<br>
<img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-81001-5-1-secure-SDLC-tasks_m.png" alt="IEC-81001-5-1-secure-SDLC-tasks.png, Jul 2021" class="media-center" title="IEC-81001-5-1-secure-SDLC-tasks.png, Jul 2021">
<br>
A short list of artifacts includes (but not limited to…):</p>
<ul>
<li>A bunch of new documents or document sections on architecture, detailed design (or new sections in existing documents)</li>
<li>New design review criteria,</li>
<li>A cybersecurity risk management file (cyber risk management plan and cyber risk assessment report),</li>
<li>A software development platform (or a toolchain, name it as you prefer) with specific tools, which can lead to heavy license costs:
<ul>
<li>Static source code analysis,</li>
<li>software composition analysis,</li>
<li>fuzzers (e.g.: DICOM fuzzers for medical imaging),</li>
<li>black box common vulnerability scanning,</li>
<li>Dynamic Application Security Testing tools,</li>
<li>and some other specific to your software technology…</li>
</ul></li>
<li>The need to perform pen tests with an independent organization. That means paying for the services of such a gang of security consultants,</li>
</ul>
<h5>Cyber maintenance</h5>
<p>After software release, it adds the need to monitor cyber issues in post-market phase. And update the cybersecurity risk management file.<br>
<br>
It also requires to have people qualified in security: Security Advisor(s). A person, who takes this role, shall have appropriate evidence of qualification.
<br>
<br>
This list is only a subset of IEC 81001-5-1 provisions. Just to demonstrate the magnitude of the overhead. Practically speaking, IEC 81001-5-1 can be seen as a “second IEC 62304” in terms on work effort.<br>
<br>
<strong>Do you remember the effort it took to implement IEC 62304 for the first time in your processes?</strong><br>
<strong>IEC 81001-5-1 will represent the same level of effort!</strong><br>
<br></p>
<h4>FDA risk-based approach</h4>
<p>If we look at the US side, IEC 81001-5-1 is a recognized standard. It is also quoted as a possible Secure Product Development Framework (SPDF) in the <a href="https://blog.cm-dm.com/post/2023/10/06/Final-2023-FDA-Premarket-Cybersecurity-guidance-released">FDA guidance on cybersecurity premarket documentation</a>. More, this guidance describes activities and documentation deliverables very similar to IEC 81001-5-1 provisions.<br>
Thus, at first sight, IEC 81001-5-1 shall also be fully applied to generate cyber documents shipped in a 510(k) submission.<br>
<br>
However, the FDA accepts to apply a risk-based approach. If you can assert that your device:</p>
<ol>
<li>Has a low cyber risk profile, and</li>
<li>Cyber risk don’t lead to unacceptable safety risks,</li>
</ol>
<p>Then it is possible to reduce the documentation to an acceptable minimum.<br>
<br>
This shall be backed with:</p>
<ol>
<li>A documented threat model,</li>
<li>And, traceability between security risks and safety risks,</li>
</ol>
<p>Giving evidence that your device has actually a low cyber risk profile.<br>
<br>
That minimum set of documentation should include:</p>
<ul>
<li>A threat model,</li>
<li>A security risk management plan,</li>
<li>A security risk assessment report, with traceability to safety risks, when needed,</li>
<li>Secure software requirement specifications (including security risk control measures),</li>
<li>Test plans and reports with test cases covering these secure software requirements,</li>
<li>Independent pen test plan and report,</li>
<li>A Software Bill of Materials (SBOM),</li>
<li>Warnings on secure software use in the Instructions for use,</li>
<li>Secure operations guidelines in accompanying documentation (targeting end-users or people with a more technical background),</li>
<li>A post-production surveillance on SOUPS, and security issues coming from the field.</li>
</ul>
<p>The diagram below sums-up this course of action:
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/Medical_Device_Cyber_Crash_Action_Plan.png" title="Medical Device Cyber Crash Action Plan.png, Feb 2024"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.Medical_Device_Cyber_Crash_Action_Plan_m.png" alt="Medical Device Cyber Crash Action Plan.png, Feb 2024" class="media-center" title="Medical Device Cyber Crash Action Plan.png, Feb 2024"></a></p>
<p>Note that the above list is a return on experience on 510(k)’s submitted the last few years. But FDA thinking may change on these matters in the near future. Don’t blame this blog if this doesn’t work with your device! And rub twice your threat model to the latest threat landscape in healthcare!<br>
<br>
By the way, FDA's approach doesn't pop out of nowhere. <a href="https://www.congress.gov/bill/117th-congress/house-bill/2617/text">FD&C Act SEC. 524B</a> says that [Manufacturers shall] <em>design, develop, and maintain processes and procedures to provide a <strong>reasonable assurance</strong> that the device and related systems are cybersecure</em> (emphasis by me).
<br></p>
<h4>Transitional Health software</h4>
<p>It is worth noting that the FDA low risk profile approach described above is close to the Transitional Health software approach found in annex F of IEC 81001-5-1. <br>
This is depicted in the diagram below:<br>
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_81001-5-1_Transitional_Health_Software.png" title="IEC 81001-5-1 Transitional Health Software.png, Feb 2024"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_81001-5-1_Transitional_Health_Software_m.png" alt="IEC 81001-5-1 Transitional Health Software.png, Feb 2024" class="media-center" title="IEC 81001-5-1 Transitional Health Software.png, Feb 2024"></a>
<br>
Transitional Health Software is a kind of IEC-62304-class-A-ish secure SDLC. Tasks at architectural and detailed design are skipped. However, some architecture-level documentation, like Data Flow Diagrams, are helpers for a sound threat model. But not the whole architecture, required by the full IEC 81001-5-1.<br>
<br>
A major difference with FDA risk-based approach, however: transitional health software requires to implement the full secure software testing strategy found in 5.7 of IEC 81001-5-1. This testing strategy is per se quite an overhead!<br>
And a second difference: “transitional” means that you shall have plans to be fully compliant to IEC 81001-5-1 in a further release of your software.</p>
<h4>EU Notified Body binary approach</h4>
<p>Today, IEC 81001-5-1 is not harmonized. Yet, it is considered as state-of-the-art (see <a href="https://www.ig-nb.de/veroeffentlichungen">IG NB questionnaires on cybersecurity (fortunately in English)</a> and <a href="https://www.team-nb.org/wp-content/uploads/2022/10/Team-NB-PositionPaper-CyberSecurity-V1-20221005.pdf">TEAM-NB position paper on cybersecurity</a>).<br>
<br>
But:<br>
NB auditors are still at the bottom of a steep Everest-like learning curve. Being able to audit a QMS implementing IEC 81001-5-1 processes or evaluating cyber sections of technical files is still out of reach of (most of) NB personnel.<br>
That will change in the near future. For sure.<br>
<br>
That should (shall?) be the case in 2028, when IEC 81001-5-1 is harmonized.<br>
<br>
So, to sum-up Notified Body thinking:</p>
<ul>
<li>Today: Manufacturer, thou shalt apply MDCG 2019-16 and give me a bare minimum (anyway, I don’t have qualified personnel to audit more than that),</li>
<li>2028: Manufacturer, thou shalt apply IEC 81001-5-1. From Genesis to Apocalypse. Otherwise, you’re non-compliant to The Cyber Writings and I'll put you a major non-conformity.</li>
</ul>
<p>More: IEC 81001-5-1 quotes IEC/TR 60601-4-5 is its body text. For those of you who have experience with Notified Bodies, you know how it can be hard to disregard a document (be it a Tech Report), if it is quoted in a standard!<br>
Thus, be prepared to have a traceability matrix between IEC 60601-4-5 high-level requirements and your secure software requirements. An additional overhead, compared to the FDA approach. Btw, IEC 60601-4-5 isn't recognized.<br>
<br>
That will be the binary (stubborn, not risk-based, still regulatory oriented …) approach of Notified Bodies. Thus, you shall be fully compliant to IEC 81001-5-1 by 2028. Or your QMS and possibly your devices will be at regulatory risk.<br>
<br>
That will probably be the last epic of the MDR – IVDR transition for medical device software.</p>
<h4>Is IEC 81001-5-1 asking to much for?</h4>
<p>No matter the risk profile of your device (the security level, if you follow the recommendations of IEC 60601-4-5), IEC 81001-5-1 is fully applicable.<br>
<br>
The working group had in mind the following goals, when writing this standard:</p>
<ul>
<li>Weaknesses and vulnerabilities can be introduced at every step of the software lifecycle, and especially in the SDLC,</li>
<li>Thus, every step of this lifecycle shall contain provisions to identify, evaluate, and track to closure weaknesses and vulnerabilities,</li>
<li>This legitimate goal leads to a heavy secure SDLC, and more general to a heavy secure software lifecycle.</li>
</ul>
<p><br>
However, it can be called into question: is it necessary to apply all provisions for a low cyber risk profile device? Or is it possible to alleviate the burden in case of low cyber risk profile? And still claiming that we do our best effort, proportionate to the cyber risk profile?<br>
<br>
State-of-the-art says that software development rigor shall be commensurate to the software risk profile. That's why we have:</p>
<ul>
<li>Software safety class in IEC 62304,</li>
<li>Documentation levels (which replaced level of concern) in <a href="https://blog.cm-dm.com/post/2023/06/16/Final-FDA-guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">FDA guidance on premarket documentation for device software function</a>,</li>
<li>And, not official but practical, a risk-based approach accepted by the FDA provided that manufacturers's cyber documents give a reasonable assurance that the device is secure.</li>
</ul>
<p>Yet, cybersecurity cannot be something only tested at the end, being ignored during design.<br></p>
<h4>Proposition to update IEC 81001-5-1</h4>
<p>This state-of-the-art advocates for such risk-based approach applied in IEC 81001-5-1 normative clauses.<br>
<br>
Proposition:
To add to IEC 81001-5-1 a system similar to IEC 62304 software safety class, based on the Capability Security Level (SL-C) claimed by the manufacturer, from the Intended Context of Use.<br>
With:</p>
<ul>
<li>For SL-C 1 and 2: a lighter secure SDLC similar to the Transitional Health Software annex:
<ul>
<li>SDLC clauses 5.1, 5.2, 5.7.1, 5.7.2, 5.7.4 and 5.8 are applicable,</li>
<li>Clauses 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.7, 4.2, 6, 7, 8, and 9 are applicable,</li>
<li>Other clauses aren't applicable.</li>
</ul></li>
<li>For SL-C 3 and 4:
<ul>
<li>The full text.</li>
</ul></li>
</ul>
<p><br>
This would lead to an approach similar to IEC 62304 class B, or FDA Basic Documentation Level, for software in SL-C 1 or SL-C 2.<br>
<br>
<br>
Hope it helps...</p>https://blog.cm-dm.com/post/2024/02/23/IEC-81001-5-1-Right-Here-Right-Now#comment-formhttps://blog.cm-dm.com/feed/atom/comments/279AAMI SW96 2023 - The keystone of security risk management for medical devicesurn:md5:62e2f2d1dc3fd84e2ca2cca3ea532ea02023-09-08T14:30:00+02:002023-10-04T17:55:56+02:00MitchStandards<p>A new standard on security risk management for medical devices was published early 2023: AAMI SW96. Unlike AAMI TIR57 and TIR97, this is a standard, not a technical report.</p> <h4>Before AAMI SW96</h4>
<p>If we start with a review of guides and standards on security risk management for medical devices, published before SW96, we have:</p>
<ul>
<li>AAMI TIR57 and TIR97: two guides (technical reports) on security risk management, for pre- and post-market. Lots of concepts and principles coming from these guides have been put in SW96. This is a classic lifecycle for AAMI documents: starting with guides, when the ground is still moving, and continuing with standards, when the subject is more mature<sup>[<a href="https://blog.cm-dm.com/post/2023/09/08/AAMI-SW96-2023-The-keystone-of-security-risk-management-for-medical-devices#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup>.</li>
<li>UL 2900-2 and UL 2900-2-1 for Network Connectable Components: clause 12 of these standards gives a brief description of what a security risk management process should be for connected medical devices.</li>
<li>IEC 81001-5-1 for Health software and health IT systems safety: clause 7 gives an even briefer description of what a security risk management process should be.</li>
<li>Guidances from regulatory authorities and international consortiums, like FDA, MDCG, TGA, and IMDRF. They present an overview or very brief description of what a security risk management process should be.</li>
<li>And more general: ISO 27005 for information systems. This standard contains a thorough description of a security risk management process, but not tweaked for medical devices.</li>
</ul>
<h4>AAMI SW96 overview</h4>
<p>It takes 14 pages in AAMI SW96 to describe a security risk management process for medical devices! Its level of description is far above the aforementioned documents (excepted ISO 27005, but not specific to MDs). We are more at the level of details of ISO 14971, if we try to make a comparison.<br />
This is actually the authors' intent: <em>to specify requirements (...) on how medical device manufacturers should manage security risk throughout the life cycle of a medical device within the risk management framework defined by ISO 14971</em>.<br />
<br />
The scope of the standard tells us what requirements are covered. They can be grouped in four sets (my analysis, this separation isn't in the standard).</p>
<h5>1.Risk management process in design:</h5>
<p>Here we retrieve the classical steps of a risk management process described in AAMI TIR57. Identifying, assessing, determining risk controls, verifying risk controls effectiveness, overall residual risk acceptability, and risk/benefit balance.</p>
<h5>2.Risk management process in post-production:</h5>
<p>The standard requires <em>establishing an enterprise-wide process to manage security post-production (...)</em> and <em>creating design features that enable production and post-production management of security risk and effective integration with healthcare delivery organization (HDO) network security policies and technologies</em><br />
These two topics are very important to establish an effective security risk management process in production and post-production. It is a combination of the appropriate processes, and appropriate features in the medical device. Thus, such features shall be present in product requirement specification (high-level requirements) and software requirement specification (more detailed requirements).</p>
<h5>3.Monitor, control and coordinate</h5>
<p>An effective risk management process requires coordination with users, customers, and integrators. It comes with (partial quote of the standard): <em>coordinating communications with HDOs for security risks; understanding and communicating the security expectations from manufacturers to those who deploy their medical devices in a user environment</em>.</p>
<h5>4.Delivery of patches, and end-of-life</h5>
<p>Risk management works with change control and design process, to deliver in a timely manner security patches. Last, the manufacturer shall anticipate the safe and secure decommissioning, and end-of-life of the device.
<br />
<br />
<br />
Here are below some other striking points of the standard that I gathered. Buy it and read it to make your own judgement.</p>
<h4>Risk management in design</h4>
<p>This is probably the subject with most of information already present in existing standards and guides. First, AAMI SW96 borrows the figure from AAMI TIR57, where the ISO 14971 process is copied into a security risk management process, with interactions between the two.<br />
Looking at other standards:</p>
<ul>
<li>IEC 81001-5-1 defined this process in a very laconic manner, and high-level risk controls can be found in IEC/TR 60601-4-5.</li>
<li>UL 2900-2-1 defines this process in section 12, with details on risk controls (a bit equivalent to IEC/TR 60601-4-5) and lots of technical details on coverage of security risk analysis. Cherry on the cake, UL 2900-2-1 in its 2023 version adds rationale on these detailed requirements.<br /></li>
</ul>
<p>If you already apply UL 2900-2-1 in design, AAMI SW96 won't tell you something so much new about risk management in design. If you already apply the laconic IEC 81001-5-1, you will learn something.<br /></p>
<h5>Risk evaluation</h5>
<p>Contrary to other standards, AAMI SW96 doesn't reference in its normative part, neither CVSS, nor MITRE, nor NIST frameworks as possible ranking systems for security risks. We see here a position similar to ISO 14971, confining the standard to a process, excluding practical contingencies.<br />
CVSS, MITRE, and NIST frameworks are quoted in the appendixes of the standard.<br />
<br />
The standard also requires implementing recurring / periodic security testing during design and development. Such testing strategy, implemented in the CI/CD for example, allows to identify new security vulnerabilities.</p>
<h5>Security controls</h5>
<p>However, AAMI SW96 remains mute on security controls, pointing vaguely to <em>relevant standards, technical reports and security frameworks</em>. A position opposite to IEC 81001-5-1 and UL 2900-2-1, which point to their own set of risk controls. This is probably a deliberate choice. AAMI SW96 is a process standard, technical requirements relevant to products have to be found elsewhere.</p>
<h5>Security controls order of priority</h5>
<p>Like ISO 14971, we retrieve the requirement on order of priority of risks controls, adapted to a security risk management process. It's worth quoting the standard:<br />
a) <em>inherent security by design;</em><br />
b) <em>inherent security by manufacturing process;</em><br />
c) <em>protective threat mitigation measures added into the medical device;</em><br />
d) <em>protective threat mitigation measures added into the manufacturing process;</em><br />
e) <em>security risk disclosure (...) and/or security risk transfer to users; and</em><br />
f) <em>where appropriate, security training to users.</em></p>
<h5>Misuse</h5>
<p>The standard includes the topic of reasonably foreseeable misuse. It requires to consider as reasonable foreseeable misuse:</p>
<ul>
<li>Exploit scenarios by threat actors,</li>
<li>Failure of some end-user populations to follow security best practices.</li>
</ul>
<p>The idea is not to inject all possible security compromising scenarios in the usability file. It is more to take from the usability file the user profiles, to take into account such intended actions from threat actors (obviously) and unintended actions from end-users (less obvious) compromising security.<br /></p>
<h5>Benefit-risk analysis</h5>
<p>AAMI SW96 offers the possibility to perform a benefit/risk analysis when a security risk isn't acceptable after practical risk controls. That could be the case with legacy devices. For example, in medical imaging with DICOM connectivity in clear format, when legacy PACS servers don't accept cyphered DICOM protocols.</p>
<h5>Overall security residual risk acceptability</h5>
<p>Last, AAMI SW96 brings a new and interesting concept in this section. Curiously, this is a note and not a requirement. It recommends to consider the balance of direct medical benefits and overall security residual risk of a device connected to a network. This balance evaluation is not found in other security risk management processes for other purposes, like privacy impact assessment, or other industries where the medical benefit doesn't exist. I warmly recommend to read twice this note, which could save your legacy devices from the trash container!
<br /></p>
<h4>Risk management production and in post-production</h4>
<p>AAMI SW96 defines the security risk management process throughout the medical device lifecycle. Conversely to risk management in design, IEC 81001-5-1 aligns better with AAMI SW96, by defining similar requirements on management responsibilities, and process periodic review. Something not so clearly present in UL 2900-x, more focused on the product.<br />
The standard goes even further, with requirements on maintaining awareness on new threats, having a security incident response plan, and vulnerability disclosure plan. Something present in FDA guidances on cybersecurity (in a precise manner) and present in MDCG 2019-16 (more generic).</p>
<h5>Supply chain, 3rd party medical devices</h5>
<p>AAMI SW96 also addresses supply chain management and risk from thrid-party medical devices. Something also present in other standards, but less specific. Here, the standard requires to document supply chain management in the security risk management plan and 3rd party medical devices security in the security risk management file.</p>
<h5>Production phase</h5>
<p>The level of details of AAMI SW96 requirements is far more precise than any other standard. If a risk control measure is established in production, its effectiveness shall be monitored. Thus, information coming form production processes shall be collected and analysed, to confirm the effectiveness of risk control measures.<br />
This standard brings detailed requirements on information collection, review and subsequent actions.<br />
<br />
Note 1: "Production" shall be understood as "manufacturing“ for software embedded in medical devices (SiMD). "Production" shall be understood as "installation and deployment" before use for SaMD.<br />
Note 2: For SaMD, when the manufacturer completely manages the infrastructure and servers, a complete set of security measures on the production environment and the supporting infrastructure should require the implementation of an ISMS, like ISO 27001 or, less heavy, SOC2.</p>
<h5>Post-production</h5>
<p>Likewise, the level of details of AAMI SW96 requirements for the post-production phase is far more precise than any other standard. Especially on information monitoring, the list of information sources contains 7 bullets, with sources like independent security researchers.
This degree of precision on information collection looks like what is required on information collection for PMS / PMCF of CE marked devices: don't miss anything otherwise you won't be compliant!<br />
And the possible actions to perform upon review of collected informations is also a very extensive list: RMF review, threat model review, and so on. The intent is clearly to avoid missing a vulnerability identified somewhere by any stakeholder.
<br />
The standard also introduces the concepts of End Of Guaranteed Support (EOGS) and End Of Support (EOS) to progressively withdraw from the market devices coming to their end of life. EOGS and EOS are present in the <a href="https://www.imdrf.org/documents/principles-and-practices-cybersecurity-legacy-medical-devices">IMDRF document on principles and practices for the cybersecurity for legacy medical devices</a>. A document to read to better understand EOGS and EOS.<br />
<br />
<br /></p>
<h4>Conclusion</h4>
<p>AAMI SW96 2023 is definitely made to be the standard defining the security risk management process for medical devices. Its level of abstraction is made to be applied by any manufacturer having SaMD or SiMD in their product portfolio. We can bet this standard will be recognized soon by the FDA.<br />
It deserves to be converted to an ISO or IEC standard, at international level.<br />
<br />
You can apply it for CE marking too. Notified Bodies will roll their eyes at first sight. But they will understand the importance of this standard when they read it. Needless to say that a few years will pass before the international version of this standard is harmonized (2030? 2040? :-) ).
<br />
<br />
Post-Scriptum: ANSM guidance on cybersecurity is quoted in the annexes. Woohoo! French cyber cooking tastes good!</p>
<div class="footnotes"><h4>Note</h4>
<p>[<a href="https://blog.cm-dm.com/post/2023/09/08/AAMI-SW96-2023-The-keystone-of-security-risk-management-for-medical-devices#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] That'll probably be the case with AAMI CR 34971.</p></div>
https://blog.cm-dm.com/post/2023/09/08/AAMI-SW96-2023-The-keystone-of-security-risk-management-for-medical-devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/275Maintained software, Supported software, Required software, and SOUPurn:md5:bbb5f84c6e4f1aeff52ccfaedd569c522023-02-20T13:56:00+01:002023-02-26T00:56:03+01:00MitchStandardsCybersecurityIEC 62304IEC 81001-5-1SOUP<p>These three concepts come from IEC 62443 and were adopted in IEC 80001-5-1. SOUP isn't present in IEC 81001-5-1.<br />
What are the differences between SOUP and Maintained software, Supported software, and Required software?</p> <h4>Definitions</h4>
<p>You will find the definitions of SOUP in IEC 62304 and Maintained software, Supported software, Required software in IEC 81001-5-1:</p>
<ul>
<li><em>SOUP</em>: software of unknown provenance. Practically speaking, if you want to integrate some 3rd party sw in your medical device, that hasn't been developed with IEC 62304, that's SOUP,</li>
<li><em>Maintained software</em>: software item for which the manufacturer will assume the risk related to security,</li>
<li><em>Supported software</em>: software item for which the manufacturer will notify the customer regarding known risks related to security,</li>
<li><em>Required software</em>: software item for which the manufacturer will consider security-related risks known before release of the health software.</li>
</ul>
<h4>Required software</h4>
<p>The case of required software is easy to manage with medical device software. The definition tells us that the <em>manufacturer will consider security-related risks known before release of the health software</em>. Thus, not after release of the health software.<br />
That contradicts ISO 14971 requirement on post-production activities and more generally requirements on post-market surveillance of regulations.<br />
Thus, that's not possible to have required software in medical devices.<br />
That's possible to have required software in health software not qualified as medical devices, but this is another story outside the scope of this blog.</p>
<h4>Supported software</h4>
<p>With supported software, <em>the manufacturer [notifies] the customer regarding known risks related to security</em>. That's a way to manage risks, so that's possible to do so with ISO 14971 and MD regulations. Provided that risks are acceptable, doing it that way.<br />
Practically speaking, if we only notify about risks, that means that supported software isn't integrated into the medical device. If it were integrated in the medical device, we'd not only notify but also provide the customer with a new version of our software.</p>
<h4>Maintained software</h4>
<p>With maintained software, <em>the manufacturer [assumes] the risk related to security</em>. That's the only way to manage risks when some software is integrated into the medical device.<br />
We retrieve here a similarity between our plain old SOUP and maintained software! With SOUP integrated in our medical device software, we have to assume the risks in the design process (IEC 62304 clause 7.1) and in the maintenance process (IEC 62304 clause 6.1).<br />
Practically speaking, when some issue (bug or vulnerability) is found in a SOUP in design, we fix it. When it is found in maintenance, we fix it (usually upgrading SOUP version and rebuilding software) and we release a new version of our software.<br />
<br />
Maintained software could be expanded to software not integrated into the medical device, thus not SOUP. That's a possibility. We could sum up that by SOUP ≤ Maintained software.<br />
But, if we want to keep things simple, we can consider that the two concepts are applicable to the same set. We could sum up that by SOUP = Maintained software.<br /></p>
<h4>Some examples</h4>
<p>The sketch of theory above deserves some examples.</p>
<h5>Mobile app or PC application</h5>
<p>All 3rd party libraries (not developed and maintained according to IEC 62304) linked to these kind of apps at build time are SOUP and maintained software.<br />
The operating system (PC platform or mobile platform) is a supported software.<br />
We cannot place the OS in required software. If we become aware of some unacceptable risk coming from the OS, we would notify the customer.<br />
Conversely, the operating system is not maintained software. We don't update it, we only notify the customer to update their OS.</p>
<h5>Software embedded in hardware medical device</h5>
<p>Once again, all 3rd party libraries (not developed and maintained according to IEC 62304) linked to our embedded binary at build time are SOUP and maintained software.<br />
The operating system (PC platform or mobile platform) is also a maintained software. If we become aware of some unacceptable risk coming from the OS, we would provide the customer with a new version of our embedded software (logistics can be tricky, but that doesn't affect the concept) with a new OS version.<br /></p>
<h5>Web application - front</h5>
<p>All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.<br />
The operating system (PC platform or mobile platform) and the browser are supported software. We cannot place them in required software. If we become aware of some unacceptable risk coming from the OS or the browser, we would notify the customer.<br /></p>
<h5>Web application - back-end, and cloud software</h5>
<p>All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.<br />
Here, we have a question about where we draw the line between SOUP and not SOUP. See the article <a href="https://blog.cm-dm.com/post/2021/03/26/When-Web-meets-SOUP">When web meets SOUP</a> about the possible answers on SOUP, OTSS, which is not SOUP, and infrastructure.<br />
We have to place the OTSS and underlying infrastructure (be it containerization or virtualization) in maintained software. We cannot place them neither in required software, nor in supported software. If we become aware of some unacceptable risk coming from one of these, we would upgrade the infrastructure version.</p>
<h5>Two software devices by two different manufacturers</h5>
<p>Let's assume we develop and maintain a medical device software, which integrates another medical device software developed by another manufacturer.<br />
Here the 3rd party software is a medical device (we assume that the manufacturer did their homework with IEC 62304), thus not a SOUP. If that other manufacturer becomes aware of some issue, they will notify us and provide us with a software update (as per IEC 62304 clause 6.1). Likewise we will update our software with this dependency update. Thus, that other medical device software is for us a maintained software.<br />
That's a peculiar case where maintained software ≠ SOUP. It is shown in this article to demonstrate that maintained software and SOUP are different concepts. But, to keep it simple, in the vast majority of cases, maintained software = SOUP.</p>
<h4>Conclusion</h4>
<p>One interesting consequence of new definitions brought by IEC 81001-5-1 is to help us understanding wether to place 3rd party software in SOUP or not in SOUP. It's frequent that design teams hesitate to place an OS in SOUP. The concepts of maintained software and supported software, are not equivalent to SOUP (the word <em>incorporated</em> appears in SOUP definition, not in required / supported / maintained software definitions). But, if we simplify by assuming that maintained software = SOUP, then we have criteria to place OS, and some other borderline cases, in SOUP or not.</p>https://blog.cm-dm.com/post/2023/02/20/Maintained-software%2C-Supported-software%2C-Required-software%2C-and-SOUP#comment-formhttps://blog.cm-dm.com/feed/atom/comments/248IEC/TR 60601-4-5 kicked out of harmonized standardsurn:md5:28e3caba3b9ee3457101afffa7f93c612022-07-08T13:52:00+02:002022-08-31T08:44:03+02:00MitchStandards<p>The 6th June 2022, <a href="https://ec.europa.eu/docsroom/documents/50274">a draft request has been published</a> to update the list of EU MDR/IVDR harmonized standards. This request brings changes to the list presented in <a href="https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5">the draft list of April 2021</a>.</p> <p>To the surprise of the reader, IEC/TR 60601-4-5 is removed from the draft list of harmonized standards.<br />
This changes a lot, and at the same time, this changes nothing. Let's see why.<br /></p>
<h4>Changes a lot</h4>
<p>This standard won't be harmonized. Thus, it won't be mandatory. That sound consistent with the fact that this is not a standard, but a Technical Report (TR) without any normative part.<br />
It was probably the result of a mistake, to include this TR in the draft list. Actually a draft list for at least one good reason!<br />
<br />
The consequence is the possibility to disregard its content as mandatory requirements (hum, not mandatory, but presumption of conformity, same old story):</p>
<ul>
<li>So Notified Bodies (NB) shouldn't take this TR as presumption of conformity to General Safety and Performance Requirements (GSPR) on cybersecurity (GSPR 17.2 and 17.4 to be specific).</li>
<li>So, you shouldn't have to present some kind of traceability matrix of your device's requirements with IEC/TR 60601-4-5 requirements.</li>
<li>So, the NB Technical File reviewer shouldn't be obliged to make a <del>disastrous hilarious fastidious</del> comprehensive review of this traceability matrix with dozens of remarks.</li>
<li>So, you shouldn't have to answer to all these remarks.</li>
<li>Bonus: so NB's shouldn't have to train their reviewers to this standard (not sure, see below).</li>
</ul>
<p><br />
This is a big change!<br />
<br /></p>
<h4>Changes nothing</h4>
<p>Anyway, the TR is referenced 4 times in notes of the normative part of IEC 81001-5-1, which stays in the list.<br />
In clause 5.2.1 <em>HEALTH SOFTWARE SECURITY requirements</em>, the Note 1 reads:<br />
<em>IEC TR 60601-4-5 gives guidance on the specification of SECURITY CAPABILITIES and their documentation in the ACCOMPANYING DOCUMENTATION and provides a method of determining requirements from the SECURITY CAPABILITY level.</em><br />
<br />
You'd better be prepared to justify it, if you choose another method of determining your security requirements!<br />
<br />
<br />
More, in clause 6.1.1 <em>Timely delivery of SECURITY updates</em>, the standard references in the body text (and not in a note) IEC 60601-4-5 as additional guidance.<br />
<br />
You'd better be prepared to justify it, if you choose policy different from IEC 60601-4-5 for delivering security updates!<br />
<br />
<br />
As an alternative, you could use FDA guidances on cybersecurity, <a href="https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission">like Appendix 1 of the new draft FDA guidance on cybersecurity framework</a>. At first sight, this could be a good option. The FDA cybersecurity framework is more mature. However it presents a drawback:</p>
<ul>
<li>Cherry-picking in the FDA guidance is not an option, you have to justify why you don't apply the rest of the guidance,</li>
<li>FDA guidances cover both regulatory considerations, like MDCG 2019-16 and technical considerations like harmonized standards.<br /></li>
</ul>
<p>It means that you'll still have to apply MGCG 2019-16, putting apart the regulatory considerations of FDA guidances, in your CE mark technical file. That's a kind of balancing act between two regulations.<br />
<br />
<br />
So, we're a bit stuck to IEC/TR 60601-4-5 even though it cannot be harmonised.<br />
<br />
That changes nothing!<br />
<br />
<br />
So, we do our homework and take IEC 81001-5-1 and IEC 60601-4-5 in our list of standards and guidance, part of our design input.<br />
No escapes.</p>https://blog.cm-dm.com/post/2022/07/08/IEC/TR-60601-4-5-kicked-out-of-harmonized-standards#comment-formhttps://blog.cm-dm.com/feed/atom/comments/263IEC 81001-5-1, final version publishedurn:md5:2a3a188f567acb9d40816ab054c4962f2022-01-13T13:54:00+01:002022-01-13T13:54:00+01:00MitchStandardsCybersecurity <p>IEC 81001-5-1 was published in December 2021. We already talked about the draft version <a href="https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5">here</a>. Combined with IEC/TR 60601-4-5, published in February 2021, these two standards constitute the state of the art in cybersecurity of medical devices in Europe.<br />
<br />
The final version is very close to the draft version, apart from a few changes to the organizational requirements; formerly clause 10 present in the draft, but removed and copied to clause 4 in the final version.<br />
<br />
Be prepared to apply these two standards for your MDR CE Mark submissions, when they are harmonized. <a href="https://ec.europa.eu/growth/tools-databases/mandates/index.cfm?fuseaction=search.detail&id=599#">Most probably by 2024</a>.</p>https://blog.cm-dm.com/post/2022/01/13/IEC-81001-5-1%2C-final-version-published#comment-formhttps://blog.cm-dm.com/feed/atom/comments/253Cybersecurity standards: IEC 81001-5-1 and IEC/TR 60601-4-5urn:md5:d278dc91a1fdba4f51fda7d62aa5bdbf2021-07-09T13:37:00+02:002021-07-15T08:17:50+02:00MitchStandardsCybersecurity<p>The <a href="https://ec.europa.eu/growth/tools-databases/mandates/index.cfm?fuseaction=search.detail&id=599#">draft list of harmonized standards for the MDR regulation</a> was published in May 2021. In this document, we find the references to the following cybersecurity standards:</p>
<ul>
<li>IEC 80001-1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software - Part 1: Application of risk management,</li>
<li>IEC 81001-5-1 (not published): Health Software and health IT systems safety, effectiveness and security - Part 5-1: Security - Activities in the product lifecycle,</li>
<li>IEC/TR 60601-4-5: Medical electrical equipment - Part 4-5: Guidance and interpretation - Safety-related technical security specifications.</li>
</ul> <p>The date of adoption of these standards is set to May 2024 in this standardization request, which contains the list of harmonized standards for the MDR and IVDR.<br />
I put deliberately apart the IEC 80001-1, it deals with network security. In this post we focus on the two other standards, which deal with software design and maintenance. <br />
<br />
Standardization request with draft standards, this sounds far from being applicable. But if you’re a manufacturer of AIMD or electromedical devices, the lifecycle of your devices streches on several years. MD design can take ages! Thus, it’s worth having a look at these drafts, to see what the Notified Bodies’ expectations will be in 2024. So, for the next generation of your devices being currently designed.<br />
<br />
Given the design cycle of a MD, it is recommended that manufacturers designing connected devices look closely at these two standards, even if IEC 81001-5-1 is in draft status. Furthermore, there is no doubt that these standards will be recognized by the FDA. The secretary of the working group is in the US, suggesting that the FDA is in the loop.</p>
<h4>Impact on the design process of connected MDs</h4>
<p>IEC 81001-1-5: its title and structure are borrowed from IEC 62304. It is made for ease of reading by teams experienced in MD software design, but with poor or no experience in secure software lifecycle. IEC 81001-5-1 complements IEC 62304 with tasks related to cyber security.<br />
<br />
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC-81001-5-1-secure-SDLC-tasks.png" title="IEC 81001-5-1-secure SDLC tasks.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-81001-5-1-secure-SDLC-tasks_m.png" alt="IEC 81001-5-1 secure SDLC tasks.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 81001-5-1 secure SDLC tasks.png, Jul 2021" /></a>
<br />
IEC/TR 60601-4-5 defines a list of security requirements to be injected in your Hardware Requirement Specification (HRS), Software Requirement Specification (SRS), and accompanying documents.<br />
Here is an example of security requirements:<br />
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_60601-4-5-requirement-example.png" title="IEC/TR 60601-4-5 requirement-example.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_60601-4-5-requirement-example_m.png" alt="IEC/TR 60601-4-5 requirement example.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC/TR 60601-4-5 requirement example.png, Jul 2021" /></a>
<br />
These two standards work together. The first one defines secure software processes (the “how to”), the second the software security requirements (the “what”).</p>
<h4>Where do these two standards come from?</h4>
<p>Cybersecurity has been a concern for a long time is other industries, which were subject to digitization and interconnection earlier than healthcare. In our case, these two standards are a transposition of two standards named IEC 62443-4-1 and IEC 62443-4-2 for Industrial Automation and Control Systems (IACS).<br />
<br />
Why standards from IACS and not ISO 2700X, or other references coming from banking and finance (a sector where cybersecurity is a high concern)?<br />
Because IACS networks and HIS networks have strong similarities.<br />
<br />
Here is a copy of a diagram from IEC/TR 60601-4-5:<br />
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC-60601-4-5-entreprise-zone-conduits.png" title="IEC/TR 60601-4-5 entreprise zone conduits.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-60601-4-5-entreprise-zone-conduits_m.png" alt="IEC/TR 60601-4-5 entreprise zone conduits.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC/TR 60601-4-5 entreprise zone conduits.png, Jul 2021" /></a>
We have an industrial firm with:</p>
<ul>
<li>Headquarters or administration offices,</li>
<li>Production plants,</li>
<li>production lines with machines and PLCs</li>
</ul>
<p>Similarly, we can have a similar structure in an healthcare center, where we find:</p>
<ul>
<li>Administration managing patients ins & outs and patients’ data,</li>
<li>Patients rooms with near-bed medical devices, some of which may be life-critical,</li>
<li>Intensive care rooms and Operating rooms with life-critical medical devices.</li>
</ul>
<p>This similarity in the structure advocates for transposing the IACS cybersecurity standards to the medical device sector. It is worth noting that the FDA has the same approach, hence IEC 62443-4-1 is <a href="https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=42309">a FDA recognized standard</a>.<br />
<br />
Industries have to protect their personnel from injury with industrial machinery, their data from theft, their IT systems from breakdown and their production lines from costly production stops. Likewise, healthcare centers have to protect their patients, their personnel, patient data, their HIS from life-threatening hazards, and their healthcare services from costly shutoff.<br />
<br />
Note: ISO 2700X family remains relevant for datacenters storing data (especially health data) and containing data management services.</p>
<h4>Content of IEC 81001-5-1</h4>
<p>The table of contents IEC 81001-5-1 is copied from the one of IEC 62304, organized in processes. The 6 processes of IEC 62304 are illustrated in the diagram below.
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC-62304-sections.png" title="IEC 62304 sections.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC-62304-sections_m.png" alt="IEC 62304 sections.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 62304 sections.png, Jul 2021" /></a>
<br />
Likewise, IEC 81001-5-1 defines security processes throughout the software lifecycle.
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_81001-5-1-sections.png" title="IEC 81001-5-1 sections.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_81001-5-1-sections_m.png" alt="IEC 81001-5-1 sections.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 81001-5-1 sections.png, Jul 2021" /></a></p>
<h4>No software safety class</h4>
<p>It’s worth noting that there is <ins>no equivalent of software safety class</ins> in IEC 81001-5-1. It means that, contrary to IEC 62304, all requirements of IEC 81001-5-1 are applicable for any software whatsoever.<br />
E.g.: requirements on detailed design present in IEC 81001-5-1 are applicable even if your software is in class A with IEC 62304.<br />
<br />
Fortunately, even if documentation of detailed design is required by IEC 81001-5-1, it doesn't go as deep as IEC 62304 where all software units shall be 100% documented. IEC 81001-5-1 only requires documenting secure design and secure interfaces. That can be reduced to a subset of all software units.<br />
So, the effort of software design documentation with IEC 81001-5-1 is higher than simple IEC 62304 class A software, but not so different from what is required for IEC 62304 class B.<br />
<br />
Instead of software safety class, IEC 81001-5-1 recommends using the concepts of security level (SL) and security capabilities (SC) found in IEC/TR 60601-4-5, and discussed below.<br /></p>
<h5>Origin of weaknesses</h5>
<p>A principle of secure software lifecycle is that security weaknesses can be introduced in every step of the software lifecycle:</p>
<ul>
<li>specifications: wrong behavior specified,</li>
<li>architecture: unsecured architecture,</li>
<li>detailed design: unsecured interface detailed design,</li>
<li>coding: language traps or wrong coding patterns,</li>
<li>make / build: unsecured generated binary or bytecode,</li>
<li>install, configure: wrong installation or configuration.</li>
</ul>
<p>This is why IEC 81001-5-1 requires to document all the steps of the secure SDLC, disregarding the concept of software safety class. This is also why it covers the full software lifecycle, like IEC 62304.</p>
<h4>Content of IEC/TR 60601-4-5</h4>
<p>I don't know what effect it has on you, but when I see a standard number with 60601 in it, I frown!<br />
Does it mean that we'll need a certificate from a security lab? Fortunately not! Because this standard is named with <ins>TR</ins>, which stands for Technical Report.<br />
However, we see some offers on cybersecurity testing blossoming from IEC 60601-1 accredited test labs. So, a TR is not a standard, but we could come up to a situation where, despite the TR, a test report from accredited test labs may be requested by the notified bodies or the FDA.<br />
<br />
IEC 60601 series is not applicable to standalone software. But in this technical report, the introduction mentions that: <em>MEDICAL DEVICE SOFTWARE, although not in the scope of IEC 60601 (all parts), can also make use of this document</em>. Thus, this technical report can be applied to standalone software! No, software editors, you can't escape like that!</p>
<h4>Definition of safety requirements for connected MDs</h4>
<p>The IEC/TR 60601-4-5 is based on the requirements of the IACS IEC 62443 family of standards, which is very engineering-intensive for its implementation.<br />
<br />
This guide defines Security Levels (SL) and Security Capabilities (SC), which depend on the impact of a security breach on the system. SL and SC are borrowed from the IEC 62443 family.<br />
The SLs are on a scale of 0 to 4 - Definition (IEC 62443-1-1):</p>
<ul>
<li>SL 0 - No prevention.</li>
<li>SL 1 - Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.</li>
<li>SL 2 - Prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.</li>
<li>SL 3 - Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, medical device specific skills and moderate motivation.</li>
<li>SL 4 - Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, medical device specific skills and high motivation.</li>
</ul>
<p>Like IEC 62304 subsystems with different security classes, security zones can be defined with different SL. It means that a medical device can have more than one security zone, with different SL.<br />
This could be the case for a home-use device, with two security zones:</p>
<ul>
<li>one connected to the internet in SL3,</li>
<li>and one with life-critical functions in SL1, isolated from the first.</li>
</ul>
<p>Of course, like IEC 62034, the security zones shall be segregated. And of course, like IEC 62304, IEC/TR 60601-4-5 doesn't define the kind of technical measures required for an effective segregation!</p>
<h5>Foundational requirements</h5>
<p>IEC/TR 60601-4-5 defines a total of 7 Foundational Requirements (FRs), borrowed from the IEC 62443-1-1:</p>
<ul>
<li>Identification and authentication control (IAC)</li>
<li>Use Control (UC)</li>
<li>System Integrity (SI)</li>
<li>Data Confidentiality (DC)</li>
<li>Restricted Data Flow (RDF)</li>
<li>Timely Response to Events (TRE)</li>
</ul>
<p>These 7 FR are refined in 123 requirements. That's a lot of requirements!<br />
But not all requirements are always applicable. The 123 requirements are only applicable to software in SL4.
It can be easily seen that SL3 and SL4 are the SL with a higher overhead. For software in SL1, "only" 50 requirements are applicable.<br />
<br />
These security requirements found in IEC/TR 60601-4-5 can be seen a "reservoir" of secure product requirements to be refined in HRS and in a Secure SRS document or a security section in the SRS.<br /></p>
<h5>SL Vector</h5>
<p>IEC/TR 60601-4-5 § A.6 allows to define different SL, according to the types of foundational requirements applicable. For example, for a device that does not handle confidential data, the SL for data confidentiality (DC) will be set to 0, whereas the SL for the system is 4.<br />
This "SL vector" approach (the term used in the standard) is possible for any system. This is a way to make a lighter list of security requirements applicable to your device.</p>
<h4>IEC 81001-5-1 and IEC/TR 60601-4-5 work together</h4>
<p>IEC 81001-5-1 and IEC/TR 60601-4-5 work in combination, the former defining a secure software development process, the latter feeding this process with security requirements.<br />
This is illustrated in the following diagram, where IEC 81001-5-1 defines the secure SDLC, and IEC/TR 60601-4-5 "injects" security requirement at system level (above the horizontal dotted line) and at software level:
<a href="https://blog.cm-dm.com/public/31-Cybersecurity/IEC_81001-5-1-and-IEC-60601-4-5-combined.png" title="IEC 81001-5-1 and IEC/TR 60601-4-5-combined.png, Jul 2021"><img src="https://blog.cm-dm.com/public/31-Cybersecurity/.IEC_81001-5-1-and-IEC-60601-4-5-combined_m.png" alt="IEC 81001-5-1 and IEC/TR 60601-4-5 combined.png, Jul 2021" style="display:table; margin:0 auto;" title="IEC 81001-5-1 and IEC/TR 60601-4-5 combined.png, Jul 2021" /></a>
<br /></p>
<h4>Conclusion</h4>
<p>Draft standards in a standardization request, the state-of-the-art is being constructed. IEC 81001-5-1 and IEC/TR 60601-4-5 are clearly paving the way to future conformity to cybersecurity requirements. In EU and in the US.
We can take the bets that their approved version will be soon recognized by the FDA and harmonized in 2024 as planned in the EU.<br />
<br />
Edit 2021/07/15: unofficial information, IEC 81001-5-1 should be published by the end of 2021 or early 2022.</p>https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5#comment-formhttps://blog.cm-dm.com/feed/atom/comments/245IEC 62304:2021 Committee Draft Version: Groundhog Dayurn:md5:e210fd6ce3faf4e3e0314c966020aa802021-02-19T13:43:00+01:002021-05-01T09:27:11+02:00MitchStandards<p>That's a déjà-vu. The second version of IEC 62304 is still in draft. It has been in this state for five years, since the publication of the amendment 1. <a href="https://blog.cm-dm.com/post/2019/11/22/IEC-62304%3A2019-or-2020-next-generation">We already had a draft version in 2019</a>. A new draft version is, again, in public review (or has been in public review in your country) under the name IEC CDV 62304:2021. Go to the website of your national standardization organization, to see if you can still download it for free!</p> <p><strong>Edit 01 May 2021: the draft has been rejected. The project is closed. It means that IEC 62304 2006 + Amd1:2015 will remain valid for some more years.</strong><br />
<strong>And everything written below is obsolete.</strong><br />
<br />
Compared to the last draft version, there isn't any significant change for software qualified as medical devices (MDSW).<br />
Some people keen at verifying the wording of the standard will see true significant changes for editors of software not qualified as medical devices. I dare say that, excepted the addition of cybersecurity, there isn't any fundamental change for MDSW, compared to the version of 2015.</p>
<h4>Scope</h4>
<p>The 2021 version extends the scope to health software, not qualified as medical device. That was already present in the 2019 version. Here, compared to the 2015 version, the 2021 version makes significant changes for software not qualified as medical device. In this article, we focus on MDSW only.<br />
<br />
The main consequence in changing the scope is on SOUPs. In the 2015 version, SOUP is software not made to be incorporated in a <em>medical device</em>. In the 2021 draft (and also 2019 draft), a note is added stating that <em>a health software system is not a SOUP</em>.<br />
<br />
Thus , when a manufacturer develops a MDSW built over a health software system not qualified as a medical device, the latter is not a SOUP. Does it mean that the manufacturer shall document the health software system according to the standard? We're in a grey zone, hence the reviewer of the Regulatory Authority is usually mandated to audit the MDSW only. However, we have the <a href="https://blog.cm-dm.com/post/2020/09/04/FDA-Guidance-on-Multiple-Function-Device-Products">FDA Guidance on Multiple Function Device Products</a> saying something similar to the IEC 62304 draft. With a risk-based approach, the health software not qualified as a medical device (the <em>other function</em> in the FDA guidance) may be in some cases documented.</p>
<h4>Exit ISO 14971</h4>
<b>ISO 14971, <font color="red"/>You're Fired!</font></b>
<p><br />
This is definitely the biggest change in this version. The clause 4.2, which strongly binds ISO 14971 and IEC 62304, has been removed and replaced by requirements on risk management. The new clause requires to have a risk management process for safety risks and security risks. ISO 14971 standard is now referenced in the annexes only.<br />
Remark: cybersecurity risk management was already present in the previous 2019 draft.<br />
<br />
Exit ISO 14971? Of course not! It should be a no-brainer that ISO 14971 is still required for MDSW. ISO 14971, bounces back to you by the regulatory path.<br />
<br />
That change comes from the scope of IEC 62034 extended to health software, and aligned with the scope of IEC 82304-1. It is possible for health software to have a risk management process not compliant to ISO 14971, like ISO 31000, or ISO 27005.<br />
Some people don't agree with these choices. Personally, I think it won't change the way IEC 62304 impacts the MDSW lifecycle and the documentation to be generated.</p>
<h4>Software Process Rigor Level</h4>
<b>This is the biggest <i>wording</i> change: Software Safety Class, <font color="red"/>You're Fired!</font></b>
<p><br />
And you're replaced by the <em>Software process rigor level</em> (SPRL, abbreviation by me), found in clauses 4.3 and 4.4. This is a big change of appearance, and absolutely not a change for the process of determination of the SW Safety Class. Huh, excuse me, the SPRL. The workflow found in clause 4.3 of the 2015 version is still present in the figure 3 of the 2021 version.<br />
The clause has been revised for the sake of clarity, explaining step-by-step the process to determine de SPRL. Especially, the list of hazardous situations found in clause 4.4.2.2 is a good supplement to the list of questions found in Annex A of ISO/TR 24971:2020.<br />
<em>Sake of clarity</em>, I hope this will be the case, and that newcomers will promptly understand how to determine the SPRL. Keep fingers crossed!<br />
<br />
Some other explanations can be guessed:</p>
<ul>
<li>The SPRL is the result of a brainstorming with marketing specialists, to promote the IEC 62304 in a TV show and make it affordable to the general public,</li>
<li>Or this is the tip of the iceberg, hiding a malignant scheme to conquer and rule the world with AI-based SaMD.</li>
</ul>
<p>But I digress.<br /></p>
<h4>Other changes</h4>
<p>Here are some other minor changes to the normative part:</p>
<ul>
<li>clause 5.1.9 configuration management planning, addition of bullet g) requiring to determine when the formal change control process will be used. Thus, it means that in some cases, e.g. during development, it may not be used,</li>
<li>clause 5.3.3 Specify functional and performance requirements of SOUP item, addition of a clear reason for these functional and performance requirements: they're necessary for the proper integration of SOUPs into the software,</li>
<li>Clause 5.8.8 was simplified to make it more modern. No more reference to replication, packaging...</li>
<li>Clause 6.2.5 Communication to regulators was dropped in favor of communication to users. Anyway, regulators bounce back by regulatory requirements,</li>
<li>Clause 7.1.2 Identify potential causes of contribution to hazardous situation: some additions to bullet d) failures external to the software,</li>
<li>Clause 7.2.1 Define risk control measures, addition of a little but useful note, on the fact that risk control measures <em>can include application of specific methods and activities in the software development life cycle</em>.</li>
</ul>
<p>Remark: the spirit of clause 7 on risk management is IMHO left untouched, compared to the 2019 version.</p>
<h4>Conclusion</h4>
<p>Wait and see if this draft version goes to FDIS and is approved as the official 2nd version. Then, we will be able to move on!<br />
<br /></p>
<pre> unsigned int uiYear = 2016;
bool bPublish = false;
std::string strVersion;
while (!bPublish) {
uiYear++;
//Watchdog stability date 2024
if (uiYear > 2024)
throw std::out_of_range(strVersion);
strVersion = u8"IEC 62304:";
strVersion += std::to_string(uiYear);
strVersion += u8" CDV";
getWG("IEC_SC_62A_ISO_TC_215").MakeDraftVersion(strVersion);
bPublish = getWG("IEC_SC_62A_ISO_TC_215").IsDraftVersionAccepted(strVersion);
}
strVersion = u8"IEC 62304:";
strVersion += std::to_string(uiYear);
strVersion += u8" FDIS";</pre>
<p><br />
<br /></p>
<h4>Post Scriptum</h4>
<p>The 2nd version doesn’t bring any new element, while software technology evolved a lot since 2015. It would be convenient to have standards or technical reports:</p>
<ul>
<li>A general guidance, like IEC 62304-2, something already exists with IEC/TR 80002-3,</li>
<li>Secure software lifecycle, a draft already exists, named IEC 80001-5-1 (I'll write about it soon).</li>
</ul>
<p>And some guidance on these subjects:</p>
<ul>
<li>A TR on application to agile methods, we already have the AAMI TIR45. It could be internationalized, like what has been done for the AAMI TIR36 and ISO/TR 80002-2,</li>
<li>A TR on application to Machine Learning based algorithms,</li>
<li>A TR on application to life-critical software,</li>
<li>A TR on best design practices for software alarms,</li>
<li>A TR on application to cloud-based applications,</li>
<li>A TR on application to mobile platforms,</li>
<li>A TR on principles of architectural segregation, MDSW vs non-MDSW, SPRL C, SPRL B and SPRL A.</li>
</ul>https://blog.cm-dm.com/post/2021/02/19/IEC-62304%3A2021-Committee-Draft-Version%3A-Groundhog-Day#comment-formhttps://blog.cm-dm.com/feed/atom/comments/244IEC 62304:2019 or 2020 - Next Generationurn:md5:a65691b74f75b53f81b7db74df8fdcf02019-11-22T14:16:00+01:002021-03-10T15:48:26+01:00MitchStandardsIEC 62304<p>The second version of IEC 62304 is still in draft. It has been is this state for almost five years, since the publication of the amendment 1. It is now in public review (or has been in public review in your country) under the name IEC 62304:2019 CDV. Go to the website of your national standardization organization, to see if you can still download it for free!</p> <p><strong>March 2021 edit</strong>: <a href="https://blog.cm-dm.com/post/2021/02/19/IEC-62304%3A2021-Committee-Draft-Version%3A-Groundhog-Day">see there</a> the latest news on IEC 62034 2nd edition.<br /></p>
<h4>Major changes</h4>
<p>The first major change is the product scope covered by this new version. In the will of alignment of IEC 82304-1 and IEC 62304, the latter has now an extended product scope with a better coverage of the former: Health Software. To be sure that the reader understands that both are aligned, the diagram found in IEC 82304 Annex A has been copied into IEC 62304 Clause 1 "Scope". We can anticipate that the next version of IEC 82304-1 will see the diagram in annex A be moved to Clause 1 accordingly.<br />
Yet, the big difference between IEC 62304 and IEC 82304-1 remains: IEC 62304 covers embedded software, not IEC 82304-1 (replaced by IEC 60601-1 for embedded software).</p>
<h5>Risk management and cybersecurity</h5>
<p>The wording of clause 4.2 on risk management process has been reviewed, to cope with cases where no hazardous situation exists (most probably some health software not qualified as medical device). But this has no impact on medical devices.<br />
<br />
The major change in this clause is the appearance of Security, equivalent to the more popular term: cybersecurity. Thus, compliance to IEC 62304 2nd edition will require a software lifecycle that fully implements a <a href="https://blog.cm-dm.com/post/2018/10/15/Cybersecurity-Part-5-Templates">cybersecurity management process</a>.<br />
Mirroring this change, the list of potential causes of contribution in clause 7.1.2 has been updated. See below.</p>
<h5>Usability everywhere</h5>
<p>A new clause 4.3 is added, requiring a usability engineering process. The standard on usability and human factors engineering, IEC 62366-1, is referenced in a note at the bottom of this clause.<br />
This clause is consistent with ISO 13485:2016, which requires usability in design inputs, and refers to IEC 62366-1.<br />
Note that the clause on software safety class is now clause 4.4, pushed down by the new clause 4.3 on usability.</p>
<h5>Legacy software</h5>
<p>Validation of legacy software was introduced in the Amendment 1 in 2015. It is still present in the 2019 draft, with the same spirit: a kind of retrospective validation based on analysis of post-market data, gap analysis and gap closure.<br />
To be aligned with clauses 4.2 and 4.3, legacy software validation found in clause 4.5 requires addressing usability and cybersecurity, on top of safety risks.<br />
<br />
But the very major change about legacy software is dug into the details of the wording: the clause 4.5.4.c was changed (emphasis is mine):</p>
<ul>
<li>From: <em>Changes to the LEGACY SOFTWARE shall be performed in accordance with <strong>clause 6</strong></em><br /></li>
<li>To: <em> Changes to the LEGACY SOFTWARE shall be performed in accordance with <strong>this document</strong></em><br /></li>
</ul>
<p>Clause 6 deals with software maintenance only, namely for patches or minor changes. Conversely, <em>This document</em> means that <strong>we can refer to clause 5 about software development</strong>.<br />
<br />
Thus, we can take a legacy software, perform the retrospective validation, and declare it is compliant to IEC 62304. Then from this legacy version, we can create a new major version where we will document, according to clause 5, only the parts new or modified in this major version!<br />
This is magic!<br />
Hurray to the IEC 62304 working group!<br />
<br />
<br />
These are the only major changes. Medical device manufacturers, your gap analysis won't be too heavy.<br />
<br /></p>
<h4>Minor changes in 4.4 software safety class</h4>
<p>The most prominent change is the rework of the clause about software safety class, now 4.4, hence 4.3 is for the new clause about human factors engineering.<br />
While the text has been quite amended, the assessment of the software safety class hasn't changed in substance, e.g. still 100% probability of software failure, still a dose of acceptability for class A. Changes were obviously brought for the sake of clarity.<br />
Several notes are added, two of which could retain your attention:</p>
<ul>
<li>Note 3: Software failures are not only bugs, but also requirements failures, or failures in human factors,</li>
<li>Note 6: External risk control measures can be not only hardware or external system, but also healthcare procedures or other means.</li>
</ul>
<p>Note 3 closes a possible discussion on the fact that foreseeable misuse of software isn't a software failure. Yes, wrong GUI, wrong man-machine interaction can be a software failure, which shall be undertaken in the assignment of a software safety class! This has all the more been present in clause 7.1.2 since the first version of the standard in 2006.<br />
<br />
Note 6 closes another possible discussion on the fact that only tangible (hardware, external system) means are acceptable risk control measures. Yes, an intangible healthcare procedure can be a risk control measure!</p>
<h4>Minor changes in 7.1.2 potential causes of contribution to a hazardous situation</h4>
<p>This clause was amended to explicitly cover all the potential causes of hazardous situations related to software, in design and at runtime.</p>
<h5>Common software defects</h5>
<p>The clause 5.1.12 about identification and avoidance of common software defect has vanished! It hasn't been moved to another location in the text.<br />
Rest assured, the requirement is still there, merged into the list of potential causes of contribution to a hazardous situation : <em>7.1.2 f) defects that may be based on the selected programming technology, including programming language issues</em>.<br />
This is actually more consistent to find this in the chapter on software risk management process, rather than in the software development plan.</p>
<h5>Defects from software tools</h5>
<p>In the same vein, the list of potential causes of contribution to a hazardous situation now contains <em>7.1.2 e) defects that may be introduced by the used software environment, including tools and libraries; defects that may be introduced by the software development environment.</em><br />
This closes a third discussion on the fact that failure of software design tools shall be included in the identification of risks. Although they are not SOUP within a strict interpretation of the definition of SOUP found in IEC 62304, they are Off-The-Shelf Software (OTSS, FDA acronym) and they can contribue to a software failure. E.g. an error of compilation.</p>
<h5>Cybersecurity</h5>
<p>As mentioned above, the list also contains <em>7.1.2 h) cyberattacks and security breaches (e,g., denial of service, malware hacking, unauthorized access via user interface)</em>. Thus cybersecurity vulnerabilities have to be taken as a hazardous phenomenon with regard to ISO 14971. This is pretty well synthesized in the Figure B.1 of informative Annex B.<br />
<br />
IEC 62304:2019 CDV contains quite a good update of clause 7.1.2. It now contains a very comprehensive list of potential software causes of contribution to a hazardous situation.</p>
<h4>Other changes</h4>
<p>Dozens of notes, rewording for clarification, references to other standards, a very articulate Annex B with examples on how to assign a software safety class. These are the other minor changes.<br />
The reason is obviously to make the standard more readable per se, and more readable by people who are not used to medical devices standards. Like medical device start-ups, or ... health software vendors.</p>
<h4>Signing session</h4>
<p>To my mind, The members of the IEC 62304 2nd edition working group could organize a signing session! When it is published, in 2020.<br />
<br />
Manufacturers of software in class I falling into class IIa, your technical file is not very ... up-to-date? You're the happy owners of legacy software? Don't pretend your documentation is up-to-date, and enjoy the new legacy software requirements. The working group members are waiting for you at the signing session with your (very expensive) hardcopy of IEC 62304 2nd edition!</p>https://blog.cm-dm.com/post/2019/11/22/IEC-62304%3A2019-or-2020-next-generation#comment-formhttps://blog.cm-dm.com/feed/atom/comments/229Cybersecurity in medical devices: a short review of UL 2900-1urn:md5:c0d4a8261e44a1484ce72f99b4a590992019-08-16T13:44:00+02:002019-08-17T20:01:29+02:00MitchStandardsCybersecurity<p>We continue this series of articles on cybersecurity with a free and non-exhaustive review of UL 2900-1 standard.<br />
What is UL 2900-1? This standard was published in 2017 by Underwriters Laboratory (UL). It contains technical requirements on cybersecurity for network connectable products. A collateral UL 2900-2-1 focuses on connectable healthcare and wellness systems. UL 2900-1 and UL 2900-2-1 are FDA recognized standards. Thus, applicable to medical devices.</p> <p>Unlike other guides and standards, e.g. AAMI TIR 57 or ISO 27005 or FDA guidances, this standard doesn't contain requirements on a cybersecurity risk management process. It is more a set of requirements on cyber security measures to document, implement and verify.<br />
However, the section 12 of the standard requires to establish a security risk management process, with some specific requirements, like the use of classification schemes. E.g. <a href="https://capec.mitre.org">CAPEC</a> or <a href="https://cwe.mitre.org/cwraf/">CWRAF</a><br />
<br />
Thus, UL 2900-1 cannot be used alone, and you should rely on other standards or guidances to establish a security risk management process, before implementing UL 2900-1 requirements.</p>
<h4>Comparison with 60601 standard?</h4>
<p>Can we dare a comparison with 60601-1 standard?<br />
IEC 60601-1 Ed3 contains a (huge) set of technical requirements, with a link to safety risk management process. UL 2900-1 contains a set of technical requirements with a link to security risk management process.<br />
Like IEC 60601-1, evidences of compliance to requirements UL 2900-1 will be found in the device design and device verification plans and reports of the Design History File (FDA) or Technical File (CE mark) of the device.<br />
Like IEC 60601-1, UL 2900-1 is made for certification of products by accredited laboratories, as of today by UL only.</p>
<h4>Link with 62304 standard</h4>
<p>IEC 62304 defines requirements on software lifecycle <em>processes</em>: development, maintenance, configuration management, and risk management.<br />
UL 2900-1 defines requirements on <em>product</em>. Thus, UL 2900-1 will affect your software development and maintenance plans, as well as software requirement analysis, test plans and test reports required by IEC 62304.<br />
In a few words: IEC 62304 is a <em>process</em> standard, UL 2900-1 is a <em>product</em> standard.<br />
Remark: this is also true for IEC 82304-1</p>
<h4>Product documentation</h4>
<p>The standard begins with requirements on product documentation. A rough half of the documentation items listed in the standard are already required by regulations or other standards, like IEC 62304.<br />
The second half is specific to UL 2900-1, and is the output of the other requirements found in the standard.<br />
This product documentation will be reviewed by UL for evaluation and certification. If you want to get a certificate.</p>
<h4>Technical requirements</h4>
<p>The rest of the standard is composed of a set of technical requirements grouped by different topics:</p>
<ul>
<li>Risk controls applicable to software design,</li>
<li>Access controls, user authentication,</li>
<li>Use of cryptographically secure mechanisms,</li>
<li>Remote communication integrity and authenticity,</li>
<li>Confidentiality of sensitive data,</li>
<li>Product management in post-market: security updates, decommissioning</li>
<li>Validation of tools and processes from a security standpoint,</li>
<li>Vulnerabilities exploits and software weaknesses,</li>
</ul>
<p>The standards ends with requirements on testing strategies, code reviews, static and dynamic analysis, addressing the above topics.<br />
Some requirements are very specific, like:</p>
<ul>
<li>Minimum length of passwords shall be at least 6 characters,</li>
<li>The number of test cases in malformed input testing shall be 1 million cases or 8 hours.</li>
</ul>
<p>The testing strategies that have to be implemented cover all levels of software architecture: source code, unitary level, and GUI/architectural level.<br />
It demonstrates that being compliant to UL 2900-1 has a strong impact both on design phases and design verification phases (If by any chance you had a doubt :-).</p>
<h4>Conclusion</h4>
<p>UL 2900-1 is a set of prescriptive requirements applicable to the design, design verification and post-market phases of a medical device. It requires the implementation of a security risk management process, to ensure the compliance to its requirements.<br />
No security risk management process is documented in UL 2900-1. You have to go to AAMI TRI 57 and, more general, to ISO 27005, to find state-of-the-art security risk management processes.</p>https://blog.cm-dm.com/post/2019/08/16/Cybersecurity-in-medical-devices%3A-a-short-review-of-UL-2900-1#comment-formhttps://blog.cm-dm.com/feed/atom/comments/225100% probability of software failure in IEC 62304 Amd1 2015urn:md5:beef52e9287606fd177abebcc2056adc2017-09-20T17:48:00+02:002017-12-15T14:13:29+01:00MitchStandards <p>A reader of the post on <a href="https://blog.cm-dm.com/post/2015/07/10/IEC-62304-Amendment-1-published">IEC 62304 Amd1 2015</a> noticed in the comments that the sentence in section 4.3.a was removed:</p>
<blockquote><p>If the HAZARD could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent.</p></blockquote>
<p>Don't be too quick to scratch the 100 percent thing!<br />
<br />
The dreadful 100 percent is still present in the informative Annex B.4.3.<br />
<br />
Even if it is no more in the normative part, you shall continue to bear in mind this assumption when assessing software risks. The underlying concept is that it's not possible to assess probability of software failure, thus the worst case shall be considered.<br />
This is the state-of-the-art, present in ISO 14971, in IEC 80002-1, in IEC 62304, and in the FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices.<br />
<br />
100% probability is not dead!</p>https://blog.cm-dm.com/post/2017/09/20/100-probability-of-software-failure-in-IEC-62304-Amd1-2015#comment-formhttps://blog.cm-dm.com/feed/atom/comments/209Wait, but what of harmonized standards?urn:md5:483593948e5fcd83977af1176969dd172017-09-20T14:18:00+02:002017-09-20T19:06:25+02:00MitchStandards<p>While the FDA continues to update periodically and reliably the list of recognized standards (last update <a href="https://www.federalregister.gov/documents/2017/08/21/2017-17603/food-and-drug-administration-modernization-act-of-1997-modifications-to-the-list-of-recognized">in August 2017</a>), the European Commission hasn't updated the <a href="http://ec.europa.eu/growth/single-market/european-standards/harmonised-standards/medical-devices/">list of harmonized standards since may 2016</a>.</p> <h4>FDA recognized standards</h4>
<p>The update of FDA recognized standards in August 2017 brought to the looong list of standards:</p>
<ul>
<li>ANSI UL 2900-1 on cybersecurity (will be analyzed in a further post),</li>
<li><a href="https://blog.cm-dm.com/post/2016/11/01/IEC-82304-1%3A2016-Health-software-Part-1%3A-General-requirements-for-product-safety">IEC 82304-1</a> on health software,</li>
</ul>
<p>to say the least, just focusing on software as a medical device.<br />
We can also check and verify on the <a href="https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/TextSearch.cfm">FDA database of recognized standards</a> that IEC 62304 amendment 1 2015 was recognized in April 2016, and IEC 62366-1 2015 was recognized in June 2016.<br /></p>
<h4>EU harmonized standards</h4>
<p>On the other side of the Atlantic Ocean, things are less ... clear.<br />
While standards published by the ISO, IEC or other international organizations continue to evolve, the list of harmonized standards still references "old" standards:</p>
<ul>
<li>For software: IEC 62304:2006, no 62304 2015 or 82304 in sight,</li>
<li>For usability: IEC 62366:2008, no 2015 in sight,</li>
<li>For general standards ISO 13485:2012 (doh!),</li>
<li>Fortunately ISO 14971 hasn't evolved yet (phew!),</li>
<li>For embedded software, old versions of IEC 60601-1-x, and IEC 60601-2-x collateral still referencing IEC 60601-1 2nd version,</li>
</ul>
<p>to say the least.<br />
I heard that more than a hundred of standards wait for being harmonized (this sounds likely, but I don't have the source and hope I'm not spreading fake news). <br />
The current list is getting older and older. The toughest element is that all manufacturers are switching or have already switched to ISO 13485:2016.<br />
<br />
<strong>Hey, European Commission, this list passed its expiry date! What do we do now?</strong></p>
<h4>Recommendations of Notified Bodies</h4>
<p>Fortunately (or strangely, or ironically, or ... choose your positive or negative adverb), Notified Bodies have the solution:<br />
<br />
<em>Disregard the current list of harmonized standards and consider the last versions of standards as state-of-the-art.</em><br />
<br />
This recommendation was given by two different notified bodies to manufacturers I work with.<br />
<br />
So, still focusing on standalone software, you can apply the following standards:</p>
<ul>
<li>IEC 62304 Amd1:2015,</li>
<li>IEC 62366-1:2015,</li>
<li>and even IEC 82304-1:2016.</li>
</ul>
<p>For embedded software, I can't imagine the confusion caused by the application of the latest versions not present in the list of harmonized standards. It's a very good idea to consult your notified body before applying the latest versions of the IEC 60601-x-y family.</p>
<h4>Now, what?</h4>
<p>Now, IEC 62304:2006 is getting old,<br />
Now, ISO 13485:2003 is withdrawn,<br />
Now, the new regulations 2017/745 and 2017/746 are there,<br />
Now, the European Commission should do their homework.</p>https://blog.cm-dm.com/post/2017/09/20/Wait%2C-but-what-of-harmonized-standards#comment-formhttps://blog.cm-dm.com/feed/atom/comments/208Cybersecurity in medical devices - Part 3 AAMI TIR57:2016urn:md5:5adc4afffd7a08b5f11355939d648e6d2017-05-16T21:53:00+02:002017-05-16T22:46:46+02:00MitchStandardsCybersecurityGuidance<p>After a long pause, we continue this series about cybersecurity in medical devices with a discussion on AAMI TIR57:2016 Principles for medical device security — Risk management.</p> <p>This TIR is the one and only document available in the corpus on medical device-related standards and guidances, dealing with the application of cybersecurity principles and their impact on ISO 14971 risk management process. Yet, FDA guidances exist, but they’re not as direct as this TIR to show the impact of cybersecurity management process on risk management process.</p>
<h4>Structure of AAMI TIR57:2016</h4>
<p>The structure of sections 3 to 9 of this document is copied from ISO 14971 standard. It shows how the security risk management process can be modeled in a manner similar to the safety risk management process.<br />
If you’re at ease with ISO 14971, you’ll be at ease with AAMI TIR57. Your effort of understanding will be focused on security risk management concepts, not the process (risk identification, evaluation, mitigation and so on…) that you already know.<br />
We can bless the working group in charge of this TIR for this effort of presentation. The diagram below, extracted from the TIR, shows the analogy between both processes.</p>
<p><img src="https://blog.cm-dm.com/public/Cybersecurity/security-risk-safety-risk.png" alt="Relationships between the security risk and safety risk management processes" style="display:table; margin:0 auto;" title="Relationships between the security risk and safety risk management processes, May 2017" />
<br />
You've probably already seen this diagram elsewhere. And I bet that many articles or newsletters dealing cybersecurity in medical devices are going to reproduce it as well!</p>
<h4>Separation of processes</h4>
<p>The TIR recommends to separate the security and safety risk management processes. This looks as a good recommendation, as people involved in both processes are not all the same. Data security and clinical safety concepts are not managed by the same persons with the same qualifications.</p>
<h5>Cons</h5>
<p>This separation is going to remain very theoretical for most of small businesses. Practically, big companies can afford maintaining two processes and the needed qualified persons, but small businesses don’t.<br />
Small businesses will require the help of security experts to manage security risks. But they will be most probably hired as consultants. People who currently manage ISO 14971 process will manage both processes, without clear separation on a day to day basis.</p>
<h5>Pros</h5>
<p>The separation of processes is a good way to monitor efficiently security risk management. Keeping a security risk management file separated form the safety risk management file allows to document the outputs of the process without mixing concepts of security risk management (threats, vulnerabilities, assets, adverse impacts), with concepts of safety risk management (hazardous phenomenon, hazardous situation, hazard, harm).</p>
<h4>Annexes of AMMI TIR:57:2016</h4>
<p>The annexes found after section 9 are another wealth of information. They contain practical methods to implement a security risk management process. There is even a list of questions that can be used to identify medical device security characteristics, like the annex C of ISO 14971 for safety risks!<br />
The TIR ends with an example based on a fictional medical device: the kidneato system, with everything that a manufacturer shouldn’t do: an implanted part, a part connected to the public network, and a server storing medical data. Delicatessen for hackers!</p>
<h4>Multiplication of risk management files</h4>
<p>With the ongoing implementation of ISO 13485:2016 by medical device manufacturers, another consequence of security risk management is the multiplication of risk management files:</p>
<ul>
<li>QMS Process risk management,</li>
<li>Safety risk management,</li>
<li>Security risk management, and</li>
<li>Risk / opportunities management, for the fans of ISO 9001:2015.</li>
</ul>
<p>We can even try to draw a table of interactions between these processes (I skip ISO 9001:2015, but don’t conclude I’m not a fan :-))</p>
<table style="text-align:center">
<tr style="background-color: #25ABA3">
<td> </td><td>Affects</td><td rowspan="2">Safety</td><td rowspan="2">QMS Process</td><td rowspan="2">Security</td>
</tr>
<tr>
<td>Risks</td><td> </td>
</tr>
<tr>
<td colspan="2">Safety</td><td style="background-color: #dddddd">X</td><td>Safety risk mitigations implemented in QMS processes</td><td>Safety risks with potential impact on security. Safety controls affecting security</td>
</tr>
<tr>
<td colspan="2">QMS Process</td><td>Hazardous situations in QMS processes with impact on safety. QMS process controls affecting safety</td><td style="background-color: #dddddd">X</td><td>QMS process risk controls affecting security. Threats, vulnerabilities, assets found in processes to assess in security risk management</td>
</tr>
<tr>
<td colspan="2">Security</td><td>Security risks with impact on safety, Security controls affecting safety</td><td>Security risks with impacts on QMS processes (and possibly safety). Security controls affecting QMS processes</td><td style="background-color: #dddddd">X</td>
</tr>
</table>
<h4>Conclusion</h4>
<p>AAMI TIR75:2016 is an excellent source of information for newbies in security risk management. A must-read for people not qualified in security risk management, who need to manage the process, and anticipate its impact on other processes.<br />
<br />
In the next article, we’ll see the consequence of cybersecurity management on software development and maintenance processes.</p>https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016#comment-formhttps://blog.cm-dm.com/feed/atom/comments/204IEC 82304-1:2016 Health software - Part 1: General requirements for product safetyurn:md5:775572ec8d6c798967003a0842949e3b2016-11-01T21:09:00+01:002016-11-01T21:11:19+01:00MitchStandardsIEC 82304 <p>IEC 82304-1:2016, the missing link on standalone medical device software validation has been published!<br />
See the official version on <a href="https://webstore.iec.ch/publication/26120">IEC webstore</a>, and <a href="https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software">comments made on the FDIS</a> (the final version shouldn't have changed).<br />
<br />
Now we wait for the FDA to recognize it and the EU to harmonize it!</p>https://blog.cm-dm.com/post/2016/11/01/IEC-82304-1%3A2016-Health-software-Part-1%3A-General-requirements-for-product-safety#comment-formhttps://blog.cm-dm.com/feed/atom/comments/199ISO/TR 80002-2: latest news on Validation of software for medical device quality systemsurn:md5:208c16cc9ea8db32a91dd6b3387318472016-06-10T13:56:00+02:002016-07-10T12:13:56+02:00MitchStandards<p><a href="http://www.iso.org/iso/catalogue_detail.htm?csnumber=60044">ISO/TR 80002-2 is the future technical report</a> on the validation of software used in regulated processed. The last version of this document, a Draft Technical Report (ISO/DTR 80002-2:2016), was released to the members of the standard committee for comments in May 2016.<br />
This document is still a draft and is to be released by the end of 2016 or early 2017. There are high expectations on this document, since the introduction of requirements on validation of software used in the QMS in section 4.1.6 of ISO 13485:2016.</p> <h4>ISO/DTR 80002-2 and AAMI TIR 36</h4>
<p>ISO/DTR 80002-2 maximizes the reuse of the only existing document on this subject published by a normalization organization: the AAMI TIR 36 Validation of software for regulated processes.<br />
Thus, most of AAMI TIR 36 document is copied-pasted to ISO/DTR 80002-2:<br />
The main chapters:</p>
<ul>
<li>3- Software validation discussion,</li>
<li>4- Software validation and critical thinking,</li>
<li>5- Documentation,</li>
<li>6- Prerequisite processes</li>
</ul>
<p>And the annexes:</p>
<ul>
<li>A - the toolbox,</li>
<li>B - Risk Management,</li>
<li>C - Examples</li>
</ul>
<h4>From 21 CFR and FDA, to international scope</h4>
<p>The main difference between both documents is the "internationalization" of ISO/DTR 80002-2:</p>
<ul>
<li>The introduction found in AMMI TIR 36 on the regulatory context focused on 21 CFR was quite logically removed from this DTR,</li>
<li>References made to the FDA and 21 CFR throughout the AAMI TIR 36 were replaced by an equivalent wording with an international point of view, when possible.</li>
</ul>
<p>Other differences are minor changes to the body text:</p>
<ul>
<li>to make it more up-to-date, eg. replace the term automated by controlled by software,</li>
<li>to rephrase, reorganize or remove some portions of texts and graphics to make it more articulate (at last, we hope so!).</li>
</ul>
<p>In the annexes, the most visible changes are:</p>
<ul>
<li>the removal of the "value" column in the Annex A - toolbox,</li>
<li>the rewording of Annex B on risk management.</li>
</ul>
<p>The new wording in annex B of ISO/DTR 80002-2 is probably the most significant change. AAMI TIR 36 didn't rely on ISO 14971 the way an international standard should do. Thus, ISO/DTR 80002-2 is totally rewritten to be consistent with ISO 14971 risk management process.</p>
<h4>What's inside?</h4>
<p>For those who never read AAMI TIR 36, ISO/TR 80002-1 defines a risk-based approach on validation of software used in QMS. Thus it matches the new requirement of ISO 13485:2016.<br />
<br />
The validation is split in 3 phases:</p>
<ul>
<li>Develop, with
<ul>
<li>Define,</li>
<li>Implement,</li>
<li>Test,</li>
<li>Deploy,</li>
</ul></li>
<li>Maintain, and</li>
<li>Retire.</li>
</ul>
<h5>Define</h5>
<p>This phase contains the definition of the scope, the intended use, use requirements of the QMS software tool. It also contains a risk analysis at process level, i.e. in processes where the QMS software tool is used. And It defines the validation plan.</p>
<h5>Implement</h5>
<p>This phase is the software design, coding and low-level testing for in-house developed software or bespoke software (even if the manufacturer outsources the software development). It also contains the risk assessment at software level: software failures, mitigations actions and traceability between risks, software requirements, and software tests.<br />
<br />
For off-the-shelf software, the design and coding are replaced by vendor audit. The risk assessment shall identify software failures and their consequences. The mitigation actions, however, can be implemented in software only if it is feasible.</p>
<h5>Test</h5>
<p>This phase is software verification: integration, GUI, non-regression, stress-test, ... whatever test methods relevant to your software. Here, software is supposed to be verified on a test bench or test platform, not the target platform.</p>
<h5>Deploy</h5>
<p>This phase is the installation of the software tool on the target platform and it commissioning.<br />
This is were you find the traditional IQ/OQ/PQ, and related activities like operators training.<br />
<strong>Note that formal IQ/OQ/PQ are not required by this technical report.</strong> It reads explicitly: <em>Select and conduct activity where appropriate</em>.</p>
<h5>Maintain</h5>
<p>This phase is the maintenance of the QMS software tool, with maintenance plan, bugs analysis, system monitoring, backup and recovery processes.</p>
<h5>Retire</h5>
<p>This phase is the decommissioning of the QMS software tool.</p>
<h4>Conclusion - Not a revolution</h4>
<p>Based on this draft standard, we can see that ISO/TR 80002-2 won't be a revolution. It is the logical next step after the introduction to ISO 13485:2016 of requirements on QMS software validation, similar to those in 21 CFR 820.<br />
Manufacturers, which already validate and maintain QMS software by applying the principles of AMMI/TIR 36, will simply have to continue their validation efforts.<br />
Manufacturers in transition to ISO 13485:2016 will probably have to apply this new technical report.</p>
<h4>Additional reading</h4>
<p>If you don't want to start from a white page, see the QMS software validation templates in the <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">Template Repository for software</a>: Software Validation Plan, Software Validation Protocol and Software Validation Report.
<br />
<br />
See also previous discussions on <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">validation of software used in production and QMS</a> and on <a href="https://blog.cm-dm.com/post/2014/03/13/Validation-of-compiler-and-IDE-Why%2C-when-and-how-to-Part-1">validation of IDE or software tools used for software design</a>.
<br />
<br />
For those who wonder how to validate workflow and data management software like Jira or Redmine, you won't find any example in AAMI TIR 36 or ISO/TR 80002-2. This is the subject of the <a href="https://blog.cm-dm.com/post/2016/07/01/How-to-validate-software-development-tools-like-Jira-or-Redmine">next article</a> on this blog.</p>https://blog.cm-dm.com/post/2016/06/10/ISO/TR-80002-2%3A-lastest-news-on-Validation-of-software-for-medical-device-quality-systems#comment-formhttps://blog.cm-dm.com/feed/atom/comments/188Is my software in class A, B or C? - 2015 reloadedurn:md5:ea9c578aaf76b8b6fb4dc15c8a0c7cf82016-05-06T13:33:00+02:002016-06-08T16:34:28+02:00MitchStandards<p>Almost four years since I wrote in 2012 the post <a href="https://blog.cm-dm.com/post/2012/04/14/Is-my-software-in-class-A%2C-B-or-C">Is my software in class A, B or C?</a>.<br />
In 2015, IEC 62304 Amendment 1 was published, changing a bit the game about software safety class.</p> <p><a href="https://blog.cm-dm.com/post/2012/04/14/Is-my-software-in-class-A%2C-B-or-C">Is my software in class A, B or C?</a> is the second most viewed page on this website, after the <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates repository for software development process</a>.<br />
<br />
Thus it deserves an update to explain how the software safety class is assessed with IEC 62304 amendment 1.<br /></p>
<h4>IEC 62304:2006</h4>
<p>IEC 62304:2006 defines in section 4.3 the software safety classes, based only on the consequence of a hazardous situation on the patient:</p>
<ul>
<li>Class A: No injury or damage to health is possible</li>
<li>Class B: Non-SERIOUS INJURY is possible</li>
<li>Class C: Death or SERIOUS INJURY is possible</li>
</ul>
<p>Another way of viewing this definition is to disregard the probability of risks linked to a software failure, and to focus only on the severity.<br />
<br />
Here is an example of risk matrix:
<img src="https://blog.cm-dm.com/public/23-IEC-62304-Amd1/.risks-matrix_m.png" alt="risks-matrix.png" style="display:table; margin:0 auto;" title="risks-matrix.png, Mar 2016" />
<br />
<em>Remark: don't take account of discussions about ISO 14971:2009 vs ISO 14971:2012 and risk acceptability criteria. The words unacceptable, tolerable and acceptable are here just examples to support the current discussion.</em><br />
<br />
The software safety classes can be seen as areas on the risk matrix:<br />
<img src="https://blog.cm-dm.com/public/23-IEC-62304-Amd1/.risks-matrix-and-safety-classes-IEC-62304-2006_m.png" alt="risks-matrix-and-safety-classes-IEC-62304-2006.png" style="display:table; margin:0 auto;" title="risks-matrix-and-safety-classes-IEC-62304-2006.png, Mar 2016" />
<br />
<br />
But this point of view has been challenged by manufacturers, when software-related hazards don't represent an unacceptable risk, prior to software mitigation action (i.e. prior to a mitigation action only implemented in software).<br />
<br />
For example, a life sustaining medical device contains embedded software. The life sustaining functions are managed by plain old electronics. The embedded software is here to record and display informative data. But for some reason (this is just an example), a software failure could result in a hazardous situation for the patient that could lead to a serious injury. The probability of such situation is improbable (less that once is the device lifetime) and no mitigation outside this software system was identified.<br />
<br />
With IEC 62304:2006 this embedded software is in class C, hence we have at least one risk of critical severity prior to software mitigation action where software failure is the hazardous phenomenon.<br />
<br />
Although this risk has a high severity, the risk evaluation matrix of manufacturers usually deems a risk acceptable or tolerable for the cell (critical, improbable). Thus setting the software in the highest class doesn't match the acceptability of the risk prior to software mitigation action.<br />
<br />
That's one reason for the amendment of IEC 62034:2006. Let's see what has changed in the amendment, in section 4.3 where software safety classes are defined.</p>
<h4>IEC 62304 Amd1 2015</h4>
<h5>Definitions</h5>
<p>The definitions of software safety classes were totally reworded:</p>
<ul>
<li>The SOFTWARE SYSTEM is software safety class A if:
<ul>
<li>the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or</li>
<li><strong>the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM</strong>.</li>
</ul></li>
</ul>
<p><br /></p>
<ul>
<li>The SOFTWARE SYSTEM is software safety class B if:
<ul>
<li>the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.</li>
</ul></li>
</ul>
<p><br /></p>
<ul>
<li>The SOFTWARE SYSTEM is software safety class C if:
<ul>
<li>the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.</li>
</ul></li>
</ul>
<p><br /></p>
<h5>Flowchart</h5>
<p>These definitions are accompanied by a flowchart, which explains at a glance the selection of safety class.<br />
<br />
Here is a snapshot of the flowchart found in section 4.3 of IEC 62304 Amd1 2015:<br />
<img src="https://blog.cm-dm.com/public/23-IEC-62304-Amd1/.Software-Safety-Class-IEC-62304-Flowchart_m.png" alt="Software-Safety-Class-IEC-62304-Flowchart.png" style="display:table; margin:0 auto;" title="Software-Safety-Class-IEC-62304-Flowchart.png, Mar 2016" />
<br />
The questions can be mapped to the above definitions:</p>
<ul>
<li>Answering 'No' to Question 1 = First bullet of definition of class A,</li>
<li>Answering 'No' to Question 2 = Second bullet of definition of class A,</li>
<li>Answering 'Yes' to Question 1 and 2 = first part of the definition of class B and class C (the common part, before the words "and the resulting..."),</li>
<li>Answering 'Non serious injury' to Question 3 = definition of class B,</li>
<li>Answering 'Serious injury' to Question 3 = definition of class C.</li>
</ul>
<h5>Consequence</h5>
<p>The consequence of these definitions is the introduction of the acceptability of risks in the assessment of software safety class:</p>
<ul>
<li>IEC 62304:2006: severity only</li>
<li>IEC 62304:Amd1:2015: severity and risk acceptability.</li>
</ul>
<p><br />
Using the same legend as in the previous matrix, the software safety classes areas can be represented like this:<br />
<img src="https://blog.cm-dm.com/public/23-IEC-62304-Amd1/.risks-matrix-and-safety-classes-IEC-62304-2015_m.png" alt="risks-matrix-and-safety-classes-IEC-62304-2015.png" style="display:table; margin:0 auto;" title="risks-matrix-and-safety-classes-IEC-62304-2015.png, Mar 2016" />
<br />
The class A region can be extended to the upper side of the matrix. This is possible thanks to the sentence in bold in the definition of class A written above. In our example, the cell (critical, improbable) sees its corresponding software safety class set to class A, hence the risk is acceptable.</p>
<h4>FDA level of concern</h4>
<p>The concept of level of concern defined by the FDA somewhat overrides the concept of safety class found in IEC 62304. <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm">The guidance which defines it</a>, is still applicable and hasn't changed since 2005.<br />
Worse, the guidance was reviewed by the FDA in 2015, upon the retrospective review process. There is no information on the FDA website stating that it should be modified after the changes of IEC 62304 Amd1.<br />
The definition of level of concern remains as is since 2005, and is to some extent stricter than the IEC 62034 Amd1 2015 software safety classes.<br />
<br />
You could come up with a software system in class A for IEC 62304 Amd1 2015, and in major or moderate level of concern for FDA. Thus don't be too much excited by the amended version of IEC 62304. Your software system could require all the documentation overhead for major or moderate level of concern, while it is deemed in class A for IEC 62304. Or you may have to argue for the low level of concern with FDA reviewers.</p>
<h4>Conclusion</h4>
<p>IEC 62304 Amd1:2015 brings a major change to the definition of software safety classes. It will prevent manufacturers from classifying software in a high class, in contradiction with the results of the risk management process.<br />
<br />
However, it also adds a gap to the concept of level of concern defined by the FDA. Aligning the level of concern of a software system, with the software safety class of IEC 62304 Amd1 2015, may not be accepted by the FDA. In this case the software documentation overhead cannot be avoided.</p>https://blog.cm-dm.com/post/2016/05/06/Is-my-software-in-class-A%2C-B-or-C-2015-reloaded#comment-formhttps://blog.cm-dm.com/feed/atom/comments/185IEC 82304-1 - Consequences on agile software development processesurn:md5:8c306de984f1465a149933082434e96a2016-04-08T14:25:00+02:002016-04-09T10:38:26+02:00MitchStandardsAgiledevelopment processIEC 62304IEC 82304Software Validation<p>Continuing our <a href="https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software">series about IEC 82304-1</a>, let's see the consequences of this standard on agile software development processes.</p> <h4>IEC 82304-1 in software development cycle</h4>
<p>The most simple presentation of the position of IEC 82304-1 in the software development lifecycle is to use the traditional waterfall process:
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.scope_of_IEC_82304-1_in_lifecycle_m.png" alt="scope_of_IEC_82304-1_in_lifecycle.png" style="display:table; margin:0 auto;" title="scope_of_IEC_82304-1_in_lifecycle.png, Dec 2015" />
But it is also applicable with agile methods, like suggested in the following graph:
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.IEC_82304-1_with_agile_methods_m.png" alt="IEC_82304-1_with_agile_methods.png" style="display:table; margin:0 auto;" title="IEC_82304-1_with_agile_methods.png, Jan 2016" />
In the example, we still have a separation between the system level, where use requirements and system requirements don't change when a version is being developed, and the software level, where agile cycles (sprints or something else) are performed.<br /></p>
<h4>Continuous user input</h4>
<p>But we can go further in the representation, by considering that user feedback (the input at the top-left corner of the previous graph), continuously changes. In this case, use requirements and system requirements are treated at sprint level. But not all sprints will contain new and/or modified use requirements and/or system requirements. And a validated version won't be released at the end of each sprint.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.IEC_82304-1_with_agile_methods_and_continuous_user_input_m.png" alt="IEC_82304-1_with_agile_methods_and_continuous_user_input.png" style="display:table; margin:0 auto;" title="IEC_82304-1_with_agile_methods_and_continuous_user_input.png, Jan 2016" />
The minor difference on the graphic compared to the previous one: continuous user input, makes a major difference for the agile development process. Thus the user input is not frozen at system level and evolves continuously.<br />
Practically speaking, the system level requirements are not given in a document, like a statement of work. They are continuously given by the users, when they are provided with demo or stable releases, and are added to the backlog.</p>
<h4>Agile at system and software level</h4>
<p>It's difficult for a medical device manufacturer to be agile both at system and software level. Having user requirements changing continuously can be troublesome.<br />
Usually, user feedback doesn't change the intended use of health software. But sometimes end-users have tons of ideas... especially when they are doctors! Being fully agile means that it could be possible that the device description or even the intended use could change! This is a situation that manufacturers don't want to encounter.<br />
That's why agile methods assign the role of product owner to someone, who acts as a filter between users' vows and what goes into the backlog.<br /></p>
<h5>Static immutable requirements</h5>
<p>Coming back to IEC 82304-1, it means that some of the user and system requirements won't change, that they set the basis of the software development project. These user and system requirements are a <strong>subset</strong> of what is found in sections 4.2 and 4.5 of IEC 82304-1. We can quote some of these types of requirements, for which we are 99% sure they won't change during the project:</p>
<ul>
<li>Intended use,</li>
<li>Addressed users or patients,</li>
<li>Main use case,</li>
<li>General system security,</li>
<li>Regulatory requirements (hum, not so sure :-).</li>
</ul>
<p>Using software development vocabulary, we can speak of static immutable requirements. All other requirements are dynamic and mutable.<br />
They can be added, deleted and changed from one sprint to another. They can be at system level i.e. other requirements found in IEC 82304-1 or at software level i.e. requirements found in section 5.2 of IEC 62304.</p>
<h5>Releasing health software</h5>
<p>Since many things can change from one sprint to another, it's not possible to have a stable release after each sprint. You won't put software in the hands of anyone after each sprint. Depending on its status you can determine to whom it will be released:</p>
<ul>
<li>Is it demo-able?
<ul>
<li>No (pliz, agile aficionados, don't frown, c'est la vie!), next sprint,</li>
<li>Yes, do a demo to the product owner,</li>
</ul></li>
<li>Is it stable?
<ul>
<li>No, next sprint,</li>
<li>Yes, consider putting it in the hands of experienced users,</li>
</ul></li>
<li>Is it ready for validation?
<ul>
<li>No, next sprint,</li>
<li>Yes, do a validation.</li>
</ul></li>
</ul>
<p><em>Ready for validation</em> means that its functional scope <em>probably</em> matches the intended use.</p>
<h5>Validating health software</h5>
<p><em>Probably matches the intended use</em> is not allowed for software on the market. A validation step is required to ensure that software does match the intended use.<br />
A formal step of validation remains mandatory for software qualified as medical device. IEC 82304-1 helps manufacturers define what should be validated in section 6 of the standard. As already mentioned, this is a major breakthrough of this standard.<br />
In the context of agile methods, the standard leaves the validation method to the choice of the manufacturer. IEC 82304-1 requires at section 6.2 to write a validation plan, which contains the validation methods. Hopefully, it doesn't impose a methods. Thus, the validation method can be:</p>
<ul>
<li>Either a formal step of validation, performed after a release candidate is delivered by the software team,</li>
<li>Or a continuous validation included in the sprints.</li>
</ul>
<p>A quick search in the scientific literature about software development, or in developers forums, shows that nobody performs a continuous validation of medical device software. It is possible, but it hasn't been implemented (or disclosed) yet.</p>
<h4>Conclusion</h4>
<p>To conclude this series of articles about IEC 82304-1, the key points are:</p>
<ul>
<li>Its scope is standalone health software,</li>
<li>It calls IEC 62304 for software development, and thus requires ISO 14971,</li>
<li>It defines types of requirements to document at user and system level,</li>
<li>It defines requirements on health software validation,</li>
<li>It will be probably recognized by the FDA and harmonized by the EU when it is published,</li>
<li>It is portable to the framework of agile methods.</li>
</ul>https://blog.cm-dm.com/post/2016/04/08/IEC-82304-1-Consequences-on-agile-software-development-processes#comment-formhttps://blog.cm-dm.com/feed/atom/comments/183IEC 82304-1 - Overview of requirementsurn:md5:f2a00c175ef60844410e2d8403584ee02016-03-11T14:53:00+01:002016-04-09T12:50:39+02:00MitchStandardsIEC 62304IEC 62366IEC 82304ISO 14971Software Validation<p>We had in <a href="https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software">a previous article</a> an overview of IEC 82304-1 <em>Health software -- Part 1: General requirements for product safety</em>, its scope and its relationships with other standards like IEC 62304.<br />
This article presents more in details (but not too much, we're not going to rephrase the standard) the requirements of IEC 82304-1.</p> <p>Let's see again the graphic representing the relationships of IEC 82304-1 with other standards.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.relationship_of_IEC_82304-1_with_other_standards_m.png" alt="relationship_of_IEC_82304-1_with_other_standards.png" style="display:table; margin:0 auto;" title="relationship_of_IEC_82304-1_with_other_standards.png, Dec 2015" />
It requires IEC 62304 but not ISO 14971.<br />
How is it possible and what are the consequences?</p>
<h4>References to IEC 62304</h4>
<p>IEC 82304-1 references several times IEC 62304 in the requirements or in the notes.<br />
The main reference is in the section 5 of IEC 82304-1 titled <em>HEALTH SOFTWARE - software lifecycle process</em>:</p>
<ul>
<li>It references sections 4.2, 4.3, 5, 6, 7, 8 and 9 of IEC 62304,</li>
<li>It doesn't reference the section 4.1 (the section about QMS) of IEC 62304,</li>
<li>It doesn't reference the section 1 either (and particularly section 1.4 about the compliance with IEC 62304).</li>
</ul>
<p>Anyway, given the small subset of requirements not applicable, all the more those with little consequences on software development and maintenance, take it for granted that you have to apply IEC 62304.<br />
<br />
<strong>Manufacturers of health software, welcome to the marvelous world of IEC 62304 and its costly requirements!</strong></p>
<h4>References to ISO 14971</h4>
<p>IEC 82304-1 doesn't reference ISO 14971 as a mandatory standard in its requirements. It only requires to:</p>
<ul>
<li>perform a risk assessment at system level in section 4.1 <em>Initial RISK ASSESSMENT of HEALTH SOFTWARE PRODUCT</em>, and</li>
<li>define risk mitigation actions in the section 4.5 <em>system requirements</em>.<br /></li>
</ul>
<p>But the note at the bottom of section 4.1 suggests to apply the first steps of ISO 14971 to do this initial risk assessment. These first steps are those found in section 4 of ISO 14971.<br />
<br />
Guess what?<br />
Are you going to apply a risk management process different from the one described in ISO 14971?<br />
No, this would add complexity to risk management, which is complex enough like that!<br />
<br />
<strong>So, You are going to apply the first steps of ISO 14971 to do this initial risk assessment!</strong></p>
<h5>Logical approach</h5>
<p>But this approach remains logical.<br />
IEC 82304-1 requires a preliminary risk assessment at system level, when requirements are perhaps not yet defined (section 4.1 is the very first section of the standard with requirements about health software). Reading between the lines, it says:</p>
<ul>
<li>do an initial (or preliminary call it as you want) risk assessment to know where you're going: critical software or risk-free software,</li>
<li>then write your system requirements with regards to this initial risk assessment.</li>
</ul>
<h5>Consequences at system level</h5>
<p>Mimiking the management of software risks of IEC 62304, IEC 82304-1 requires to define mitigations actions in the form of system requirements (software requirements for IEC 62304).<br />
IEC 82304-1 also requires to validate the health software product. Thus the validation plan shall contain tests, which bring evidence that the mitigation actions are in place and effective (like software system tests for IEC 62304).<br /></p>
<h5>Types of risks</h5>
<p>Risks found and mitigated at system level will include a larger set of hazardous situations, that are not addressed <strong>explicitly</strong> by IEC 62304, focused on software:</p>
<ul>
<li>Instructions for use,</li>
<li>Labelling,</li>
<li>IT systems (detailed in section 7.2.3.2 of IEC 82304-1).</li>
</ul>
<p>It doesn't come immediately to the mind of the reader of IEC 62304 to think about these types of risks. Software risk management is usually focused on software failure, not the aforementioned types of risks.<br />
<br />
For those who know IEC 60601-1, we see here once again that IEC 82304-1 takes the same role as IEC 60601-1, but for standalone software.</p>
<h5>ISO 14971 is mandatory</h5>
<p>Strictly speaking, the mandatory nature of ISO 14971 is only given by the requirements in the section 4.2 of IEC 62304.<br />
Section 4.2 of IEC 62304 is called by section 5 of IEC 82304-1. Thus ISO 14971 is mandatory for the software lifecycle processes. No surprise here, ISO 14971 is really the gold standard for patient risk management.<br />
It looks more consistent to apply the risk management process of ISO 14971, throughout the full lifecycle of health software. But IEC 82304-1 leaves the door open for other risk management process at system level.</p>
<h5>Exemption for 3rd party software</h5>
<p>IEC 82304-1 leaves the door open also at software level. The section 5 of IEC 82304-1 authorizes the health software manufacturer to apply partially the ISO 14971 risk management process when health software contains third party software.<br />
This looks pretty much like the SOUP concept of IEC 62304, since IEC 82304-1 requires to analyze residual risks for this third party software and implement mitigation actions if risks are unacceptable.</p>
<h4>References to IEC 62366-1</h4>
<p>IEC 82304-1 requires in section 4.2 to define the <em>HEALTH SOFTWARE PRODUCT use requirements</em>. But it doesn't require to apply IEC 62366-1 (nor the previous version IEC 62366:2008). IEC 62366-1 is only quoted in a note at the bottom of the section, as a potential source of information.<br />
But, for health software qualified as medical device, IEC 62366-1 is already recognized by the regulation authorities (only by the FDA, at the time of writing). Thus even if IEC 62366-1 is not referenced, manufacturers of standalone software medical device will apply IEC 62366-1.<br />
<br />
Anyway, for health software NOT qualified as medical device IEC 62366-1 is absolutely not required.</p>
<h4>System-level requirements</h4>
<p>The references of IEC 82304-1 to other standards makes a framework, which allows to reuse the state-of-the-art in the software development, maintenance and risk management processes. But the novelty of the standard resides in the specific sections dealing with the system level.<br />
The clauses of IEC 82304-1 aim to define a framework for the design of the standalone software system:</p>
<ul>
<li>Use requirements: the top-most requirements,</li>
<li>System requirements: technical requirements consistent with use requirements,</li>
<li>Validation: how to validate the use requirements.</li>
</ul>
<p>They also aim to define a framework for user documentation and labeling, with clauses about:</p>
<ul>
<li>Identification,</li>
<li>Accompanying documents,</li>
<li>Content of accompanying documents, especially for the system administrator.</li>
</ul>
<p>And they finally aim to define a framework for post-market activities:</p>
<ul>
<li>Software maintenance,</li>
<li>Revalidation,</li>
<li>Communication with interested parties,</li>
<li>Decommissioning and disposal.</li>
</ul>
<h4>Health Software Validation</h4>
<p>The best improvement of IEC 82304-1 is its intent to fill the big gap between the software verification of IEC 62304 and the software validation requirements of regulations, when health software is regulated as a medical device.<br />
Validation is performed versus a set of top-level requirements. That's why IEC 82340-1 contains clauses about use requirements, system requirements, and accompanying documents.<br />
<br />
Validation is not a step, this is a journey. Health software product shall be maintained validated during its whole life on the field. That's why IEC 82304-1 contains clauses about post-market activities.<br /></p>
<h4>Conclusion</h4>
<p>IEC 82304-1 fills the gap between IEC 62304 and software medical device validation required by regulations. To do so, it contains a minimum set of clauses defining what is needed at system level, and it references existing state-of-the-art standards (ISO 14971 and IEC 62304) for the software level.<br />
This approach makes IEC 82304-1 relatively short, compared to IEC 62304, ISO 14971, and IEC 62366-1. But its content is essential, to ensure health software products are correctly maintained in a validated state.<br />
<br />
<br />
<a href="https://blog.cm-dm.com/post/2016/04/08/IEC-82304-1-Consequences-on-agile-software-development-processes">Next Article</a> is on the application of IEC 82304-1 with agile methods.</p>https://blog.cm-dm.com/post/2016/03/11/IEC-82304-1-Overview-of-requirements#comment-formhttps://blog.cm-dm.com/feed/atom/comments/179IEC 82304-1 - latest news about the standard on Health Softwareurn:md5:d4d8fc396a6bed4f074197a72573b42a2016-01-15T14:30:00+01:002016-06-23T20:01:45+02:00MitchStandardsCE MarkFDAIEC 62304IEC 82304ISO 14971Software Validation<p>IEC 82304-1 <em>Health software -- Part 1: General requirements for product safety</em> standard is still under development. Its status is visible on the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59543">page of ISO website, dedicated to IEC 82304-1</a>. There is even a preview of the first three pages of this draft standard.</p> <p>The last draft of IEC 82304-1 was published for comments in July 2015. It is a DIS (draft international standard) and should pass a step early 2016, by being accepted by the drafting committee. It means that a FDIS (final draft international standard) should be published in S1 2016. If it is accepted, the final version should be published by the end of 2016.</p>
<h4>What is the scope of IEC 82304-1?</h4>
<p>The scope of IEC 82304-1 intersects the scope of IEC 62304 but is not identical. It includes different types of software and different steps of the software lifecycle.
IEC 82304-1 deals with health software. The definition of health software is given in the section 3.6 of the standard:</p>
<blockquote><p>HEALTH SOFTWARE<br />
software intended to be used specifically for maintaining or improving health of individual persons, or the delivery of care.</p>
<p></p></blockquote>
<p>It is completed with the definition of health software product in the section 3.7 of the standard:</p>
<blockquote><p>HEALTH SOFTWARE PRODUCT<br />
combination of HEALTH SOFTWARE and ACCOMPANYING DOCUMENTS</p>
<p></p></blockquote>
<p>The definition of medical device software, given at section 3.x of IEC 62304-2015 is different from the definition of health software:</p>
<blockquote><p>MEDICAL DEVICE SOFTWARE<br />
SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE<br />
NOTE: This includes a MEDICAL DEVICE software product, which then is a MEDICAL DEVICE in its own right.</p>
<p></p></blockquote>
<p>The definition of SOFTWARE PRODUCT, which was used in IEC 62304:2006, was removed from IEC 62304:2015. We now have the definition of HEALTH SOFTWARE PRODUCT in IEC 82304-1. This is one proof, amongst others, to make IEC 82304-1 and IEC 62304 a two-standard team.</p>
<h4>Types of software</h4>
<h5>Types of software regarding the medical intended use</h5>
<p>The first main difference between both definitions is the intended use. IEC 62304 deals only with software with medical intended use, whereas IEC 82304-1 deals with any kind of software, which directly or indirectly has an effect on health.<br />
The scope of IEC 82304-1 is broader than the scope of IEC 62304. The following types of software are in the scope of IEC 82304-1 but not IEC 62304:</p>
<ul>
<li>Radiology Information Systems (RIS),</li>
<li>Prescription Management Systems (PMS),</li>
<li>Laboratory Information Management Systems (LIMS),</li>
<li>Mobile Apps, which are not Mobile Medical Apps, according to the <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">FDA Guidances on this subject</a>,</li>
<li>Software, which are not qualified as medical devices, according to the <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">MEDDEV 2.1/6 EU Guidance</a>.</li>
</ul>
<p>Thus IEC 82304-1 includes in its scope standalone software, which are not regulated as medical devices.</p>
<h5>Types of software regarding the platform</h5>
<p>IEC 82304-1 deals only with standalone software. Contrary to IEC 62304, it doesn't deal with software embedded in medical devices or embedded in devices with specific hardware. Only software running on a standard PC, server, tablet, or smartphone with a general purpose Operating System are in the scope of IEC 82304-1.<br />
The graphic below, borrowed from IEC 82304-1, shows the scope of this standard versus the scope of IEC 62304.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.Scope_of_IEC_82304-1_m.png" alt="Scope_of_IEC_82304-1.png" style="display:table; margin:0 auto;" title="Scope_of_IEC_82304-1.png, Dec 2015" />
Note: the rectangle in green is not present in the graphic of the standard. It was added here for clarification to show the scope of IEC 62304.</p>
<h4>Steps of the software lifecycle</h4>
<p>IEC 82304-1 deals with standalone health software product. It defines requirements at the system/product level like:</p>
<ul>
<li>Product Requirements,</li>
<li>Product Validation,</li>
<li>Product Identification and Instructions For Use,</li>
<li>Post-market activities.</li>
</ul>
<p>And it references IEC 62304:2015 for requirements at software level.<br />
IEC 82304-1 kind of takes the place of IEC 60601-1 or IEC 61010 for standalone software. IEC 60601-1 defines requirements at system level for Programmable Electric Medical Systems (PEMS), and references IEC 62304 for the software lifecycle.<br />
<br />
Likewise, IEC 82304-1 defines requirements at system level for health software systems, and references a subset of IEC 62304 for the software lifecycle.<br />
The graphic below sums up this.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.scope_of_IEC_82304-1_in_lifecycle_m.png" alt="scope_of_IEC_82304-1_in_lifecycle.png" style="display:table; margin:0 auto;" title="scope_of_IEC_82304-1_in_lifecycle.png, Dec 2015" />
Consequence: if you want to apply IEC 82304-1 to your software, you have to apply a subset of IEC 62304 at the same time.</p>
<h4>Relationships with other standards</h4>
<p>Another way of putting this standard in the picture, it to draw the relationships of this standard with other standards, like we already did <a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010">here for IEC 62304</a>.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.relationship_of_IEC_82304-1_with_other_standards_m.png" alt="relationship_of_IEC_82304-1_with_other_standards.png" style="display:table; margin:0 auto;" title="relationship_of_IEC_82304-1_with_other_standards.png, Dec 2015" />
This graphic anticipates a bit what is explained in the next article: ISO 14971 is not required by IEC 82304-1 but is still required by IEC 62304.</p>
<h4>Is it mandatory?</h4>
<h5>Short answer:</h5>
<p>No. A standard is never mandatory, expected in very rare cases, but surely not for health software!<br /></p>
<h5>Not so long answer:</h5>
<p>Standards are never mandatory but when they are recognized by regulation authorities, like the FDA, they become "gold standards" de facto.<br />
So, for standalone software regulated as medical devices (eg. mobile medical apps), it could become recognized by the regulations authorities as soon as the final version is published. It would make it almost mandatory.<br />
But for standalone software NOT regulated as medical devices, since they are out of the scope of regulations authorities, the manufacturers of such software could show very little willingness to implement IEC 82304-1!<br />
<br />
In a nutshell:</p>
<ul>
<li>if you develop standalone software medical devices, be prepared to see IEC 82304-1 recognized by the FDA and harmonized by the European Commission when it is published. Probably not before late 2016,</li>
<li>if you develop standalone health software not qualified as medical device, we don't know what regulation authorities will make of this standard. But odds are low that it will become mandatory<br /></li>
</ul>
<p><br />
<a href="https://blog.cm-dm.com/post/2016/03/11/IEC-82304-1-Overview-of-requirements">Next time</a> we'll see more in details the requirements of this standard.</p>https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/178IEC 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/174IEC 62304 Amendment 1 publishedurn:md5:33d038c348f0bbeea80425a2a316e3732015-07-10T11:52:00+02:002015-07-27T08:36:41+02:00MitchStandardsIEC 62304 <p>The new version of IEC 62304, also known as IEC 62304:2015 or amendment 1 of IEC 62304 was published by the IEC at the end of June 2015.<br />
There were no major changes compared to the drafts that were circulated earlier this year.<br />
<br />
The two major new requirements, compared to IEC 62304:2006 are:</p>
<ul>
<li>Requirements about legacy software,</li>
<li>Changes in the definition of the security classes, based on risk assessment.</li>
</ul>
<p>IEC 62304:2015 is available on IEC website at the astounding / amazing / appealing / astonishing (delete as appropriate) price of 650 swiss francs (approx. US$700) for the consolidated version.<br />
Enjoy!<br />
<br />
<br />
Now we need to wait for this version to be harmonized by EU and recognized by the USA.</p>https://blog.cm-dm.com/post/2015/07/10/IEC-62304-Amendment-1-published#comment-formhttps://blog.cm-dm.com/feed/atom/comments/167