Software in Medical Devices, by MD101 Consulting - Tag - FDABlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearTemplates: 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/280Final 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/277IEC 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/271Cybersecurity 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/260FDA Draft Guidance on Content of Premarket Submissions for Device Software Functionsurn:md5:b150005508f5e0415b24aeec891a380a2021-12-06T13:32:00+01:002021-12-06T13:32:00+01:00MitchRegulationsClassificationFDAGuidanceSaMD<p>Great news! The FDA announced their list of new or revised guidances for 2022. Software is going to be privileged, with 6 guidances on Clinical Decision Support software, SaMD risk categorization, cybersecurity, QMS SW, and Artificial Intelligence / Machine Learning. The draft guidance <em>Content of Premarket Submissions for Device Software Functions</em> opens the ball in 2021. This draft guidance will supersede the guidance titled <em>Content of Premarket Submissions for Software Contained in Medical Device</em>, when it is published in its final version. This little change in the title is a sign of the times.</p> <p>The title matters: the FDA regulates SaMD, SiMD, unifying them under the umbrella of <em>Device Software Functions</em>. We already saw that in the <a href="https://blog.cm-dm.com/post/2020/09/04/FDA-Guidance-on-Multiple-Function-Device-Products"><em>Multiple Function Device Products: Policy and Considerations</em> guidance</a>. The title and the content of this draft guidance is consistent with the content of that other guidance. Especially, the appendix B at the end of the draft guidance give quite good examples on how to document health software with device software functions.<br />
This draft guidance is also referencing all the other guidances linked to software in section II <em>Background</em>. It is actually a good starting point to know what the FDA expects from manufacturers about software.</p>
<h4>Definition of Serious Injury</h4>
<p>Let's do a focus point on the definition of <em>Serious Injury</em> given by the FDA. It is simply the definition found in the 21 CFR 803.3 (w). It is equal to the one in the current guidance, also quoting the 21 CFR 803 (to be specific, an old version of 21 CFR 803). No change there, and there is no discrepancy compared to the definition found in IEC 62304. That's important to underline it, before reading the rest of the document, with the goal in mind to apply this guidance and IEC 62304 seamlessly.</p>
<h4>Software validation</h4>
<p>A note also on <em>software validation</em> definition. The one in the draft guidance is undoubtedly better than the one found in IEC 82304-1: <em>confirmation, through the provision of objective evidence, that the requirements for a specific INTENDED USE or application have been fulfilled</em>. Advantage: it is short; drawback: it is laconic. The definition found in the draft guidance draws the link with design controls, and gives cues on how to perform that software validation.<br />
Reminder: there's no such definition in IEC 62304, which limits its scope to software verification, not validation.</p>
<h4>Documentation level</h4>
<p>Here we are in the interesting part of this draft guidance!<br />
<br />
The three levels of concern are whipped out, and replaced by a twofold documentation level:</p>
<ul>
<li>Basic Documentation Level (BDL) and,</li>
<li>Enhanced Documentation Level (EDL).</li>
</ul>
<p>The criteria to evaluate whether a software is in EDL have evolved compared to those present in the determination of the Major Level of Concern of the current guidance. Fortunately, the criterion <em>accessory to a device of major level of concern</em> disappeared; a criterion difficult to apply to SaMD, which raised more questions than it gave answers!<br />
But the other criteria are similar in both versions of the guidance, with an effort to make them more articulate in the draft guidance.<br />
<br />
Thus, we have the following strict correspondance between Level of Concern and Documentation Level:</p>
<ul>
<li>Major Level of Concern --> Enhanced Documentation Level,</li>
<li>Moderate or Minor Level of Concern --> Basic Documentation Level.</li>
</ul>
<p><br />
Likewise, since the definition Serious Injury present in the IEC 62304 is equivalent to the one in the 21 CFR 803.3(w) section, we have a almost strict correspondance between Software Safety Class and Documentation Level:</p>
<ul>
<li>Class C --> Enhanced Documentation Level,</li>
<li>Class B or A --> Basic Documentation Level.</li>
</ul>
<p>Provided that the software intended use matches factor #4 only. A quite common situation, there aren't so many software in combination products, or blood bank products, or class III devices, compared to all types of software placed on the market.</p>
<h4>Risk Control Measures</h4>
<p>One ambiguity remains in the factor #4 present in the draft guidance. It's written: <em>These risk(s) should be assessed prior to implementation of risk control measures</em>. It would be better either to rephrase it or to explain in the text under the list of factors that the risks are assessed prior to implementation of risk control measures in software.<br />
Removing this ambiguity would be more in line with the concept of essential performance present in IEC 60601-1. A software doesn't contribute to the essential performance when a hardware risk control measure is present to prevent a hazardous situation coming from a software failure. Likewise, we have the same approach in the chart of IEC 62304 Amd1:2015 clause 4.3, where we evaluate the acceptability of risks, after application on risk control measures external to software.<br />
For the record, the same ambiguity is present in the currently applicable FDA guidance.<br /></p>
<h4>Probable risk</h4>
<p>The term <em>probable</em> is used in factor #4: <em>A failure or latent flaw of the device software function(s) could present a <strong>probable</strong> risk of death or serious injury</em>. Then, under the definitions of factors, the guidance adds: <em>The term ‘probable’ in factor #4 above is intended to capture reasonably foreseeable software and hardware risks associated with the device</em>.<br />
That's also somewhat aligned with the chart of IEC 62304 Amd1:2015 clause 4.3, which considers the acceptability of risks. A risk that isn't reasonably foreseeable will leave the software in basic documentation level. Such a risk is usually acceptable (or tolerable) according to a risk management plan, thus leaving the software in class A, according to IEC 62304.</p>
<h4>Discussion on the software documentation level</h4>
<p>Changing the number of levels, either Level of Concern, or software safety class, isn't a new debate. The options being regularly debated are:</p>
<ul>
<li>4 levels, aligned with the <a href="http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf">IMDRF Possible Framework for SaMD risk categorization</a>, and the good old <a href="http://www.imdrf.org/docs/ghtf/final/sg1/technical-docs/ghtf-sg1-n15-2006-guidance-classification-060627.pdf">GHTF Principles of Medical Devices Classification</a>,</li>
<li>3 levels, staying in the current practice. We don't like when things change,</li>
<li>2 levels, like in this draft guidance. Exit class A / Low Level of Concern,</li>
<li>No level, every software is documented like class C / Major Level of Concern!</li>
</ul>
<p>Some discussions popped out on some social networks, to propose that all software shall be documented like class C software. I don't subscribe to this. This is flawed for two reasons. First objective reason: this is not in line with a risk-based approach, obviously present in the regulatory classes. Second subjective reason: I think this is a bias of people who don’t have enough experience in software development.<br />
<br />
Four levels raises the question on the amount of documentation to provide for each level. IMDRF levels I to III could be aligned with IEC 62304 classes A to C. IMDRF level IV would be a kind of IEC 62304 class C+ (or C++ :-)). That fourth level would require a very thoroughly documented design with a clear demonstration of safety and performance, with full horizontal and vertical traceability, like safety assurance cases. This is by the way what the FDA recommends for <a href="https://www.fda.gov/medical-devices/general-hospital-devices-and-supplies/infusion-pumps">infusion pumps</a>. Neither IEC 62304, nor current FDA guidances (excepted for infusion pumps) require explicitly such level of scrutiny in the design documentation for highly critical software.<br />
<br />
Two levels have the virtue of simplification. Keeping the equivalent of classes B and C, and removing class A isn't a wrong choice (I didn't write this is the right one). The cybersecurity requirements advocate for the removal of class A. Applying UL 2900-x or IEC 81001-5-1 standards require to document the architectural design, and at least the detailed design of interfaces subject to cyber hazards. Likewise, the advent of multiple function devices also advocates for some architectural documentation, which goes beyond pure class A documentation, to understand where the medical device functions reside.<br />
<br />
I'd personally be in favor of having 4 levels, aligned with the IMDRF, and aligned with the regulatory classes of the majority of regulations throughout the world. However, this solution is obviously not aligned with the US regulatory classes, and the twofold choice of this draft guidance. By the way, the <a href="https://en.wikipedia.org/wiki/DO-178C">DO-178C</a> defines 5 levels, but this is another industry.</p>
<h4>Differences with IEC 62304</h4>
<p>Even if the FDA wants to set their own standards, manufacturers submitting their devices elsewhere than the US, have to rely on the IEC 62304 at the same time. We can try to find the differences between the clause 5 of IEC 62304 and the section V of the draft guidance.</p>
<h5>Documentation level evaluation</h5>
<p>Even though the criteria differ, the concepts are similar and shall be documented.</p>
<h5>Software description</h5>
<p>This looks more like what we have in IEC 82304-1 clause 4. However, the FDA expects this both for SaMD and for SiMD. IEC 82304-1 is not applicable to the latter.</p>
<h5>System and Software Architecture Diagram</h5>
<p>Similar to clause 5.3 of IEC 62304, the wording of the draft guidance is a bit different. It uses the wording <em>module</em> and <em>unit</em>, whereas IEC 62304 uses <em>software item</em> and <em>software unit</em>. These are somewhat similar concepts, with the notable difference that the FDA includes hardware components in these terms. Moreover, modules are generally considered of bigger size than software items. A software item can be a module, but a module-software-item can be decomposed in smaller software items.<br />
However, it is possible to document the architecture the way it is recommended, like in the examples at the end of the draft guidance. Such diagrams can be used both for FDA submissions and IEC 62304 architectural decomposition.</p>
<h5>Risk management file</h5>
<p>Here, nothing to say, apply ISO 14971 and IEC 62304 clause 7. You will be in line with what is required by this long section of the draft guidance. It should be noted that the draft guidance quotes the IMDRF SaMD risk categorization for identifying and evaluating software risks.</p>
<h5>Software requirements specifications</h5>
<p>Not surprising, the draft guidance contains recommendations similar to IEC 62304 clause 5.2. However, the FDA goes beyond the standard, by suggesting the use of <em>well elaborated stories, use cases, textual descriptions, screen mockups, and control flows</em>.</p>
<h5>Software Design Specification</h5>
<p>Software Design specification is required for Enhanced Documentation Level only. We can draw a link with IEC 62304 clause 5.4, where the inner content of software units shall be documented in class C. It is worth noting (funny to note) that the FDA recommends to document SDS prospectively and not retrospectively! Software development teams will appreciate this recommendation.</p>
<h5>Software development and maintenance practices</h5>
<p>That's... interesting that the FDA relies on the IEC 62304 for this. Whereas the guidance completely overrides the standard, it bounces back to the standard on development and maintenance plans. But why not. A premarket submission is a review of the device design output, not the design history file. The design process is reviewed during FDA inspections.<br />
That’s also why the order of paragraphs in section V is different from the subclauses 5.x of IEC 62304. This guidance is made to let the FDA understand how the software design allows to achieve the claimed safety and performance. The FDA puts the emphasis on readability throughout the text of the draft guidance.</p>
<h5>Software testing as part of Verification and Validation</h5>
<p>There we retrieve the requirements of clauses 5.5 to 5.7 of IEC 62304 in class B and class C on software testing. However, it is worth noting that the draft guidance has no equivalent of IEC 62304 clause 5.5.4. That was already the case in the current guidance.</p>
<h5>Revision level history</h5>
<p>The revision level history is present in an indirect manner in IEC 62304, through clauses 8.3 and 5.8. Here the FDA emphasizes that when iterative development methods are used, <em>information on any changed software requirements and how they continue to meet the system requirements or design inputs should be provided</em>. Not a game changer, but not present in IEC 6204.</p>
<h5>Unresolved anomalies</h5>
<p>There we retrieve the equivalent of IEC 62304 clause 9, to be able to provide such design output. Particularly, <em>FDA suggests ranking anomalies based on risk to patient and/or operator (user)</em>, something required by the problem resolution process.</p>
<h4>COTS - SOUP</h4>
<p>Last thing, SOUP! The FDA just say they're going to update their guidance on COTS: Off-The-Shelf Software Use in Medical Devices. From an IEC 62304 perspective, this guidance requires additional documentation, compared to what is required in the standard. The guidance will remain applicable. So, not a game changer.<br />
<br />
<br /></p>
<h4>Conclusion</h4>
<p>This guidance is a draft guidance. Things may be reverted back to three levels of concern, if lots of people post negative comments to the FDA. But this is wishful thinking. The guidance is well thought out. It looks like the FDA spent some energy to create this twofold documentation system. Add multiple function devices plus cybersecurity, and there is very little chance that the FDA fundamentally changes its content.<br />
<br />
IEC 62304 committee, forewarned is forearmed.</p>https://blog.cm-dm.com/post/2021/12/06/FDA-Draft-Guidance-on-Content-of-Premarket-Submissions-for-Device-Software-Functions#comment-formhttps://blog.cm-dm.com/feed/atom/comments/252FDA about to exempt fifteen software devices from 510k clearanceurn:md5:59274f123c6bcbefaa5b067cc9fec5162021-02-05T12:40:00+01:002021-04-17T14:44:24+02:00MitchRegulationsFDASaMD<p>A <a href="https://www.federalregister.gov/documents/2021/01/15/2021-00787/making-permanent-regulatory-flexibilities-provided-during-the-covid-19-public-health-emergency-by#p-64">Notice was published in the Federal Register the 15th January 2021</a>, about the exemption of a long list of medical devices from premarket notification. This list, found in table 6 of the Notice, contains 83 class II devices.<br />
Yet, we have to wait for 120 days, to see this Notice published with the list in its final version.</p> <p><strong>EDIT 2021-04-17: <a href="https://www.federalregister.gov/documents/2021/04/16/2021-07760/making-permanent-regulatory-flexibilities-provided-during-the-covid-19-public-health-emergency-by">the notice has been withdrawn</a>, and my comments below are just irrelevant gibberish. There's no free lunch.</strong><br />
<br />
The main reason of these exemptions is the absence of serious adverse events reported the last 10 years (from 1st November 2010 to 30th November 2020) on these device types.<br />
<br />
Amongst these 83 devices, the word "software" appears 15 times. Here is the list:</p>
<ul>
<li>Electrocardiograph for OTC use,</li>
<li>Normalizing Quantitative Electroencephalograph Software,</li>
<li>Digital Pathology Image Viewing And Management Software,</li>
<li>Computer-Assisted Diagnostic Software For Lesions Suspicious For Cancer,</li>
<li>Radiological Computer-Assisted Triage And Notification Software,</li>
<li>Radiological Computer Assisted Detection/Diagnosis Software For Fracture,</li>
<li>Radiological Computer Assisted Detection/Diagnosis Software For Lesions Suspicious For Cancer,</li>
<li>Radiological Computer-Assisted Prioritization Software For Lesions,</li>
<li>X-Ray Angiographic Imaging Based Coronary Vascular Simulation Software Device,</li>
<li>Automated Radiological Image Processing Software,</li>
<li>Source Localization Software For Electroencephalograph Or Magnetoencephalograph,</li>
<li>Automatic Event Detection Software For Polysomnograph With Electroencephalograph</li>
<li>Automatic Event Detection Software For Full-Montage Electroencephalograph,</li>
<li>Burst Suppression Detection Software For Electroencephalograph,</li>
<li>Infusion Safety Management Software.</li>
</ul>
<p>Some of them have striking words, like "Detection", "Diagnosis", "Automated", and "Safety".<br />
<br />
If we take one example (not chosen at random :-) <em>Radiological Computer Assisted Detection/Diagnosis Software For Fracture</em>, the <a href="https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/classification.cfm?id=QBS">product code is QBS</a>, and the section in 21 CFR is 892.2090. We're in the Radiology software devices regulated by 892.2050 to 892.2090 sections of the 21 CFR.<br />
We can repeat the same exercise with "Radiological Computer Assisted Detection/diagnosis Software For Lesions Suspicious For Cancer", product code QDQ and 892.2090, and so on.<br />
Yet, the PACS viewer, product code LLZ, remains in class II not exempted. There appears a pattern: medical imaging software used for primary diagnosis are not exempted; medical imaging delivering information of secondary importance are exempted.<br />
<br />
The first thought that comes to mind is that the FDA is probably overwhelmed by too many 510k submissions on such software of secondary importance (no offense, manufacturers). And this kind of software blossomed with literally dozens to software making use of artificial intelligence to detect patterns in medical images.<br />
<br />
Likewise, we have the <em>Infusion Safety Management Software</em>, product code <a href="https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpcd/classification.cfm?id=2799">PHC</a>, used to preprogram infusion pumps, and other functions such as alarm transmission. The exemptions go way beyond medical imaging!<br />
<br />
These software will never harm anybody, thanks to the fact that:</p>
<ul>
<li>The kind of output data is only an aid to ease or speed-up the patient care,</li>
<li>There is always a medical professional between the computer and the patient, catching erroneous results.</li>
</ul>
<p><br />
Manufacturers of class II exempt software, enjoy!<br /></p>
<h4>On the European side</h4>
<p>As long as we have the deadly rule 11 for standalone software, with this wording: <em>Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa</em>, there's no chance that software like the ones mentioned above can be placed in class I. Even if they give information of secondary importance, that information is still in the category <em>Inform clinical management</em>, placed in class IIa in the section 11 Annex III of the MDCG 2019-11.<br />
About Infusion Safety Management Software, they "drive or influence" perfusion pumps, and are in the same class.<br />
<br />
Yes, manufacturers of standalone software equivalent to the exempted list, your business is still subject to the European regulatory hazard sparked by Rule 11. With this list of 510k exempted devices, the FDA gives you another reason to begin with the US market.</p>https://blog.cm-dm.com/post/2021/02/05/FDA-about-to-exempt-fifteen-software-devices-from-510k#comment-formhttps://blog.cm-dm.com/feed/atom/comments/242FDA Guidance on Multiple Function Device Productsurn:md5:e6413e10593cf2388af05f019b73fcea2020-09-04T14:34:00+02:002020-09-06T08:39:05+02:00MitchRegulationsFDAGuidanceIEC 62304mobile medical apprisk managementsoftware failure<p>The FDA published in July the final version of the <a href="https://www.fda.gov/regulatory-information/search-fda-guidance-documents/multiple-function-device-products-policy-and-considerations">Guidance on Multiple Function Device Products</a>. Despite the absence of the word "software" in the title, it addresses at first software medical devices. It also addresses hardware devices, but we will focus on software in this post.</p> <p>Typical examples of multiple function device are platforms with software modules, within which some don't qualify as medical devices or are 510k exempted:
<img src="https://blog.cm-dm.com/public/27-FDA-Multiple-Function-Device/.sw-platform-multiple-function-device_m.png" alt="sw-platform-multiple-function-device.png, Aug 2020" style="display:table; margin:0 auto;" title="sw-platform-multiple-function-device.png, Aug 2020" />
<br />
An even simpler case is a mobile app with some MD functions and some non-MD functions:
<img src="https://blog.cm-dm.com/public/27-FDA-Multiple-Function-Device/.mobile-app-multiple-function-device_m.png" alt="mobile-app-multiple-function-device.png, Aug 2020" style="display:table; margin:0 auto;" title="mobile-app-multiple-function-device.png, Aug 2020" />
<br /></p>
<h4>Impact of 510k exempt or non-MD</h4>
<p>Qualifying software as a medical device is not the purpose of this guidance. <a href="https://blog.cm-dm.com/pages/The-essential-list-of-guidances-for-software-medical-devices#FDA">Other FDA guidance documents</a> are there to answer this absolutely not simple question.<br />
This guidance focuses on the safety and effectiveness of MD functions / modules when they are coupled with non-MD or 510k exempt functions. Practically speaking, the FDA wants to now the impact of these functions on the MD function under review:</p>
<ul>
<li>Your MD function is coupled with other software,</li>
<li>These other software may fail,</li>
<li>As a side effect your MD function may also fail,</li>
<li>The consequence of this failure on the safety and effectiveness has to be addressed.</li>
</ul>
<h4>Other function</h4>
<p>The guidance defines the term "other function" as functions not regulated by the FDA, or not subject to premarket review (i.e. 510k exempt). The FDA also include General Purpose Computing Platform in this definition.<br />
<em>General Purpose Computing Platform</em>: Rings a bell! It sound like SOUP from IEC 62304 or OTSS from other FDA guidance. This is true, this General Purpose Computing Platform can be a platform developed by 3rd party software editor, it can also be developed by the manufacturer without applying any appropriate state-of-the-art development process (i.e. IEC 62304 or FDA guidance on General Principles on Software Validation), namely the definition of SOUP.<br />
<br />
But it can be more than that: this General Purpose Computing Platform can be a class I medical device 510k exempt, developed with appropriate standards according to design controls (820.30) by the manufacturer.<br />
This could be the case in example 1, where the manufacturer could claim that:</p>
<ul>
<li>either the software platform is a MDDS or a Medical Image Storage device not regulated by the FDA,</li>
<li>or it is a class I accessory to the MD module providing low-risk functions like data merging or alerts (not alarms!).</li>
</ul>
<p>So the "other function" is software not subject to a premarket review.</p>
<h4>Negative impact or positive impact of the other function.</h4>
<p>The main message of this guidance is: the FDA wants the manufacturer to bring evidence that the other functions don't have a negative impact on the MD function under review. Taking a risk assessment wording, the negative impact is a sequence of events involving the other function that shall not be assessed as an unacceptable risk of software failure.<br />
<br />
The second part of this main message is: if there is a positive impact on the MD function (e.g. the platform manages alerts), it shall be documented in the design control records. Finding positive impacts can be far-fetched with frameworks or OS'es. Usually, you chose a general-purpose computing platform because the technology is made like that (e.g. Android or iOS). Full stop. No positive impact there.<br />
So if there is no obvious positive impact, don't waste your time seeking desperately for that one. If you have a positive impact, lucky you!<br />
<br />
<em>Note to EU manufacturers: don't mix that positive impact with the benefit of MD found in EU MDR. Please, don't cross the streams. It would be bad.</em></p>
<h5>Is there an impact</h5>
<p>The FDA proposes a flowchart as an help to assess the impact of other function. Though simple and not that much helpful, this diagram has the virtue to display the assessment process in a graphical manner.<br />
More interesting are the examples of questions to ask when assessing the impact. They give cues to determine if and how the MD software exchanges data or shares resources with the other function. These questions are very technical and need to document the architecture of the MD software with its interfaces, like IEC 62304 clause 5.3.2.</p>
<h5>What is the impact - A taste of SOUP</h5>
<p>The guidance continues with recommendations on how to assess the impact when there is one. These recommendations look quite similar to what we do when we assess the impact of SOUP, like IEC 62304 clause 7.1.2.c. The advantage of the guidance is to give a list of questions to clarify the impact assessment. These questions can be advantageously used to identify and evaluate risk arising from SOUP.<br />
Let's do a little exercise to show the analogy between other function and SOUP: replace "other function" by "SOUP":<br />
E.g. #1 in section VI.B.1 bullet 1:</p>
<blockquote><p>The “SOUP” introduces a new hazardous situation or a new cause of an existing hazardous situation that is not otherwise present in the device function-under-review</p></blockquote>
<p>E.g. #2 in section VI.B.2 bullet 1:</p>
<blockquote><p>The performance or clinical functionality of the device function-under-review depends on the “SOUP” for the device function-under-review to perform as specified.</p></blockquote>
<p>Warning: it doesn't mean that "other functions" shall be treated as SOUP. It means that the process of risk assessment is similar. The big difference between the other function and SOUP is when the other function is a class I device not subject to premarket review. In this case this is not a SOUP, hence subject to design controls. But take note that the last paragraph about general-purpose computing platform before section VII looks very typical of SOUP risk assessment. More, when there is no evidence of design controls, this general-purpose computing platform will be treated as SOUP in IEC 62304 processes.<br /></p>
<h5>Cybersecurity</h5>
<p>Ah, there it is! The cybersecurity risk assessment shall include the impacts of cyber risks arising from the other function. No surprise there, if a cyber risk can have a consequence on the patient, it shall be addressed in the impact assessment.</p>
<h4>Separation of design and implementation</h4>
<p>This is the second message of this guidance. Though separation of design is not so much discussed, compared to the negative / positive impact, the former is as important as the latter. Here we retrieve the good old principles of architectural segregation found in IEC 62304.<br />
Our little exercise allows to show once again the analogy: replace medical "device function" by "class B (or class C) software" and "other function" by "class A software".<br />
<br />
E.g. #1 in the sentence found in section V.A</p>
<blockquote><p>The <em>class B function</em> should, to the extent possible, be separated from <em>class A function</em> in its design and implementation (e.g., logical separation, architectural separation, code, and data partitioning).</p></blockquote>
<p>E.g. #2 in the sentence found in section VII.D</p>
<blockquote><p>an architecture diagram may demonstrate the independence of the <em>class B function</em> from the <em>class A function</em>, or design documents may demonstrate the use of shared resources</p></blockquote>
<p>It also works with the impact assessment with the sentence found in section VII.E</p>
<blockquote><p>The device hazard analysis (...) for the <em>class B software</em> should include the results of a risk-based assessment of any potential adverse impact (...) of the <em>class A software</em> to the safety or effectiveness of the device function-under-review.</p></blockquote>
<p>Thus, if your software is of major level of concern (or IEC 62304 Class C), be prepared to demonstrate in your premarket submission documentation how your MD software is separated for other functions. Namely by hardware segregation or by fully documented logical segregation with common failure modes analysed in the risk assessment report.<br />
As a consequence, it won't work with web applications with intertwined services or monolithic mobile apps. Fortunately, a not so clear logical segregation may work with MD software in moderate level of concern (or IEC 62304 Class B), provided that other function failure doesn't result in an unacceptable risk.</p>
<h4>Documentation requirements</h4>
<p>In case of negative or positive impact, you have to add documents on the other function in the premarket submission, to begin with indications for use, device description and specific labelling for the other function. Then, practically speaking, you have to rely on the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. It means that you have to assign a level of concern to the other function. Then, the guidance doesn't require to bring all documents according to this level of concern for the other function. Only a subset is required, but their content shall be in line with the guidance on premarket submission for devices with software.</p>
<h4>Having all ducks aligned</h4>
<p>MD software under review, other function, OTSS, SOUP... Delineating the software components subject to premarket review, the other function, and combining that with OTSS/SOUP of IEC 62304 can be a challenging task!
Some cases will be simple:</p>
<ul>
<li>A post-processing medical imaging software exchanges images with a PACS server (the other function),</li>
<li>Software analyzing genetic data exchanges HL7 streams with a LIMS (the other function).</li>
</ul>
<p>Some other case may be less simple:</p>
<ul>
<li>A module raising alerts to check for potential adverse drug events, based on patient data, is included in a larger Computerized physician order entry (CPOE, other function),</li>
<li>A legacy health information system (HIS, other function) contains some functions qualified as medical devices, intertwined in the system.</li>
</ul>
<p>Some cases may be a nightmare:<br />
When the other function contains the mitigation action of an unacceptable risk. What should we do? Leave it as other function? Include it in the software under review? This will be a case-by-case answer.</p>
<h4>Conclusion</h4>
<p>It is quite practical for manufacturers to split their software platform in MD software and other function, allowing to reduce the regulatory burden. This guidance puts an end to the situation where manufacturers legitimately exclude from their submission software not subject to premarket review, leaving blind spots in the submission. And blind spots are the reason for countless questions from the FDA!<br />
By requiring to document in their submission the pedigree of other functions, the FDA ceases to be blind and will be able to assess in a more straightforward way the MD software integrated in its technical environment. There is a drawback for manufacturers: they are forced to document the architecture and the risk assessment of the other function in the premarket submission. <br />
<br />
<br />
<br />
<br />
<ins>1st EU MDR oriented remark</ins>: In the absence of such guidance for the EU MDR, make use of the principles of the FDA guidance when you have a part of your software not qualified as SaMD per MDCG 2019-11. It is a way to answer to general requirements 14.2.d, 14.5, 17.3, and 23.4.ab.<br />
<br />
<ins>2nd EU MDR totally grumpy and non-constructive remark</ins>: don't expect any equivalent guidance from EU MDCG for a long time. FDA is the horizon of other authorities for software, as usual.</p>https://blog.cm-dm.com/post/2020/09/04/FDA-Guidance-on-Multiple-Function-Device-Products#comment-formhttps://blog.cm-dm.com/feed/atom/comments/238Cybersecurity - Draft guidances from FDA and Health Canadaurn:md5:15090212dca076a23d5e68ce72b9d1dd2019-01-24T12:50:00+01:002019-01-28T18:47:21+01:00MitchRegulationsCybersecurityFDAGuidance<p>The US FDA published in October 2018 a new draft version of its <a href="https://www.fda.gov/MedicalDevices/DigitalHealth/ucm373213.htm">guidance on the content of premarket submissions for management of cybersecurity in medical devices</a>. Two months later, Health Canada published in December 2018 a <a href="https://www.canada.ca/en/health-canada/services/drugs-health-products/public-involvement-consultations/medical-devices/consutation-premarket-cybersecurity-profile/draft-guidance-premarket-cybersecurity.html">draft guidance document on pre-market requirements for medical device cybersecurity</a>.</p> <p>We are surrounded by draft guidances!<br />
<br /></p>
<h4>US FDA Draft Guidance</h4>
<p>To refresh your memory, this guidance defines the documentation to compile about cybersecurity for a premarket submission.
The new draft guidance brings three significant changes, compared to the previous guidance of 2014:</p>
<ul>
<li>The concept of trustworthy device,</li>
<li>A categorization of software: tier 1 and tier 2,</li>
<li>A list of recommended mitigation actions by design.</li>
</ul>
<p>Like the previous approved version, this draft guidance relies on the NIST Cybersecurity Framework to manage cybersecurity:</p>
<ul>
<li>Identify, protect,</li>
<li>Detect,</li>
<li>Respond,</li>
<li>Recover.</li>
</ul>
<p>That's a good thing, as this framework is freely and globally available on the NIST website for all medical devices manufacturers around the world. Free documentation is a good option when you want to promote security and protection from criminal organizations!</p>
<h5>Trustworthy device</h5>
<p>Cybersecurity introduces lots of new concepts for people who never rubbed their skin to cybersecurity. To make a parallel with patient safety, the concept of trustworthy device (you will find the definition in the guidance) is equivalent to the concept of validated device in terms of safety and clinical performance.<br />
If a device is clinically validated, you trust it for patient management. If a device is trustworthy in the meaning of this guidance, you trust it for cybersecurity protection.</p>
<h5>Tier 1 and Tier 2 devices</h5>
<p>The really good news is the introduction of a hint of explicit risk-based approach in this guidance. It defines two categories:</p>
<ul>
<li>Tier 1: <em>Higher Cybersecurity Risk</em>,</li>
<li>Tier 2: <em>Standard Cybersecurity Risk</em>.</li>
</ul>
<p>The level of evidence to bring to the FDA, to demonstrate that your device is a trustworthy one, is higher for tier 1 (full documentation) and lower for tier 2 (rationale-based partial documentation).<br />
Thus, introducing <a href="https://blog.cm-dm.com/post/2018/10/15/Cybersecurity-Part-5-Templates">cybersecurity risk assessment</a> in your risk management process is a good idea.</p>
<h5>List of recommended mitigation actions by design</h5>
<p>The other good news is the clarification of FDA's expectations on design for cybersecurity. The guidance lists no less than 37 design measures for cybersecurity management. It is striking that these measures are numerous and precise. There is probably a will of the FDA to promote the design of secure devices by directly pointing to the relevant measures.<br />
The drawback of this list is to limit or focus on a subset of measures, drawing the attention of the reader to these measures only. (I had to find a drawback, no ?)<br />
It is also worth noting that most of the recommendations can be found in the UL 2900-1 standard (to be reviewed in a next post).</p>
<h5>Labeling recommendations</h5>
<p>To end this quick tour of this guidance, just two remarks on labeling recommendations.<br />
<br />
Information on cybersecurity have to be disclosed to end-users. This is a basic principle of cybersecurity management that you will find in other documents like ISO 2700X standard family. The FDA follows this principle in their labeling recommendations.<br />
<br />
And I can't help but finish by this last comment on Cybersecurity Bill Of Material (CBOM). CBOM is the list of all off-the shelf software that are or could become susceptible of vulnerabilities. The CBOM shall be <em>cross referenced with the National Vulnerability Database (NVD) or similar known vulnerability database</em>.<br />
Do you like IEC 62304 requirements on SOUP periodic review? Trust me, you are going to love CBOM - NVD cross-reference!!!<br />
<br /></p>
<h4>Health Canada FDA Draft Guidance</h4>
<p>Like the US FDA guidance, this guidance gives recommendations on documentation to provide with medical device licence submission.<br />
The guidance recognizes that a cybersecurity strategy shall be defined for devices incorporating software, from class I to class IV. This strategy should include:</p>
<ul>
<li><em>Secure design</em></li>
<li><em>Risk management</em></li>
<li><em>Verification and validation testing</em></li>
<li><em>Planning for continued monitoring of and response to emerging risks and threats</em></li>
</ul>
<p>Unlike the US FDA Tier 1 and 2 categories, the full Canadian guidance is applicable to all regulatory classes. however, the documentation is only reviewed by Health Canada for class III and class IV medical device licence applications. Class I a simple registration, and class II doesn't require to submit the design dossier.</p>
<h5>NIST Cybersecurity Framework</h5>
<p>Like the US FDA guidance, the Canadian guidance relies on the NIST framework for cybersecurity management. Yes, you read it right, Canada references a document available on nist<mark>.gov</mark> website.</p>
<h5>Cybersecurity measures</h5>
<p>Like the US FDA guidance, the Canadian one gives a list of design measures to envision: no less than 17 measures are found in tables 1 and 3. It is worth noting that some of these measures come from UL 2900-1, referenced by the guidance.</p>
<h5>Safety risk vs security risk</h5>
<p>This draft guidance references AAMI TIR 57. It also contains screen shots (figure 2) of AAMI TIR 57 on the relationship between safety risk management and cybersecurity risk management.<br />
The table 2 gives <em>Examples of the relationship between cybersecurity risk management and patient safety management</em>. Beware if you read this table: you have to understand that each line is a chunk of a risk management process. E.g. the line <em>Security risk with a safety impact</em> contains <em>Not applicable</em> for <em>Security Control</em>, hence the line focusses on the risk, not the control.</p>
<h5>Medical Device Licence Application</h5>
<p>All in all, the main goal of this guidance is to give recommendations on the content of a medical device licence application for class III and IV devices, also applicable to class II and class I design files. It embraces the state-of-the-art in this discipline and defines how it should be documented.</p>
<h4>UL 2900-1 and AAMI TIR 57</h4>
<p>On the normative side, the Canadian guidance references a few standards and guidances. We find <a href="https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016">AAMI TIR 57</a>. It gives very good hints on the relationship between security risk and safety risk management.<br />
We have also UL 2900-1, the one and only standard addressing cybersecurity in medical devices design, up to now. UL 2900-1 overlaps partially with the two draft guidances. All design measures found in the guidances are found in UL 2900-1. Thus UL 2900-1 sets a common ground for the design on medical devices.<br />
We will see that in the next post.<br />
BTW, IEC 62304 and ISO 14971 are also referenced. Like everyday life!</p>
<h4>Conclusion</h4>
<p>North American agencies are strengthening their expectations on cybersecurity in regulatory submissions. Health Canada is the newcomer, with their guidance copyright Her Majesty the Queen in Right of Canada. (Who is also Her Majesty the Queen of the UK!).<br />
<br />
<strong>Hey European Commission, where is your guidance to answer to General Requirements #17 and #23.ab in Annex 1 of regulation 2017/745/UE?</strong></p>https://blog.cm-dm.com/post/2019/01/24/Cybersecurity-Draft-guidances-form-FDA-and-Health-Canada#comment-formhttps://blog.cm-dm.com/feed/atom/comments/218FDA Guidance on Medical Device Accessories updatedurn:md5:b0c58ff59cf2cbe08fc040baef5e055b2018-01-19T14:15:00+01:002018-01-19T20:53:44+01:00MitchRegulationsClassificationFDAGuidanceSaMD<p>Here is a quick follow-up of the new version of the FDA Guidance titled <em>Medical Device Accessories – Describing Accessories and Classification Pathways</em>, published in December 2017. This comes a bit in parallel to the Section 3060 guidance described in the <a href="https://blog.cm-dm.com/post/2018/01/12/Consequences-of-the-21st-Century-Cures-Act-State-of-Play">previous post on the 21st Century Cures Act</a>.</p> <p>The <a href="https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types">previous version of this guidance</a> had been published in January 2017.<br />
<br />
First remark, the FDA didn't include the changes of the accessories guidance in <a href="https://blog.cm-dm.com/post/2018/01/12/Consequences-of-the-21st-Century-Cures-Act-State-of-Play">the Section 3060 guidance</a>. This is understandable, as the final version of the accessories guidance had been published in January 2017 after the 21st Century Cures Act.<br />
<br />
Second remark, the major update of the accessories guidance is the addition of a new section on <em>Accessory Classification Process</em>. Its stems from the <a href="https://www.congress.gov/bill/115th-congress/house-bill/2430">FDA Reauthorization Act of August 2017</a>, posterior to the 21st Century Cures Act. We find in this section the provisions of the section 707 of the Reauthorization Act about accessories.<br /></p>
<h4>Optional accessories</h4>
<p>One tiny change in the text of the guidance is the inclusion of optional articles in the definition of accessory.<br />
An article intended to be used with a parent medical device and labelled as optional is an accessory.</p>
<h4>Accessory classification process</h4>
<p>The main change is the addition of the section named "Accessory Classification Process".<br />
It makes the distinction between:</p>
<ul>
<li>New accessory types,</li>
<li>Existing accessory types;</li>
<li>New accessory types through the De Novo process.</li>
</ul>
<p>The purpose of the section is to explain how to request the FDA to classify an accessory parent of a device when the device is submitted in a 510k, a PMA or a De Novo process. The guidance clarifies the possibilities to put accessories in a class different from the parent device, with a risk-based approach.<br /></p>
<h4>Software As a Medical Device (SaMD) accessories</h4>
<p>For Software As a Medical Device (SaMD), this guidance doesn't change much of the regulatory landscape. The recommendations of the guidance don't change about what kind of software should be deemed an accessory.<br />
The following sentence, present <a href="https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types">in the version of January 2017 of the guidance</a>, remains in this new version:</p>
<blockquote><p>FDA intends for the risk- and regulatory control-based classification paradigm discussed in this guidance to apply to all software products that meet the definition of an accessory, including those that may also meet the definition of Software as a Medical Device (SaMD).</p></blockquote>
<p>We now know with this new version of the guidance that we have these options to classify a SaMD, which comes as an accessory to a medical device, in a class different from the parent device.</p>https://blog.cm-dm.com/post/2018/01/19/FDA-Guidance-on-Medical-Device-Accessories-updated#comment-formhttps://blog.cm-dm.com/feed/atom/comments/212Consequences of the 21st Century Cures Act - State of Playurn:md5:33e1334f4fbc66f2d39bae728d52b0532018-01-12T15:00:00+01:002018-01-14T14:29:24+01:00MitchRegulationsClassificationFDAGuidancemHealthmobile medical appPACS<p>Since the <a href="https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types">last blog post</a> on US FDA guidance on software classification, things evolved quickly with the FDA. We know where they want to go with software as medical device, but not exactly how they will implement it.<br />
Let's do a review of what has been done since the publication of the 21st Century Cures Act.</p> <h4>21st Century Cures Act in December 2016</h4>
<p>To begin, we've had the <a href="https://www.congress.gov/bill/114th-congress/house-bill/34/text#toc-H73E766CC72AC4EB8AAF36670EB540164">21st Century Cures Act</a>, with Section 3060 "Clarifying medical software regulation". This is the top-level document as it is regulation voted by the Congress in December 2016.<br />
This Act was published after guidances on <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">general wellness, mobile medical apps, and PACS and MDDS</a> had been published in 2016. They are in final status, but when you download these guidances, the first page contains now an additional cover page stating that these guidances have to be revised.<br /></p>
<h4>Guidance on Section 3060 of the 21st Century Cures Act</h4>
<p>To do so, the FDA published in December 2017 a draft guidance titled <a href="https://www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/documents/document/ucm587820.pdf">"Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act"</a>. This is a guidance on how other guidances will be revised (you follow me?). We call it <em>Section 3060 guidance</em> in this article.<br />
This guidance is organized by software functions, rather than types of platforms. This is to stress that software shall be qualified as medical device, based on its functions, not the platform. For example, the same function present in an mobile app or a web site will have the same regulatory status.<br />
<br />
The Section 3060 guidance is good news, many software functions are removed or are confirmed to be outside the scope of medical device definition. The functions below are NOT medical devices:</p>
<ul>
<li>Laboratory Information Management Software (LIMS),</li>
<li>Electronic Patient Records (EHR) management systems,</li>
<li>Patient Health Records (PHR) management systems,</li>
<li>Medical Image Storage systems, such as Radiological Information System (RIS),</li>
<li>Medical Image Communication systems, and</li>
<li>Medical Device Data Systems (MDDS),</li>
</ul>
<p>Provided that they don't offer functions in the scope of medical device definition, such as aid to diagnosis.<br />
<br />
Note also that there is a footnote on Medical Image Communication devices in the guidance. Some devices will continue to be regulated as medical devices.<br />
<br />
The Section 3060 guidance is also good news for software generating notifications and flags when a value is outside a range, like telemedicine or remote surveillance applications. Provided that these notifications don't require immediate clinical action, the FDA doesn't intend to enforce regulations.<br />
Usually, when immediate clinical action is required, such software functions are named alarms and active patient monitoring.<br />
<br />
The Section 3060 guidance is finally good news for a subset of wellness devices in the grey zone: those with functions for the management of a healthy lifestyle, while addressing chronic diseases or conditions. The FDA doesn't intend to enforce regulation on such devices either.<br />
<br /></p>
<h4>Comparison with European guidance</h4>
<p>The Section 3060 guidance contains a section on software functions for <em>transferring, storing, converting formats, displaying data and results</em>. The wording used to name these functions is close to the one used in the European guidance <a href="http://ec.europa.eu/DocsRoom/documents/17921/attachments/1/translations">MEDDEV 2.1/6 of July 2016</a>.<br />
<br />
The MEDDEV uses the terms <em>storage, archival, communication, simple search or lossless compression</em>. This is equivalent to <em>transferring, storing, converting formats</em> in the FDA guidance. The FDA uses <em>converting formats</em>, which has a broader meaning that <em>lossless compression</em> in MEDDEV guidance. This can be interpreted as: the medical device definition in European regulations exclude medical data conversion unless information is lost during conversion. <br />
For the wording <em>displaying data and results</em> present in the Section 3060 guidance, there is the same approach in the Meddev guidance: as long as software is not used for diagnosis or treatment, such as functions displaying data to a technician, to verify that data are present, it is not a medical device.<br />
<br />
Thus, we have a kind of convergence between the FDA guidance and the European guidance on qualification of software as medical device.<br />
<br /></p>
<h4>Work in progress</h4>
<p>This guidance is still work in progress. First, it is a draft guidance. Second, the guidance refers to other guidances work in progress:</p>
<ul>
<li>The draft guidance on Clinical Decision Support Software (will be the subject of a future blog post),</li>
<li>A future guidance on multi-functionality software combining medical device and non-medical device functions (<a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">there's an old post</a> on this subject),</li>
<li>A future guidance on Medical Image Communication systems.</li>
</ul>
<p><br />
<br />
<br />
The section 3060 guidance is really good news for many software editors in the field of medical data management on the one hand, and wellness or healthy lifestyle on the other hand. Even if it is a draft guidance, things shouldn't radically change in the final version. The 21st Century Cures Act doesn't give much space to interpretation.</p>https://blog.cm-dm.com/post/2018/01/12/Consequences-of-the-21st-Century-Cures-Act-State-of-Play#comment-formhttps://blog.cm-dm.com/feed/atom/comments/211Final FDA Guidance on Postmarket Management of Cybersecurity in Medical Devices - Final version releasedurn:md5:a2c6398cc0958aea47e330959db3a5202017-02-10T14:20:00+01:002017-02-11T16:32:05+01:00MitchRegulationsCybersecurityFDAGuidance<p>This article is a follow-up of the previous article on the <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">Draft guidance on Postmarket Management of Cybersecurity in Medical Devices</a>.</p> <h4>Postmarket Management of Cybersecurity in Medical Devices</h4>
<p>The FDA released the final version of this guidance in December 2016. Let's see what changes the FDA made, compared to the draft version.<br />
This guidance underwent many changes, compared to the draft version. One of the most prominent is in the scope:</p>
<blockquote><p>This guidance applies to any marketed and distributed medical device including: 1) medical devices that contain software (including firmware) or programmable logic; and 2) software that is a medical device, including mobile medical applications. In addition, this guidance applies to medical devices that are considered part of an interoperable system and to “legacy devices,” i.e., devices that are already on the market or in use.</p></blockquote>
<p>Argh! Legacy devices! Good luck...<br />
Well, this scope was updated to cover any type of medical device with software or with data transmission functions (i.e. the presence of interoperable device) and to make it as articulate as possible.</p>
<h4>Essential Clinical Performance replaced by Patient Harm</h4>
<p>In the Definitions section, the essential clinical performance disappeared and was replaced by Patient Harm.
The concept of “essential clinical performance”, which was developed in the draft guidance, was removed in the final version.<br />
The definition of patient harm is fairly long and won't be copy-pasted here. It is aligned with the definition of patient harm in ISO 14971. The guidance stresses out the risk-based assessment of cybersecurity vulnerabilities, which can lead by a sequence of events to patient harm.<br />
<br />
Interestingly, the guidance excludes vulnerabilities compromising confidential data. It only recommends to protect devices from such situations, and refers to other regulations like HIPAA.</p>
<h4>Postmarket Considerations</h4>
<p>The posmarket considerations were updated to remove to recommendation to "Clearly [define] essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk". It was replaced by (emphasis added):</p>
<blockquote><p>Using threat modeling to clearly define how to maintain <ins>safety and essential performance</ins> of a device by developing mitigations that protect, respond and recover from the cybersecurity risk.</p></blockquote>
<p>The postmarket considerations were also augmented with the recommendation:</p>
<blockquote><p>Maintaining robust software lifecycle processes that include mechanisms for:<br />
o monitoring third party software components for new vulnerabilities throughout the device’s total product lifecycle;<br />
o design verification and validation for software updates and patches that are used to remediate vulnerabilities, including those related to Off-the-shelf software<br /></p></blockquote>
<p>We retrieve somewhat here the requirements on software maintenance of section 6 of IEC 62304, read through the lens of cybersecurity management.<br />
<br />
Talking about standards, the guidance mentions that the FDA has recognized <em>ISO/IEC 30111:2013: Information Technology – Security Techniques – Vulnerability Handling Processes</em>, and <em>ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure</em>, which the FDA thinks may be useful for manufacturers.</p>
<h4>Maintaining Safety and Essential Performance</h4>
<p>In relation with the removal of essential clinical performance, the section on "Defining Essential Clinical Performance" was removed and replaced by "Maintaining Safety and Essential Performance".<br />
This section draws the link between cybersecurity risk management, safety and essential performance, threat modeling, and remediations (in cybersecurity vocabulary) / mitigation actions.</p>
<h4>Evaluation and control of risk patient harm</h4>
<p>Likewise, the section on "Evaluation of Risk to Essential Clinical Performance" was replaced by "Evaluation of Risk of Patient Harm", and the section on "Control of Risk to Essential Clinical Performance" was replaced by "Control of Risk of Patient Harm" <br />
The body text of both sections was almost left untouched, with a direct search-and-replace of essential clinical performance by patient harm. It makes their wording more in line with what QA/RA people have the habit to read: risk management addresses patient harm.<br />
These sections were also slightly updated, with recommendations on adopting a vulnerability disclosure policy, and recognizing that changes (mitigations / remediations) may have an impact on the performance of a medical device. In other words, a risk resulting of the mitigation action.</p>
<h4>Criteria for defining active participation by a manufacturer in an ISAO</h4>
<p>ISAO: Information Sharing Analysis Organization - see <a href="https://www.dhs.gov/isao-faq">ISAO FAQ</a> to better understand the purpose of these organizations.<br />.
This is a new section in the final guidance. It emphasizes the participation of manufacturers in an ISAO. Reading between the lines, this is the kind of recommendation, which can become a compulsory practice.</p>
<h4>Elements of an effective postmarket cybersecurity program</h4>
<p>To finish with this quick scan of the guidance, this appendix hasn't changed that much. We retrieve the direct search-and-replace of essential clinical performance by patient harm, along with small changes to the body text.</p>
<h4>Conclusion</h4>
<p>Compared to the draft guidance, this final guidance contains only small fixes and a clarification of management of cybersecurity vs patient harm. It doesn't reduce nor increase the burden of cybersecurity management. While reducing the burden could have been an expectation of some manufacturers, it is not feasible. Fortunately, it hasn't increased between the draft and the final guidance.<br />
<br />
With this final guidance on Postmarket Management of Cybersecurity in Medical Devices, and the <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices</a>, we now have a full set of recommendations for cybersecurity management over the medical device software lifecycle.<br />
<br />
We now have GCyP: Good Cybersecurity Practices.</p>https://blog.cm-dm.com/post/2017/02/10/FDA-Guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices-Final-version-released#comment-formhttps://blog.cm-dm.com/feed/atom/comments/202Final FDA Guidance on Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Typesurn:md5:367a465c647625aa1580d359f67c34d82017-02-10T14:19:00+01:002017-02-10T14:19:00+01:00MitchRegulationsCybersecurityFDAGuidance<p>This article is a follow-up of the article on the <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">Draft guidance on Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Types</a>.</p> <p>The FDA released the final version of two guidances in December 2016 (yes, I know, I'm a bit late. But you see, this blog is still alive...). One on the medical devices accessories and one on postmarket management of cybersecurity in medical devices.<br />
Let's see what changes the FDA made to the medical devices accessories guidance, compared to the draft version.</p>
<h4>Medical Device Accessories</h4>
<p>This guidance didn't suffer many changes. The guidance describes what the FDA considers an accessory to a medical device and how it regulates them. Accessories with risk profile different from their parent devices may fall within a different class than the device with which they're intended to be used.<br />
<br />
The truly interesting changes are those clarifying the status of software as a medical device:</p>
<blockquote><p>FDA intends for the risk- and regulatory control-based classification paradigm discussed in this guidance to apply to all software products that meet the definition of an accessory, including those that may also meet the definition of “Software as a Medical Device (SaMD).”</p></blockquote>
<p>Thus SaMD intended to support, supplement, and/or augment the performance of one or more parent devices are medical devices accessories and may fall within a class different from their parent devices. This actually opens the door to the De Novo clearance process for SaMD with no "easy" predicate.<br />
<br />
Another truly interesting change, compared to the draft version, is the examples on articles used in conjunction with the device, which do not fall in the definition of accessories:</p>
<blockquote><p>FDA would generally not consider a mobile phone that is used as a general platform for applications that include mobile medical applications that are medical devices or an off-the-shelf computer monitor used to display medical data as accessories unless they are specifically intended for use with such medical devices.</p></blockquote>
<p>Likewise:</p>
<blockquote><p>non-device-specific off-the-shelf replacement parts (e.g., batteries, USB cables, computer mouse, etc.) may be used with a medical device, but FDA does not intend to consider these products to be accessories or medical devices.</p></blockquote>
<p>These two examples are welcome. How many times newcomers in the world of SaMD have asked if these types of articles are medical devices. It's way better written in back and white.</p>
<h4>Conclusion</h4>
<p>Not so much new things compared to the draft guidance. The FDA confirms their approach on medical devices accessories, allowing to place accessories in a class different from their parent devices, and opening the gate to the De Novo process.<br />
Besides that, the examples found in this guidance about off-the-shelf hardware are very helpful to determine if such articles are accessories of software medical device or not.
<br />
<br />
The <a href="https://blog.cm-dm.com/post/2017/02/10/FDA-Guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices-Final-version-released">next article</a> is on postmarket management of cybersecurity in medical devices.</p>https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types#comment-formhttps://blog.cm-dm.com/feed/atom/comments/201Three new FDA guidancesurn:md5:aee48d749405a60b3e68a003222007722016-08-19T13:48:00+02:002016-08-19T13:48:00+02:00MitchRegulationsFDAGuidance<p>The FDA released three new FDA guidances in July 2016:</p>
<ul>
<li>Two draft guidances on Deciding When to Submit a 510(k) for a Change to an Existing Device,</li>
<li>The final guidance on General Wellness: Policy for Low Risk Devices.</li>
</ul> <h4>General Wellness Policy for Low Risk Devices guidance</h4>
<p>The General Wellness Policy for Low Risk Devices guidance was discussed in a previous article when it was in released in draft by the FDA: see article <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">When the FDA releases guidances in burst mode</a>.<br />
The final version of this guidance doesn't change the conclusions of the article. The FDA summed-up the changes between the draft and final versions <a href="http://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm515955.htm">in the web page announcing a webinar on the guidance</a>.</p>
<h4>Deciding When to Submit a 510(k) twin guidances</h4>
<p>These two draft guidances are titled:</p>
<ul>
<li>Deciding When to Submit a 510(k) for a Change to an Existing Device, and</li>
<li>Deciding When to Submit a 510(k) for a <strong>Software</strong> Change to an Existing Device.</li>
</ul>
<p>The first one is no surprise, the existing guidance also titled <em>Deciding When to Submit a 510(k) for a Change to an Existing Device</em> is almost 20 years old! This new one is intended to <a href="https://www.federalregister.gov/articles/2016/08/08/2016-18713/deciding-when-to-submit-a-510k-for-a-change-to-an-existing-device-draft-guidance-for-industry-and">clarify when a change in a legally marketed medical device would require that a manufacturer submit a premarket notification 510(k)</a>. No doubt it will be the bedside book of regulatory affairs professionals.<br />
<br />
The second one is more exciting, at least for this blog. The FDA managed the feat of creating a flowchart to assess what a major software change is. No surprise, the flowchart is closely linked to the risk-based approach.<br />
<br />
We can see how it is difficult to design a flow chart for software changes in the last box of the chart: <em>Evaluate additional software factors that may affect the decision to file</em>. This box leaves the assessment opened to any kind of situation, which could happen with software changes.<br />
Fortunately, the FDA shipped a good batch of examples in the package. These examples are here to raise alarm bells of reviewers of software changes.<br />
<br />
The only surprise is to see nothing on human factors in this guidance. Graphical User Interface is most of times a big part of software systems. But this is not inadvertence, human factors are already addressed in the "main" guidance.<br />
A way to remember that the guidance on software changes shouldn't be used alone to assess changes in a medical device.</p>https://blog.cm-dm.com/post/2016/08/19/Three-new-FDA-guidances#comment-formhttps://blog.cm-dm.com/feed/atom/comments/195New FDA draft guidance on interoperable medical devicesurn:md5:9e659c59c65fc36709e9da06e14d6ccd2016-02-05T13:45:00+01:002016-02-09T16:35:06+01:00MitchRegulationsdevelopment processFDAGuidanceIEC 62304IEC 82304risk management<p>The draft guidance about <a href="http://www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/documents/document/ucm482649.pdf">Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices</a> was published late January 2016.</p> <p>The purpose of this guidance is to mitigate any risk related to the failure or misuse of Electronic Data Interfaces (EDI) in an interoperable medical device. To do so, the guidance gives recommendations on artifacts to include in the software development process, and recommendations on how to document these artifacts in premarket submissions.</p>
<h4>Content of the guidance</h4>
<p>This guidance recommends, for each interface, to:</p>
<ul>
<li>Define the purpose of the interface,</li>
<li>Define the anticipated users,</li>
<li>Verify and Validate the interface,</li>
<li>Include information in labeling about interoperability.</li>
</ul>
<h5>Link with IEC 82304-1</h5>
<p>There is an big overlap between the artifacts found in this guidance and the artifacts found in <a href="https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software">IEC 82304-1 standard</a>. This is probably not a coincidence.<br />
IEC 82304-1 requires to:</p>
<ul>
<li>Define the purpose of health software,</li>
<li>Define use requirements of health software,</li>
<li>Mitigate risks related to health software,</li>
<li>Validate the health software,</li>
<li>Identify and create accompanying documents of health software.</li>
</ul>
<h5>Link with IEC 62304</h5>
<p>Likewise, there is an overlap with the artifacts of IEC 62304, at a lower level of details:</p>
<ul>
<li>Specify and design the interface,</li>
<li>Mitigate risks related to medical device software,</li>
<li>Verify the interface.</li>
</ul>
<h5>Link with ISO 14971</h5>
<p>The guidance recommends to consider new possible hazardous situations, that could arise form the use (or the presence, even if it isn't used) of electronic data interfaces. This guidance echoes here the two guidances about cybersecurity in medical devices (see <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">here</a> and <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">here</a>), with risks dealing with safety.<br />
Surprisingly, ISO 14971 is only quoted in a footnote, and IEC/TR 80001-1 series is not quoted either. Perhaps FDA doesn't want to impose a risk management standard in a guidance. Or this is still a draft guidance, and the final version will contain a list of standards in the bibliography section.</p>
<h4>How to apply it</h4>
<p>Just add the relevant artifacts in your existing software documentation:</p>
<ul>
<li>Purpose and anticipated users should be found in a high-level document, for example device description,</li>
<li>They should be refined in software requirement specifications, and their design documented in architectural and detailed design documents,</li>
<li>Verification and validation of interfaces should be found in verification and validation plans, tests descriptions and reports.</li>
</ul>
<p>For risk management, just consider the new hazardous situations pointed out by the FDA. A section about interoperability in the risk management plan and in the risk assessment report could be a effective means of documenting risk assessment of interfaces.</p>
<h4>Conclusion</h4>
<p>This guidance is not a revolution. It is in the stream of evolutions of expectations of regulatory authorities about medical device software. Fortunately, it doesn't put much pressure on manufacturers (unlike cybersecurity guidances). It can be applied by adding relevant artifacts to the existing software development and maintenance processes.</p>https://blog.cm-dm.com/post/2016/02/05/New-FDA-draft-guidance-on-interoperable-medical-devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/186FDA draft guidance on Postmarket Management of Cybersecurity in Medical Devicesurn:md5:f9e54a472ea62d77d2495dbb8a4fd26e2016-01-29T14:30:00+01:002016-01-29T14:30:00+01:00MitchRegulationsFDAGuidancerisk management<p>The FDA released one week ago a new <a href="http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm481968.htm">draft guidance on Postmarket Management of Cybersecurity in Medical Devices</a>.<br />
This guidance is the sister of the <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices</a> released in 2014. Both guidances address cybersecurity at different steps of software lifecycle: the 2014 guidance is about cybersecurity during design and development, the 2016 draft guidance is about cybersecurity during post-market surveillance.</p> <h4>Essential Clinical Performance</h4>
<p>Before going further, the first thing to introduce is the new concept of <em>Essential Clinical Performance</em>. This concept <em>has been developed for the purpose of this guidance</em> and most of the approach developed in the guidance stems from this concept. In a footnote, FDA makes the parallel with the concept of essential performance found in IEC 60601-1<br />
Have look at both definitions:</p>
<blockquote><p>ESSENTIAL PERFORMANCE (IEC 60601-1 ed3.1)<br />
performance of a clinical function, other than that related to BASIC SAFETY, where loss or degradation beyond the limits specified by the MANUFACTURER results in an unacceptable RISK</p></blockquote>
<blockquote><p>Essential Clinical Performance (FDA draft guidance)<br />
Essential clinical performance means performance that is necessary to achieve freedom from unacceptable clinical risk, as defined by the manufacturer. Compromise of the essential clinical performance can produce a hazardous situation that results in harm and/or may require intervention to prevent harm.</p></blockquote>
<p>If you are used to applying IEC 60601-1 3rd edition and its risk-based approach, the content of this guidance will be easier to understand.</p>
<h4>Risk-based process</h4>
<p>Based on the concept of essential clinical performance, this guidance defines the process to set-up for the postmarket management of cybersecurity. This is a risk-based process detailed in sections 5 and 6 of the guidance, which references ISO 14971.<br />
Recommendations are mostly about evaluation of risks, with new scales of severity and probability.<br />
Rather than repeating the content of the guidance, here are a few comments.</p>
<h5>Definitions</h5>
<p>In section 4 definitions, the terms "compensating controls", "cybersecurity signal", "exploit", "remediation", "threat", "threat modeling" and "vulnerability" are defined. All these terms are taken from the field of IT security. They require to have a background either in IT security or software to well understand the meaning of these terms.<br />
People working in the medical device industry are more likely to be trained to ISO 19471, and to know the meaning of terms like "hazardous phenomenon", "hazardous situation", "hazard", and "mitigation action".<br />
The guidance would be easier to understand by people who have a QA/RA background but not a technical background, if the guidance contained a section explaining the correspondence between definitions of section 4 and definitions of section 3 of ISO 14971.</p>
<h5>ISAO vs 21 CFR part 806</h5>
<p>One peculiar recommendation of this guidance is inviting manufacturer to participate to an Information Sharing Analysis Organization (ISAO). Manufacturers participating to such programme will be exempted from reporting non-serious adverse events linked to cybersecurity, per 21 CFR 806.</p>
<h5>References to NIST documents</h5>
<p>This guidance contains several references to National Institute of Standards and Technology (NIST) documents. While most are just references, the FDA recommends applying the <em>NIST Framework for Improving Critical Infrastructure Cybersecurity</em>.<br />
This framework represents a consistent effort for manufacturers.</p>
<h5>Common Vulnerability Scoring System</h5>
<p>The Common Vulnerability Scoring System (CVSS) is a method to provide a numerical score reflecting the severity of a vulnerability. Like NIST framework, applying the CVSS represents a consistent effort. However, it may be better to define a more simple scale, which is closer to the scoring habits of medical device risk management.</p>
<h5>Fifty shades of risk</h5>
<p>I can't help but commenting the figure on page 15!<br />
The text talks about binary determination of uncontrolled or controlled risk. And the figure given as an example uses an artistic greyscale. I won't bet that this figure will remain like that in the final guidance.</p>
<h4>Consequences for manufacturers</h4>
<h5>People</h5>
<p>Performing a relevant risk assessment for cybersecurity requires the help of experts in security. Manufacturers will have to recruit skilled people or consultants, and train people involved in the process, like QA/RA. At least, risk managers should understand what cybersecurity guys are doing, to ensure that the risk management process remains effective.</p>
<h5>QMS</h5>
<p>Post-market surveillance procedure and risk-management procedures are going to be touched by this guidance. A separate procedure or instruction could be necessary to manage cybersecurity signals, risk analysis vs essential clinical performance, and remediation actions or fixes.<br />
This guidance has also an impact on maintenance and problems resolution processes of IEC 62304. Depending on how they're structured, procedures implementing these processes could be impacted.</p>
<h5>Cost</h5>
<p>A lot.<br />
But what do you prefer?<br />
The known cost of cybersecurity?<br />
Or the unknown cost of a cyberattack?</p>
<h4>A guidance or a standard?</h4>
<p>The content of this guidance is new to medical device manufacturers. There is no equivalent of this guidance neither in the regulations (this guidance is an interpretation of regulations written long before cybersecurity became a concern), nor in recognized standards.<br />
If you search the Recognized Consensus Standards database for "Cybersecurity", you won't find anything. If you search for security, you will find standards, but their content doesn't cover the content of this guidance.<br />
This guidance is probably worth making a standard. Before IEC 62304, people used to apply the General Principles of Software Validation FDA guidance. Likewise, people are going to apply this guidance until a international standard is released (If it is ever released!). The content of this standard would be the same as the content of this guidance, stripped from any reference to US governmental organizations.</p>
<h4>Conclusion</h4>
<p>This guidance is still a draft but don't expect its core principles to change a lot. Thus anticipate the work necessary to implement its recommendations. It takes time to build a process like that, and you won't know whether it's effective or not until you face a real problem.</p>https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/184IEC 82304-1 - latest news about the standard on Health Softwareurn:md5:d4d8fc396a6bed4f074197a72573b42a2016-01-15T14:30:00+01:002016-06-23T20:01:45+02:00MitchStandardsCE MarkFDAIEC 62304IEC 82304ISO 14971Software Validation<p>IEC 82304-1 <em>Health software -- Part 1: General requirements for product safety</em> standard is still under development. Its status is visible on the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59543">page of ISO website, dedicated to IEC 82304-1</a>. There is even a preview of the first three pages of this draft standard.</p> <p>The last draft of IEC 82304-1 was published for comments in July 2015. It is a DIS (draft international standard) and should pass a step early 2016, by being accepted by the drafting committee. It means that a FDIS (final draft international standard) should be published in S1 2016. If it is accepted, the final version should be published by the end of 2016.</p>
<h4>What is the scope of IEC 82304-1?</h4>
<p>The scope of IEC 82304-1 intersects the scope of IEC 62304 but is not identical. It includes different types of software and different steps of the software lifecycle.
IEC 82304-1 deals with health software. The definition of health software is given in the section 3.6 of the standard:</p>
<blockquote><p>HEALTH SOFTWARE<br />
software intended to be used specifically for maintaining or improving health of individual persons, or the delivery of care.</p>
<p></p></blockquote>
<p>It is completed with the definition of health software product in the section 3.7 of the standard:</p>
<blockquote><p>HEALTH SOFTWARE PRODUCT<br />
combination of HEALTH SOFTWARE and ACCOMPANYING DOCUMENTS</p>
<p></p></blockquote>
<p>The definition of medical device software, given at section 3.x of IEC 62304-2015 is different from the definition of health software:</p>
<blockquote><p>MEDICAL DEVICE SOFTWARE<br />
SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE<br />
NOTE: This includes a MEDICAL DEVICE software product, which then is a MEDICAL DEVICE in its own right.</p>
<p></p></blockquote>
<p>The definition of SOFTWARE PRODUCT, which was used in IEC 62304:2006, was removed from IEC 62304:2015. We now have the definition of HEALTH SOFTWARE PRODUCT in IEC 82304-1. This is one proof, amongst others, to make IEC 82304-1 and IEC 62304 a two-standard team.</p>
<h4>Types of software</h4>
<h5>Types of software regarding the medical intended use</h5>
<p>The first main difference between both definitions is the intended use. IEC 62304 deals only with software with medical intended use, whereas IEC 82304-1 deals with any kind of software, which directly or indirectly has an effect on health.<br />
The scope of IEC 82304-1 is broader than the scope of IEC 62304. The following types of software are in the scope of IEC 82304-1 but not IEC 62304:</p>
<ul>
<li>Radiology Information Systems (RIS),</li>
<li>Prescription Management Systems (PMS),</li>
<li>Laboratory Information Management Systems (LIMS),</li>
<li>Mobile Apps, which are not Mobile Medical Apps, according to the <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">FDA Guidances on this subject</a>,</li>
<li>Software, which are not qualified as medical devices, according to the <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">MEDDEV 2.1/6 EU Guidance</a>.</li>
</ul>
<p>Thus IEC 82304-1 includes in its scope standalone software, which are not regulated as medical devices.</p>
<h5>Types of software regarding the platform</h5>
<p>IEC 82304-1 deals only with standalone software. Contrary to IEC 62304, it doesn't deal with software embedded in medical devices or embedded in devices with specific hardware. Only software running on a standard PC, server, tablet, or smartphone with a general purpose Operating System are in the scope of IEC 82304-1.<br />
The graphic below, borrowed from IEC 82304-1, shows the scope of this standard versus the scope of IEC 62304.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.Scope_of_IEC_82304-1_m.png" alt="Scope_of_IEC_82304-1.png" style="display:table; margin:0 auto;" title="Scope_of_IEC_82304-1.png, Dec 2015" />
Note: the rectangle in green is not present in the graphic of the standard. It was added here for clarification to show the scope of IEC 62304.</p>
<h4>Steps of the software lifecycle</h4>
<p>IEC 82304-1 deals with standalone health software product. It defines requirements at the system/product level like:</p>
<ul>
<li>Product Requirements,</li>
<li>Product Validation,</li>
<li>Product Identification and Instructions For Use,</li>
<li>Post-market activities.</li>
</ul>
<p>And it references IEC 62304:2015 for requirements at software level.<br />
IEC 82304-1 kind of takes the place of IEC 60601-1 or IEC 61010 for standalone software. IEC 60601-1 defines requirements at system level for Programmable Electric Medical Systems (PEMS), and references IEC 62304 for the software lifecycle.<br />
<br />
Likewise, IEC 82304-1 defines requirements at system level for health software systems, and references a subset of IEC 62304 for the software lifecycle.<br />
The graphic below sums up this.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.scope_of_IEC_82304-1_in_lifecycle_m.png" alt="scope_of_IEC_82304-1_in_lifecycle.png" style="display:table; margin:0 auto;" title="scope_of_IEC_82304-1_in_lifecycle.png, Dec 2015" />
Consequence: if you want to apply IEC 82304-1 to your software, you have to apply a subset of IEC 62304 at the same time.</p>
<h4>Relationships with other standards</h4>
<p>Another way of putting this standard in the picture, it to draw the relationships of this standard with other standards, like we already did <a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010">here for IEC 62304</a>.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.relationship_of_IEC_82304-1_with_other_standards_m.png" alt="relationship_of_IEC_82304-1_with_other_standards.png" style="display:table; margin:0 auto;" title="relationship_of_IEC_82304-1_with_other_standards.png, Dec 2015" />
This graphic anticipates a bit what is explained in the next article: ISO 14971 is not required by IEC 82304-1 but is still required by IEC 62304.</p>
<h4>Is it mandatory?</h4>
<h5>Short answer:</h5>
<p>No. A standard is never mandatory, expected in very rare cases, but surely not for health software!<br /></p>
<h5>Not so long answer:</h5>
<p>Standards are never mandatory but when they are recognized by regulation authorities, like the FDA, they become "gold standards" de facto.<br />
So, for standalone software regulated as medical devices (eg. mobile medical apps), it could become recognized by the regulations authorities as soon as the final version is published. It would make it almost mandatory.<br />
But for standalone software NOT regulated as medical devices, since they are out of the scope of regulations authorities, the manufacturers of such software could show very little willingness to implement IEC 82304-1!<br />
<br />
In a nutshell:</p>
<ul>
<li>if you develop standalone software medical devices, be prepared to see IEC 82304-1 recognized by the FDA and harmonized by the European Commission when it is published. Probably not before late 2016,</li>
<li>if you develop standalone health software not qualified as medical device, we don't know what regulation authorities will make of this standard. But odds are low that it will become mandatory<br /></li>
</ul>
<p><br />
<a href="https://blog.cm-dm.com/post/2016/03/11/IEC-82304-1-Overview-of-requirements">Next time</a> we'll see more in details the requirements of this standard.</p>https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/178IMDRF final document: Software as a Medical Device (SaMD): Application of Quality Management Systemurn:md5:19496d252fff34099e3df6fea29cdb392015-12-18T15:33:00+01:002015-12-28T21:07:44+01:00MitchMiscdevelopment processFDAISO 13485<p>The <a href="http://www.imdrf.org">IMDRF</a> published in October 2015 the guidance document titled "Software as a Medical Device (SaMD): Application of Quality Management System" in its final version.</p> <p>The draft version was published <a href="https://blog.cm-dm.com/post/2015/05/15/IMDRF-document%3A-Software-as-a-Medical-Device-%28SaMD%29%3A-Application-of-Quality-Management-System">in March 2015</a>. The draft version was opened to comments through a public consultation made by the IMDRF between March and May 2015.<br />
The final version was updated after analyzing the comments from the public consultation.<br />
<br /></p>
<h4>IMDRF and MDSAP</h4>
<p>IMDRF's job is not on software medical devices only. It has several working groups, including one working on the <a href="http://www.imdrf.org/workitems/wi-mdsap.asp">Medical Devices Single Audit Program (MDSAP)</a>. The mission of the MDSAP working group is to define an audit scheme applicable to several regulations (see IMDRF website, that's not simple :-).<br />
Canada is in terms of reactivity the country which takes the MDSAP the most seriously. By 2017, Canada will accept MDSAP certificates to get the clearance of medical devices. And by 2019, Canada will accept MDSAP certificates ONLY. This is what they <a href="http://www.hc-sc.gc.ca/dhp-mps/md-im/activit/int/mdsap-trans-notice-avis-eng.php">announced early December 2015</a>.</p>
<h4>What to do with this document?</h4>
<p>This IMDRF document claims that it is not intended to replace existing regulations and standards. For sure, the IMDRF can't do that, this is not their field of action.<br />
But,<br />
Given that:</p>
<ul>
<li>This document is one of the rare guidances on QMS for standalone software medical devices,</li>
<li>IMDRF's mission is to develop the MDSAP,</li>
<li>Auditors are keen at looking at guidances, to issue remarks laid on solid foundations,</li>
<li>Auditors also like when manufacturers define the provisions of their QMS based on relevant guidances,</li>
<li>MDSAP auditors will know the existence of IMDRF documents,</li>
</ul>
<p>This document may acquire a reputation, and even notoriety.<br />
<br />
This is just speculating. But such document requires a lot of work. I bet it won't be left apart.</p>https://blog.cm-dm.com/post/2015/12/18/IMDRF-final-document%3A-Software-as-a-Medical-Device-%28SaMD%29%3A-Application-of-Quality-Management-System#comment-formhttps://blog.cm-dm.com/feed/atom/comments/177IEC 62366-1 becomes recognized by the FDAurn:md5:3effac067a845d68db20b7ff35f9fc762015-09-23T09:57:00+02:002015-09-25T08:41:57+02:00MitchStandardsCE MarkFDAIEC 60601-1IEC 62366<p>Long time no see. For those of you guys who have been following this blog for a long time.<br />
Today I have time to write a short article on the new version of IEC 62366 standard: IEC 62366-1:2105 <em>Application of usability engineering to medical devices</em>.</p> <p>It was first published by the IEC at the beginning of 2015. Then the FDA was quick to add it to its list of recognized standards. It was published in <a href="http://www.gpo.gov/fdsys/pkg/FR-2015-08-14/html/2015-19991.htm">the Federal Register in August 2015</a> and the old version was marked withdrawn.<br />
It looks like the FDA wasn’t happy with the previous version to be so prompt to add the new one and withdraw the old one (pure speculation of mine).<br /></p>
<h4>Difference between US and EU</h4>
<p>We are now in a situation where the FDA recognizes the IEC 62366-1:2015 while the European Commission still references the IEC 62366:2007 in the list of harmonized standards. Discrepancies between standards versions can be difficult to handle.<br />
For those of you who know the changes in versions of IEC 60601-1 <em>Medical electrical equipment - Part 1: General requirements for basic safety and essential performance</em>, you know the hassle it can be. Fortunately, the case is more simple with IEC 62366.<br />
<br />
If your company designs products to be sold on the US and European markets, you’d better choose IEC 62366-1 than the old version. Why? Because it’s probably easier to bring evidence that you’re compliant with European regulations with the new standard (namely essential requirements about usability) than to bring evidence that you’re compliant with US regulations with the old standard that was withdrawn.<br />
Add to this that IEC 62366-1 should be referenced in the list of harmonized standards sooner or later. Thus there’s really no use to continue applying IEC 62366:2007 for new designs.</p>
<h4>Consequence on IEC 60601-1-6</h4>
<p>Coming back to IEC 60601-1, the IEC 60601-1-6 <em>Part 1-6: General requirements for basic safety and essential performance – Collateral standard: Usability</em> references IEC 62366. It basically takes IEC 62366 as is and adds some changes on the scope of products and some requirements on instructions for use.<br />
Even if IEC 60601-1-6 references the old version of IEC 62366, it is easy to apply the changes required by IEC 60601-1-6 to IEC 62366-1:2015 hence the wording of IEC 62366 hasn't changed. Thus, there's once again no use to continue applying the old version of IEC 62366.</p>
<h4>IEC 62366:2007 is dead</h4>
<p>As a consequence you have now to rely on the new usability engineering process defined in the requirements of IEC 62366-1. It is not easy to implement as it brings new concepts: formative evaluation and summative evaluation.<br />
We already talked about that <a href="https://blog.cm-dm.com/post/2015/01/09/IEC/FDIS-62366-1-released-in-November-2014">in a previous article</a>. Just to say that if you’ve been waiting for the last moment to change your design procedures to be in line with IEC 62366-1, uh, now, it’s time.<br />
<br />
<br />
Edit: fixed dates of IEC 62366 thanks to remarks of <a href="http://www.dm-experts.fr">Denys Durand Viel of DM Experts</a>.</p>https://blog.cm-dm.com/post/2015/09/23/IEC-62366-1-becomes-recognized-by-the-FDA#comment-formhttps://blog.cm-dm.com/feed/atom/comments/174Validation of software used in production and QMS - Part 3 Validation Protocol and Reportsurn:md5:454ac87f96e4f76d598958a75fa3e7d62015-08-28T12:54:00+02:002015-08-28T12:54:00+02:00MitchRegulationsCE MarkFDAISO 13485Software Validation<p>We continue this <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">series on validation of software used in production</a> and QMS with the Validation Protocol and Reports.</p> <p>The Validation Master Plan (VMP) comes with other documents:</p>
<ul>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-VMP-template.docx">Validation Master Plan template</a> itself, it contains general provisions for software validation,</li>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-Validation-Protocol-template.docx">Validation Protocol template</a>, it contains the application of the VMP for a given system,</li>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-Validation-Report-template.docx">Validation Report template</a>, it contains results of the validation protocol for a system,</li>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-Final-Validation-Report-template.docx">Final Validation Report</a>, it contains the conclusion of the validation of a system.</li>
</ul>
<p>I share these templates with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<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>.
<br />
<br />
<h4>Content of the Validation Protocol</h4>
<p>The validation protocol is the instanciation of the provisions of the Validation Master Plan (VMP). You will have one validation protocol per system needing validation.<br />
The content of the validation protocol repeats the phases found in the VMP, with specific provisions, if needed.<br />
<br />
For example, a system of low level of concern may have a validation protocol with IQ and PQ only, considering that OQ is not mandatory given the system features. Of course, skipping OQ shall be documented!
<br /></p>
<h4>Content of the Validation Reports</h4>
<p>The validation reports are simply the records of validation protocol.</p>
<h5>Validation Report</h5>
<p>The validation report is filled with data gathered during qualification phases. There may be a single report recording all phases or multiple reports. When qualification phases are long or verbose, having a report per phase is a good option.<br />
The validation report ends with a conclusion about the conformity of the product versus requirements verified during the phase. It's important to keep this part hence it inks the status of the system at the end of the phase. That's also a cultural way of doing this in the world of physical equipment qualification!</p>
<h5>Final Validation Report</h5>
<p>The final validation report contains:</p>
<ul>
<li>The identification of the system that is validated,</li>
<li>The final conclusion about the validation.</li>
</ul>
<p>The identification is important, to be sure which version is validated and who can use what in routine. This is also a favorite way of auditors to search for pitfalls in the identification of the validated system.<br />
The final conclusion is about the compliance of the system versus regulatory requirements. Note the difference between validation reports (compliance to requirements in the scope of the phase) and the final validation report (compliance to regulatory requirements).
<br />
<br />
<br />
That's the end of this <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">series about computerized systems validations</a>.<br />
With all this templates and explanations, you should be ready to perform you own computerized systems validations. Feel free to ask questions in comments!<br /></p>https://blog.cm-dm.com/post/2015/08/28/Validation-of-software-used-in-production-and-QMS-Part-3-Validation-Protocol-and-Reports#comment-formhttps://blog.cm-dm.com/feed/atom/comments/170Validation of software used in production and QMS - Part 2 Validation Master Planurn:md5:e2e9ba9415c539ce2786e41b6f47b7c22015-07-24T11:57:00+02:002015-09-03T07:43:53+02:00MitchRegulationsCE MarkFDAISO 13485ISO 14971Software Validation<p>We continue this <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">series on validation of software used in production</a> and QMS with the Validation Master Plan (VMP).<br />
Better than endless explanations, I added a Validation Master Plan template to my <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates repository page</a>.</p> <p>The Validation Master Plan (VMP) is here: <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-VMP-template.docx">Validation Master Plan template</a>. It contains general provisions for software validation.<br />
<br />
It comes with other documents that we'll see in the next post:</p>
<ul>
<li>The Validation Protocol template, it contains the application of the VMP for a given system,</li>
<li>The Validation Report template, it contains results of the validation protocol for a system,</li>
<li>The Final Validation Report, it contains the conclusion of the validation of a system.</li>
</ul>
<p>I share these templates with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<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>.
<br />
<br />
<h4>Content of the VMP</h4>
<p>The Validation Master Plan contains the provisions for:</p>
<ul>
<li>Identifying systems that require validation,</li>
<li>Defining the level of scrutiny of the validation.</li>
</ul>
<h5>Selecting systems</h5>
<p>Not all systems used by a company should be validated. As we already saw <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">in the previous article</a>, only those in the scope of requirements found in applicable regulations and standards shall be validated.<br />
The VMP template gives hints to define the selection criteria and to present the results of the selection.</p>
<h5>Level of concern</h5>
<p>The VMP template introduces the concept of "level of concern", to help validation team define the steps required by validation.<br />
The level of concern is borrowed from the FDA concept found in its guidances on medical device software. It is here adapted to the context of computerized system validation.</p>
<h5>Validation steps</h5>
<p>The validation steps are the very classical ones found in every validation protocol:</p>
<ul>
<li>Design Qualification (DQ),</li>
<li>Installation Qualification (IQ),</li>
<li>Operations Qualification (OQ),</li>
<li>Performance Qualification (PQ).</li>
</ul>
<p>These concepts don't mach well those found in software validation. But some links can be drawn between them.</p>
<h5>Design Qualification</h5>
<p>Design qualification is applicable only to a subset of selected systems. DQ is applicable when software is internally developed or when its configuration is complex, with scripting and the like. See VMP template for hints on DQ applicability.<br />
DQ is simply a software development project. The most obvious model of software development is the waterfall model but any other kind of model is possible.<br />
The DQ should contain the classical documents and records found in a software development project:</p>
<ul>
<li>Development plan,</li>
<li>Software Requirements Specifications,</li>
<li>Design review.</li>
<li>Software Test Plan,</li>
<li>Software Test Report,</li>
<li>Final review.</li>
</ul>
<p>You may use the "all-in-one template" in the <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates repository page</a> to document the development projet of a software tool.<br /></p>
<h5>DQ is not IQ / OQ / PQ</h5>
<p>Don't miss the point about DQ. It's a phase which is different from IQ / OQ / PQ.<br />
To make things simple, DQ is made on a test platform or pilot platform, IQ/OQ/PQ are made on the target platform.<br />
There may be cases where the test platform is also the target platform. But, to make things clear and catch the concepts, remember <em>DQ equals test platform</em> and <em>IQ / OQ / PQ equals target platform</em>.
<img src="https://blog.cm-dm.com/public/Templates/CSV/.DQ-IQ-OQ-PQ_m.png" alt="DQ-IQ-OQ-PQ.png" style="display:block; margin:0 auto;" title="DQ-IQ-OQ-PQ.png, Jul 2015" />
Using the language of software development teams, the version output of DQ is like a Release Candidate version ready to be tested by other people than the software development team.</p>
<h5>Installation Qualification</h5>
<p>Installation qualification is the verification of the installation of software on its target platform. The IQ can be made either during the installation or after the installation.<br />
<br />
When it is done during the installation, the tester runs the installation and verifies at the same time that the installation is running well. The IQ is then a mix of installation tests (eg: running the installer) and of inspections (eg: checking the hardware version, the OS version, the documentation...)<br />
<br />
When it is done after the installation, the verification is an inspection of the installation records. The tester goes through all installation records and checks that the installation was correct.<br />
<br />
Note that the IQ happens on the target platform. It shouldn't be confused with the installation of software on a test platform during DQ. Verifying that software can be installed and run on the test platform is a part of Design Qualification or of preliminary tests before the IQ.<br />
<br />
Using the language of software development teams, the version installed in IQ is the Release Candidate.</p>
<h5>Operations Qualification</h5>
<p>Operations Qualification is the verification of software functions on its target platform. The OQ is made after the IQ (I can't verify software if it wasn't properly installed before).<br />
OQ is a set of tests verifying the functional requirements of software. The functional requirements can be either user requirements or technical requirements. These requirement are input data of the validation process.<br />
<br />
When OQ is preceded by DQ, DQ tests and OQ tests may overlap. The most simple solution is to redo all the tests passed during DQ. OQ test can also be a reduced set of DQ tests - like typical user scenarios. OQ tests can also be completely different tests if DQ was oriented to verification of technical requirements.<br />
<br />
When OQ is not preceded by DQ, a test protocol verifying the requirements shall be written.<br />
<br />
Using the language of software development teams, the version output of OQ is like RC2 or RC3, where most of bugs found by users have been removed.</p>
<h5>Performance Qualification</h5>
<p>Performance Qualification is the verification of software in routine use. The PQ is made after the OQ (I can't verify in routine use if software functions haven't been properly tested before).<br />
<br />
PQ can be a set of structured tests verifying user scenarios. It can also be made of free tests by end-users. The PQ should contain a predefined period of surveillance of software used in routine by the end-users.<br />
<br />
Using the language of software development teams, the version output of PQ is the Final Release of software.</p>
<h4>Latitude in DQ / IQ / OQ / PQ content</h4>
<p>These four steps are heavy to implement, but we have escape plans.<br />
<br />
The VMP gives latitude to the validation team in the exclusion of the validation steps and in their content. Provided that rationale and evidence are brought, it is possible to make the validation more simple than these four steps.<br />
DQ is obviously not required for purchased software with minimal configuration settings. It's possible to simplify IQ, OQ and PQ steps when the context allows it. Likewise it's possible to exclude IQ or OQ with justification. It looks difficult to exclude PQ. But it may be possible to have OQ and PQ merged in a single step.</p>
<h4>Retrospective validation</h4>
<p>With legacy system, it's possible to do a retrospective validation. This is another kind of escape plan.<br />
It is based on the analysis of historical data of a system already used in routine. The retrospective validation consists in assessing the conformity of the system to regulations by analyzing:</p>
<ul>
<li>Records output by the system,</li>
<li>Non-conformities linked to the system or to processes involving the system,</li>
<li>Customer complaints linked to the system or to processes involving the system,</li>
<li>Any other relevant data (argh, can't be more precise ...).</li>
</ul>
<p>Be careful with retrospective validation hence it is not "appreciated" by auditors and inspectors. They're going to search for the pitfall in this kind of validation.<br />
The easiest pitfall to find is if you modify the system after you've validated it retrospectively. How to convince the auditor that a complete revalidation is not necessary? A tiny software change can have dire side effects.<br />
<br />
Anyway, retrospective validation is sometimes the only way to validate a legacy system that has been used for a long time without any bugs, and without any will of the users to modify it.<br />
<br />
<br />
<br />
Next time, we'll see the <a href="https://blog.cm-dm.com/post/2015/08/28/Validation-of-software-used-in-production-and-QMS-Part-3-Validation-Protocol-and-Reports">Validation Protocol and Validation Reports</a>.</p>https://blog.cm-dm.com/post/2015/07/24/Validation-of-software-used-in-production-and-QMS-Part-2-Validation-Master-Plan#comment-formhttps://blog.cm-dm.com/feed/atom/comments/169