Software in Medical Devices, by MD101 ConsultingBlog 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-18T07:25:39+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearIs my software in class A, B, C - IEC 62304 2nd editionurn:md5:dedf83b4224cafe45b3ade5400edb2a22024-03-15T14:35:00+01:002024-03-15T14:35:00+01:00Mitch<p>Do you know that standard also have design specifications? This is the case for IEC 62304 2nd Edition.<br>
This version doesn't exist yet. But its design specs have been defined and <a href="https://www.iec.ch/ords/f?p=103:227:17378962100131::::FSP_ORG_ID,FSP_LANG_ID:1359,34">published on IEC website</a>.</p> <p>I will not bother to explain the reason why IEC 62304 2nd edition will include MD software, as well as Health software. The consequence is that ISO 14971 is not hardlinked to IEC 63204 any more.<br>
I'm fine with that. Some others aren't. This isn't interesting (unless you're a MDSW guru).</p>
<h4>Software process rigor</h4>
<p>The spec introduces the concept of <em>Software Process Rigor</em>.<br>
It was actually present in the previous draft versions, that were dismissed. That Software Process Rigor replaces the Software Safety Class.<br>
<br>
And, Tadaaa, <em>a two-level classification has been proposed to simplify the software classification process.</em><br>
Exit the software safety class and the three levels!<br>
Bonjour a twofold system with level I and II. The equivalences pointed by the design specification are:</p>
<ul>
<li><em>Current Class A is equivalent to level I</em>,</li>
<li><em>Classes B and C are intended to be level II</em>.</li>
</ul>
<p>Consequence:</p>
<ul>
<li>Level I is assigned to software when <em>[it] cannot contribute to a hazardous situation</em>,</li>
<li>Level II is assigned when software can contribute to a hazardous situation, prior to mitigation action in this software.</li>
</ul>
<p>We see here a <mark>bottom-up approach</mark>:</p>
<ul>
<li>No Hazardous situation => Level I</li>
<li>Otherwise => Level II</li>
</ul>
<p>Please note that a hazardous situation can lead to a non-serious or a serious injury.<br>
<br>
Does it mean that, when software can contribute to a non-serious injury, a software process rigor similar to the current class C shall be applied?<br>
There are some elements of answers to this question in IEC 62304 2nd edition design spec.</p>
<ul>
<li>About clause 5.4: <em>Due to the flexible nature of this requirement and the capability of tools this should be appropriate for all software rigor levels</em>.
<ul>
<li>I won't elaborate on the <em>capability of tools</em>. This looks like wishful thinking, when you have a sw development background...</li>
<li>The draft spec also mention replacing "Detailed Design" by "Design''. This is interesting to read this in relation to the flexible nature of this requirement. That leaves the door to more or less detailed design,</li>
<li>The draft spec also mentions the need for guidance in annex B.5.4. I think this will make a lot of guidance (imagine something being of practical use for: real-time software, daemon / kernel software, PC software, GUI, gui-less software, micro-services, middleware, web apps, mobile apps, rule engines, ... ML algorithms, ... SQL databases, NoSQL databases, ... industrial PLCs, industrial IHM panels, cobot scripts ... shell scripts ... Mathlab code ... and probably a lot more). This is one again wishful thinking to elaborate a guidance appropriate for all cases,</li>
</ul></li>
<li>About clause 5.5: <em>no changes per the discussion</em>
<ul>
<li>I already see how fun it will be to document additional unit acceptance criteria with software currently in class B,</li>
<li>As well as unit test strategy equivalent to class C (unless we also have flexibility here).</li>
</ul></li>
</ul>
<p><br>
I've seen almost bitwise design for some real-time safety critical software in class C (and timelines almost documenting sw behavior at every CPU clock cycle). I've also seen more than lightweight unit design for class B software. The level of flexibility of new clause 5.4 and 5.5 will be like a rubber band used in bungee jumping.<br>
<br></p>
<h4>FDA guidance compatibility?</h4>
<p>We've seen in a <a href="https://blog.cm-dm.com/post/2023/06/16/Final-FDA-guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">previous post on the FDA guidance on Content of Premarket Submissions for Device Software Functions</a> that the twofold FDA system is:</p>
<ul>
<li>Enhanced Documentation Level: <em>where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury</em></li>
<li>Basic Documentation Level: <em>where Enhanced Documentation does not apply</em>.</li>
</ul>
<p>We see here a <mark>top-down approach</mark>:</p>
<ul>
<li>Serious Injury => Enhanced documentation level,</li>
<li>Otherwise => Basic documentation level.</li>
</ul>
<p>Here is a little table to make it clear:<br></p>
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;border-color:#ccc; margin-left: auto; margin-right: auto; }
.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#fff;}
.tg th{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#f0f0f0;}
.tg .tg-4eph{background-color:#f9f9f9}
</style>
<table class="tg">
<tr>
<th class="tg-031e" style="width:25%" >SW Risk</th>
<th class="tg-031e" style="width:25%" >IEC 62304 2015</th>
<th class="tg-031e" style="width:25%" >IEC 62304 2nd Ed</th>
<th class="tg-031e" style="width:25%" >FDA Guidance</th>
</tr>
<tr>
<td class="tg-4eph" >None</td>
<td class="tg-4eph" >Class A</td>
<td class="tg-4eph" >Level I</td>
<td class="tg-4eph" rowspan="2">Basic Documentation Level</td>
</tr>
<tr>
<td class="tg-4eph" >Non-serious injury</td>
<td class="tg-4eph" >Class B</td>
<td class="tg-4eph" rowspan="2">Level II</td>
</tr>
<tr>
<td class="tg-4eph" >Serious injury</td>
<td class="tg-4eph" >Class C</td>
<td class="tg-4eph" >Enhanced Documentation Level</td>
</tr>
</table>
<p><br>
<strong>Compatibility between IEC 62304 Software Process Rigor Level and FDA Documentation Level equals zero.</strong><br>
<br></p>
<h4>And IEC 81001-5-1 compatibility?</h4>
<p>We've seen in <a href="https://blog.cm-dm.com/post/2024/02/23/IEC-81001-5-1-Right-Here-Right-Now">a previous post</a> that IEC 81001-5-1 requires to implement a software lifecycle documentation closer to class B than class A.<br>
It implies that class A documentation, as required by IEC 62304 2015, isn't possible. For example: it is not possible to skip architectural design when applying IEC 81001-5-1 . This is anticipated in IEC 62304 2nd edition design spec, with the following comments on clause 5.3:</p>
<ul>
<li><em>a certain level of Architecture planning is appropriate for all rigor level software products</em>, and</li>
<li><em>This is especially true to support cybersecurity requirements that should be addressed outside of IEC 62304</em>.</li>
</ul>
<p>So, compatibility with IEC 81001-5-1 is expected.<br>
<br></p>
<h4>Effort of documentation</h4>
<p>Based on the elements that we've seen above, we can make a comparison on the effort of documentation required by the aforementioned documents.<br></p>
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;border-color:#ccc; margin-left: auto; margin-right: auto; }
.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#fff;}
.tg th{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#f0f0f0;}
.tg .tg-4eph{background-color:#f9f9f9}
</style>
<table class="tg">
<tr>
<th class="tg-031e" style="width:25%" >IEC 62304 2015<br/>(reference)</th>
<th class="tg-031e" style="width:25%" >IEC 62304 2nd Ed</th>
<th class="tg-031e" style="width:25%" > FDA guidance</th>
<th class="tg-031e" style="width:25%" >IEC 81001-5-1</th>
</tr>
<tr>
<td class="tg-4eph" >Class A documentation effort</td>
<td class="tg-4eph" >N/A</td>
<td class="tg-4eph" >N/A</td>
<td class="tg-4eph" >N/A</td>
</tr>
<tr>
<td class="tg-4eph" >Class B documentation effort</td>
<td class="tg-4eph" >Level I</td>
<td class="tg-4eph" >Basic Documentation level</td>
<td class="tg-4eph" >Architectural design for cybersecurity</td>
</tr>
<tr>
<td class="tg-4eph" >Class C documentation effort</td>
<td class="tg-4eph" >Level II</td>
<td class="tg-4eph" >Enhanced Documentation level </td>
<td class="tg-4eph" >Design for cybersecurity</td>
</tr>
</table>
<p><br>
Please note once again that Level II is for software that could lead to minor injury or serious injury.<br>
<br></p>
<h4>Conclusion</h4>
<p>As proposed in <a href="https://blog.cm-dm.com/post/2024/02/23/IEC-81001-5-1-Right-Here-Right-Now">a previous post on IEC 81001-5-1</a>, we have a trend to foster inflation of documentation for medical device software. Documentation is a key aspect to demonstrate that the rigor of software processes throughout its lifecycle. However, that rigor shall remain proportionate to the hazardous situations resulting from software failure.<br>
<br>
Documentation shall not be overkill, especially when software can only lead to minor injury.<br>
IEC 62304 2nd Edition is not taking this direction.</p>https://blog.cm-dm.com/post/2024/03/15/Is-my-software-in-class-A%2C-B%2C-C-IEC-62304-2nd-edition#comment-formhttps://blog.cm-dm.com/feed/atom/comments/281Templates: Security Risk Management Plan and Security Risk Assessment Reporturn:md5:abc5bd7326231134c454fa05e34777a82024-03-08T13:47:00+01:002024-03-08T13:47:00+01:00MitchTemplatesCybersecurityFDAIEC 81001-5-1<p>Cybersecurity guidances and standards have quite evolved the last few months.<br>
It's time to push new templates!</p> <p>I updated the two templates for security risk management process: the <a href="https://blog.cm-dm.com/public/Templates/security-risk-management-plan-template-2024.doc">Security Risk Management Plan</a> and the <a href="https://blog.cm-dm.com/public/Templates/security-risk-assessment-report-template-2024.doc">Security Risk Assessment Report</a>.</p>
<p><strong>I gather all my templates on the <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates page</a>.</strong> You'll find them all there.</p>
<p>Please, feel free to give me feedback on my e-mail contact@cm-dm.com</p>
<p>I share this template with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<br />
<br />
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/fr/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/">Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License</a>.
https://blog.cm-dm.com/post/2024/03/08/Templates%3A-Security-Risk-Management-Plan-and-Security-Risk-Assessment-Report#comment-formhttps://blog.cm-dm.com/feed/atom/comments/280IEC 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/279New version of the FDA guidance on off-the-shelf software use in medical devicesurn:md5:8b8959b14dd2e6cb7e587881652e0c9a2023-10-20T14:12:00+02:002023-10-20T14:12:00+02:00MitchRegulations<p>The FDA released in August 2023 a new version of their guidance on off-the-shelf software (OTSS) use in medical devices. It’s worth noting that this guidance didn’t go through a draft version.<br />
Something visible in the content of that guidance.</p> <p>The recommendations present in this guidance are supposed to be following a least burdensome approach. But when you read the guidance, you wonder how this principle has been applied. The people who wrote this guidance are absolutely knowledgeable in medical device software, but the recommendations aren’t applicable to many software, if you try to apply them by the book.<br />
<br />
The guidance begins slowly by aligning the documentation effort with the basic and enhanced documentation levels, found in the <a href="https://blog.cm-dm.com/post/2023/06/16/Final-FDA-guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">guidance on premarket submissions for device software functions</a>. Then, things get complicated when the guidance dives into details.<br />
<br />
This is where an extensive interpretation of this FDA guidance is necessary. This is a bit unusual to react like this in the columns of this blog. But this is actually what a manufacturer should do. Otherwise, the guidance is unapplicable.<br /></p>
<h4>Software failure in OTSS</h4>
<p>Depending on the architecture, the data structures and data streams in your software, OTSS failure may or may lead to an unacceptable risk to the patient. We can borrow the approach of the IEC 62304, which allows placing software items (including SOUPs) in a class lower than the software system class.<br />
<br />
Based on this approach, you can have OTSS leading to no or low risk (meaning acceptable risk), even in a software of enhanced documentation level. Thus, we can split OTSS in two categories (binary approach and not ternary approach as in the former guidance), with high risk OTSS and not high risk OTSS. “not high-risk” is clumsy, thus we use “low-risk” in this post.</p>
<h4>Interpretation based on OTSS risk profile</h4>
<p>The table below summarizes the interpretations that could be made to alleviate the burden of the recommendations, based on this binary approach. If the FDA doesn’t write clearly the least burdensome approach in their guidance, let’s help them in this task!<br />
<br /></p>
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;border-color:#ccc; margin-left: auto; margin-right: auto; }
.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#fff;}
.tg th{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#f0f0f0;}
.tg .tg-4eph{background-color:#f9f9f9}
</style>
<table class="tg">
<tr>
<th class="tg-031e" style="width:30%" >Guidance Section</th>
<th class="tg-031e" style="width:35%" >Interpretation high risk OTSS</th>
<th class="tg-031e" style="width:35%" >Interpretation low risk OTSS</th>
</tr>
<tr>
<td class="tg-4eph" colspan="3">III OTS Software documentation elements</td>
</tr>
<tr>
<td class="tg-4eph" colspan="3">A. Description of OTS Software</td>
</tr>
<tr>
<td class="tg-4eph">1. What is it?</td>
<td class="tg-4eph" colspan="2">No tricky question here, excepted:<br/>
<i>“Why is this OTS software appropriate for this medical device?”</i> <br/>
The answer could be based on the functions delivered by the OTSS, its maturity level, and the supplier evaluation.<br/>
<br/>
<i>“What are the expected design limitations of the OTS software?”</i><br/>
The answer should conclude that the design limitations don’t bring an unacceptable risk
</td>
</tr>
<tr>
<td class="tg-4eph">2. What are the Computer System Specifications for the OTS Software?</td>
<td class="tg-4eph">For high-risk OTSS, the validated configuration shall be clearly documented. Changes in configuration may lead to unacceptable risks.</td>
<td class="tg-4eph">The <i>“complete list of any patches that have been provided by the OTSS manufacturer”</i> can be hard to answer.<br/>
Especially with OS. If the OS is a low-risk OTSS, it may be better stating that patches applied by the OS vendor don’t represent an unacceptable risk.<br/>
Same thing for cloud software, where the configuration may not be fully managed but the manufacturer.
</td>
</tr>
<tr>
<td class="tg-4eph">3. How will you assure appropriate actions are taken by the End User?</td>
<td class="tg-4eph">For high-risk OTSS, these questions are ok. Unspecified or forbidden user actions may lead to unacceptable risks.</td>
<td class="tg-4eph">Questions about non-specified OTSS may be difficult to address, especially for SaMD. Such non-specified software shall not lead to unacceptable safety risks (Security risk remain anyway if the user can install malware).<br/>
Then, the only way to address them is by labelling and, perhaps summative evaluation.
</td>
</tr>
<tr>
<td class="tg-4eph">4. What does the OTS Software do?</td>
<td class="tg-4eph">For high-risk OTSS, these questions are ok. Unspecified performance may lead to unacceptable risks.</td>
<td class="tg-4eph"><i>“specify[ing] exactly which OTS components will be included in the design of the medical device”</i> or knowing <i>“the links with other software including software outside the medical device”</i> can be difficult. Especially with SaMD, or OS.<br/>
It may be better stating that such lack of configuration management at runtime doesn’t represent an unacceptable risk.
</td>
</tr>
<tr>
<td class="tg-4eph">5. How do you know it works?</td>
<td class="tg-4eph" colspan="2">No tricky recommendation here.<br/>For most of OTSS, knowing it works is based on the absence of bugs in test results.</td>
</tr>
<tr>
<td class="tg-4eph">6. How will you keep track control of the OTS Software?</td>
<td class="tg-4eph">For high-risk OTSS, lack of configuration control may lead to unacceptable risk.<br/>
However, <i/>“On startup, ideally, the medical device should check to verify that all software is the correct title, version level, and configuration”</i> may be impossible in many cases where scarcity of hardware resources is the rule. The best way to address that is to sign software with state-of-the art cryptographic algorithms. When hardware is powerful enough.</td>
<td class="tg-4eph">Implementation of measures <i>“to prevent the introduction of incorrect versions”</i> is not practically feasible in most cases with embedded software.<br/>
It may be better stating that such lack of configuration management at runtime doesn’t represent an unacceptable risk.<br/>
For SaMD, signing software is made possible or mandatory on app stores and shall be fostered.</td>
</tr>
<tr>
<td class="tg-4eph">B. Risk Assessment of OTS Software</td>
<td class="tg-4eph" colspan="2">No tricky recommendation here. Just do risk assessment on OTSS.</td>
</tr>
<tr>
<td class="tg-4eph" rowspan="2">C. Software Testing as Part of Verification and Validation</td>
<td class="tg-4eph">For high-risk OTSS, it may be relevant to have test plans and reports provided by the OTSS vendor.<br/>
This means that open-source software without such documentation may not be adequate.<br/>
Once again, the lack of documentation may not represent an unacceptable risk.</td>
<td class="tg-4eph">For low-risk OTSS, the absence of documentation on OTSS tests doesn’t represent an unacceptable risk.<br/>
Tests as those presented in the line below are enough to support this.</td>
</tr>
<tr>
<td class="tg-4eph" colspan="2">What is recommended is good testing practices. Most of times, it is not possible to test OTSS directly when it is integrated in the Medical Device Software (MDSW). Thus, qualifying an OTSS is most of times an indirect result of functional tests run on the integrated software.<br/>
Providing a list of OTSS defects is necessary. They shall not represent an unacceptable risk.
</td>
</tr>
<tr>
<td class="tg-4eph">D. Assurance of Development Methodologies and Continued Maintenance of OTS Software</td>
<td class="tg-4eph" ><i>“Provide assurance to the FDA that the product development methodologies used by the OTS software developer are appropriate and sufficient for the intended use of the OTS software within the specific medical device”</i><br/>
This should be reserved to very high-risk OTSS, like a certified multitask real-time OS.<br/>
See MAFs below.
</td>
<td class="tg-4eph" >For 99.99% of OTSS (choose your number of 9 after the comma), the manufacturer has no clue of the product development methodology. If there is one!<br/>
The recommendation in the left cell is absolutely unapplicable and shall be discarded for low-risk OTSS.</br>
Said in a diplomatic way: For low-risk OTSS, the absence of such documentation on OTSS doesn’t represent an unacceptable risk.
</td>
</tr>
<tr>
<td class="tg-4eph" colspan="3">IV. OTS Software in Marketing Applications</td>
</tr>
<tr>
<td class="tg-4eph">A. Master Files for Devices (MAFs)</td>
<td class="tg-4eph">This should be limited to OTSS representing a high risk in case of failure.<br/>
MAFs are a good solution for software vendor targeting the MD market.
</td>
<td class="tg-4eph">This will not be used by low-risk OTSS vendors (or vendors, which don't target the MD market).</td>
</tr>
<tr>
<td class="tg-4eph">B. OTS Software Changes requiring a 510(k)</td>
<td class="tg-4eph" colspan="2">No comment.</td>
</tr>
<tr>
<td class="tg-4eph">C. Investigational Device Exemption and Changes to OTS Software</td>
<td class="tg-4eph" colspan="2">No comment.</td>
</tr>
<tr>
<td class="tg-4eph">D. Premarket Approval and OTS Software</td>
<td class="tg-4eph" colspan="2">No comment on PMA procedure itself.<br/>
The sentence <i>“The extent to which the medical device manufacturer ensures that the OTS software was developed using appropriate life cycle control depends upon the overall risk of the medical device, the role of the OTS software, and the probable risk of death or serious injury”</i> is in line with the principle used throughout this blog post.
</td>
</tr>
<tr>
<td class="tg-4eph">E. Product Labeling</td>
<td class="tg-4eph" colspan="2">This is in line with question 3: “How will you assure appropriate actions are taken by the End User?”</td>
</tr>
</table>
<p><br />
<br /></p>
<h4>Appendix A</h4>
<p>Looking at the appendixes, the discussion on OS, drivers and utilities is interesting. In short, the FDA doesn’t recommend to have general public OS in a MDSW.<br />
<br />
E.g.: it is possible (acceptable risk) to use Windows, MacOS, iOS or Android with a SaMD of basic documentation level. Likewise, it is acceptable with a SaMD of enhanced documentation level, when OS failure doesn’t represent an unacceptable risk. But it is hardly possible to have an industrial PC with such an OS inside a life-sustaining medical device.<br />
<br />
The discussion is also interesting on the “excess of functionality” of general public OS. Sure! Imagine an OS “detecting” some medical image as a photo, and suggesting to share it on social media!<br />
<br /></p>
<h4>Appendix B</h4>
<p>The examples given in this appendix are interesting. But curiously, OTSS documentation level is always attached to the device documentation level. Since all cases can be found in nature, a case like this could be added:<br />
<br />
<br />
<strong>(3) A retinal diagnostic software device</strong><br />
<strong>Description:</strong> The device is limited to prescription use and incorporates an AI/ML-enabled algorithm that is intended to evaluate images for diagnostic screening to identify retinal diseases or conditions.<br />
<br />
Example OTS Software 1: <strong>OTS AI/ML libraires</strong>.<br />
OTS Software Documentation: A failure or latent flaw of these libraries can lead to a failure of the device software function(s), such as a diagnostic algorithm failure that provides a false result. These failures <strong>could</strong> present a hazardous situation with a probable risk of death or serious injury to the patient prior to the implementation of risk control measures. Therefore, since the device has an Enhanced Documentation Level, <strong>the AI/ML libraries</strong> OTS Software Documentation will follow the Enhanced Documentation Level in this guidance.<br />
<br />
Example OTS Software 2: <strong>OTS cloud-based platforms and operating systems on local computers</strong>.<br />
OTS Software Documentation: A failure or latent flaw of the OTS cloud-based platform and operating systems on local computers can lead to a failure of the device software function(s), where the failure modes are device unusable or not responding. These failures <strong>don’t</strong> present a hazardous situation with a probable risk of death or serious injury to the patient prior to the implementation of risk control measures. They only represent a risk of delayed diagnosis or treatment with minor consequences to the patient. Therefore, in the absence of unacceptable risk in case of OTSS failure, <strong>the OTS cloud-based platforms and operating systems on local computers</strong> OTS Software Documentation will follow the Basic Documentation Level in this guidance. Recommendations in sections III and IV of this guidance are given only for information for such Documentation Level.<br />
<br /></p>
<h4>Conclusion</h4>
<p>This guidance is unapplicable.<br />
Why? Manufacturers can't apply recommendations without interpretation.<br />
Why? The recommendations aren’t technically / practically applicable.<br />
Why? The guidance didn’t follow the draft guidance / public review workflow.<br />
Why? Dunno, FDA, please check your SOPs.<br />
<br />
Proposed correction: Release a new draft guidance for comments.</p>https://blog.cm-dm.com/post/2023/10/20/New-version-of-the-FDA-guidance-on-off-the-shelf-software-use-in-medical-devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/278Final 2023 FDA Premarket Cybersecurity guidance releasedurn:md5:eb954de98536ffc711a22831b88adf7e2023-10-06T14:09:00+02:002023-10-06T14:09:00+02:00MitchRegulationsCybersecurityFDAGuidanceIEC 81001-5-1risk management<p>The final version of the FDA guidance titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions was published the 27th September 2023.</p> <p>The draft had been issued in 2022, and had been subject to <a href="https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission">a review in this article</a>.<br />
<br />
Amongst a long list of minor changes, the final version contains the following majors changes in the body text:</p>
<ul>
<li>IEC 81001-5-1 is know referenced as a possible Secure Product Development Framework, this is good news for manufacturers selling their devices in EU and the USA,</li>
<li>AAMI TIR57 is recommended to document <em>the security risk management activities for a medical device system</em>. It's worth noting that <a href="https://blog.cm-dm.com/post/2023/09/08/AAMI-SW96-2023-The-keystone-of-security-risk-management-for-medical-devices">AAMI SW96</a> isn't mentioned (yet),</li>
<li>The above bullet is found in a new section V.A.2. Cybersecurity Risk Assessment. Its content is broadly aligned with AAMI SW96,</li>
<li>A new section V.A.3 on <em>Interoperability considerations</em>. In short, security controls are required when exchanging information with other software or devices (MD or non-MD),</li>
<li>Manufacturers should provide SBOM in machine readable format, something which is going to be made systematic for all software in the US in the coming years,</li>
</ul>
<p>And the last major change is the Appendix 4 <em>General Premarket Submission Documentation Elements and Scaling with Risk</em>.<br />
It summarizes in table 1 the documentation expected by the FDA in premarket submissions. The documentation should scale with the cyber risks of your devices.<br />
<br />
Of course, we find the usual guidance warning: <em>This table is not intended to serve as merely a deliverable checklist</em>.<br />
But, gosh, yes, you are going to use it as a checklist. I am going to use it as a checklist. FDA reviewers are going to use it as a checklist!<br />
<br />
<br />
All in all, the message delivered by the FDA in this final guidance doesn’t change, compared to the draft version. Cybersecurity shall be taken seriously.<br />
<br />
Prepare your security risk management files, your secure SDLC documents and your cyber PMS!</p>https://blog.cm-dm.com/post/2023/10/06/Final-2023-FDA-Premarket-Cybersecurity-guidance-released#comment-formhttps://blog.cm-dm.com/feed/atom/comments/277Time it takes an evaluator to review your tech file in 2023urn:md5:09f4388e7d61cb097244e3f6b8fe291d2023-09-28T18:02:00+02:002023-09-28T17:07:51+02:00MitchMisc<p>Will it take more time than the age of the universe?</p> <p><a href="https://blog.cm-dm.com/public/TIME_IT_TAKES_AN_EVALUATOR_TO_REVIEW_YOUR_TECH_FILES_IN_2023.png" title="TIME IT TAKES AN EVALUATOR TO REVIEW YOUR TECH FILES IN 2023.png, Sep 2023"><img src="https://blog.cm-dm.com/public/.TIME_IT_TAKES_AN_EVALUATOR_TO_REVIEW_YOUR_TECH_FILES_IN_2023_m.png" alt="TIME IT TAKES AN EVALUATOR TO REVIEW YOUR TECH FILES IN 2023.png, Sep 2023" class="media-center" title="TIME IT TAKES AN EVALUATOR TO REVIEW YOUR TECH FILES IN 2023.png, Sep 2023" /></a></p>https://blog.cm-dm.com/post/2023/09/28/Time-it-takes-an-evaluator-to-review-your-tech-file-in-2023#comment-formhttps://blog.cm-dm.com/feed/atom/comments/276AAMI 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/275Final FDA guidance on Content of Premarket Submissions for Device Software Functionsurn:md5:2d212d4d5dcc856bfc5b0dceb4a81fbf2023-06-16T13:54:00+02:002023-10-04T17:56:40+02:00MitchRegulations<p>The final version of the <a href="https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions">FDA guidance on Content of Premarket Submissions for Device Software Functions</a> has been published.</p> <p>When the draft guidance had been released in 2021, we discussed the <a href="https://blog.cm-dm.com/post/2021/12/06/FDA-Draft-Guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">it in a previous article</a>.<br />
Compared to the draft version, the final version isn't a game changer: it still contains the Basic Documentation Level and Enhanced Documentation Level. But compared to the previous guidance of 2005, it is a game changer: exit the three levels of concern, and exit IEC 62304 class A.<br /></p>
<h4>Changes compared to the draft version</h4>
<p>The final guidance wording updated throughout the document, with some remarkable changes:</p>
<ul>
<li>Reference to the <a href="https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission">guidance on content of premarket submissions for cybersecurity</a>,</li>
<li>A discussion on software verification and validation, and the risk of having the adequate control on the design process if the documentation is written after development,</li>
<li>The declaration of conformity to IEC 62304 is made more specific by quoting the clauses expected to be implemented,</li>
<li>Additional documentation items in the software description section, especially if the software contains AI/ML models,</li>
</ul>
<p><br /></p>
<ul>
<li>The section on risk management file has been refactored. It is more in line with ISO 14971 and the reference to IMDRF documents has been removed, it is interesting to see the interpretation of order of priority of mitigation actions for software. I quote the body text of the guidance, due to peculiar interest of this section:
<ul>
<li><em>Design (e.g., eliminating or reducing unnecessary features, modifying the software architecture to prevent hazardous situations, modifying the user interface to prevent usability errors)</em></li>
<li><em>Protective measures (e.g., defensive programming checks that detect unexpected faults followed by automatic intervention to halt the delivery of results or therapy, alarms allowing user intervention to prevent a hazardous situation)</em></li>
<li><em>Information for safety (e.g., written warnings, on-screen warnings, training</em></li>
</ul></li>
</ul>
<p>Remark: determining whether alarms are information for safety or not is a recurrent debate. This extract of the guidance gives the FDA's thinking on that situation.
<br /></p>
<ul>
<li>For software design specification in basic documentation level, the FDA now recommends to document it in the DHF (that wasn't present in the draft guidance),</li>
<li>Additional items should be documented on unresolved anomalies</li>
<li>And the section on Off-The-Shelf (OTS) Software Use in Medical Devices has been removed. This is not surprising, the draft guidance just quoted the changes that would be done to the guidance on OTS use in medical devices. Just expect to see a new version of the OTS guidance, aligned with the guidance on content of premarket submission for device software functions.</li>
<li>In appendix, we find a long list of examples of devices placed in Basic or Enhanced Documentation level.</li>
</ul>
<p>These are the most prominent changes. Other little changes have been made throughout the document.<br />
<br /></p>
<h4>To make it short</h4>
<p>The game has changed. Prepare yourself to apply this guidance if you have MD software. Now.</p>https://blog.cm-dm.com/post/2023/06/16/Final-FDA-guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions#comment-formhttps://blog.cm-dm.com/feed/atom/comments/274Maintained 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 81001-5-1 was added to the list of recognized consensus standardsurn:md5:4c57c909d26dd3748dc55cdd5dff60ef2023-01-09T15:31:00+01:002023-01-09T17:49:15+01:00MitchRegulationsCybersecurityFDA <p>The FDA added late December 2022 IEC 81001-5-1 to the list of recognized consensus standards.<br />
That's it. After beating around the bush on this blog on whether UL 2900-x or IEC 81001-5-1 would be applicable to 510(k) submissions and other regulatory clearances, we now have the answer.<br />
<br />
We can use IEC 81001-5-1 as:</p>
<ul>
<li>A Secure Product Development Framework according to <a href="https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission">the latest draft FDA guidance on cybersecurity</a>,</li>
<li>A <a href="https://blog.cm-dm.com/post/2021/07/09/Cybersecurity-standards%3A-IEC-81001-5-1-and-IEC/TR-60601-4-5">method of answer to GSPR on cybersecurity</a> of EU MDR and IVDR.</li>
</ul>
<p>A good way to make thing (a bit) more simple.<br />
<br />
Remark: UL 2900-x can still be applied in the US!</p>https://blog.cm-dm.com/post/2023/01/09/IEC-81001-5-1-was-added-to-the-list-of-recognized-consensus-standards#comment-formhttps://blog.cm-dm.com/feed/atom/comments/271FDA Guidance on Clinical Decision Support Softwareurn:md5:ef4cf2b43e9c7e9a983450dbbf856d1b2023-01-06T13:24:00+01:002023-02-26T00:58:20+01:00MitchRegulations<p>The latest version of the <a href="https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software">FDA Guidance on Clinical Decision Support Software</a> (CDSS) was published in September 2022. Here is a review of the document and a short comparison with the status of CDS with regard to the MDR.</p> <p>The purpose of this guidance is to give rationale to exclude CDSS from the medical device regulation scope. The rationale is based on 4 criteria (see below). CDSS itself very sounds like medical device software intended use, according to the definition of medical device laid in article 2 of the EU Medical Device Regulation (MDR).<br />
Let’s see how much CDSS can be treated differently, according to these 4 criteria in the US regulation, and according to the MDR definition of medical device (a.k.a MDRDef below in this post).</p>
<h4>The Four Criteria</h4>
<p>Here are these criteria present in the US Regulation, after the amendment of the FD&C Act, and how they can be seen from a EU MDR standpoint.<br />
CDSS function can be excluded if they meet all of the following criteria:</p>
<blockquote><p><em>1. not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system</em></p></blockquote>
<ul>
<li>That first criterion is quite similar in its intent to the MDRDef. There is not much to say. CDSS not matching this criterion are medical devices.</li>
</ul>
<blockquote><p><em>2. intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines)</em></p></blockquote>
<ul>
<li>This one looks a bit like the question 3 (Q3) of the MDCG 2019-11. However, "Analyzing" goes beyond that question 3 and may have a SW fall in the scope of the MDRDef.</li>
<li>The examples given further in the <em>Discussion</em> section of the guidance for criterion 2 suggest that this is not the software, which analyzes medical information, but the HCP user. In this case, this is aligned with MDCG 2019-11 Q3, and the SW function is outside the scope of the MDRDef.</li>
</ul>
<blockquote><p><em>3. intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition</em></p></blockquote>
<ul>
<li>The explanations given in the <em>Discussion</em> section of the FDA guidance on <em>prevention, diagnosis, or treatment of a disease or condition</em> are definitely in the scope of the MDRDef. Especially the wording sounds like <em>Informing clinical management</em> present in the IMDRF SaMD risk categorization framework, and Annex 1 of MDCG 2019-11.</li>
<li>Examples contain CPOE, definitely considered as medical device within the EU MDR. The FDA guidance distinguishes software used to <em>enhance, inform, influence HCP's decision making</em> from software used to <em>substitute, replace, or direct HCP's judgment</em>. Such distinction is not present either in the MDRDef or in the MDCG 2019-11. Thus, software with such mode of action would fall in the MDR scope.</li>
<li>Likewise, software for remote surveillance of patients, not intended to support time-critical decision making would match criterion 3. Conversely, that non time-critical remote surveillance definitely falls in the EU MDR scope.</li>
</ul>
<blockquote><p><em>4. intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient</em></p></blockquote>
<ul>
<li>Once again, this sounds very much like the MDRDef. SW function that outputs recommendations, to make a clinical diagnosis or treatment, two purposes present in the MDRDef.</li>
<li>The property of not relying primarily on such information can’t be taken as a rationale to exclude CDSS from the MDRDef.</li>
<li>The discussion on criterion (4) is absolutely not audible with regard to the MDR. As soon as a software function presents recommendations for diagnosis or treatment purpose, it's in the MDR scope. Yet, it may be <em>informing patient management</em> but that doesn't save the software function from the MDR claws and class IIa infection.</li>
<li>The FDA insists in the discussion on labelling to exclude the software function from the US medical device regulation. This is totally not receivable with the MDR. No such rationale can exist.</li>
<li>The fourth criterion is probably the one, which introduces the biggest gap between the FD&C Act and the EU MDR. It allows excluding SaMD with such intended use and labelling from US regulatory scope, whereas such SaMD will remain in MDR scope.</li>
<li>One remark on AI/ML algorithms: They can't meet the sub-criterion (4)(c)(i) as long as explainability of ML algorithm isn't scientifically proved. However, rules engines can meet this criterion. Usually, rule engines can exhibit the rule(s), which data rely upon, to output the result.</li>
</ul>
<h4>Examples of NonDevice CDS Software Functions</h4>
<p>The FDA guidance contains a long list of examples of CDSS not regulated according to US regulation. The table below show the differences in regulatory status that we can expect between US regulation and EU regulation.<br />
<br />
The rationale for MDR qualification in the rightmost column makes use of the Question 3 found in the MDCG 2019-11: 'Is the software performing an action on data different from storage, archival, communication, simple search, lossless compression''.</p>
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;border-color:#ccc; margin-left: auto; margin-right: auto; }
.tg td{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#fff;}
.tg th{padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:#ccc;color:#333;background-color:#f0f0f0;}
.tg .tg-4eph{background-color:#f9f9f9}
.tg .tg-MDR-couleur-PQ{background-color:#EFCBC9}
</style>
<table class="tg">
<tr>
<th class="tg-031e" style="width:20%" >Software Function</th>
<th class="tg-031e" style="width:50%" >Detail</th>
<th class="tg-031e" style="width:30%" >MDR qualification</th>
</tr>
<tr>
<td class="tg-4eph" rowspan="2" >Evidence-based clinician order sets for an HCP to choose from, tailored for a particular condition, disease, or clinician preference:</td>
<td class="tg-4eph">Software function that provides groupings of standard order sets, consistent with clinical guidelines, for patient admission to critical care.</td>
<td class="tg-4eph">Can be probably seen as "simple search", not MD. The Manual on Borderline and Classification V1.22 of 2019 contains a somewhat similar case at section <i>9.4. Qualification of software for interpretation of a guideline</i>.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that provides a list of diagnostic and treatment order options to an HCP based on clinical guidelines for the care of adult patients presenting with pneumonia symptoms</td>
<td class="tg-4eph"> Can be probably seen as "simple search", not MD. Same comment as above.</td>
</tr>
<tr>
<td class="tg-031e" rowspan="2" >Matching patient-specific medical information from records or reports to reference information (e.g., clinical guidelines) that is routinely used in clinical practice:</td>
<td class="tg-031e">Software function that matches patient-specific medical information (e.g., diagnosis, treatments, allergies, signs or symptoms) to reference information routinely uses in clinical practice (e.g., practice guidelines) to facilitate assessments of specific patients. <br/>For example, a software function that uses a patient’s diagnosis and other medical information to provide an HCP with current practice treatment guidelines for common illnesses or conditions such as influenza, hypertension, and hypercholesterolemia</td>
<td class="tg-031e">Can be probably seen as "simple search", not MD</td>
</tr>
<tr>
<td class="tg-031e">Software function that matches patient-specific medical information to peer-reviewed literature publications on related topics.</td>
<td class="tg-031e"> Can be probably seen as "simple search", not MD </td>
</tr>
<tr>
<td class="tg-4eph" rowspan="2">Contextually relevant reference information about a disease or condition:</td>
<td class="tg-4eph">Software function that provides HCPs with recommendations on the use of a prescription drug for a disease (as indicated in the patient’s medical record) that that are consistent with the current version of drug’s FDA-approved labeling</td>
<td class="tg-4eph">Communicating, displaying medical data, not MD</td>
</tr>
<tr>
<td class="tg-4eph">Software function that provides HCPs with available treatment options, including drug, device, surgical and/or lifestyle changes for heart failure patients based on their disease stage and clinical guidelines.</td>
<td class="tg-4eph"> Can be probably seen as "simple search", not MD </td>
</tr>
<tr>
<td class="tg-031e" rowspan="3">Drug-drug interaction and drug-allergy contraindication notifications to avert adverse drug reactions:</td>
<td class="tg-031e">Software function that identifies drug-drug interactions and drug-allergy contraindications, based on the current version of FDA-approved drug or device labeling or other up-to-date and peer-reviewed sources and patient-specific information, to attempt to prevent adverse drug reactions.</td>
<td class="tg-MDR-couleur-PQ" rowspan="3">Drug prescription assistance software is qualified as MD as per <a href="https://blog.cm-dm.com/post/2019/10/09/What-happened-to-my-Drug-Prescription-Assistance-Software">European Court of Justice decision</a> and is at least in class IIa.</td>
</tr>
<tr>
<td class="tg-031e">Software function that enables an HCP to enter multiple drug names and provides information regarding known drug-drug interactions.</td>
</tr>
<tr>
<td class="tg-031e">Software function that identifies drug-disease interactions and contraindications, such as notifying an HCP that a patient with asthma should not be prescribed a non-selective beta-blocking drug</td>
</tr>
<tr>
<td class="tg-4eph" rowspan="2">Drug formulary guidelines:</td>
<td class="tg-4eph">Software function that provides HCPs with a list of medications on a formulary for a given disease or condition.</td>
<td class="tg-4eph"> Communicating, displaying medical data, not MD.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that provides alerts to HCPs regarding changes in a formulary and recommends alternatives.</td>
<td class="tg-4eph"> Communicating, displaying medical data, not MD.</td>
</tr>
<tr>
<td class="tg-031e" rowspan="2">Duplicate testing or medication error prevention notifications (e.g., medication reconciliations and test reconciliations):</td>
<td class="tg-031e">Software function that provides an alert to notify an HCP of redundant test orders and advise discontinuation of the order.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search" and more than communicating medical data. Such alerts have an impact on decisions on diagnosis and/or treatment. They are seen as MD functions with the MDR, they provide information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e">Software function that flags patient results for an HCP based on specific clinical parameters (e.g., out of range test results where the reference ranges are predetermined by the lab or HCP) in response to a medication order. Example:<br/> Software function that flags low potassium and/or magnesium levels in a patient in response to a prescription for digoxin.</td>
<td class="tg-MDR-couleur-PQ" >Probably more than "simple search" and more than communicating medical data. Flagging low levels can be seen as alerts, MD functions with the MDR. Alerts are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph" rowspan="2">Reminders for preventive care or clinician’s orders:</td>
<td class="tg-4eph">Software function that provides an HCP with reminders for preventive care (e.g., breast cancer screening or immunizations) for a patient based on practice guidelines using medical information in the patient’s medical record.</td>
<td class="tg-4eph"> Can be probably seen as "simple search", and communicating medical data. A reminder is not an alert, not MD.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that provides an HCP with reminders for orders for Hemoglobin A1C tests for diabetic patients using patient-specific medical information from the medical record (e.g., the patient’s diagnosis, date of prior Hemoglobin A1C test) based on practice guidelines</td>
<td class="tg-4eph">Can be probably seen as "simple search", and communicating medical data. A reminder is not an alert, not MD.</td>
</tr>
<tr>
<td class="tg-031e" rowspan="2">Patient data reports and summaries (e.g., discharge papers):</td>
<td class="tg-031e">Software function that uses medical information from the patient’s medical records to provide an HCP with recommended assessments prior to discharge, such as a pain assessment.</td>
<td class="tg-031e">Can be probably seen as "simple search", and communicating medical data. Recommendations are not alerts, not MD.</td>
</tr>
<tr>
<td class="tg-031e">Software function that aggregates possible post-operative care instructions, medication needs, and follow-up instructions to assist an HCP in assembling discharge papers for a patient.</td>
<td class="tg-031e" > Can be probably seen as communicating and displaying medical data, not MD. </td>
</tr>
<tr>
<td class="tg-4eph" rowspan="5">List of preventive, diagnostic or treatment options:</td>
<td class="tg-4eph">Software function that provides a list of appropriate cholesterol-lowering drugs to HCPs to consider based on a patient’s cholesterol levels and demographics found in the electronic health record (EHR).</td>
<td class="tg-MDR-couleur-PQ">Borderline case: could be seen as "simple search". However, using demographics data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Such list provide information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above </td>
</tr>
<tr>
<td class="tg-4eph">Software function that analyzes medical information on a patient’s asthma diagnosis and demographics from the patient’s medical record and provides an HCP with a list of FDA-approved treatment options for asthma.</td>
<td class="tg-MDR-couleur-PQ">Borderline case: could be seen as "simple search". However, using diagnosis and demographics data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Such treatment options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that provides to an HCP a list of FDA-approved chemotherapeutic agents for a cancer type identified through analysis of medical information on the patient’s diagnosis and pathologist confirmed biopsy result.</td>
<td class="tg-MDR-couleur-PQ">Borderline case: could be seen as "simple search". However, using demographics and biopsy data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Thus in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that analyzes family history, prior mammogram results, and BRCA1 status from the medical record and recommends that an HCP consider increased mammography frequency or supplemental breast ultrasound for the patient.</td>
<td class="tg-MDR-couleur-PQ">Borderline case: could be seen as "simple search". However, using such data found in patient-specific EHR could be seen as more than "simple search" and as an aid to treatment. Such information is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that enables an HCP to input the specific mutation results of an FDA-authorized Epidermal Growth Factor Receptor Mutation (EGFR) test for a patient with non-small cell lung cancer (the same clinical condition for which the FDA-authorized EGFR test was clinically validated) and identifies FDA-approved treatments for non-small cell lung cancer indicated for use with the FDA- authorized EGFR test.
</td>
<td class="tg-MDR-couleur-PQ">Borderline case: could be seen as "simple search". However, using such data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Thus in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e" rowspan="4">Prioritized list of preventive, diagnostic or treatment options</td>
<td class="tg-031e">Software function that analyzes the type of arthritis diagnosis in the patient’s medical record and identifies prioritized treatment options available for that condition.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", with the "prioritized" list. The software function analyzes data found in patient-specific EHR and outputs information seen as an aid to treatment. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e">Software function that analyzes patient-specific symptoms to provide a prioritized list of diagnostic tests for the HCP to consider.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", with the "prioritized" list. The software function analyzes data found in patient-specific EHR and outputs information seen as an aid to diagnosis. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e">Software intended for HCPs that analyzes patient-specific medical information to determine which over-the-counter (OTC) allergy drug class is likely to be most effective in alleviating the patient’s seasonal allergies and provides a list of available medications in that drug class.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", with the "prioritized" list. The software function is a function similar to drug prescription assistance software. Thus in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e">Software function that analyzes information on a patient’s glaucoma diagnosis in the patient’s medical record and provides HCP with a list of prioritized treatment options to consider for that patient.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", with the "prioritized" list. The software function analyzes data found in patient-specific EHR and outputs information seen as an aid to treatment. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph" rowspan="5">List of follow-up or next-step options for consideration (e.g., after a physician office visit, hospitalization, procedure):</td>
<td class="tg-4eph">Software function that analyzes a patient’s age, sex, gender, and radiologist’s report for findings of low bone density and micro cervical fractures in order to provide an HCP with a list of follow-up options for consideration, such as performance of periodic bone-densitometry scans, nonpharmacological management (e.g., weight-bearing exercise), or referral of the patient to a specialist.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", using such data found in patient-specific EHR could be seen as an aid to diagnosis and/or treatment. Such follow-up options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that tracks and analyzes a chronic obstructive pulmonary disease (COPD) patient’s age and average number of steps walked per day in order to provide a list of follow-up options for the HCP to consider (e.g., office visit, chest CT, spirometry) to evaluate disease progression.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", using such data found in patient-specific EHR could be seen as an aid to diagnosis and/or treatment. Such follow-up options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that analyzes blood glucose laboratory test results and pre- diabetes diagnosis from a patient’s medical record and provides an HCP with a list of next-step options to consider, such as more frequent office visits or referral to a specialist.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", using such data found in patient-specific EHR could be seen as an aid to diagnosis and/or treatment. Such next-step options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that interprets daily results of a basic metabolic panel for a hospitalized patient and recommends several options for IV fluids that may be beneficial to ensure proper hydration and to prevent acidosis. In some cases, this software function may also provide recommendations for potential follow-up testing options.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", using such data found in patient-specific EHR to provide potential follow-up testing options could be seen as an aid to diagnosis and/or treatment. Such recommendations are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">Software function that inputs information about a patient’s cancer progression and treatment history and other medical information from a patient’s medical record and recommends, in addition to prioritized treatments, that the healthcare practitioner also consider one or more legally marketed companion diagnostic tests.</td>
<td class="tg-MDR-couleur-PQ">Probably more than "simple search", using such data found in patient-specific EHR to pinpoint companion diagnostic tests could be seen as an aid to diagnosis. Such recommendation is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. (IVDR status also to consider)</td>
</tr>
</table>
<br/>
<h4>Examples of NonDevice CDS Software Functions - Criterion 4</h4>
<p>The FDA guidance also contains examples of CDSS excluded by US regulation, with specific rationale for criterion 4. The table below shows the differences in regulatory status that we can expect between US regulation and EU regulation. As written above, the difference of regulatory status is striking.<br /></p>
<table class="tg">
<tr>
<th class="tg-031e" style="width:20%" >Software Function</th>
<th class="tg-031e" style="width:50%" >Detail</th>
<th class="tg-031e" style="width:30%" >MDR qualification</th>
</tr>
<tr>
<td class="tg-031e" rowspan="4">Software function that analyzes patient-specific medical information (e.g., end stage renal disease (ESRD) diagnosis, lab test results, and patient demographics from the patient’s medical record) and provides an HCP with a list of treatment options for ESRD based on implementation of practice guidelines. To enable the HCP to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, the software labeling and function provide the following information to the HCP:</td>
<td class="tg-031e">The intended use, HCP user, and patient population are clearly identified. The intended use is not time-critical, and the intended HCP is expected to have sufficient time and training to understand the practice guidelines that are the basis of the recommendations;</td>
<td class="tg-MDR-couleur-PQ">More than "simple search": using such data found in patient-specific EHR and outputting data according to this intended use is an aid to diagnosis. Such treatment options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e">The input medical information is clearly identified and relevant, with data quality requirements to ensure compatibility to enable relevant medical information to be extracted from the EHR;</td>
<td class="tg-031e" rowspan="3">Such labelling won't save the software from MDR scope.</td>
</tr>
<tr>
<td class="tg-031e">A plain language description of the underlying algorithm development and validation that forms the basis for any recommendations is provided. In addition, the practice guidelines being implemented are clearly identified to the HCP, and the guidelines contain sufficient information on their development and clinical studies underlying the recommendations for ESRD treatment options; and</td>
</tr>
<tr>
<td class="tg-031e">The recommendations are provided to the HCP with relevant patient-specific information including a description of how the patient-specific information matches the criteria for treatment options in the practice guidelines. The output indicates whether any expected input medical information from the medical record was missing.</td>
</tr>
<tr>
<td class="tg-4eph" rowspan="4">Software function that recommends a prioritized list of FDA-approved chemotherapeutic agents (approved for the patient’s diagnosed cancer type) to an HCP based on analysis of reported outcomes in a database of clinical studies using the patient’s diagnosis and demographics from the medical record. To enable HCPs to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, the following information is provided to the HCP:</td>
<td class="tg-4eph">The intended use, HCP user, and patient population are clearly identified. The use is not time-critical, and the intended HCP is expected to have sufficient time and training to assess the clinical studies that are the basis of the recommendations;</td>
<td class="tg-MDR-couleur-PQ">More than "simple search" and a "prioritized" list: using such data found in patient-specific EHR and outputting data according to this intended use is an aid to treatment and can be seen as a drug prescription assistance software. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above.</td>
</tr>
<tr>
<td class="tg-4eph">The cancer diagnosis and patient demographics are clearly identified as the inputs being used in the database search and analysis;</td>
<td class="tg-4eph" rowspan="3">Such labelling won't save the software from MDR scope.</td>
</tr>
<tr>
<td class="tg-4eph">Information about how the clinical studies included were selected, the full reports of the clinical studies being relied upon are clearly identified, with a brief summary of the strength of each study (e.g., number of patients, outcome metrics, randomization, comparison arm), and the key elements of the diagnosis or demographics searched for in the medical record are noted;</td>
</tr>
<tr>
<td class="tg-4eph">The prioritized list of FDA-approved chemotherapeutic agents and the basis of the prioritization is provided to the HCP, and the studies that most closely matched the patient-specific diagnosis and demographics are identified. Other considerations, such as the warnings and contraindications from the current version of the FDA-approved drug labeling, are also provided to the HCP for consideration prior to making a final decision.</td>
</tr>
<tr>
<td class="tg-031e" rowspan="4">Software function that analyzes a COPD patient’s age and average number of steps walked per day in order to provide a list of follow-up options for the HCP to consider (e.g., office visit, chest CT, spirometry) to evaluate disease progression. To enable HCPs to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, the following information is provided to the HCP:</td>
<td class="tg-031e">The intended use, HCP user, and patient population are clearly identified. The use is not time-critical, and the intended HCP is expected to have sufficient time and training to assess the clinical studies that are the basis of the recommendations;</td>
<td class="tg-MDR-couleur-PQ">More than "simple search": using such data found in patient-specific EHR and outputting data according to this intended use is an aid to diagnosis and/or treatment. Such list of follow-up options is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above.</td>
</tr>
<tr>
<td class="tg-031e">The patient’s age and average number of steps walked per day and the date of the measurement are clearly identified as the input information. The software also describes how this information is collected;</td>
<td class="tg-031e" rowspan="3">Such labelling won't save the software from MDR scope.</td>
</tr>
<tr>
<td class="tg-031e">A plain language summary is provided to the HCP describing how the algorithm is analyzing patient age and steps walked to assess activity and any validation studies, as appropriate;
</td>
</tr>
<tr>
<td class="tg-031e">The list of follow-up options is provided to the HCP to consider. The average metrics of the patient over time are shown in comparison with a subset of subjects from the underlying database with similar age, disease severity and demographics. The algorithm identifies limitations to consider, such as number of days with missing step information or high variability in daily measurements, which could impact the analysis or the follow-up recommendation based on the HCP’s judgement.</td>
</tr>
</table>
<br/>
<h4>Report on risks and benefits to health of non-device software functions</h4>
<p>The FDA also published a <a href="https://www.fda.gov/medical-devices/digital-health-center-excellence/digital-health-reports">Report on risks and benefits to health of non-device software functions</a> in December 2022. The executive summary concludes: <em>In general, the analysis found more benefits than risks to patient safety and health related to these software functions</em>.<br />
If we dig a bit, there is a specific section for <em>Certain Clinical Decision Support</em>. This section highlights evidence found in literature of a positive impact on patient safety, benefits and risks to health.<br />
Even though they are not regulated, CDSS achieve a satisfying level of performance and safety. No need to regulate such low-risk software, then!</p>
<h4>Conclusion</h4>
<p>This FDA guidance on CDSS allows to exclude SaMD from the medical device scope of US regulations, when all 4 criteria are met. We saw above that this doesn't allow to exclude such CDSS from the EU MDR scope for approximately 50% of CDSS examples.<br />
The winner is the US medical device market, attracting medical device manufacturers with their regulation exclusion policy for low risk software.<br />
<br />
And the looser is the EU medical device market. Once again, the stricter qualification scope and up-classification by MDR rule 11 act as a scarecrow for medical device manufacturers. The amended FD&C Act and the resulting FDA guidance just make things better in the US, and by a mirror effect, worse in the EU.<br />
The MDR doesn't need anybody to dig its hole. Unfortunately (or fortunately, it depends on the point of view), the US regulation adds a shovel of earth to the MDR grave.
<br />
<br />
Please, don't do SaMD in Europe and <a href="https://blog.cm-dm.com/post/2019/05/24/MDR%3A-one-year-left-and-too-late-for-class-I-software">stay away from EU MDR</a> unless you have very very good reasons! Especially for low risk and low profit software.<br />
Believe me, or you won't sleep at night.</p>https://blog.cm-dm.com/post/2023/01/06/FDA-Guidance-on-Clinical-Decision-Support-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/269Manual on Borderline Classification Version 2 - December 2022urn:md5:f3c25644861dc163ac04e1cad018dfe32022-12-16T13:50:00+01:002022-12-19T21:13:31+01:00MitchRegulations<p>The <a href="https://health.ec.europa.eu/latest-updates/manual-borderline-and-classification-under-regulations-eu-2017745-and-2017746-version2-december-2022-2022-12-15_en">Manual on borderline and classification under Regulations (EU) 2017/745 and 2017/746 - Version2 - December 2022 </a> has been published yesterday.</p> <h4>Medical Calculators</h4>
<p>Have a look at section 1.1.9.2 Medical Calculators and make your own judgment.<br />
Mine is that class IIa for such tool informing on clinical management is overkill.<br />
Deadly Rule 11, once again.<br />
Tremble, you poor excel sheets and web forms!</p>https://blog.cm-dm.com/post/2022/12/16/Manual-on-Borderline-Classification-Version-2-December-2022#comment-formhttps://blog.cm-dm.com/feed/atom/comments/270Letter to EPSCO for their meeting of the 9th December 2022urn:md5:a9a77823948321bc372458fc0dcea5592022-12-05T11:47:00+01:002022-12-10T15:28:13+01:00MitchMisc<p>Hi EPSCO!<br />
<br />
I hope you’re doing well!<br />
We’re a bit concerned by your mindset, it looks like you don’t know where you have to go at <a href="https://www.consilium.europa.eu/en/meetings/epsco/2022/12/09/">your meeting of the 9th December</a>.<br />
Please find below some suggestions just for you.</p> <p><br />
<img src="https://blog.cm-dm.com/public/MDR__is_guilty.JPG" alt="MDR _is_guilty.JPG, Dec 2022" style="display:table; margin:0 auto;" title="MDR _is_guilty.JPG, Dec 2022" /><br />
<br /></p>
<h4>Proposal for MDR 2017/745/ UE amendment</h4>
<p><br /></p>
<h5>At the end of article 2 Definitions, add the following paragraph:</h5>
<p>(72) <a href="https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/premarket-notification-510k">Substantial equivalence</a>: A device is substantially equivalent if, in comparison to a predicate it: <br /></p>
<ul>
<li>has the same intended use as the predicate; and has the same technological characteristics as the predicate; or</li>
<li>has the same intended use as the predicate; and has different technological characteristics and does not raise different questions of safety and effectiveness.</li>
</ul>
<p><br />
<br /></p>
<h5>At the end of article 61 Clinical Evaluation, add the following paragraph:</h5>
<p>14. Alternatively to paragraph 1, for all devices other than class III devices or class IIb devices referred to in point (b) of Article 54(1), the manufacturer may demonstrate the safety and performance of medical devices by substantial equivalence.<br />
The information present in the technical documentation, as set out in annex II, demonstrates that the device is as safe and effective as the legally marketed device.<br />
<br />
The technical documentation establishes that:</p>
<ul>
<li>the new and predicate devices have the same intended use and any differences in technological characteristics do not raise different questions of safety and effectiveness;</li>
<li>the device is as safe and effective as the predicate device by scientific methods used to evaluate differences in technological characteristics and performance data.</li>
</ul>
<p><br />
<br /></p>
<h5>In Article 120 Transitional provisions:</h5>
<p>Replace every occurrence of:<br />
27 May 2022<br />
by:<br />
27 May 2032,<br />
<br />
Replace every occurrence of:<br />
27 May 2024<br />
by:<br />
27 May 2034,<br />
<br />
Replace every occurrence of:<br />
27 May 2025<br />
by:<br />
27 May 2035,<br />
<br />
<br /></p>
<h5>In Article 121 Evaluation:</h5>
<p>Replace:<br />
By 27 May 2027,<br />
By:<br />
Every two years, starting from 27 May 2023.<br />
<br />
<br /></p>
<h5>In annex VIII Classification, chapter III, paragraph 6.3</h5>
<p>Replace:<br />
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes<br />
By:<br />
Software intended to provide information which is <strong>directly</strong> used to take decisions with diagnosis or therapeutic purposes<br />
<br />
<br /></p>
<h4>Key takeaways</h4>
<p>As you can see, it solves the current bottleneck by:</p>
<ul>
<li>enlarging the duration of the transition period for legacy devices,</li>
<li>alleviating the overhead of the MDR on innovative devices.</li>
</ul>
<p>Send this to your colleagues at Health and Food Safety Directorate. They will update other articles for consistency. They have plenty of skilled lawyers able to do it promptly.<br />
Feel also free to tell them to update other rules of annex VIII, <ins>to retrieve a reasonable classification system</ins>. Less class III and more class I will be more in line with what other MD regulations do. <br />
<br />
<strong>Last thing: don't forget IVDR. It's the elephant in the room.</strong><br />
<br />
Warm Regards.</p>https://blog.cm-dm.com/post/2022/12/05/Letter-to-EPSCO-for-their-meeting-of-the-9th-December-2022#comment-formhttps://blog.cm-dm.com/feed/atom/comments/268Computer Software Assurance for Production and Quality System Softwareurn:md5:0de0001bc23bf1fe57822f039d4c79de2022-11-11T13:24:00+01:002022-11-11T13:24:00+01:00MitchProcesses<p>That's a bit like a new album of your favorite group. You've been waiting it for years. At last, it's been released! Are you going to be be impressed or disappointed?<br />
The draft FDA guidance on <em>Computer Software Assurance [CSA] for Production and Quality System Software</em> has been published in September 2022. At last!</p> <h4>Scope and purpose</h4>
<p>First, this guidance is neither about Software as a Medical device (SaMD, a.k.a. standalone software medical device), nor about Software in Medical device (SiMD, a.k.a. embedded software).<br />
This guidance in about software in used in QMS processes and production processes. It addresses 21 CFR 820.70(i) requirement. From an ISO 13485 perspective, it addresses clauses 4.1.6 and 7.5.6.<br />
<br />
The reason why this guidance has been published is explained in the <em>Background</em> section. The use of software to automate the realization or the monitoring of processes is quite common. The FDA felt the need to supplement the section 6 of the existing guidance on <em>General Principles of Software Validation</em> (GPSV). It's true that this existing guidance, published in 2002 suffers of its age. It is a bit vague on the validation process to establish. Manufacturers had to rely on other guidance like AAMI TIR 36 or IEC/TR 82002-2 to define their QMS software validation procedures.<br />
Even though the draft FDA guidance brings some new recommendations, the AAMI and IEC guidances are still useful. We can view this draft guidance as a complement of information on how to validate QMS software to be in line with regulatory requirements.</p>
<h4>Similarities with medical device software</h4>
<p>This CSA draft guidance works pretty like medical device software guidance. It requires:</p>
<ul>
<li>An intended use,</li>
<li>A risk-based approach, like in the <em>Content of premarket submissions for device software functions</em> draft guidance,</li>
<li>A modular approach, like the <em>Multiple Function Device Products: Policy and Considerations</em> guidance,</li>
<li>And a testing strategy resulting from the two above, like the GPSV guidance</li>
</ul>
<h4>Intended use</h4>
<p>That's where all begins, like medical device software (MDSW).<br />
You can use a QMS software to record your recalls and only rely on it. But you may continue to have hardcopy records, using that software only to have a convenient workflow. Same software, different intended uses, the CSA approach will be different as well.<br />
<br />
Logically, the draft guidance also states that 21 CFR 820.70(i) doesn't apply to software, which is neither directly used in, nor supports production production or QMS. Namely software outside the scope of your QMS. <br />
Surprisingly, the draft guidance quotes software intended to support business continuity as such software. Beware about that example! If the same software supports business continuity and record retention, then 21 CFR 820.70(i) is applicable.</p>
<h4>Risk-based approach and modular approach</h4>
<p>The new recommendations (not so new, the way of thinking is already applied by manufacturers veterans in QMS software validation) stem from a risk-based approach. This risk-based approach is based on the intended use of the software.<br />
We can see here a similar approach to the one we have for medical device software in the <a href="https://blog.cm-dm.com/post/2021/12/06/FDA-Draft-Guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">draft guidance on content of premarket submissions for device software functions</a>; a twofold approach (emphasis below from FDA):</p>
<ul>
<li>High process risk software: <em>Software used <strong>directly</strong> as part of production or QMS</em>,</li>
<li>Not high process software: <em>Software used to <strong>support</strong> production or QMS</em>.</li>
</ul>
<p>Note that the wording <em>low risk</em> isn't present in the guidance.<br />
<br />
This looks like what we have in gestation for medical device software, a twofold approach based on the intended use of the medical software function:</p>
<ul>
<li>Basic software documentation level, for low-risk medical software function,</li>
<li>Enhanced software documentation level, for high-risk medical software function.</li>
</ul>
<p>We can see here a new paradigm (or a new fashion) appearing with this binary approach to all kinds of software by the FDA.<br />
Exit the major / moderate / minor levels of concern!<br />
<br /></p>
<h4>Reasonably foreseeable risk</h4>
<p>The draft guidance also insists on the way risks should be managed. Organisations should <em>consider which failures are reasonably foreseeable (as opposed to likely)</em>. We see the difference of treatment between medical device software risks, versus production or QMS software risks.<br />
To say it (a bit too) short:</p>
<ul>
<li>Every medical device risk shall be treated seriously, hence they lead to direct (or indirect for SaMD) harms to patients,</li>
<li>Production and QMS risks can be taken with more flexibility when they aren’t reasonably foreseeable,</li>
<li>Production and QMS risks shall be taken seriously, when they are reasonably foreseeable and result in the <em>potential to compromise the production or the [QMS]</em>.</li>
</ul>
<p>A similar approach with severity and frequency, borrowed from ISO 14971, can be taken to assess production or QMS software risks:<br />
Taking QMS / produbtion software failure as the initial step in the sequence of events, we can draw several sequences of events depending of the intended use:<br />
<br />
With QMS software:</p>
<ul>
<li>Sequence
<ul>
<li>Data Corruption / Loss Re. Process (records, traceability…) E.g.: loosing archived batch records</li>
</ul></li>
<li>Consequence
<ul>
<li>Regulatory non-conformity</li>
</ul></li>
</ul>
<p><br />
With production software:</p>
<ul>
<li>Sequence
<ul>
<li>Production data Corruption / Loss E.g.: labeling, control card</li>
</ul></li>
<li>Consequence
<ul>
<li>Product non-conformity or production process non-conformity</li>
</ul></li>
</ul>
<p><br />
Or service support software:</p>
<ul>
<li>Sequence
<ul>
<li>Data Corruption / Loss Re. service (service interventions, complaints…) E.g.: not treating complaints</li>
</ul></li>
<li>Consequence
<ul>
<li>Service process Non-conformity and possibly missed adverse event</li>
</ul></li>
</ul>
<h4>Mitigation action outside software</h4>
<p>The draft guidance also makes use of the principle of mitigation action to decrease the QMS / production software risk profile.<br />
No need to have a hardware mitigation action in place, like in most of software embedded in an electromedical device. Some <em>additional controls or mechanisms</em> can be implemented, provided that they are effective. For example, human awareness or review is accepted (provided that operators are trained and so on, this is another story).<br />
This is similar to the type of mitigation action accepted by clause 4.3.a of IEC 62304:2006 + Amd1:2015.</p>
<h4>Modular approach</h4>
<p>It is possible to split software into several modules, features or functions. Each function may have a different intended use, with a different risk profile. The guidance gives an example with a spreadsheet. I find the example of an ERP more handy. An ERP has several modules. Some are not QMS software (accounting). Some are QMS software with various functions, like a CRM module. If this module is used to manage customer complaints, some high risk profile is expected for the subset of functions managing customer complaints. But not for functions managing other aspects of CRM.<br />
This logic is similar to the <a href="https://blog.cm-dm.com/post/2020/09/04/FDA-Guidance-on-Multiple-Function-Device-Products">Multiple Function Device Products: Policy and Considerations</a> guidance.</p>
<h4>Bespoke software</h4>
<p>The draft guidance contains nothing clear about bespoke software; namely software internally developed or outsourced to a software development firm.<br />
You won't find a word about design qualification, a step often found in QMS software validation procedures. A practical solution for bespoke software it to follow a software development lifecycle similar to IEC 62304 class A.</p>
<h4>Expected records for high-risk software</h4>
<p>The draft guidance gives some examples for high-risk and not high-risk software. High risk software records list looks quite similar to what is expected by clause 5.7 of IEC 62304.<br />
Some differences, however, are present for not high-risk software. The FDA accepts some reduced of even very abbreviated test plans and test reports. They use the wording <em>unscripted testing</em>, something disallowed by IEC 62304.<br />
<br />
The draft guidance also contains a discussion about types of testing strategies. No worries if you don't use them. It's quite common to use robust scripted testing for high risk, limited scripted testing for moderate risk and unscripted testing for low risk software. These testing strategies are there for information.</p>
<h4>No IQ/OQ/PQ!</h4>
<p>You will not find these concepts in this guidance. No need to disguise your software validation process in a tweaked IQ/OQ/PQ process, commonly used for hardware equipments! Most of validation procedures make use of this IQ/OQ/PQ artefact. It is an easy way to make software-illiterate auditors happy (that kind of beast tends to disappear).<br />
Thanks to this FDA guidance, we can do a plain old Software test plan and a software test report, getting rid of this IQ/OQ/PQ behemoth!<br /></p>
<h4>21 CFR part 21</h4>
<p>The draft guidance reminds the reader that some data (most of data) treated / stored by QMS / production software are electronic records according to 21 CFR part 11. The guidance doesn’t give any cue on hiw to validate software functions in the scope ot part 11.<br />
I suggest to take that seriously and not hesitate to put some effort on part 11 validation protocol (using robust script testing and a detailed traceability matrix to part 11 requirements), despite the least burdensome approach claimed by the FDA.</p>
<h4>Conclusion</h4>
<p>We have a clear least burdensome approach in this draft guidance! The previous GPSV guidance left the manufacturer in an unclear situation about the extent of validation to perform with various QMS / production software risk profiles. And the AAMI TIR 36 or IEC/TR 82002-2 didn’t give the FDA view. <br />
<br />
With this new guidance: we know we can pull the brakes on low-risk software, and use the two other guides as a source of information on how to validate high-risk software.</p>https://blog.cm-dm.com/post/2022/11/11/Computer-Software-Assurance-for-Production-and-Quality-System-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/266NIS2 Directive: are you involved or concerned?urn:md5:19b7f5ddba4cf0ace27fb1bb8d1262942022-09-30T14:01:00+02:002022-12-28T21:49:23+01:00MitchRegulationsCE MarkCybersecurity<p>That’s the story of the pig and the hen for breakfast: the pig is involved (ham) and the hen is concerned (eggs). With the NIS2 directive in preparation, a medical device manufacturer will be in either situation.<br /></p> <p>A <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2020:823:FIN">proposal for the NIS2 directive</a> has been published in December 2020. Its goal is <em>ensuring a high level of cybersecurity within the Union</em>. Like any other regulation, it brings its own constraints and overhead to targeted organizations. Fortunately, it is not applicable to micro or small entreprises. However, some additional criteria exist. Let’s see how medical device manufacturers are involved or concerned.</p>
<h4>NIS directive and NIS2 directive</h4>
<p>By the way, subject matter experts call it the NIS2 directive. Its real official name is the <em>directive on measures for a high common level of cybersecurity across the Union</em>. It will replace the <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG&toc=OJ:L:2016:194:TOC">Directive on security of network and information systems</a> (aka NIS directive, <a href="https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations">mentioned on this blog 6 years ago</a>) in force since 2016. NIS2 is used as a nickname, reminder of the replacement of the NIS directive.</p>
<h4>Essential Entities and Important Entities</h4>
<p>The NIS2 directive defines two types of entities:</p>
<ul>
<li><strong>Essential Entities</strong>: Medical Device manufacturers of critical medical devices, according to Annex I of the NIS2 directive. The annex references the regulation on European Medicines Agency in crisis preparedness. It is in draft state, and defines what “critical” medical devices are,</li>
<li><strong>Important Entities</strong>: All medical device manufacturers, according to annex II of the NIS2 directive.</li>
</ul>
<p>We can conclude that all medical device manufacturers, other than small businesses, are at least in the scope of the NIS2 directive and categorized as Important Entities.<br />
<br />
However, some other criteria exist at article 2. Like if the manufacturer is the sole provider of a service in the EU or if it is of importance at regional or national level. Especially, the NIS2 directive references yet another regulation in preparation, the Resilience and critical entities directive, which defines a list of critical entities.<br />
<br />
If a manufacturer matches one of these criteria at article 2, it can be an Essential Entity or Important Entity. Small business or not.<br />
<br />
Examples of medical devices manufacturers, that could be in scope of the NIS2 Directive:</p>
<ul>
<li>A manufacturer of telehealth / teleradiology solution when their software is deployed at regional or national level (criteria at article 2),</li>
<li>A manufacturer of patient file management software, not a medical device but usually editors of such software have medical devices in their product portfolio, when their software is deployed at regional or national level (criteria at article 2),</li>
<li>A manufacturer of a cloud-based SaMD with a large user base, where a potential disruption of the service provided by the entity could have an impact on public safety (criteria at article 2),</li>
<li>A manufacturer of ventilators used to cure patients with covid-19, probably in the future list of critical devices of the EMA crisis preparedness regulation (criteria at annex I),</li>
<li>Another manufacturer of medical devices, not small business (criteria at annex II).</li>
</ul>
<p>To sum-up: to know if a manufacturer is an Essential Entity, or Important Entity, or none of these, it is necessary to read three documents:</p>
<ul>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2020:823:FIN">NIS2 directive</a>, with criteria defined at article 2,</li>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A52020PC0725">EMA crisis preparedness regulation</a>, referenced in annex I of the NIS2 directive,</li>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52020PC0829">Resilience of critical entities directive</a>, referenced in article 2 of the NIS2 directive.</li>
</ul>
<p>Piece of cake! Isn’t it?<br />
<br />
One important thing: The list of entities matching the criteria found in article 2 will be established by Member States. Thus, small businesses won’t decide by themselves if they match these criteria. Such list isn’t defined on the back of an envelope. Member States will need to collaborate with presumed entities to establish the list. Such entities will know well in advance that they will be in the list!<br />
This is also the case for the list of critical entities according to the EMA crisis preparedness regulation and the Resilience of critical entities directive.<br /></p>
<h4>You are Involved!</h4>
<p>If your company is in the scope of the NIS2 directive, you are involved. Essential Entity or Important Entity, you have to establish (article 1):</p>
<ul>
<li>A cybersecurity risk management process,</li>
<li>A reporting process,</li>
<li>An information sharing process.</li>
</ul>
<p>Article 18 defines the requirements on <em>Cybersecurity risk management measures</em>. Article 20, the <em>Reporting obligations</em>, and article 26 the <em>Cybersecurity information sharing arrangements</em>.<br />
<br />
To do so, technical specifications or methodological specifications can be adopted by the European Commission. The European Union Agency for Cybersecurity (<a href="https://www.enisa.europa.eu">ENISA</a>) can also publish guidelines. There is no mention of harmonized standards, though. Only a requirement for Member States to encourage the use of international or European standards. (articles 18 and 22).<br />
<br />
This is going to consume a significant part of enterprises resources. It is wise to put non-critical small businesses out of scope!<br />
These processes will be monitored by a Competent Authority, at Member State level. Obviously, different from the Competent Authority for MD/IVD. I don’t explain further the network of agencies in charge of cybersecurity and crisis management (ENISA, <a href="https://csirtsnetwork.eu" title="CSIRTS Network">CSIRT</a>, <a href="https://www.enisa.europa.eu/news/enisa-news/blue-olex-2020-the-european-union-member-states-launch-the-cyber-crisis-liaison-organisation-network-cyclone">CyCLONe</a>…).<br />
<br />
It is important to note that the NIS2 directive has an impact on entities’ organization. The most straightforward (and expensive) compliance pathway is an Information Security Management System (ISMS) implemented according to ISO 27001.<br />
<br />
MDR and IVDR target products with ISO 13485 and ISO 14971 (plus cybersecurity harmonized / recognized standards).<br />
Thus, a solution for MD manufacturers in the scope of the NIS2 directive could be to have an integrated QMS, compliant to ISO 27001 and ISO 13845.</p>
<h4>Difference between Essential Entities and Important Entities</h4>
<p>Accustomed to MDR/IVDR rules, we can see Important Entities a bit like class I, and Essential Entities as Class II+. This is visible in articles 29 and 30, about supervision of Essential Entities and Important Entities, respectively.<br />
<br />
Essential Entities are subject to <em>regular audits</em> and <em>random checks</em> (sort of unannounced audits). Important Entities can be subject to <em>ex-post</em> inspection by Competent Authorities, after a cyber adverse event occurred. No regular audit, then.<br />
<br />
The NIS2 directive also leaves the possibility to impose certification schemes to Essential Entities and Important Entities (article 21). Hello ISO 27001! Hello, also, future <a href="https://www.enisa.europa.eu/topics/standards/certification">certification schemes</a> that ENISA could elaborate or adopt.<br />
Curiously, the suspension of certification is a sanction only present for Essential Entities.</p>
<h4>You are Concerned!</h4>
<p>Even though a company doesn’t match any criteria of article 2 and isn’t in the scope of the NIS2 directive, it can be impacted by the supply chain. As a manufacturer, you are in the supply chain of healthcare providers, which <ins>will</ins> be essential or important entities, according to article 2. Keep reading, you are concerned!<br />
<br />
Article 18 requires to implement cybersecurity risk management measures in the <em>supply chain security including security-related aspects concerning the relationships between each entity and its suppliers or service providers</em>.<br />
Thus, as a medical device manufacturer, hardware, or software, or software as a service, we have to implement such measures, either in the QMS (for non-active devices), or in the QMS and the devices (for active devices). MDR CE marked devices shall already be compliant to general requirements at annex I of MD / IVDR.<br />
<br />
Article 18 also requires to implement <em>policies and procedures (testing and auditing) to assess the effectiveness of cybersecurity risk management measures</em>.<br />
It means that our clients, who are happy to be Essential or Important Entities, will audit our QMS and/or our products. They will verify that cybersecurity provisions in the QMS and in the device design and post-market are appropriate.<br />
<br />
Last, article 18 adds <em>entities shall take into account the vulnerabilities specific to each supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures</em>.<br />
Cherry on the cake, client’s audits will take into account vulnerabilities in products and the secure development process, like the one described in IEC 81001-5-1.<br />
<br />
That’s a bit like a sterilization service supplier, who is audited by its clients. As a supplier of devices or ICT services considered as critical by your clients, you will be audited by your clients. Of course, with auditors qualified in cybersecurity management.<br />
<br />
Here are some examples:</p>
<ul>
<li>A hospital, registered as Essential Entity, could audit their hardware MD suppliers, when these MD are considered as critical devices for patient care,</li>
<li>A big pharma company, registered as Essential Entity, could audit their suppliers of companion apps (qualified as SaMDs), when these companions apps deliver a service considered as critical for patient management,</li>
<li>A medical imaging manufacturer, registered as Important Entity, could audit their suppliers of medical imaging libraries (themselves MD or not), when these libraires are considered as a critical part of the integrated system.</li>
</ul>
<p>So, we are concerned!</p>
<h4>Consumer electronics is not left apart</h4>
<p>A last proposal for regulation as been issued in September 2022. This is the <a href="https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM:2022:454:FIN">Regulation on horizontal cybersecurity requirements for products with digital elements</a>. Its scope is <em>products with digital elements</em>. It excludes MD and IVD who are already regulated by the MDR and IVDR.<br />
However, the Annex I of this proposal contains a list of general requirements. It's worth reading them, to see what detailed requirements on cybersecurity could be for medical devices!<br />
<br />
We see with this last proposal for regulation that the EU takes cybersecurity seriously, by putting some pressure on all electronic devices.<br /></p>
<h4>And the MDR?</h4>
<p>Let's end with the running-gag of 2022 on this blog: some MDR-bashing!<br />
<br />
As of today, the MDR is a dead-end. It drains all the energies of medical devices manufacturers towards poorly useful QMS updates, technical files updates, and endless Notified Bodies reviews.<br />
<br />
But the geopolitical landscape has changed. Cybersecurity is a real concern. Probably a concern stronger than the safety and performance of medical devices.<br />
<br />
Practically speaking, I feel like I'm doing something useful when I work on securing the design of medical devices. And I feel like I'm doing something useless (even sometimes pointless), when I work on filling some heavy MDR technical file template.<br />
Fortunately, this is only sometimes true for new devices. Unfortunately, this is always true for legacy devices transitioning to the MDR.<br />
What a waste of manufacturers' resources!<br />
<br />
The MDR should be updated to alleviate the burden on MD manufacturers. Their resources shall be set in order of battle to strengthen the security of their products and processes. This is the purpose of a directive like NIS2. We’ve seen that it requires a lot of resources to do it right.<br />
<br />
<strong>We shall not fight the wrong battle: more Cyber, less MDR</strong><br />
<br />
<br />
<strong>Edit 2022/12/28</strong>: <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555">the NIS2 directive, named Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union </a> has been published the 2022/12/27. It shall be transposed in National law no later than September 2024. Articles of the draft version discussed above were shifted by 3 digits in the final version. E.g.: article 18 is now article 21.</p>https://blog.cm-dm.com/post/2022/09/30/NIS2-Directive%3A-are-you-involved-or-concerned#comment-formhttps://blog.cm-dm.com/feed/atom/comments/264MDCG 2022-14: Red Queen Effecturn:md5:5d9b20e3206ab76469ba5fad7835ba762022-09-02T12:47:00+02:002022-09-02T12:47:00+02:00MitchRegulations<p>The MDCG published in August 2022 the <a href="https://health.ec.europa.eu/system/files/2022-08/mdcg_2022-14_en.pdf">MDCG 2022-14</a> position paper on Notified body capacity and availability of medical devices and IVDs.</p> <p>The role of the MDCG is to tell the law, not to change the law. In the current situation, any proposition from the MDCG only scratches the surface of the problem during the transition phase. It doesn't treat the root cause.<br />
The bottlenecks will remain after the transition phase. The root cause is a too strict classification, onboarding lots of low-risk devices in a Notify Body certification scheme.<br />
<br />
As long as this is not changed, the MDR / IVDR will be a major obstacle to the supply of medical devices and a major impairment to innovation. This is not the role of the MDCG but the role of the Parliament to change this.<br />
<br />
The MDCG is subject to the Red Queen effect:<br /></p>
<blockquote><p>It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!</p></blockquote>
<p><a href="https://blog.cm-dm.com/public/Alice_Wonderland_Red_Queen_Race.jpg" title="Alice Wonderland Red Queen Race.jpg, Aug 2022"><img src="https://blog.cm-dm.com/public/.Alice_Wonderland_Red_Queen_Race_m.jpg" alt="Alice Wonderland Red Queen Race.jpg, Aug 2022" style="display:table; margin:0 auto;" title="Alice Wonderland Red Queen Race.jpg, Aug 2022" /></a></p>https://blog.cm-dm.com/post/2022/09/02/MDCG-2022-14%3A-Red-Queen-Effect#comment-formhttps://blog.cm-dm.com/feed/atom/comments/265IEC/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/263MDR: Les Shadoks and MHRA: The Gibisurn:md5:090767a6c488d64d0a85e32857c7407b2022-06-27T14:50:00+02:002022-06-27T14:50:00+02:00MitchRegulations<p>The UK <a href="https://www.gov.uk/government/consultations/consultation-on-the-future-regulation-of-medical-devices-in-the-united-kingdom">Government response to consultation on the future regulation of medical devices in the United Kingdom</a> has been published on Sunday 26th June 2022.</p> <p>Note: You can't catch <a href="https://en.wikipedia.org/wiki/Les_Shadoks">the cartoon reference in the title</a> if you didn't live in France or the UK in the '70s.<br />
<br />
<br />
The results of this consultation are full of common sense. We can see the influence of the MDR requirements in the answers. The right part of the MDR requirements, not the wrong-one. The general public who answered to this consultation already knows what's right or wrong in the MDR!<br />
<br />
Software as Medical Device (SaMD) is covered in chapter 10.<br />
The main takeaways are:</p>
<ul>
<li>Manage distant sales, aka software available on some UK cloud server, a bit like MDR article 6,</li>
<li>Use <a href="https://www.imdrf.org/documents/software-medical-device-possible-framework-risk-categorization-and-corresponding-considerations">IMDRF's Possible Framework for Risk Categorization and Corresponding Considerations</a> to amend the classification rules for SaMD,</li>
<li>Introduce an <em>airlock classification rule</em> when the software <em>risk profile is unclear</em>,</li>
<li>Add cybersecurity and data privacy to essential requirements, like MDR GSPR 17,</li>
<li>Add guidance on validation of Artificial Intelligence medical devices. It should follow the principles of IMDRF’s <a href="https://blog.cm-dm.com/post/2016/11/04/Software-as-a-Medical-Device-%28SAMD%29%3A-clinical-evaluation">Software as a Medical Device (SaMD): Clinical Evaluation</a> document.</li>
</ul>
<p><br />
Using IMDRF's risk categorisation, aligned with international consensus, is probably the best option to avoid under- or over-classification of SaMD. The airlock rule, like FDA De Novo pathway, is another good option. Bravo MHRA and UK government, you do it right!<br />
<br />
Just a little reminder: comparison between IMDRF classification on the left and the <a href="https://blog.cm-dm.com/post/2019/10/31/Is-my-software-in-class-IIa%2C-IIb%2C-or-III%2C-Dark-Fate">interpretation found in MDCG 2019-11 of the MDR rogue Rule 11 classification</a> on the right:<br />
<img src="https://blog.cm-dm.com/public/25-MDR-Rule-11/IMDRF_SAMD_table_and_MDCG_SAMD_table_comparison.png" alt="IMDRF SAMD table and MDCG SAMD table comparison.png, Oct 2019" style="display:table; margin:0 auto;" title="IMDRF SAMD table and MDCG SAMD table comparison.png, Oct 2019" />
<br />
<br />
<em>When the Shadoks pumped, nothing happened; and the more they pumped, the more nothing happened.</em></p>https://blog.cm-dm.com/post/2022/06/27/MDR%3A-Les-Shadoks-and-MHRA%3A-The-Gibis#comment-formhttps://blog.cm-dm.com/feed/atom/comments/262MDCG 2022-11 - Monty Python and the Holy Grailurn:md5:2fb66355f650b024f4520596df956fc42022-06-14T21:41:00+02:002022-06-14T20:42:23+02:00MitchMiscMDR<p>Have you seen the <a href="https://ec.europa.eu/health/latest-updates/mdcg-2022-11-mdcg-position-paper-notice-manufacturers-ensure-timely-compliance-mdr-requirements-2022-06-13_en">MDCG 2022-11</a> - MDCG Position Paper: Notice to manufacturers to ensure timely compliance with MDR requirements?</p> <p>They say:<br />
<em>Therefore and in order to ensure that devices can continue to be placed on the market and to avoid shortages of medical devices, it is essential that all manufacturers adjust their system, finalise transition to the MDR and apply to a notified body, submitting complete and compliant applications, as soon as possible and well in advance of the end of the transition period to ensure timely compliance with the MDR.</em><br />
<br />
Either the <strong>MDCG</strong> is completely off the ground and should be renamed the <strong>MPHG</strong>, Monty Python and the Holy Grail, or this is a disguised message to the European Commission.<br />
<br />
<br />
I keep faith in mankind and lean towards the second solution.<br />
<br />
<img src="https://blog.cm-dm.com/public/.monthy_horse_s.jpg" alt="monthy horse.jpeg, Jun 2022" style="display:table; margin:0 auto;" title="monthy horse.jpeg, Jun 2022" /></p>https://blog.cm-dm.com/post/2022/06/14/MDCG-2022-11-Monty-Python-and-the-Holy-Grail#comment-formhttps://blog.cm-dm.com/feed/atom/comments/261Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissionurn:md5:b7a004729ef3260a2ab492e9093127b12022-06-10T13:47:00+02:002022-08-31T08:43:49+02:00MitchRegulationsCybersecurityFDAGuidanceIEC 62304<p>The FDA issued in April a new draft guidance on <em>Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions</em>. This guidance will supersede the guidance on <em>Content of Premarket Submissions for Management of Cybersecurity in Medical Devices</em> of 2014, when it is finalized. There’s no word about the draft guidance of 2018. We can suppose that one is obsolete.</p> <p>This is a long guidance, like every FDA guidance, you’d say. However, every word counts. This guidance is 45 pages long and contains 40 pages of recommendations in every other paragraph. That makes a lot of recommendations. A hell lot of recommendations.<br />
(Translation for beginners: recommendations = requirements, unless you’re feel wiser than the FDA to overlook these recommendations).<br />
<br />
These recommendations are very precise and were obviously written by cybersecurity experts, making this guidance of a quite high technical level. Meaning that you’ll need people qualified enough to understand these recommendations. That was not exactly the case with the previous guidance, where software design teams could evade the issue.<br />
<br />
If you want to implement this guidance the right way, you’d better take every recommendation seriously. A good option is to put the paragraphs of the guidance in a traceability table to your QMS procedures / instructions, DHF / DMR / DHR and 510(k) templates. Needless to say, it will take a hell lot of man-hours to implement it seriously.</p>
<h4>Secure Product Development Framework (SPDF)</h4>
<p>The keyword of this guidance is: SPDF. The FDA gives this definition: <em>An SPDF is a set of processes that reduce the number and severity of vulnerabilities in products throughout the device lifecycle.</em><br />
In short, a manufacturer has to integrate cybersecurity provisions in the QMS procedures covering the software lifecycle. E.g.: Software risk management, design, V&V, installation, support, maintenance, decommission. The SPDF also spreads its branches to customer complaints, and CAPA. The procedures generate cybersecurity documentation output recorded in the DHF, DMR, and DHR, as well as premarket submissions like section 16 of a 510(k) file.<br />
To do so, the FDA relies on the National Institute of Standards and Technology Framework Cybersecurity Framework (NIST CSF) and the Medical Device and Health IT Joint Security Plan (JSP). Both have the virtue to be freely accessible. This way, the FDA respects the basic cybersecurity principle to have free access to relevant cybersecurity information.</p>
<h5>Security risk management process</h5>
<p>Among all topics addressed by the guidance, the security risk management is probably the first one to implement. Relying of the AAMI TIR 57, the FDA recommends to conduct and document a security risk management file separated from the safety risk management file. Note that documents shall be separated, but not the safety and security risk management processes. Those two processes interact one another.<br />
<br />
There are also quite good discussions about Security Assessment of Unresolved Anomalies and TPLC Security Risk Management. E.g.: the magnitude of effects of unresolved anomalies in terms of security can be far higher than safety.</p>
<h5>Security architecture</h5>
<p>The draft guidance is prescriptive about what it expects in terms of documentation about security architecture. It recommends to document 4 specific types of architectural views:</p>
<ul>
<li>Global System View</li>
<li>Multi-Patient Harm View;</li>
<li>Updateability/Patchability View; and</li>
<li>Security Use Case View(s)</li>
</ul>
<p>It also recommends to document traceability between the elements found in these views and security requirements.<br />
<br />
That confirms the <a href="https://blog.cm-dm.com/post/2021/12/06/FDA-Draft-Guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions">exit of Low Level of Concern / IEC 62034 class A documentation</a>.</p>
<h4>Link with European harmonized standards.</h4>
<p>Fortunately, the guidance also quotes the ISA 62443-4-1 standard as a possible framework to implement cybersecurity provisions throughout the SW life cycle.</p>
<h5>IEC 81001-5-1</h5>
<p>This allows us to bridge this draft guidance with <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 future European Harmonized standard: IEC 81001-5-1</a>. That standard actually stems from ISA 62443-4-1 and its structure is similar to the one of IEC 62304. Thus, IEC 81001-5-1 defines a SPDF over the software lifecycle framework of IEC 62304.<br />
That makes possible to have procedures encompassing both this FDA guidance and the EU harmonized standard at the same time. Especially, the section V.C Cybersecurity Testing defines a testing strategy very similar to IEC 81001-5-1.<br />
But some gaps remain. The draft guidance goes further than the standard on some subjects like architecture documentation, and vice-versa in IEC 81001-5-1, like secure software documentation acceptance criteria and reviews.</p>
<h5>IEC 60601-4-5</h5>
<p>The draft guidance doesn’t quote neither ISA 62443-4-2, nor IEC 60601-4-5. They’re not recognized standards. So that’s not surprising.<br />
Alternatively, the draft guidance contains a section V.B.1 <em>Implementation of security controls</em> and Appendix 1 on <em>Security Control Categories and Associated Recommendations</em>. We retrieve in this appendix a content roughly similar to ISA 62443-4-2. But in a more condensed manner. This content is also focused on medical devices, whereas the ISA standard comes from another industry.<br />
<br />
On the labeling side, IEC 60601-4-5 defines in clause 6 <em>Technical Description</em> a long list of information to communicate to users. The draft guidance does the same in the section A Labeling Recommendations for Devices with Cybersecurity Risk. Beware of the possible gaps between the two.<br />
<br />
We can wonder why neither ISA 62443-4-2, nor IEC 60601-4-5 are recognized standards. It's true that these two standards are applicable to medical devices with some drawbacks:</p>
<ul>
<li>IEC 60601-4-5 cannot be used without ISA 62443-4-2,</li>
<li>ISA 62443-4-2 itself references ISA 62443-3-3, the latter is needed to fully understand some security requirements,</li>
<li>The wording of ISA 62443-4-2 is oriented to industrial systems. This makes necessary a clumsy interpretation of its requirements body text to apply them to medical devices.</li>
</ul>
<p>I don't have the true reason with the FDA doesn't recognize these two standards. But these drawbacks are enough to explain the situation.</p>
<h4>And UL 2900-x?</h4>
<p>UL 2900-x are recognized standards. However, the draft guidance quotes them only in a footnote: <em>The following standards may partially meet the security testing recommendations in ANSI/UL 2900 Software Cybersecurity for Network-Connectable Products (...)</em>.<br />
The draft guidance just reserves a small folding seat to UL 2900. ISA 62443-4-1 takes the lion's share, quoted twice in the guidance. Especially in introduction to section V: <em>Frameworks from other sectors may also comply with the QSR, like the framework provided in ANSI/ISA 62443-4-1 (...)</em>.<br />
UL 2900 was in 2017 the first recognized standard about cybersecurity. It has been the reference about cybersecurity since them. The draft guidance changes the situation and fosters more the use of ISA 62443-4-1. UL 2900 is reduced to testing recommendations.<br />
<br /></p>
<h4>Conclusion</h4>
<p>Recognized standards or not recognized standards, this draft guidance open the Pandora's box to an SPDF. It will require a hell lot of work to be implemented in a correct manner. Prepare your Secure Software Design procedure, your Security Risk Management procedure, and all their siblings!</p>https://blog.cm-dm.com/post/2022/06/10/Cybersecurity-in-Medical-Devices%3A-Quality-System-Considerations-and-Content-of-Premarket-Submission#comment-formhttps://blog.cm-dm.com/feed/atom/comments/260