Software in Medical Devices, by MD101 Consulting - Tag - GuidanceBlog 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:9c06172e7cd5ed0f5b192883b657eabbDotclearFinal 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/277Cybersecurity 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 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/238MDCG 2019-16 Guidance on cybersecurity for medical devicesurn:md5:410d3b034928e18ddbe5d0a05afe4b142020-05-03T14:20:00+02:002020-05-09T14:00:01+02:00MitchRegulationsCybersecurityGuidance<p>So we have a new guidance on cybersecurity for medical devices: the MDCG 2019-16. This is not the one we expected so quickly, but we're not going to complain about the existence of this guidance! It was published in December 2019. At last I found time to write a review.<br />
This guidance covers a broad range of topics applicable to all stakeholders in the medical device supply chains, and to end-users. It explains a bit why it is 46 pages long.</p> <h4>Section 1 - Introduction</h4>
<p>The first section of the guidance draws the link between regulatory requirements and cybersecurity processes / artifacts. The figures 1 & 2 are quite a good synthesis of the MDR requirements covering cybersecurity. Note that these figures could be duplicated with several other topics, like electrical security, biocompatibility (and so on), and state-of-the-art applicable standards.<br />
The topics listed in section 1.4 cover all topics where cybersecurity is involved. This list is very useful to assess where cybersecurity requirements shall be implemented in your QMS processes. E.g: design controls, post-market surveillance.<br /></p>
<h4>Section 2 - Basic cyber concepts</h4>
<p>If you've already read documents like AAMI TIR 57 or the 2 FDA guidances on cybersecurity, you will retrieve in this section some information common to these documents. The novelty in this MDCG guidance is the link between these concepts and the MDR General Safety and Performance Requirements (GSPR).<br />
We also retrieve in this section concepts of <em>defense in depth</em>, <em>good security hygiene</em> (basic security hygiene in FDA guidance), and the relationship between security risks and safety risks.<br />
Another concept is introduced, not so easily found in other guidance: the link between usability engineering and cybersecurity:<br />
<em>[a vulnerability] should be regarded as an enabler of reasonably foreseeable misuse </em>.<br />
If an exploit exists, an user will use it with a probability to assess, linked to the user's education level and the ease of exploitation based on use scenarios.<br />
<br />
The concept of joint responsibility is also introduced. All stakeholders in the supply chain shall take their part of the job: medical device integrators operators, and users. Manufacturers, don't be fooled by this <em>joint responsibility</em>: as usual, your responsibility will be engaged in case of adverse event. You shall have established processes to ensure the proper installation, deployment, configuration, and exploitation of your devices in a secure manner. Simply said, this joint responsibility doesn't exonerate manufacturers. Quite the opposite, it engages the responsibility of other stakeholders.</p>
<h4>Section 3 - Secure design and manufacture</h4>
<p>Section 3 delves into technical details (as far as a guidance can do, it's not a standard), with a list of good practices to ensure that the device is secure by design. These 6 best practices can be seen as the steps of processes found in IEC 62304 design and maintenance processes:</p>
<ol>
<li>Security management:
<ol>
<li>4.1 of ISO 13485, for the security risk management process</li>
<li>5.1 of IEC 62304: Software development plan</li>
<li>6.1 of IEC 62304: Software maintenance</li>
</ol></li>
<li>Specification of Security Requirements:
<ol>
<li>5.2 of IEC 62304: software requirements analysis</li>
</ol></li>
<li>Secure by design, including defense in depth:
<ol>
<li>5.3 of IEC 62304: software architecture</li>
</ol></li>
<li>Secure implementation:
<ol>
<li>5.4 of IEC 62304: software detailed design</li>
<li>5.5 of IEC 62304: software implementation and unit verification</li>
<li>and a precision on SOUP management</li>
</ol></li>
<li>Secure Verification and Validation
<ol>
<li>5.6 of IEC 62304: software integration testing</li>
<li>5.7 of IEC 62304: software system verification</li>
</ol></li>
<li>Management of security-related issues
<ol>
<li>6.2 of IEC 62304: Problem and modification analysis</li>
<li>9 of IEC 62304: Problem resolution</li>
</ol></li>
<li>Security update management
<ol>
<li>6.3 of IEC 62304: Modification implementation</li>
<li>8.2 of IEC 62304: Change control</li>
</ol></li>
<li>Security guidelines:
<ol>
<li>5.8 Software release</li>
<li>and also software documentation, see IEC 82304-1 section 7.</li>
</ol></li>
</ol>
<h5>Security Risk management</h5>
<p>Section 3.2 continues with recommendations on the security risk management process, especially the link between security risks and their impact on safety. A very important remark is present in this section, for the sake of clarity of safety risk management reports: <em>safety risk assessment might list generic security related hazards (...). This is to avoid detailing every possible attack vector</em>.<br />
This section also insists on the fact that compliance to GSPR 1 to 4 requires to assess security risks. Thus, cybersecurity isn't nested only in GSPR 17.2 on software, but is promoted to the first main GSPR's.</p>
<h5>Security capabilities</h5>
<p>Section 3.3 lists some possible security capabilities for software. This list is absolutely not exhaustive. This is a good starting point, though.<br />
Interestingly, this section also contains an analogy between the precedence of safety mitigation actions (section 6.2 of ISO 14971) and their security risk equivalent. Worth reading!<br />
This section ends with a remark on the need to maintain <em>safety and effectiveness but also performance requirements and efficiency of mitigation actions</em>, with security capabilities. New columns to your risk assessment matrices?</p>
<h5>Minimum IT requirements</h5>
<p>Section 3.6 gives an indicative list of IT security requirements. You can take this list as the equivalent of the annex C of ISO 14971:2009 (not 2019, you will have to pay twice but this is another subject).<br />
This section also gives recommendations on accompagnying documents about cybersecurity. It's funny to read that they recommend to have these instructions in electronic format (hello regulation 207/2012/EU, e-IFU isn't a risk, it's a mitigation action!).</p>
<h5>Verification and validation</h5>
<p>This rather short section, is actually too short! If you want to know everything about verification of security measures, go to UL 2900-1 and UL 2900-2-1.</p>
<h5>Lifecycle aspects</h5>
<p>This last sub section of section 3 covers the support processes with respect to cybersecurity. It is elaborated in section 5 of the MDCG guidance. The best method is to update your current software maintenance process and problem resolution process to add provisions about security feedback and problems. Likewise, the PMS report or PSUR shall contain a section about cybersecurity.</p>
<h4>Section 4 - Documentation on IFU</h4>
<p>This section deals with all GSPR 23.x, on how to see them from the point of view of security. It's a very useful section, to fill your answers to GSPR matrix template. The recommendations on information to the users also overlap with the requirements found in IEC 82304-1. Likewise, this section is useful to add new sections about cybersecurity in your IFU template.</p>
<h4>Section 5 - PMS and vigilance</h4>
<p>Section 5 makes the link between regulatory requirements on PMS / vigilance, and cybersecurity. It makes a short recall on PMS, incidents and serious incidents. Examples of security events that have to be considered as incidents are given in annex II. The best way to follow these recommendations is probably to update your PMS process (PMS plans, PSUR templates) to add provisions to manage security incidents, like any other incident.<br />
This section ends with a reference to the IMDRF reporting tool. But there is no explanation on why the MDCG relies on this tool, nor is there any reference to the IMDRF elsewhere in the guidance. Some other guidances are expected on reporting tools. The mystery remains...</p>
<h4>Conclusion</h4>
<p>Compared to FDA guidances, the MDCG 2019-16 covers of both premarket and post market FDA cybersecurity guidances. It is a good surprise in the regulatory landscape.<br />
In terms of compliance for manufacturers, I suggest to put this document in an excel sheet and do a traceability matrix to ensure the right application of all the recommendations (requirements!) contained in these 46 pages.</p>https://blog.cm-dm.com/post/2020/05/03/MDCG-2019-16-Guidance-on-cybersecurity-for-medical-devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/234Cybersecurity - 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/211Cybersecurity in medical devices - Part 3 AAMI TIR57:2016urn:md5:5adc4afffd7a08b5f11355939d648e6d2017-05-16T21:53:00+02:002017-05-16T22:46:46+02:00MitchStandardsCybersecurityGuidance<p>After a long pause, we continue this series about cybersecurity in medical devices with a discussion on AAMI TIR57:2016 Principles for medical device security — Risk management.</p> <p>This TIR is the one and only document available in the corpus on medical device-related standards and guidances, dealing with the application of cybersecurity principles and their impact on ISO 14971 risk management process. Yet, FDA guidances exist, but they’re not as direct as this TIR to show the impact of cybersecurity management process on risk management process.</p>
<h4>Structure of AAMI TIR57:2016</h4>
<p>The structure of sections 3 to 9 of this document is copied from ISO 14971 standard. It shows how the security risk management process can be modeled in a manner similar to the safety risk management process.<br />
If you’re at ease with ISO 14971, you’ll be at ease with AAMI TIR57. Your effort of understanding will be focused on security risk management concepts, not the process (risk identification, evaluation, mitigation and so on…) that you already know.<br />
We can bless the working group in charge of this TIR for this effort of presentation. The diagram below, extracted from the TIR, shows the analogy between both processes.</p>
<p><img src="https://blog.cm-dm.com/public/Cybersecurity/security-risk-safety-risk.png" alt="Relationships between the security risk and safety risk management processes" style="display:table; margin:0 auto;" title="Relationships between the security risk and safety risk management processes, May 2017" />
<br />
You've probably already seen this diagram elsewhere. And I bet that many articles or newsletters dealing cybersecurity in medical devices are going to reproduce it as well!</p>
<h4>Separation of processes</h4>
<p>The TIR recommends to separate the security and safety risk management processes. This looks as a good recommendation, as people involved in both processes are not all the same. Data security and clinical safety concepts are not managed by the same persons with the same qualifications.</p>
<h5>Cons</h5>
<p>This separation is going to remain very theoretical for most of small businesses. Practically, big companies can afford maintaining two processes and the needed qualified persons, but small businesses don’t.<br />
Small businesses will require the help of security experts to manage security risks. But they will be most probably hired as consultants. People who currently manage ISO 14971 process will manage both processes, without clear separation on a day to day basis.</p>
<h5>Pros</h5>
<p>The separation of processes is a good way to monitor efficiently security risk management. Keeping a security risk management file separated form the safety risk management file allows to document the outputs of the process without mixing concepts of security risk management (threats, vulnerabilities, assets, adverse impacts), with concepts of safety risk management (hazardous phenomenon, hazardous situation, hazard, harm).</p>
<h4>Annexes of AMMI TIR:57:2016</h4>
<p>The annexes found after section 9 are another wealth of information. They contain practical methods to implement a security risk management process. There is even a list of questions that can be used to identify medical device security characteristics, like the annex C of ISO 14971 for safety risks!<br />
The TIR ends with an example based on a fictional medical device: the kidneato system, with everything that a manufacturer shouldn’t do: an implanted part, a part connected to the public network, and a server storing medical data. Delicatessen for hackers!</p>
<h4>Multiplication of risk management files</h4>
<p>With the ongoing implementation of ISO 13485:2016 by medical device manufacturers, another consequence of security risk management is the multiplication of risk management files:</p>
<ul>
<li>QMS Process risk management,</li>
<li>Safety risk management,</li>
<li>Security risk management, and</li>
<li>Risk / opportunities management, for the fans of ISO 9001:2015.</li>
</ul>
<p>We can even try to draw a table of interactions between these processes (I skip ISO 9001:2015, but don’t conclude I’m not a fan :-))</p>
<table style="text-align:center">
<tr style="background-color: #25ABA3">
<td> </td><td>Affects</td><td rowspan="2">Safety</td><td rowspan="2">QMS Process</td><td rowspan="2">Security</td>
</tr>
<tr>
<td>Risks</td><td> </td>
</tr>
<tr>
<td colspan="2">Safety</td><td style="background-color: #dddddd">X</td><td>Safety risk mitigations implemented in QMS processes</td><td>Safety risks with potential impact on security. Safety controls affecting security</td>
</tr>
<tr>
<td colspan="2">QMS Process</td><td>Hazardous situations in QMS processes with impact on safety. QMS process controls affecting safety</td><td style="background-color: #dddddd">X</td><td>QMS process risk controls affecting security. Threats, vulnerabilities, assets found in processes to assess in security risk management</td>
</tr>
<tr>
<td colspan="2">Security</td><td>Security risks with impact on safety, Security controls affecting safety</td><td>Security risks with impacts on QMS processes (and possibly safety). Security controls affecting QMS processes</td><td style="background-color: #dddddd">X</td>
</tr>
</table>
<h4>Conclusion</h4>
<p>AAMI TIR75:2016 is an excellent source of information for newbies in security risk management. A must-read for people not qualified in security risk management, who need to manage the process, and anticipate its impact on other processes.<br />
<br />
In the next article, we’ll see the consequence of cybersecurity management on software development and maintenance processes.</p>https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016#comment-formhttps://blog.cm-dm.com/feed/atom/comments/204Final 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/201Software as a Medical Device (SAMD): clinical evaluationurn:md5:ea0506e268f7bff5fd71d03e9c3ef4432016-11-04T15:37:00+01:002016-11-04T15:37:00+01:00MitchMiscGuidanceIMDRF<p>The FDA released a guidance on clinical evaluation of standalone software medical device (a.k.a SAMD) in October 2016. This guidance is the same text and has the same presentation as the International Medical Device Regulatory Forum (IMDRF) guidance on SAMD clinical evaluation published in August 2016.</p> <h4>FDA and IMDRF guidance</h4>
<p>If you want to compare the two guidances:</p>
<ul>
<li>The guidance on <a href="http://www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/documents/document/ucm524904.pdf">FDA website</a>,</li>
<li>The guidance on <a href="http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-samd-ce.pdf">IMDRF website</a>.</li>
</ul>
<p>The only difference is the front page added by the FDA.<br />
This reference of the FDA to a document issued by the IMDRF has consequences outside the scope of this guidance. It gives strength to other guidances already issued by the IMDRF. This is also a positive sign that the MDSAP program is going to be successful and adopted by the FDA.</p>
<h4>A unique document of its kind</h4>
<p>This document is a gem. There is no equivalent guidance on clinical evaluation of standalone software medical device, either in the US (of course), or the European Union. The MEDDEV 2.7/1 revision 4 of June 2016 on clinical evaluation is for all medical devices and doesn't focus on software.<br />
As such, even if this guidance is still a draft, it is de facto the state-of-the-art for clinical evaluation of standalone software.</p>
<h4>Content</h4>
<p>This guidance is 45 pages long, but only the section 6 is on the clinical evaluation method itself. Chapters 1 to 5 put the reader in the picture, to understand the content of chapter 6.</p>
<h5>The method</h5>
<p>Chapter 6, the heart of the document, is 10 pages long and describes the clinical evaluation method. I won't paraphrase the guidance but just mention that it is divided into:</p>
<ul>
<li>Scientific evidence: the scientific basis for using the SAMD,</li>
<li>Analytical evidence: the V&V process,</li>
<li>Clinical performance evidence: the "real" clinical assessment.<br /></li>
</ul>
<p>Chapter 7 modulates the level of clinical evidence based on the profile of risk of the SAMD. For example, clinical performance evidence is required for high risk profiles only. Chapter 8 gives some insightful examples.</p>
<h5>References to other guidances</h5>
<p>While this guidance can be read without knowing other IMDRF guidances, it references them throughout the document. Thus reading these other guidances helps understanding the content of this one. This represent a lot of pages to read eventually (yes, I'm lazy). See other guidances on <a href="http://www.imdrf.org/documents/documents.asp">IMDRF website</a> and <a href="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">some comments on these guidances</a>.</p>
<h4>Agile clinical evidence</h4>
<p>Yes, you read it right: the guidance on SAMD clinical evaluation talks about <strong>agile clinical evidence</strong>!<br />
<br />
If you come form the software world, you'd say that the word "agile" is abused and distorted. But I prefer saying "welcome" to the clinicians. Sure, clinicians won't perform any clinical evaluation every week. "Agile" here means something else and the transposition of the agile concept to clinical evaluation is interesting.<br /></p>
<ul>
<li>The first reason of the use of the word "agile" stems from the idea that standalone software has the capability of communicating, compared to physical medical devices. As such, data use to set the ground of the clinical evidence can be easily and continuously acquired form the field (either in clinical evaluation or in post-market clinical follow-up) to confirm or adjust the clinical performance and safety of the device.<br /></li>
<li>The second reason stems from the capability of software to be continuously enhanced, thanks to the agile methods. As such, a standalone software in a first version can be used with a set of clinical claims, usually low risk, which will be extended in further version to newer, and more risky clinical claims, as feedback coming form the field can be used to:
<ul>
<li>Implement new functionalities, and</li>
<li>Demonstrate the clinical performance of these new functionalities.</li>
</ul></li>
</ul>
<p>This is typical of software to have simple functions at the beginning, and to evolve with advanced functions based on user feedback. This close interaction between software versions and user feedback requires to continuously reevaluate the clinical performance of software medical device. Through the lens of clinical evaluation and its timeframe, this is a kind of agility.</p>
<h4>Regulations</h4>
<p>This guidance carefully avoids binding its recommendations to any regulation. When the guidance recommends clinical performance evidence doesn't mean that regulations recommend clinical performance evidence, and vice-versa.<br /></p>
<h5>US regulations</h5>
<p>Clearance of medical devices rarely requires clinical data for class I and class II devices with predicate. Thus it won't change the clinical data required in 510k files. Class III devices require clinical assays, making the guidance not very helpful for this kind of devices. The De Novo process is probably the best candidate to make an intensive use of this guidance. Low or medium risk devices without predicate may or may not require clinical data. The guidance will give a substantial assistance in this case.</p>
<h5>EU regulations</h5>
<p>CE marking of medical devices always require clinical data, expected if bulletproof rationale is given. Thus this document will be significantly helpful to design the clinical evaluation plan of standalone software medical device.<br />
On top of that, standalone software medical device will be <a href="https://blog.cm-dm.com/post/2016/07/22/Is-my-software-in-class-I%2C-IIa%2C-IIb-or-III-2016-Revolution">more subject to be in a high regulatory class with the new Medical Device Regulation</a>. Thus making it much harder to define rationale to skip clinical evaluations.<br />
<br /></p>
<h4>Conclusion</h4>
<p>This guidance document is still a draft but can already be considered as the state-of-the-art in the field of clinical evaluation of standalone software medical device (or SAMD as defined in the guidance). It has no equivalent and will be of great help to design a clinical evaluation plan for standalone software.</p>https://blog.cm-dm.com/post/2016/11/04/Software-as-a-Medical-Device-%28SAMD%29%3A-clinical-evaluation#comment-formhttps://blog.cm-dm.com/feed/atom/comments/198Three 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/195MEDDEV 2.1/6 2016urn:md5:cdca59af59cd92ed5caabecdbe3763d72016-08-10T10:09:00+02:002016-08-10T09:20:25+02:00MitchRegulationsCE MarkGuidance <p>A new version of the <a href="http://ec.europa.eu/DocsRoom/documents/10362/attachments/1/translations">MEDDEV 2.1/6 was published in July 2016</a>.<br />
<br />
The <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">first version of 2012</a> was a major breakthrough. The new version won't change you life. Almost nothing new, excepted a few definitions on software, input data, output data, a remarkable reference to IMDRF definitions, and a non-significant update of the first decision tree.<br />
<br />
Add to that a few typos, and you have the new version of the MEDDEV:</p>
<ul>
<li>"lossless compression" disappeared from the decision tree (was it intentional?) but is still present in the explanations of decision step 3,</li>
<li>Decision step 7 doesn't have any explanation.</li>
</ul>
<p><br />
MEDDEV for nothing ♫ and tips for free ♬.</p>https://blog.cm-dm.com/post/2016/08/10/MEDDEV-2.1/6-2016#comment-formhttps://blog.cm-dm.com/feed/atom/comments/194New 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/184When the FDA releases guidances in burst modeurn:md5:6cb9deb5e308f637aa7f08f512b333dc2015-03-20T17:03:00+01:002015-03-20T17:59:26+01:00MitchRegulationsFDAGuidancemobile medical appPACS<p>If you watch from time to time the new guidances released by the FDA, you probably noticed that two guidances about software were released in january and february 2015.</p> <p>We have the :</p>
<ul>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM401996">Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices</a> guidance released in February,</li>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM429674">General Wellness: Policy for Low Risk Devices</a> Draft Guidance released in January,</li>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM429672">Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Types</a> Draft Guidance released in January.</li>
</ul>
<p>Add to these very recent guidances, the :</p>
<ul>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366">Mobile Medical Applications</a> guidance released in september.</li>
</ul>
<p>That's a lot of stuff to read. I'll try to sum up all of these.</p>
<h4>About MDDS and PACS</h4>
<p>The first guidance <em>Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices</em>, is actually about PACS servers and Health IT systems, without modules performing data processing for diagnostic or treatment purposes.<br />
<strong>The guidance simply says that PACS servers and MDDS are actually medical devices, but the FDA doesn't intend to regulate them</strong>.<br />
This produced a lot of fuss in the medical devices galaxy. But this isn't a scam or a joke. If you want to confirm by yourself that this is true,</p>
<ul>
<li>First, have a look at the recent FDA webinar <a href="http://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm433146.htm">Overview of Medical Device Data Systems, General Wellness Devices, and Medical Device Accessories - February 24, 2015</a>, the question is raised by many attendants and the FDA speaker's answer is clear of this subject,</li>
<li>Second, if you have a doubt, contact the FDA to confirm that your software falls in the scope of this guidance,</li>
<li>Third, enjoy.</li>
</ul>
<p>Anyway, if your system falls in the guidance scope today, this may not be the case tomorrow. If you plan to add advanced modules processing data for clinical purposes, you should anticipate this evolution:</p>
<ul>
<li>Either by insulating advanced modules and concealing the rest of the system in SOUP,</li>
<li>Or, to be safe, by applying the IEC 62304 requirements to have the required documentation when your system is back to the medical device regulated zone.</li>
</ul>
<h4>About Mobile Apps</h4>
<p>The two following guidances are about mobile apps:</p>
<ul>
<li>The Mobile Medical Applications guidance,</li>
<li>The General Wellness draft guidance.</li>
</ul>
<p>The slides of the FDA Webinar contain a simple diagram, which explains at a glance the status of mobile apps.
<img src="https://blog.cm-dm.com/public/.FDA_mobile_apps_categories_m.png" alt="FDA_mobile_apps_categories.png" style="display:block; margin:0 auto;" title="FDA_mobile_apps_categories.png, Mar 2015" />
The triangle symbolizes the volumes of apps available on mobile apps stores: thousands at the bottom, a dozen at the top.<br />
<br />
The triangle is split in three zones:</p>
<ul>
<li>Top: medical devices with no doubt on the intended use,</li>
<li>Bottom: general wellness devices with no doubt on the non-medical intended use,</li>
<li>Middle: the gray area where the intended use or the level of risks of the apps shall (yes, shall) be assessed with the FDA.</li>
</ul>
<p>Thus, if you have doubts about the medical device status of your mobile app, contact the FDA. They will decide whether your device is regulated or not, based on its intended use and risks identified in the use of your device. This is what they call <em>law enforcement discretion</em>.</p>
<h4>About accessories</h4>
<p>The last guidance we haven't commented yet is the Medical Device Accessories draft guidance.<br />
While this guidance is not focussed on software, it has consequences on software. Many mobile apps are used to remotely access a medical device or medical data. Thus, they could be qualified as accessories.<br />
<br />
The guidance gives the definition of an accessory. If your app is an accessory, it is likely to be at the top of the triangle. Based on risk assessment, this accessory may come closer to the tip of the triangle or get closer to the grey zone.<br />
<br />
For innovative mobile medical apps without predicates, the FDA <em>encourages manufacturers and other parties (...) to utilize the de novo classification process</em>. With this guidance, the FDA leaves the door open for a clearance process less painful than a PMA (financially wise).<br />
With the blossom of mobile medical apps, it's probable that some manufacturers will be in this case.<br />
<br />
There's no occurence of the word <em>software</em> in the accessories guidance. But it's clear that it is consistent in its intent with the three other ones.</p>
<h4>And then?</h4>
<p>The accessories guidance and the general wellness guidance are still drafts. The FDA will probably publish another one called <em>Draft Guidance on Medical Device Decision Support Software</em>. It is planned in the <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/MDUFAIII/ucm321367.htm">A-list of guidances for 2015</a>.<br />
This last one will also have some side effects existing software or future software in the plans of manufacturers.<br />
All these draft guidances are in the B-List of final guidances of 2015. Meaning that the FDA's intent is to publish their final version, if FDA resources are available.<br />
<br />
<br />
Medical software landscape is changing fast. So is the FDA's position, expressed in their guidance.</p>https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode#comment-formhttps://blog.cm-dm.com/feed/atom/comments/164NBOG’s Best Practice Guide 2014-3: all you wanted to know about reporting software design changesurn:md5:f753972ee3fbf992838409bb55e367ed2014-12-12T21:42:00+01:002014-12-12T23:53:52+01:00MitchRegulationsCE MarkGuidance<p>When should a manufacturer report devices changes or QMS changes to notified bodies, according to the 93/42/CE directive?<br />
There hasn't been clear criteria, until the Notified Bodies Operating Group (NBOG) published the <a href="http://www.nbog.eu/resources/NBOG_BPG_2014_3.pdf">Best Practice Guide 2014-3</a> : <em>Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System</em>.</p> <p>This guidance is the third of a <a href="http://www.nbog.eu/2.html">series of 3 guidances</a> published in november 2014 by the NBOG. The first two are more intended to be followed by notified bodies and should be known by manufacturers for their information.<br />
The third one is the purpose of this post.</p>
<h4>Change control</h4>
<p>The guidance begins with a reminder of the EU regulations, a few definitions (pay attention to the definition of "critical supplier"). It then gives the recommended <em>Steps of the manufacturer for the change assessment procedure</em>.<br />
Needless to say that you should review your Change Control procedure(s), in the light of these recommendations!<br />
<br />
The recommendations insists on reporting substantial changes of the QMS or in the design of devices to notified bodies. The notified bodies made sure for a long time that manufacturers communicate on substantial changes, either by contract, or during audits, or through non-conformities. This guidance just sets a frame, which ensures that practices are harmonized between notified bodies.<br />
This is good, but not the best part of the guidance.</p>
<h4>Criteria for "substantial changes"</h4>
<p>Section 5 of the guidances entitled Criteria for "substantial changes" is really the gem hidden inside the document.<br />
For the first time, a European organization has established a set of criteria and listed examples to assess what a substantial design change is for a medical device and for a QMS.<br />
The set of criteria is not closed. Hence the word <em>should</em> is employed on the introductory sentence of sections 5.1 Product changes, 5.2 Quality system changes, and 5.3 Changes to the product ranges. E.g. in 5.1: <em>Product changes should be considered substantial if the change may affect ...</em>. But these criteria are still precise.<br />
Precisions are given in the section 5.4 <em>Particular cases, examples</em>, with a section entitled <em>Changes to software</em>.</p>
<h4>Ah, ah, changes to software</h4>
<p>I don't know how many times I was asked the question: We've modified our software, should we report the change to our notified body? And I don't know how many times I answered: it depends. With the uneasy feeling that I passed for a consultant specialized in air fan! Thanks to this guidance I shouldn't.<br />
The guidance addresses the vast majority of possible software changes, either in specifications, or usability, or algorithms, or bug fixes of different levels. The rationale behind the cases listed in the guidance is the calling into question of the intended use or of the risk assessment, caused by software change.<br />
Based on the examples given in the guidance, it should (and I'm sure that it will) be easier to decide if software changes are substantial or not.</p>
<h4>The curious case of operating system</h4>
<p>The guidance considers that <em>a software change that incorporates a significant change to the operating system on which the software runs</em> should be considered a substantial change.<br />
Needless to say that a variant of the question above is: We've installed our software on Windows <choose your version>, it runs perfect, should we report the change to our notified body? I think I'm going to continue to answer: it depends.<br />
More seriously, by experience, the change of operating system is absolutely the most recurring case, for which deciding whether it is a substantial change or not, is not obvious.<br />
It's true that change of OS should be questioned. But this case should have been extended to any SOUP the software uses to run.</p>
<h4>What about the FDA?</h4>
<p>For once, we can congratulate the NBOG for having succeeded in publishing a guidance with no equivalent on the US side!<br />
The FDA published in 1997 <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm080235.htm">the guidance: Deciding When to Submit a 510(k) for a Change to an Existing Device</a>, with its famous decision-tree and its question B8, B8.1, B8.2, and B8.3 with considerations similar to those found in the NBOG’s Best Practice Guide 2014-3. But examples given are not as articulate as those found in NBOG's guide about software.<br />
However, the FDA guidance is 17 years old! An eternity for software. Software wasn't as ubiquitous as today.<br />
<br />
Anyway, NBOG’s Best Practice Guide 2014-3 is a very useful guidance, for software but more generally for all types of medical devices.</p>https://blog.cm-dm.com/post/2014/12/12/NBOG%E2%80%99s-Best-Practice-Guide-2014-3%3A-all-you-wanted-to-know-about-reporting-software-design-changes#comment-formhttps://blog.cm-dm.com/feed/atom/comments/159Analysis of the FDA Cybersecurity Guidanceurn:md5:3e49e1f75ffbd0922d3fbd15c5b46e852014-11-21T12:46:00+01:002014-12-12T21:32:22+01:00MitchRegulationsFDAGuidancerisk management<p>At last! The FDA has published last October a <a href="http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf">guidance about cybersecurity</a> that matters!<br />
Not that the guidance previously published about <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm077812.htm">Off-the-shelf software cybersecurity</a> wasn’t worth reading it (Guidance to Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software), but its scope was more than reduced.</p> <h4>Scope of the guidance</h4>
<p>The new cybersecurity guidance stretches its scope to all concerns about confidentiality, security, privacy and so on. It applies also to any medical device software, including firmware. Networked software comes immediately to our minds, but not only.
Even if software is embedded in a medical device without any kind of external connection, it is in the scope of the guidance. Hence such device, say, with a software update capability by USB stick, could be subject to cyber attacks.</p>
<h4>Content of the guidance</h4>
<p>After classical introduction, scope, and a bunch of definitions, the guidance contains three main sections: general principles, cybersecurity functions, and cybersecurity documentation.<br />
Note: text in <em>italic</em> font in this article, quotes sentences from the guidance.</p>
<h5>General principles</h5>
<p>I won’t paraphrase the general principles in the guidance, and let you read them by yourself. If you don’t have time, just remember that:</p>
<ol>
<li>The FDA <em>recognizes that medical device security is a shared responsibility between stakeholders</em> (including manufacturers),</li>
<li><em>Manufacturers should address cybersecurity during the design and development of the medical device</em>,</li>
<li>Cybersecurity management approach is <em>part of the software validation and risk analysis</em>.</li>
</ol>
<p>As a consequence (this is my interpretation), manufacturers should include in their design procedure and risk-management procedure provisions to manage cybersecurity.</p>
<h5>Cybersecurity Functions</h5>
<p>In this section, the FDA <em>recommends that medical device manufacturers consider the following cybersecurity framework core functions to guide their cybersecurity activities: Identify, Protect, Detect, Respond, and Recover</em>.<br />
This framework is the National Institute of Standards and Technology <a href="http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214-final.pdf">Framework for Improving Critical Infrastructure Cybersecurity</a>.<br />
<br />
The guidance then gives more information about the recommended actions related to these core functions, like <em>Limit access to devices through the authentication of users, or Restrict software or firmware updates to authenticated code</em>.<br />
Needless to say that it is highly recommended to have rationale when some of these functions are not applicable to your device or when an <em>alternative method or approach</em> is used.<br />
<br />
This list of recommended actions is a good set of input data for cybersecurity risk analysis. Like the questions found in annex C of ISO 14971, these recommendations could be rephrased in a set of questions used to come up against cybersecurity concerns.</p>
<h5>Cybersecurity documentation</h5>
<p>This section gives FDA expectations about documents and records bringing evidence that cybersecurity management process completion. To sum-up:</p>
<ol>
<li>During software design: hazard analysis, cybersecurity controls, and traceability matrix between both,</li>
<li>During software use and maintenance: plans, controls, and instructions put in place to ensure device cybersecurity throughout its lifecycle.</li>
</ol>
<p>The FDA expects especially a <em>plan for providing validated software updates and patches as needed throughout the lifecycle of the medical device to continue to assure its safety and effectiveness</em>. This makes the link with the previous guidance about <em>Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software</em>, hence the plan should include actions to monitor OTS software security concerns.<br />
Note that this documentation should take place in the DHF. The cybersecurity plans, controls and instructions put in place to manage cybersecurity after design transfer should also be in the DMR.</p>
<h5>Recognized standards</h5>
<p>The guidance ends with a list of recognized standards dealing with IT security. IEC 80001-2-2 is here as well as other standards about IVD security, and about Industrial communication networks security.<br />
The most notable absentee in this list of standards are: ISO 27001 and ISO 27005. These standards are about security of IT systems, usually the concern of health care providers. But the FDA states in the beginning of the guidance that cybersecurity is a <em>shared responsibility between stakeholders</em>.
If so, why not adding ISO 27001 and ISO 27005? Manufacturers know that the HIPAA rules have an impact on medical device software design. Likewise, ISO 27001 and ISO 27005 may have an impact on medical device software design and manufacturers should be aware of it.</p>
<h4>Conclusion</h4>
<p>The conclusion was already in the first paragraph of this post: At last! A cybersecurity guidance!
Once again the FDA is a giant leap further than ROW regulation authorities (Hello, European Commission!).</p>https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance#comment-formhttps://blog.cm-dm.com/feed/atom/comments/158Content of DHF, DMR and DHR for medical device software - Part 1 DHFurn:md5:1c94726ddc83e477bf5f85fdeb88a97d2014-10-03T13:58:00+02:002014-10-30T13:25:20+01:00MitchRegulationsdevelopment processFDAGuidanceIEC 62304Software ValidationSoftware Verification<p>After a temporary absence, I'm back on the waves with a new series of articles to talk about the files required by the 21 CFR 820 regulations:</p>
<ul>
<li>DHF: Design History File,</li>
<li>DMR: Device Master Record,</li>
<li>DHR: Device History Record.</li>
</ul>
<p>Let's begin with the DHF.</p> <h4>What is the Design History File (DHF)?</h4>
<p>The DHF is a term defined by the US regulations. You can find it in the online copy of 21 CFR on the FDA website.</p>
<h5>Definition</h5>
<p>The <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.3">section 21 CFR 820.3(e)</a>, gives the definition of DHF:<br /></p>
<ul>
<li><em>Design history file (DHF) means a compilation of records which describes the design history of a finished device.</em></li>
</ul>
<p><br />
Okay, the DHF applies to a finished device, not to a prototype or to a device still in the design phase.</p>
<h5>Design Controls</h5>
<p>The <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.30">section 21 CFR 820.30</a> about Design Controls states the requirements about the DHF:<br /></p>
<ul>
<li>21 CFR 820.30 (a): <em>General</em>
<ul>
<li><em>(1) Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, <strong>shall establish and maintain procedures to control the design of the device</strong> in order to ensure that specified design requirements are met.</em></li>
<li><em>(2) The following class I devices are subject to design controls:</em>
<ul>
<li><em>(i) Devices automated with computer software</em></li>
<li>(...)</li>
</ul></li>
</ul></li>
</ul>
<p>In other words, you shall maintain a DHF, whichever the class of your medical device software (even in class I).</p>
<ul>
<li>21 CFR 820.30 (j): <em>Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.</em><br /></li>
</ul>
<p>In other words, the first sentence of this last section requires to: establish and maintain a DHF for each type of device. For standalone software, a "type of device" may be a software alone or a system made of software working together (eg a client and a server) or a software suite (with a well established list of software in the suite!).<br />
<br />
The second sentence requires to gather all the records necessary to prove that the design controls requirements of 21 CFR 820.30 are met. These design controls requirements are described in the sections (b) to (i) of 21 CFR 820.30. They list the mandatory steps of a design process: <em>Design and Development Planning, Design Input, Design Output, Design Review, Design Verification, Design Validation, Design Transfer</em>.<br />
<br />
Thus the DHF contains the records, which prove that these mandatory steps were actually followed.</p>
<h4>Design Controls for software</h4>
<p>The "translation" of these steps for software design can be found in two places: in the <a href="http://www.fda.gov/MedicalDevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm">"General Principles of Software Validation" (GPSV) FDA guidance</a>, or in the IEC 62304 FDA recognized standard.<br />
We can draw the links between GPSV and IEC 62304 chapters, and designs steps listed in 21 CFR 830.30.<br />
<br />
Note: these links are relevant for standalone software. When software is embedded in a hardware device, IEC 62304 requirements are not enough. Eg: Design input contains also requirement management at system level.</p>
<h5>Design and Development Planning</h5>
<p>GPSV <em>5.2.1. Quality Planning</em>, and IEC 62304 <em>5.1 Software development planning</em> require to define procedures and/or plans to follow during design.</p>
<h5>Design Input</h5>
<p>GPSV <em>5.2.2 Requirements</em>, and IEC 62304 <em>5.2 Software requirements analysis</em>.<br />
For both documents, this is the input data of software requirement definition (the high-level requirements, the use-cases, the user requirement not formalized),</p>
<h5>Design Output</h5>
<p>GPSV <em>5.2.2 Requirements</em>, and IEC 62304 <em>5.2 Software requirements analysis</em>. But now, this is the output data of software requirement definition (the actual software requirements written in a formal way, used to design software).<br />
For GPSV, we have also <em>5.2.3. Design, 5.2.4. Construction or Coding</em>, and for IEC 62304 we have <em>5.3 Software Architectural Design, 5.4 Software Detailed Design, 5.5 Software Unit implementation and verification, 5.6 Software integration and integration testing</em> (for the integration part).</p>
<h5>Design Review</h5>
<p>GPSV <em>3.5 Design review</em> section gives basic principles of design reviews for software, and requires design reviews in <em>5.2.2 Requirements</em> and <em>5.2.3. Design</em>.<br />
IEC 62304 doesn't use the term <em>design review</em> but uses in place the word <em>verify</em>. Sections <em>5.2.6 Verify software requirements</em>, <em>5.3.6 Verify software architecture</em>, and <em>5.4.4 Verify detailed design</em> are good landmarks to define the content of a design review.<br />
There may be one or more design reviews, depending on the complexity and the length of the software development. But there shall be at least one design review, containing the review of the above elements in its agenda.</p>
<h5>Design Verification</h5>
<p>Verification is testing software. Provisions for tests are described in GPSV <em>5.2.5. Testing by the Software Developer</em>, <em>5.2.6. User Site Testing</em> (when user takes part to verification tests), and in IEC 62304 <em>5.6 Software integration and integration testing</em> (for the testing part), and <em>5.7 Software System testing</em>.</p>
<h5>Design Validation</h5>
<p>21 CFR 820.3 Definition of design validation is <em>establishing by objective evidence that device specifications conform with user needs and intended use</em>.<br />
The recommendations of GPSV document about validation are in fact the whole section 5.2.<br />
Narrowing the scope to what happens after verification, validation is <em>5.2.6 User Site Testing</em> (when user takes part to validation tests).<br />
Here for IEC 62304 we don't have any relevant section, hence this standard ends at the verification phase. But for standalone software, requirements described in <em>5.7 Software System testing</em> are quite convenient to formalize and record a user validation step.<br />
Another way of appraising validation is to apply the recommendations of GPSV and from A to Z.</p>
<h5>Design Transfer</h5>
<p>In GPSV, we don't have a specific chapter. Hence it stops the list of recommendations at the end of validation.<br />
In IEC 62304, section <em>5.8 Software release</em> contains some requirements about design transfert. Design transfert can be seen as freezing a software configuration and its associated documentation (design docs, release notes ...). But design transfer is more than that because it aims to prepare the Device Master Record.<br />
We'll see that in the next article of this series.</p>
<h4>Content of the DHF for software</h4>
<p>Based on the steps of design controls listed above, we can list the kind of documents that we need to prove that these steps were followed:</p>
<ul>
<li>Planning: A design procedure and/or plans for design, i.e. project management plan, software development plan, software configuration management plan, and risk management plan,</li>
<li>Input: any input document relevant for software design (algorithms, scientific articles, user requirements, prototypes, mock-ups...), including preliminary risk assessment report and preliminary usability specifications,</li>
<li>Output: software requirements specifications, usability specification, risk assessment report, software architecture design, software detailed design, ... and the code (better in a software configuration management tool),</li>
<li>Review: review meeting reports (be it architectural, detailed design, code reviews, integration review or else), according to plans,</li>
<li>Verification: software test plan, software test description, software test reports, for each test phase,</li>
<li>Validation: software test plan, software test description, software test reports, for the validation test phase, if there is one, plus validation meeting review reports.</li>
<li>Transfer: version delivery description, release notes... (see next article)</li>
</ul>
<p>You may find some documents templates on <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">the templates repository for software development process page</a>.</p>
<h4>Evolution of the DHF with multiple software versions</h4>
<p>Software versions are never frozen for long. Sooner or later, a new incremental version, a brand new version, or patches are released.<br />
All these patches or evolutions of software have to be recorded in the DHF. To do so, the way they are released need to be planned, and they need to be documented.</p>
<h5>Software maintenance plan</h5>
<p>GPSV has the section <em>5.2.7. Maintenance and Software Changes</em>, and IEC 62304 has the chapter <em>6 Software maintenance process</em>. Both require to establish a maintenance process, to analyse user problems or requests, and to implement them using the development process (under the change control provisions of the quality management system).<br />
The DHF may contain a software maintenance procedure and/or a software maintenance plan, to keep track of how design changes were planned.</p>
<h5>Software maintenance documentation</h5>
<p>Software maintenance activities are actually design activities for evolutions, and design flaws fixes for bugs. The documentation to add to the DHF is either the updates of all design documents listed in the design phases (especially updates of the risk assessment report), or documents describing patches (if bug fixes didn't change the design and the list of tests).<br />
As its name suggests, the Design History file contains the history of design! Thus it shall contain all versions of software documents created for each software version, including patches and minor versions.
If you use a bug tracking tool, its content can be seen as a piece of the DHF. Freezing or exporting the content of the bug tracking tool is a good way to keep track of the status of bugs for each released version or patch.<br /></p>
<h4>To sum-up the DHF content</h4>
<p>The DHF contains the set of all documents and records related to software design, for every software version (major or minor) and for every patch.<br />
Procedures and plans followed during design and maintenance can also be seen as a part of the DHF, hence they contain the description of the processes followed at the time software was designed.<br />
The content of software development tools, mainly configuration management and bug tracking can also be seen as a important piece of the DHF. Thus they contain the history of source files and the history of bugs.<br />
<br />
<a href="https://blog.cm-dm.com/post/2014/10/17/Content-of-DHF%2C-DMR-and-DHR-for-medical-device-software-Part-2-DMR">Next time</a> we'll see the Device Master Record and how to build it with Design Transfer.</p>https://blog.cm-dm.com/post/2014/10/03/Content-of-DHF%2C-DMR-and-DHR-for-medical-device-software-Part-1-DHF#comment-formhttps://blog.cm-dm.com/feed/atom/comments/153