Software in Medical Devices, by MD101 Consulting - Tag - ClassificationBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-18T07:25:39+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearFDA 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/252Is my software in class I MDD: Stayin' aliveurn:md5:cdebfb2ae36e1c0a00d7e50a9a887ffe2019-12-06T14:10:00+01:002019-12-06T14:10:00+01:00MitchRegulationsCE MarkClassificationIEC 62304IEC 82304ISO 14971<p>So we have a corrigendum (almost 100% sure. A vote by the EU Parliament is still in the pipe December the 16th, though). To corrigendumize: that's a neologism I propose to name bug fixing activities in legal matters. I corrigendumize, you corrigendumize, they corrigendumize! Any resemblance to "randomize" is purely coincidental!</p> <p>Seriously, we've all waited for a step from the EU in the direction of a smoother transition to the MDR. Now, we have it. Alas, they didn't do it to please manufacturers. They did it, pushed by the unavoidable necessity brought by the lack of notified bodies, and behind that, the lack of qualified persons.<br />
<br />
Anyway, let's see the consequences and opportunities for medical device software.</p>
<h4>Class IIa and higher with MDD</h4>
<p>The corrigendum doesn't bring any change. Your class IIa certificate continues to live after May 2020, <a href="https://blog.cm-dm.com/post/2019/07/19/Guidance-from-GMED-Notified-Body-on-significant-changes-in-the-framework-of-article-120-of-MDR">provided that you freeze the design</a>. Small changes, like bug fix and cosmetic arrangements are still possible after May 2020. But if you have bigger changes, you have to pass a MDR certification.</p>
<h4>Class I MDD</h4>
<p>The corrigendum brings a huge change! Your class I <strong>auto certified</strong> software can continue to live after May 2020, provided that you freeze the design. Like class IIa MDD software.</p>
<h5>May 25, 2020 11:59pm CET</h5>
<p>Now, you are in a race to the end of class I liberty. You are literally free to augment the intended use of your class I MDD software. After the deadline, you will be chained to a notified body. And believe me, it will be a dreadful hindrance. So, urge yourself to do everything you can as long as class I MDD is alive.</p>
<h5>Intended use in class I MDD</h5>
<p>Be very careful to stay in class I MDD, by adding functions matching the permissive rule 12 of the MDD. Think also about <a href="https://blog.cm-dm.com/pages/The-essential-list-of-guidances-for-software-medical-devices">the MEDDEV guide and manual on borderline classification</a>. With that in mind, stuff your software with as many functions as you can. Even those far in your product roadmap or at the bottom of your backlog. You won't be able to do that after May 2020.</p>
<h5>Risk management</h5>
<p>Here, no choice: stay compliant to ISO 14971:2012 (the year is important) but with the bare minimum. E.g. no need to have 500 risks for a class I mobile app of average size. If you have trouble to assess risks on some functions, remove them.<br />
Include also hazardous situations related to cybersecurity in your risk assessment. That's better to design a secure device at once!</p>
<h5>Software development</h5>
<p>Stay compliant to IEC 62304 and IEC 82304-1, once again with the bare minimum. E.g. If you're in class A, prepare documents required for class A and only those for class A. Priority is on implementation. If your software is in class A or B, and adding new functions make you think that it can be raised to class C, then remove these functions. That's a sign that your software may not be in regulatory class I, even with the MDD.<br />
Yet, don't do just anything and release software without major bugs. Compliance to IEC 62304 requires to ensure that residual bugs don't represent an unacceptable risk.</p>
<h5>Usability</h5>
<p>Do one formative evaluation, reduced to Q&A with user representatives or end-users if that's easy. Prepare a summative evaluation protocol compliant to IEC 62366-1. Once again, don't be too picky and define the number of end-users and validation criteria with the bare minimum. E.g. only unacceptable risks are assessed.</p>
<h5>Clinical evaluation</h5>
<p>Through literature, obviously. Craft a clinical evaluation report concluding on the essential requirements found in MEDDEV 2.7/1 rev.4. If you can't reach a positive conclusion on benefit/risk ratio, strip your software from the guilty functions. Rely as much as you can on post-market surveillance to bring data on unanswered questions.<br />
Polish your clinical evaluation report. This is the document that your competent authority will be prone to read in details, in case of inspection.</p>
<h5>IFU and Labelling</h5>
<p>Be. Compliant. To essential requirement #13 on IFU and labelling found in MDD. That's so easy for a competent authority to tackle you on this. On top of that, insert in your IFU sections required by clauses on IFU in IEC 82304-1.</p>
<h5>Final validation</h5>
<p>Schedule a design freeze and a formal validation early in May 2020. Make sure everything is compliant, with the bare minimum. Use the template <a href="https://blog.cm-dm.com/post/2019/11/30/Template-Verification-Validation-Transfer-Review-Report">there</a>. Keep time to fix things before the deadline.</p>
<h5>Declaration of Conformity</h5>
<p>Write, sign, and send the declaration of conformity, and other required documents the May 22nd, 2020. The 22nd is a Friday. Don't wait until Monday 25th 2020. this is your ultimate safety margin.</p>
<h4>From May 26th, 2020 onwards</h4>
<p>That's over. You can't touch your class I MDD software any more. You'll only be authorized to perform bug fixing. And you will have bugs to fix! Especially if you've waited for the last minute to add new functions to your ultimate class I MDD release. Fortunately, bug fixing is allowed.<br />
Thus, any other tiny change will propel your software to class IIa and beyond, <a href="https://blog.cm-dm.com/post/2019/10/31/Is-my-software-in-class-IIa%2C-IIb%2C-or-III%2C-Dark-Fate">by the rogue, the villainous rule 11</a>.
<br />
<br />
<br />
All of this may sound borderline to you ears accustomed to hearing concerns about compliance. It is. You may feel like it's not aligned with your own standards. Just get inspiration from this crash plan and set your own standards of compliance in this exceptional context.<br />
Remember that after the deadline, it's the notified body you choose, who will set the standards, not you.<br />
And it won't be the bare minimum.</p>https://blog.cm-dm.com/post/2019/12/06/Is-my-software-in-class-I-MDD%3A-Stayin-alive#comment-formhttps://blog.cm-dm.com/feed/atom/comments/231Is my software in class IIa, IIb, or III, Dark Fateurn:md5:95414fcca7d802573d176580ed925d022019-10-31T14:03:00+01:002019-10-31T14:03:00+01:00MitchRegulationsCE MarkClassificationIMDRFIVDRMDR<p>Here we are! <a href="https://en.wikipedia.org/wiki/Papal_conclave#Smoke_colors">White smoke</a> over the European Parliament! The MDCG 2019-11 guidance on qualification and classification of medical device software (MDSW) was published the 11th of October 2019.</p> <p>This guidance could compete with a FDA guidance, if there were an international contest of MD guidances. Similar structure, with definitions and reminders on the regulatory context, with plenty of examples, a bit verbose ... like a FDA guidance.<br /></p>
<h4>No surprise on qualification</h4>
<p>The MDCG 2019-11 reuses the successful receipt of the <a href="https://blog.cm-dm.com/post/2016/08/10/MEDDEV-2.1/6-2016">MEDDEV 2.1/6</a>: decision trees to qualify software as a medical device: one for MDSW and one for IVD SW. The decisions trees were adapted to the changes of the MDR/IVDR, compared to the MDD/IVDD. But there is no fundamental change: a software qualified as a SAMD for the MDD, remains qualified as a SAMD. Conversely, it's highly probable that software not qualified as SAMD with regard to the MDD will remain outside the scope of the MDR.<br />
For this reason, and without any surprise, we retrieve almost the verbatim of the examples found in the MEDDEV 2.1/6.<br />
<br />
The guidance also brings clarification on how to qualify SAMD using IVD data, either of SAMD, or of IVD SW, depending on the relevance of input data. A grey zone remains on software using both MD data and IVD data as input data. MD or IVD? We'll see in a couple of years if new examples are added to the guidance or the Manual on Borderline Classification.</p>
<h4>Annex XVI software</h4>
<p>The guidance also covers the case of software falling in devices listed in Annex XVI or their accessories. My two cents: don't try to place on the market such software right now. Wait for common specifications or guidances on Annex XVI.</p>
<h4>No surprise on classification</h4>
<p>Bid you farewell class I SAMD. The guidance doesn't resuscitate class I software and goes to a strict interpretation of the rogue, the villainous rule 11.<br />
In a last symbolic gesture, the MDCG even added at the very end of the guidance an example of class I SAMD. But it is not convincing at all. If I were the vendor of this poor software, I would claim its use for wellness only, outside the scope of the MDR, with the help of a cryptic disclaimer written by my lawyer.</p>
<h4>IMDRF SAMD categorization</h4>
<p>Probably knowing how many SAMD would be sentenced to class III with a too strict reading of rule 11, the MDCG called the IMDRF cavalry to assist them in their quest for mercy.<br />
The <a href="http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf">IMDRF SAMD categorization framework</a> proposes a classification system, which is summed up in a table of the IMDRF document. This table was borrowed and amended by the MDCG, to map the MDR regulatory classes to the IMDRF classification table.<br />
<a href="https://blog.cm-dm.com/public/25-MDR-Rule-11/IMDRF_SAMD_table_and_MDCG_SAMD_table_comparison.png" title="IMDRF SAMD table and MDCG SAMD table comparison.png"><img src="https://blog.cm-dm.com/public/25-MDR-Rule-11/.IMDRF_SAMD_table_and_MDCG_SAMD_table_comparison_m.png" alt="IMDRF SAMD table and MDCG SAMD table comparison.png" style="display:table; margin:0 auto;" title="IMDRF SAMD table and MDCG SAMD table comparison.png, Oct 2019" /></a><br />
The IMDRF cagetorization scheme looks like a risk assessment policy, to establish the SAMD class:</p>
<ul>
<li>Significance of SAMD information: likelihood that wrong data from software can lead to a damage,</li>
<li>State of healthcare: severity of the damage.</li>
</ul>
<p>Thanks to this table inserted into the MDCG, it's now possible to introduce a dose of likelihood in the determination of SAMD regulatory class. E.g.: risk of death places your software in class III if we disregard the likelihood, with a strict reading of rule 11. Risk of death (critical situation) with software driving clinical management (medium significance) places your software in class IIb. Phew...</p>
<h4>"Drives or influences", "in combination"</h4>
<p>The implementing rule "drives or influence" was already a classification propeller in the MDD. It retains its characteristics in the MDR and IVDR similar implementing rules. But for SAMD, there's a risk that SAMD class is going to be boosted by rule 11.<br />
If rule 11 classes SAMD higher than the implementing rule, rule 11 wins.<br />
<br />
This is also applicable to embedded software (de facto a combination of software and medical device, see section 6.2 of MDCG 2019-11). If embedded software provides functions only inside the scope of the intended use of the hardware host, the device result of the HW+SW combination is in the class of the hardware. But if software has some more functions extending the intended use, rule 11 has to be invoked to give its judgement.<br />
Thus, a device combination of a hardware host and an embedded software, can be placed in a higher class than hardware alone, per rule 11.</p>
<h4>IVD SAMD</h4>
<p>A few words on IVD SAMD classification. The guidance doesn't bring any interpretation of IVDR classification rules. A new guidance is in preparation for IVDR classification. This makes the title of the MDCG 2019-11 a kind of misleading advertising.<br />
But we shouldn't place too high expectations on this future guidance. IVD SAMD will be placed in IVDR regulatory class B or higher, like the other IVD devices.</p>
<h4>Conclusion</h4>
<p>Class I SAMD is dead. But SAMD will rarely be in class III, with the benevolent assistance of the IMDRF categorization. Almost 100% of SAMD will require the CE certificate of a notified body, to be placed on the market. A wave of SAMD certification requests is already growing.<br />
<br />
But where are the notified bodies able to certify SAMD? Where are the regiments of technical file reviewers, qualified at the same time on MDR/IVDR and SAMD, with a real understanding of software design processes and software risk management? In the MDR limbo.</p>https://blog.cm-dm.com/post/2019/10/31/Is-my-software-in-class-IIa%2C-IIb%2C-or-III%2C-Dark-Fate#comment-formhttps://blog.cm-dm.com/feed/atom/comments/228What happened to my Drug Prescription Assistance Software?urn:md5:e2dd2bc0e57bb772d00c92b66cbb77bc2019-10-09T14:39:00+02:002019-10-21T21:17:27+02:00MitchRegulationsCE MarkClassificationSaMD<p>We know that Drug Prescription Assistance Software are software as a medical device, <a href="http://curia.europa.eu/juris/document/document.jsf?docid=197527&text=&doclang=EN&pageIndex=0&cid=1939372">thanks to the European Court of Justice</a>. But how to CE mark that kind of software?</p> <h4>What is its regulatory class?</h4>
<p>Thanks to <a href="https://blog.cm-dm.com/post/2019/05/24/MDR%3A-one-year-left-and-too-late-for-class-I-software">the rogue, the villainous rule 11 of the 2017/745/EU MDR</a>, we know that our software is in class IIa. At least.<br />
Such software is used to detect contraindications, drug interactions and excessive doses (see the last paragraph at the bottom of the page through the link to the European Court of Justice above). Contraindications, drug interactions and excessive doses are hazardous situations for the patient. What if we have a software failure leading to a false negative on one of these hazardous situations?<br />
The bets are opened:</p>
<ol>
<li>In some cases, death of the patient, for instance if the medical personnel using the software doesn't detect the problem on a critical interaction, or</li>
<li>More potentially, severe consequences to the patient leading to additional medical intervention, or</li>
<li>If we are lucky, non-severe consequences to the patient.</li>
</ol>
<p>Thus, thanks to the rogue, the villainous rule 11, our software is, depending on the context:</p>
<ol>
<li>In class III, or</li>
<li>In class IIb, or</li>
<li>In class IIa.</li>
</ol>
<p>So, if we don't restrict by the intended use the type of drugs managed by our software, or the personnel using it, our software is potentially in Class III. I repeat <strong>C.L.A.S.S. T.H.R.E.E</strong>.<br />
<br />
Lucky us, class I 93/42/CE MDD -> class III 2017/745/EU MDR.</p>
<h4>What is its IEC 62304 safety class?</h4>
<p>Same player shoot again.<br />
Our software can lead to, depending on the context:</p>
<ol>
<li>Death or permanent injury, or injury requiring medical intervention: In class C, or</li>
<li>Non-serious injury: In class B,</li>
<li>Forget class A, unless you're able to demonstrate that you have a mitigation action outside software (e.g. a mandatory clinical protocol) leading to an acceptable risk of false negative.</li>
</ol>
<h4>Conclusion on classification</h4>
<p>Once again, if we don't restrict the intended use, in other words, if we allow any kind of drug prescription in our software, we have the perfect combo:<br />
2017/745/EU <strong>Class III</strong> and IEC 62304:2006+Amd1:2015 <strong>Class C</strong>.</p>
<h4>CE marking</h4>
<h5>Preclinical data</h5>
<p>Here, the path is well known, we have to apply the standards for software: IEC 82304-1, ISO 14971, IEC 62304 and IEC 62366-1. Plus standards on IFU, the future ISO 20417, and labelling ISO 15223-1.<br />
No need to say that we have to polish our design control process, and the associated documents. No need to say that it will cost an arm and a leg.</p>
<h5>Clinical data</h5>
<p>Ah ah, <strong>article 61 of the MDR</strong>, here we are!<br />
What does it say for Class III devices? Article 61.4, a clinical investigation is mandatory.<br />
I'm absolutely not a specialist of clinical investigations, but I'm sure we have a little problem. If my software isn't restricted by its intended use, my software addresses any patient with any pathology. Defining the cohort of patients in the clinical investigation protocol is going to be tricky!<br />
<br />
But, thinking out loud, my software doesn't have a clinical performance. It only displays information on drugs. It's the drugs, which support the clinical performance.</p>
<h5>Non-clinical validation?</h5>
<p>My software doesn't have any clinical performance, but only a technical performance:</p>
<ul>
<li>Displaying data coming from a thesaurus on drugs, and/or</li>
<li>Computing drug doses from weight or body mass index, namely a rule of three, and/or</li>
<li>Displaying some alerts based on thresholds found in the same thesaurus.</li>
</ul>
<p>So I don't need a clinical investigation. Performance bench testing should be enough, that's what allows the article 61.10. But this article 61.10 begins with the legal jargon: <em>without prejudice to 61.4</em>.<br />
<br />
Clinical investigation or not clinical investigation, that is the question.<br />
Pliz, European Commission, we need a guidance, a common specification, whatever.<br />
<br />
<br /></p>
<h4>Conclusion</h4>
<p>If you have a Drug Prescription Assistance Software to CE mark, craft very carefully the intended use. Or the probability of regulatory failure will be set to 1.<br />
<br />
<br /></p>
<h4>Edit 2019/10/21 after the publication of MDCG 2019-11</h4>
<p>From what we have in the new MDCG 2019-11 guidance on qualification and classification of software, we should be able to release the lash on Drug Prescription Assistance Software. The guidance makes use of the <a href="http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf">IMDRF SaMD possible risk categorization guidance</a>, especially the table in section 7.2. This table is copied and interpreted in table 1 of the MDCG guidance.<br />
Using this table 1 in the MDCG guidance we should be able to assert that we are in a case where our software:</p>
<ul>
<li><em>Drives clinical management</em>, and not the highest level <em>treat or diagnose</em> (the drug treats the patient),</li>
<li>May be used in <em>Critical situation or condition</em>, here we take the highest level since we don't know.</li>
</ul>
<p>In this case, we fall in the cell III.i, which places our software in class IIb.<br />
This is a better situation than class III. But it doesn't wipe out the issue on letting a notified body swallow the article 61.10 for a class IIb device. Bon appétit Notified Body.</p>https://blog.cm-dm.com/post/2019/10/09/What-happened-to-my-Drug-Prescription-Assistance-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/226MDR: one year left and too late for class I softwareurn:md5:1f019498920e4cd981d3a527503b0d802019-05-26T14:00:00+02:002019-07-22T14:06:30+02:00MitchRegulationsCE MarkClassificationMDRSaMD<p>Today is the 26th of May 2019. Rings a bell? In one year exactly, your class I MD software will be living in borrowed time on the EU market.<br />
Why?<br />
Because of rule 11 of 2017/745/UE Medical Device Regulation (MDR).</p> <p>As mentioned in <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">a previous article on MDR</a>, the rule 11 impacts all manufacturers of software medical devices. Another terrible news, the rule is applicable to all software whatsoever. Standalone or embedded. For, the rule 11 doesn't contain the word "standalone" or "embedded"<br />
<br />
In this context, I can assert that <strong>a majority of active devices will be at least in class IIa ; and most of standalone software, if not 99%, will be in class IIa</strong>.<br />
Why?<br />
Because of rule 11 of MDR.<br />
The rogue, the villainous rule 11.<br /></p>
<h4>Class IIa for everybody</h4>
<h5>Definition of medical device</h5>
<p>First, for software, the definition of a medical device didn't change between the directive and the MDR. Some words like "prediction, prognosis" were added, which clarify the definition. But these are minor changes. So, if your software is a medical device with the 93/42/CE Medical Device Directive (MDD), it is a medical device with the MDR.</p>
<h5>Qualification of medical device</h5>
<p>Software embedded in a hardware medical device is a medical device. Simple case. Standalone software is more subject to interpretations. i.e. Software running on non-dedicated hardware, like PC, tablet, smartphone etc.<br />
<br />
Now that the European Court of Justice<a href="http://curia.europa.eu/juris/document/document.jsf?text=&docid=197527&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=253077"> set a legal precedent</a> with <a href="https://ec.europa.eu/growth/sectors/medical-devices/current-directives/guidance_en">the MEDDEV 2.1/6</a>, we can officially use the decision tree #1 in this MEDDEV to determine whether standalone software (aka Software as Medical Device, SaMD) is a medical device or not.<br />
Using this workflow, if we have the three conditions:</p>
<ol>
<li>Software performing functions other than storage, communication and "simple search" (simple search has a very broad interpretation, have a look at <a href="https://ec.europa.eu/growth/sectors/medical-devices/current-directives/specific-areas-development_en">the manual on borderline classification</a>),</li>
<li>Software delivering new information, based on individual patient's data, and</li>
<li>The manufacturer (you) claiming that this new information is for diagnosis or treatment purposes,</li>
</ol>
<p>Then, this software is a medical device.<br />
<br />
To make it short:<br />
<strong>If software for diagnosis or treatment purposes then medical device</strong>.<br />
Note: I put apart the cases of accessories and implementing rules, extensive interpretation of "simple search" of MEDDEV 2.1/6 or manual on borderline classification.
<br /></p>
<h5>Classification of medical device</h5>
<p>With the MDD, most of software are in class I, unless you're unlucky to fall in a higher class to per MEDDEV 2.4/1 rev.9 or the Manual on Borderline Classification.<br />
With the new rule 11 of the MDR, things get harder. Standalone or embedded, apply rule 11 if your medical device contains software.<br />
The tree below shows the rule in a graphical representation:<br />
<a href="https://blog.cm-dm.com/public/25-MDR-Rule-11/MDR-rule-11-Danger-Regulatory-Hazard.png" title="MDR rule 11: Danger Regulatory Hazard, Apr 2019"><img src="https://blog.cm-dm.com/public/25-MDR-Rule-11/MDR-rule-11-Danger-Regulatory-Hazard.png" alt="MDR-rule-11-Danger-Regulatory-Hazard.png" style="display:table; margin:0 auto;" title="MDR rule 11: Danger Regulatory Hazard, Apr 2019" /></a></p>
<p>We can see that <strong>Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is in class IIa or higher</strong> (left part of the tree).<br />
<br />
But, we know per MEDDEV 2.1/6 that standalone software is qualified of medical device if the manufacturer claims that the intended use is for diagnosis or treatment.<br />
Thus, standalone software qualified of medical device is automatically classified in class IIa or higher. More, this rule is applicable to standalone software and embedded software, like IOT, and connected widgets of all sorts that blossomed the last 3-4 years.<br />
<br />
To make it short:<br />
<strong>If software in class I with MDD then software in class IIa with MDR</strong>.<br />
Note: I put apart the cases of accessories, implementing rules, monitoring, and some residual cases of SaMD not for diagnosis or treatment purposes.<br /></p>
<h4>Rewriting rule 11?</h4>
<p>We were told in our management courses that mourning and yelling isn't a good thing. Let's try being positive, and rewrite the rule 11 in a way more consistent with <strong>a risk-based approach</strong>!<br />
We can get inspiration from the <a href="http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf">IMDRF SaMD Risk Categorization Framework</a>. The table below comes from the IMDRF document: <img src="https://blog.cm-dm.com/public/25-MDR-Rule-11/.SAMD-Risk-Categorization_m.png" alt="SAMD-Risk-Categorization.png" style="display:table; margin:0 auto;" title="SAMD-Risk-Categorization.png, May 2019" />
<br />
This table shows that software driving clinical management (namely aid to diagnosis) for non-serious diseases is in class I. Thus, there is a consensus at the IMDRF level that an intended use claiming an aid to diagnosis on a non-serious disease can be in IMDRF category I (equivalent of EU regulatory class I).<br />
In the examples of the IMDRF document, we find in category I (class I):<br />
<em>SaMD that analyzes images, movement of the eye or other information to guide next diagnostic action of astigmatism</em>.<br />
If this is not an aid to diagnosis, I don't know what it is.<br />
<br />
Taking this information, we could change the rule 11 to align the regulatory classes with the consequences for the patient of a software failure. Here is the result of the modified rule 11 (wording to be improved, just food for thought):<br />
<br />
<a href="https://blog.cm-dm.com/public/25-MDR-Rule-11/MDR-rule-11-Proposed-Changes.png" title="MDR-rule-11-Proposed-Changes.png"><img src="https://blog.cm-dm.com/public/25-MDR-Rule-11/MDR-rule-11-Proposed-Changes.png" alt="MDR-rule-11-Proposed-Changes.png" style="display:table; margin:0 auto;" title="MDR-rule-11-Proposed-Changes.png, Apr 2019" /></a>
<br />
The changes proposed to rule 11 are pure speculation or utopia. Alas, we must live with the dystopian rule 11. So, what can we do?</p>
<h4>Action plan</h4>
<p>You have software in class I and the medical device directive hasn't been a big deal for you so far?
Here are some possible actions.</p>
<h5>Stay away, ever!</h5>
<p>Claiming that your product is a medical device is a marketing argument? Stay away! Don't listen to marketing departments, who want the CE mark on the device because competitors blah blah. They hardly know the consequences.<br />
Stop a product line with medical intended use. Or carefully carve your intended use to stay outside the definition of medical device. Stay inside the limits of storage, communication, and simple search. Don't claim a medical device intended use.</p>
<h5>Stay away, as long as possible!</h5>
<p>Postpone new products with medical intended use to 2021 or later. Wait for the dust to fall.<br />
Go to the American market first!</p>
<h5>Prepare the transition, now!</h5>
<p>If your devices are definitely medical devices, and the EU market is strategic, then you have no choice. You must plan a transition to the EU MDR. If you read these lines and have been in the MD industry for long, I suppose that you've already set up (or thought to set up) an action plan, and that you shudder at the thought of even finding a Notified Body.<br />
If you are new to the MD industry, don't think about a transition unless you have a very good reason to do so. Go back to the first two actions, and consider seriously other markets, like the USA. I'm not happy to write that.</p>
<h4>Costs and schedule</h4>
<p>I can throw a few figures to give you an idea of the immensity of the task:</p>
<ul>
<li>100 kEuros (or 100 kDollars, or 6.02E23 Imperial Credits) to prepare your Class IIa MDR submission,</li>
<li>In the worst case, add a clinical investigation,</li>
<li>At least one year to get the CE certificate,</li>
<li>At least one person full-time managing the CE marking project,</li>
<li>Changes you can't imagine in the design of your software,</li>
<li>About 50-100 documents to write and review, and maintain in the long run,</li>
<li>A PMS and PMCF to set up (If you don't know what a PMS and PMCF are: go back to the first two possible actions).</li>
</ul>
<p>You have an idea of the order of magnitude of the human and financial effort.<br /></p>
<h4>Too late for the directive</h4>
<p>Don't put hope on changing the intended use of your existing device and getting a certification with the MDD in class IIa. The notified bodies don't take new submission with the MDD. They're fully booked. The availability of Notified Bodies is a major bottleneck. Contact me in private message if you know one with spare time!<br />
More, it is a very bad idea to CE mark a SaMD with the MDD. When the MDD expires in May 2020, the design of your device will be frozen. Something totally in contradiction with software lifecycle in general.</p>
<h4>A new hope</h4>
<p>Let me end, though, on a positive note.<br />
Reading the bare-bone text of the MDR without the right interpretation can lead to exageration. In other words, the 2017/745/UE MDR lacks guidances.<br />
Good news: a software classification guidance, written by the software WG of the CAMD Implementation Taskforce (<a href="https://www.camd-europe.eu/regulatory/medical-devices-regulation-vitro-diagnostics-regulation-mdr-ivdr-roadmap/">see their roadmap</a>), will be published by the end of 2019. We have to right to hope that they'll have a relaxed interpretation of rule 11 (<em>no, non, nein, we didn't want to say that!</em>).<br />
<br />
Other good news: Notified Bodies are winning their MDR notification, to begin with BSI and TÜV SÜD. Others are in the pipe but the risk of bottleneck is still present.<br />
<br />
Anyway, if you can stay away from the MDR and its rule 11, then <a href="https://youtu.be/Hs2FcUu_N5k" title="Nirvana - Stay Away">stay away</a>.</p>https://blog.cm-dm.com/post/2019/05/24/MDR%3A-one-year-left-and-too-late-for-class-I-software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/219FDA 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/211Is my software in class I, IIa, IIb or III - 2016 Revolutionurn:md5:661a1563a9e94bd4426981336c4f37a22016-07-22T13:28:00+02:002019-11-09T20:23:45+01:00MitchRegulationsCE MarkClassificationIEC 62304IMDRFISO 14971<p>The final version of the negotiated text of the new Medical Device Regulation (MDR) was published by the European Commission in June 2016. It is a big upheaval for all medical device manufacturers. Contrary to what the <a href="https://blog.cm-dm.com/post/2016/02/17/Breaking-news%3A-standalone-software-is-not-an-active-medical-device%21">draft version of September 2015</a> contained, software is invited to the party.</p> <h4>Software is an active medical device</h4>
<blockquote><p>Software shall be considered an active device.</p></blockquote>
<p>It's written at the end of the definition of <em>active device</em>. We were doubtful, we're reassured.<br />
More, in the implementing rules of the classification rules in Annex VII, we have:</p>
<blockquote><p>If the software is independent of any other device, it is classified in its own right.</p></blockquote>
<p>Standalone software is then an active device and it is classified in its own right.</p>
<h4>Classification rule 10a</h4>
<p>The biggest change in the MDR is the introduction of a new classification rule, specific to standalone software:</p>
<blockquote><p>Rule 10a<br />
<br />
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes, is in class IIa, except if such decisions have an impact that may directly or indirectly cause:<br />
- the death or an irreversible deterioration of the state of health, in which case it is in class III;<br />
- a serious deterioration of the state of health or a surgical intervention, in which case it is in class IIb.<br />
<br />
Software intended to monitor physiological processes is in class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations is such that it could result in immediate danger to the patient, in which case it is in class IIb.<br />
<br />
All other software is in class I.</p></blockquote>
<p><br />
This rule shows clear similarities with the works of the <a href="http://www.imdrf.org/workitems/wi-samd.asp">IMDRF on risk categorization of software as a medical device</a>. The criteria of categories I to IV of IMDRF are close to the criteria of classes I to III of rule 10a.</p>
<h4>A major change for standalone software</h4>
<p>The rule 10a is a major change since the classification is based on the purpose and the risk assessment of the device, and not the purpose of the device alone. This notion of risk was already present in the directive 93/42/CE, in rules 6, 9, 11 (<em>potentially hazardous</em>) and 10 (<em>immediate danger</em>), shifting the class up one level for affected devices.<br />
Now, for standalone software, the risk assessment is the keystone of the regulatory classification. A single risk with high severity can push a software medical device to a higher class.<br />
The other major change is the possibility to have standalone software in class III. With the directive, it's only possible per the implementing rule 2.3 of annex IX.</p>
<h4>No classification change for embedded software</h4>
<p>The classification of embedded software is left unchanged in the MDR. Embedded software takes the class of its device.<br />
Likewise, the implementing rule 2.3 is still present: software, which drives or influence a medical device takes its class. Unfortunately, the MDR doesn't define the word <em>influence</em>, leaving the rule to interpretation, like in the directive.<br /></p>
<h4>Advantage</h4>
<p>The single advantage of this new rule is to better synchronize the definitions of IEC 62304 safety classes and the MDR classes. However, <a href="https://blog.cm-dm.com/post/2016/05/06/Is-my-software-in-class-A%2C-B-or-C-2015-reloaded">the last changes in the definition of safety classes in IEC 62304 Amd1 2015</a> are not present in the wording of MDR rule 10a.<br />
We will have to wait for some feedback from the authorities to see if a software medical device with an improbable risk of severe injury (thus usually making the risk acceptable) will be put in class I or not.</p>
<h4>Drawbacks</h4>
<p>The main drawback of rule 10a (I take the point of view of manufacturers) is to likely push the regulatory class of software to levels higher than current rules of the 93/42/CE directive. It is possible to have software in class I per rule 12 of the directive. Eg: software delivering information but not for direct diagnosis.<br />
With the new MDR, the rule clearly shows that:</p>
<ul>
<li>If software delivering information for diagnosis is in IEC 62304 class B (non-serious injury), it will be in MDR class IIa per rule 10a,</li>
<li>If software delivering information for diagnosis is in IEC 62304 class C (serious injury but not death), it will be in MDR class IIb per rule 10a</li>
<li>If software delivering information for diagnosis is in IEC 62304 class C (death), it will be in MDR class III per rule 10a</li>
</ul>
<h4>Examples</h4>
<p>Since we don't have any examples of classification per the new MDR, we have to look elsewhere. Fortunately, the <a href="http://www.imdrf.org/workitems/wi-samd.asp">IMDRF risk categorization rules</a> provide very interesting examples: they can be interpreted for rule 10a. Let's see examples for medical imaging post-processing software, which are usually in class IIa or class IIb per directive rule 10.</p>
<h5>Still Class IIa with MDR</h5>
<p><em>SaMD that interpolates data to provide 3D reconstruction of a patient’s computer tomography scan image, to aid in the placement of catheters by visualization of the interior of the bronchial tree; in lung tissue; and placement of markers into soft lung tissue to guide radiosurgery and thoracic surgery</em><br />
It's category II for IMDRF, thus likely to be class IIa for MDR.</p>
<h5>Still Class IIb with MDR</h5>
<p><em>SaMD that is used to provide information by taking pictures, monitoring the growth or other data to supplement other information that a healthcare provider uses to diagnose if a skin lesion is malignant or benign</em><br />
It's category III for IMDRF, thus likely to be class IIb for MDR.</p>
<h5>Class III with MDR</h5>
<p><em>SaMD that calculates the fractal dimension of a lesion and surrounding skin and builds a structural map that reveals the different growth patterns to provide diagnosis or identify if the lesion is malignant or benign</em><br />
It's category IV for IMDRF as<br />
<em>SaMD is used to diagnose a disease that may be life threatening, may require major therapeutic intervention, and may be time sensitive</em>,<br />
thus likely to be <strong>class III</strong> for MDR.<br />
<strong>BAM!</strong><br /></p>
<p><em>SaMD that performs diagnostic image analysis for making treatment decisions in patients with acute stroke, i.e., where fast and accurate differentiation between ischemic and hemorrhagic stroke is crucial to choose early initialization of brain-saving intravenous thrombolytic therapy or interventional revascularization</em><br />
It's category IV for IMDRF as<br />
<em>SaMD is used to treat a fragile patient in a critical condition that is life threatening</em>,<br />
thus likely to be <strong>class III</strong> for MDR.<br />
<strong>BAM!</strong><br />
<br />
Warning: all of this is speculation based on the <a href="http://www.imdrf.org/workitems/wi-samd.asp">IMDRF document</a>. We have to wait for a new version of MEDDEV 2.4/1 or MEDDEV 2.1/6 to see the interpretation of this rule and what kind of examples will be given for class III standalone software.<br /></p>
<h4>What to do if your software is pushed to a higher class?</h4>
<h5>Market withdrawal</h5>
<p>First and foremost solution: to withdraw your software. If the additional certification costs are not likely to be covered by the market (the market won't accept higher prices, despite the turmoil) then this is one possible solution.<br />
For devices rocketed to class III, this is probably the only solution, given the additional costs incurred by clinical studies.</p>
<h5>Do the job</h5>
<p>The second solution is simply to determine the new regulatory class, do a gap analysis, and set a plan to make the software compliant with its new class. Something to do for the QMS whatsoever.</p>
<h5>Change software</h5>
<p>The third solution is to change the intended use and/or the critical functions to make it stay in its current class. It's possible if the functions, which put the device in a higher class per risk assessment, are a nice-to-have and not a must-have. You should remove/change them only if it won't make the end-users unsatisfied or the clinical outcome unsatisfactory.</p>
<h5>Change software for bigger</h5>
<p>The last solution is to seize the opportunity to implement all the functions, which were left apart, because they would have pushed your software to a higher class. Change software for better, and do the job!</p>
<h4>Hello Notified Bodies!</h4>
<p>We've seen that it is reasonably foreseeable to expect that a significant number of standalone software will be pushed to higher classes. Higher than class I. Thus Notified Bodies will have to absorb the overload of devices of class IIa or higher to CE mark.<br />
The situation is not as bad as for IVD's. But NB's are already struggling to overcome the wave of denotifications, the unannounced audits, and the pressure of Competent Authorities. Manufacturers can expect long delays between their requests and the date of the NB 's audit.</p>
<h4>Conclusion</h4>
<p>Standalone software is put in the turmoil by the new MDR, like every other type of medical device. Manufacturers of low-class (mainly class I) devices will face changes of classification. Some manufacturer will see their devices propelled to class III. The transition period is at most of four years. It means that by 2020 all manufacturers will have to be ready for the new MDR.<br />
Manufacturers, consultants and Notified Bodies, we have plenty of work ahead of us!<br />
<br />
<br />
In <a href="https://blog.cm-dm.com/post/2016/09/02/EU-Medical-Device-Regulation-changes-for-software">a next article</a>, we'll see other changes for software brought by the MDR. See also the <a href="https://blog.cm-dm.com/post/2019/10/31/Is-my-software-in-class-IIa%2C-IIb%2C-or-III%2C-Dark-Fate">interpretation of rule 11 by the MDCG</a> (Medical Device Coordination Group) in the final version of the MDR.</p>https://blog.cm-dm.com/post/2016/07/22/Is-my-software-in-class-I%2C-IIa%2C-IIb-or-III-2016-Revolution#comment-formhttps://blog.cm-dm.com/feed/atom/comments/191Breaking news: standalone software is not an active medical device!urn:md5:c27787131e930efe37395509c6c1fb172016-02-17T10:13:00+01:002016-07-31T21:53:33+02:00MitchRegulationsCE MarkClassification<p><strong>Warning: obsolete content. Please read: <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">Is my software in class I, IIa, IIb or III</a>.</strong><br />
Last update on 2016/07/31.<br />
<br />
The British Standard Institute published in February 2016 a white paper titled <a href="http://www.bsigroup.com/en-GB/medical-devices/resources/whitepapers/downloads/">How to prepare for and implement the upcoming MDR – Dos and don’ts</a>. Register on BSI website to download the paper.<br />
This white paper gives top-notch recommendations on the way to compliance with the future EU Medical Device Regulation (MDR), based on the draft version. But their interpretation of MDR classification rules on standalone software are somewhat surprising.</p> <p>One the latest version of the draft MDR (they're not all public, that' work in progress) can be <a href="http://www.consilium.europa.eu/en/press/press-releases/2015/09/23-medical-devices/">downloaded on the European Council website</a>.<br /></p>
<h4>Standalone software definition removed</h4>
<p>Compared to the early versions of 2012, the MDR versions of mid 2015 and after don't include the term <em>standalone software</em> in the definition of active medical device.<br /></p>
<h5>Before, version of 2012</h5>
<blockquote><p>‘active device’ means any device, the operation of which depends on a source of electrical energy or any source of power other than that directly generated by gravity and which acts by changing the density of or converting this energy. Devices intended to transmit energy, substances or other elements between an active device and the patient, without any significant change, shall not be considered to be active devices.<br />
<strong>Stand alone software shall be considered an active device</strong>.</p></blockquote>
<p>Text set bold here for emphasis<br /></p>
<h5>After, version of 2015</h5>
<blockquote><p>‘active device’ means any device, the operation of which depends on a source of energy other than that generated by the human body for that purpose or by gravity and which acts by changing the density of or converting this energy. Devices intended to transmit energy, substances or other elements between an active device and the patient, without any significant change, shall not be considered to be active devices.<br /></p></blockquote>
<h5>Consequences</h5>
<p>When the version without <em>standalone software</em> was published, most of readers didn't notice the change or just think that the definition shouldn't be too specific. Specific definitions have the drawback to exclude peculiar cases from their scope.<br />
<br />
But this is not the real consequence.<br />
<br />
The authors of BSI white paper, who are kind of messengers of European Commission city of the gods, brought to us, mere mortals, the real consequence of this change.<br />
<br />
Page three of the white paper, they say:<br />
<br /></p>
<p style="margin-left: 40px; font-style: italic;">Standalone software is no longer classified as active medical device: revisit classification of software currently on the market as medical device and make gap assessment for additional technical requirements for software classified in higher risk class.</p>
<p><img src="https://blog.cm-dm.com/public/.confusion_ahead_s.png" alt="confusion_ahead.png" style="display:table; margin:0 auto;" title="confusion_ahead.png, Feb 2016" /></p>
<p style="text-align:center; color:red; font-weight: bold;">Standalone software is no longer classified as active medical device?</p>
<br/>
<p style="text-align:center; font-weight: bold;">Standalone software is no longer classified as active medical device!</p>
<p><br /></p>
<h5>Computer science unplugged</h5>
<p>OK, standalone software is not an active medical device. Let's unplug it!<br />
That's possible to do your work unplugged, when you're a rock-star!<br />
That's possible to do <a href="http://csunplugged.org">computer science unplugged</a>, but that's not very useful in professional life!<br /></p>
<h5>Don't say his name</h5>
<p>Or perhaps should we ask Harry Potter how to run software without electric power?<br />
Or perhaps He-Who-Must-Not-Be-Named was removed from the definition?<br />
<br />
Seriously:<br /></p>
<h4>Where does it come from?</h4>
<p>This change seems to come from the situation where some kind of standalone software are put in class I with the current 93/42/CE directive, per rule 12, whereas they should be set in a higher class.<br />
Hum, I thought that the implementing rule set in Annex IX 2.3 of the directive:<br /></p>
<p style="margin-left: 40px; font-style: italic;">Software, which drives a device or influences the use of a device, falls automatically in the same class.</p>
<p>was there to avoid such situation.<br />
We retrieve the same rule in the new MDR, with precision on independent software:<br /></p>
<p style="margin-left: 40px; font-style: italic;">Software, which drives a device or influences the use of a device, falls automatically in the same class as the device.
<br/>
If the software is independent of any other device, it is classified in its own right.</p>
<p>This new sentence in the implementing rule formalizes what manufacturers are already doing with the current directive.
<br />
Perhaps that wasn't enough and in some rare cases standalone software is set in class I whereas it should be in class IIa or IIb. But it doesn't explain the decision to remove standalone software from active medical devices.<br />
<br />
Let's try some examples.</p>
<h4>Drug dose calculator</h4>
<p>A drug dose calculator uses patient's weight, average SOP2 and heart rate as input data. This is a standalone software medical device, for it uses patient data to compute a value intended to treat the patient condition.</p>
<h5>Current MDD</h5>
<p>Classification with the current medical device directive:</p>
<ul>
<li>Rule 1 : non-invasive device, Ok applicable,</li>
<li>Rules 2, 3 and 4 : not applicable,</li>
<li>Rules 5, 6, 7, 8 : invasive devices, not applicable,</li>
<li>Ah ah, active devices, my software is an active device, let's see there rules:
<ul>
<li>Rule 9: active therapeutic devices intended to administer or exchange energy, not applicable,</li>
<li>Rule 10 : Active devices intended for diagnosis, not applicable</li>
<li>Rule 11 : All active devices intended to administer and/or remove medicines, <strong> we could say that it is applicable but no, this rule is made for devices like infusion pumps, not standalone software</strong>, this is probably the kind of situation that the change is trying to address,</li>
<li>Rule 12 : default rule, <strong>applicable</strong>,</li>
</ul></li>
<li>Rules 13 to 18 : special rules, not applicable.</li>
</ul>
<p>Conclusion: drug dose calculator is in class I per rule 12.</p>
<h5>Future MDR</h5>
<p>Classification with rules in annex VII of the future medical device regulation:</p>
<ul>
<li>Rule 1 : non-invasive device, Ok applicable,</li>
<li>Rules 2, 3 and 4 : not applicable,</li>
<li>Rules 5, 6, 7, 8 : invasive devices, not applicable,</li>
<li>Ah ah, active devices, my software is NOT an active device, rules 9 to 12 not applicable,</li>
<li>Rules 13 to 23 : special rules, not applicable.</li>
</ul>
<p>Conclusion: drug dose calculator is in class I per rule 1.<br />
This is not very convincing.</p>
<h5>If software drives or influence another device</h5>
<p>If the drug dose calculator is used to, say, set the parameters of an infusion pump, it will take the class of the infusion pump: class IIb. The new MDR doesn't change the result.</p>
<h4>Post-processing medical imaging software</h4>
<p>A medical imaging software post-processes DICOM compliant data to produce new data to help physicians in their diagnostics. This is a standalone software medical device, for it uses patient data to compute new data intended to diagnose the patient's condition.</p>
<h5>Current MDD</h5>
<p>Classification with the current medical device directive:</p>
<ul>
<li>Rule 1 : non-invasive device, Ok applicable,</li>
<li>Rules 2, 3 and 4 : not applicable,</li>
<li>Rules 5, 6, 7, 8 : invasive devices, not applicable,</li>
<li>Ah ah, active devices, my software is an active device, let's see there rules:
<ul>
<li>Rule 9: active therapeutic devices intended to administer or exchange energy, not applicable,</li>
<li>Rule 10 : Active devices intended for diagnosis, <strong>applicable</strong>, per bullet 3 <em>intended to allow direct diagnosis</em>,</li>
<li>Rule 11 : All active devices intended to administer and/or remove medicines, not applicable,</li>
<li>Rule 12 : default rule, not applicable as rule 10 is applicable,</li>
</ul></li>
<li>Rules 13 to 18 : special rules, not applicable.</li>
</ul>
<p>Conclusion: medical imaging post-processing software is in class IIa per rule 10.</p>
<h5>Future MDR</h5>
<p>Classification with rules in annex VII of the future medical device regulation:</p>
<ul>
<li>Rule 1 : non-invasive device, Ok applicable,</li>
<li>Rules 2, 3 and 4 : not applicable,</li>
<li>Rules 5, 6, 7, 8 : invasive devices, not applicable,</li>
<li>Ah ah, active devices, my software is NOT an active device, rules 9 to 12 not applicable,</li>
<li>Rules 13 to 23 : special rules, not applicable.</li>
</ul>
<p>Conclusion: medical imaging post-processing software is in class I per rule 1.<br />
Bye bye notified body!</p>
<h5>If software drives or influence another device</h5>
<p>It is admitted that post-processing medical imaging software doesn't drive or influence the use of imagers. For example, software post-processing CT images is most of times in class IIa, even if the CT scanner is in class IIb.<br />
The new definition in the future MDR doesn't change the conclusion on the application of this implementing rule.</p>
<h4>Conclusion</h4>
<p>It has to be agreed that we're missing something.<br />
Trying to apply the classification rules of the future MDR, we reach the opposite, lower class, of what the regulator is seeking to obtain, higher class.<br />
<br />
The published MDR versions are still drafts, they can change until the final version of the MDR. Let's hope that this will be clarified, either in the MDR, or in future MEDDEV guidances.<br />
<br />
<br />
BTW, this post shouldn't stop you reading the BSI white paper. This is a top-level document on the consequences of the MDR.</p>https://blog.cm-dm.com/post/2016/02/17/Breaking-news%3A-standalone-software-is-not-an-active-medical-device%21#comment-formhttps://blog.cm-dm.com/feed/atom/comments/187IMDRF consultation: Software as a Medical Deviceurn:md5:853ca6524cc74e9bf16f6e515a6ba6622014-05-26T00:02:00+02:002014-05-26T00:02:00+02:00MitchMiscClassificationFDAIEC 62304IMDRF<p>After MHRA's guidance on standalone software, we continue with another official document published by the International Medical Device Regulators Forum (IMDRF): the <a href="http://www.imdrf.org/consultations/cons-smd-samd.asp">consultation on software as a medical device: Possible Framework for Risk Categorization and Corresponding Controls</a>.</p> <h4>A consultation</h4>
<p>This is a consultation, thus this document is just the draft version of a future guidance that is left open to anybody for comments by may 31th 2014. We can expect in the coming months a new version of this document.<br />
There is no fixed schedule of releases, hence the working group is waiting for the results of the comments phase to decide what to do next.</p>
<h4>Four software classes</h4>
<p>The major innovation of this document is to introduce <em>four risk-based types based on the levels of impact</em> (quote from the document):</p>
<ul>
<li>Very High Impact</li>
<li>High Impact</li>
<li>Medium Impact</li>
<li>Low Impact</li>
</ul>
<p>This is clearly new compared to existing software categorizations, with three levels found in IEC 62034 (Class A, B, and C) as well as in <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm#6">FDA level of concern</a> (major, moderate, and minor).<br />
Choosing to categorize software in four classes is consistent with the general classification of medical devices (and in vitro diagnosis) defined by the GHTF (the "father" of IMDRF), which defines four classes as well.<br /></p>
<h4>Conditions</h4>
<p>Another innovation, and probably the best one of this document, is to introduce a set of rules to define into which category a software falls. This set of rules is based on the types functionalities found in standalone software.<br />
<br />
IEC 62304 is based on risk assessment, and FDA level of concern (LoC) is bound to its medical device classification.<br />
IMDRF categories are based on the patient condition in which software is used, or the effect of software on patient. Unlike IEC 62304 classes or FDA LoC, these categories are not based on software risks on patient.<br />
<br />
So, we rely more on the intended use and less on the risk assessment to define the software category. This is really handy.<br />
Worth reading it!</p>
<h4>How to branch to the existing standards and regulations</h4>
<p>Of course, the question coming to everybody's lips is: how do we map IMDRF classes with existing - and official - regulations and standards?<br />
The IMDRF tries to give an answer by introducing a relationship between the four classes and the kind of "controls" that a manufacturer has to do to mitigate risks to an acceptable level. Basically, these controls are risk management, clinical assessment, and:</p>
<ul>
<li>Very High Impact = IEC 62304 class C</li>
<li>High Impact = IEC 62304 class B</li>
<li>Medium Impact = IEC 62304 class A</li>
<li>Low Impact = IEC 62304 class A</li>
</ul>
<p>There is however no difference of control between medium and low impact.<br />
Perhaps we have to wait for further versions of this document to have more information about the differences between medium impact and low impact categories.<br />
<br />
All in all, this document is very innovative and brings a new way to categorize standalone software. It is however not complete and we can expect changes to make it more articulate in the next versions.</p>https://blog.cm-dm.com/post/2014/05/26/IMDRF-consultation%3A-Software-as-a-Medical-Device#comment-formhttps://blog.cm-dm.com/feed/atom/comments/145FDA issues final Mobile Medical Apps Guidanceurn:md5:8586e8788a2ecf6591529b0f5e7f27b62013-09-25T17:28:00+02:002013-09-25T16:56:10+02:00MitchRegulationsClassificationFDAGuidancemHealthmobile medical app<p>After two years of gestation, FDA issues final Guidance on Mobile Medical Apps!</p> <p>The guidance gives the definition of a mobile medical medical app.<br />
Basically, there are 3 categories, an app is a medical device if:</p>
<ul>
<li>it is an extension of an existing medical device,</li>
<li>it transforms the mobile platform by using on-purpose peripherals,</li>
<li>it performs patient specific data analysis for diagnosis or treatment.</li>
</ul>
<p>Read carefully the definitions of FDA, those above are summed-up for easy reading.<br />
<br />
But these rules are not enough, many apps are borderline as their perform tasks related to patient condition but don't match the 3 above rules.<br />
FDA gives a list of borderline cases in its guidance, like <em>Provide patients with simple tools to organize and track their health information</em>. For these borderline cases, <em>FDA intends to exercise enforcement discretion</em>.<br />
<br />
In other words, how can you be sure that the App you develop is not a mobile medical app?<br />
Just ask FDA, or apply the <em>not seen, not taken</em> policy, which I don't recommend!<br />
<br />
But the most interesting part is probably in the annexes. They contain a long list of examples that can help you figure out whether your app is a regulated device or not. Especially, FDA gives cases, for which mobile apps are not medical devices.<br />
A lot of cases are covered by these examples. There is actually little chance that an app manufacturer doesn't find a case that matches his app in the list.</p>
<pre></pre>
<p>More information on <a href="http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm369431.htm">FDA news release</a>.</p>https://blog.cm-dm.com/post/2013/09/25/FDA-issues-final-Mobile-Medical-Apps-Guidance#comment-formhttps://blog.cm-dm.com/feed/atom/comments/134How to bring legacy software into line with IEC 62304? - part 2urn:md5:efd8ae320494229f7c81016169cae8822013-03-01T14:31:00+01:002013-03-08T15:44:08+01:00MitchStandardsClassificationdevelopment processIEC 62304risk management<p>We've seen <a href="https://blog.cm-dm.com/post/2013/02/06/How-to-bring-legacy-software-into-line-with-IEC-62304-part1">in the last post</a> how to manage changes in legacy software. Let's see it from another point of view: the type of legacy software.</p> <h3>Type of legacy software</h3>
<p>The type of legacy software may have a huge impact on the way it will be managed in a software development.</p>
<h4>Legacy software wasn't in the same class of risks</h4>
<p>Software development usually begins by determining the class of software. It's interesting to determine in which class the legacy software would have been, if IEC 62304 had been applied when it was developed.<br />
If both cases are in the same class (eg software in old device and software in new device are in class B) then this is consistent to reuse software in a new device. But if both cases are not in the same class, things can be more tricky:</p>
<ul>
<li>Old = class A, new = class B or C: raises a red flag, does this legacy software match the high standards of the new context?</li>
<li>Old = class C, new = class A: raises a red flag, does this legacy software match the low standards of the new context?</li>
<li>Old = class C, new = class B, or Old = class B, new = class A or C: very context-dependent.</li>
</ul>
<p>In other words, if there is a difference of class in the old and new contexts, then the question whether the software matches its new context is relevant.<br />
That said, this analysis is preliminary to other questions and should be made at first.</p>
<h4>Legacy software is a framework</h4>
<p>This is the worst case. Legacy software is a framework which offers a long list of services. They are used by newly developed software but are not documented. Doing the documentation would be a tedious task, especially for software in class C.</p>
<h5>Treat it as a SOUP?</h5>
<p>We saw in the last post that legacy software can be treated as a SOUP. The problem with a framework, is that the SOUP is bigger than the new software. Even if IEC 62304 doesn't define any criteria on the size of SOUPs, it is conceptually difficult to have a SOUP bigger than own-developed software.<br />
If the framework is supposed to be changed during the new development cycle, then cases described in my previous post are there to define an action plan.</p>
<h5>Don't treat it as a SOUP?</h5>
<p>If the framework was tailor-made for a family of devices, it may be worth doing reverse engineering and document the framework to be reusable in any future device of the manufacturer.<br />
If it's worth doing it, then the framework documentation shall be compliant with the expectations of the standard for the highest expected class of risk in the family of devices.<br />
For example, if the family of devices contains class A and class B software, then the framework shall be documented with the level of scrutiny required for class B devices.<br />
By the way, the framework should benefit from this reverse engineering. It's probable that risk mitigation measures were already implemented but left undocumented. A new round of risk analysis can unveil pitfalls in these risk mitigations. As a consequence, new mitigation actions will be implemented and the framework will be seen as more secure.</p>
<h5>Treat it as a SOUP!</h5>
<p>However if the framework is used as is, the black-box SOUP approach should be feasible. This is what everybody does with frameworks developed outside medical field, like C++ or java general-purpose frameworks.<br />
Like any other SOUP, the necessary tasks are focussed on risk assessment:</p>
<ul>
<li>Identify functional and technical requirements managed by the framework,</li>
<li>Do a risk analysis of these functional and technical requirements,</li>
<li>Do a risk analysis of framework integration in the medical device,</li>
<li>Do a risk analysis of known bugs in the framework,</li>
<li>If necessary, add a mitigation layer between the framework and newly developed software.</li>
</ul>
<p><img src="https://blog.cm-dm.com/public/19-legacy-SW/.Slide4-trunc_m.jpg" alt="software in medical devices - Legacy Software is a framework" style="display:block; margin:0 auto;" title="software in medical devices - Legacy Software is a framework, fév. 2013" /></p>
<h5>Testing</h5>
<p>Since a framework delivers a lot of services, it may be necessary to add a step of validation of the framework alone. For mission-critical software, it may be deemed necessary to validate a SOUP alone. In the case of a framework, a test plan should be created where every service and/or function used by the device is tested alone. The framework is verified as a black box with this test plan and validated once the tests pass.<br />
The next step is to verify the newly developed software + the framework with an adequate test plan.</p>
<h4>Legacy software is not a medical device</h4>
<p>This is not a problem. It is 100% aligned with the SOUP concept.<br />
Short answer: Treat it like a SOUP.<br />
<br />
However, if is it a framework with existing modules, where new modules are added with medical intended use, the problem is not so simple to solve.<br />
The solution may be architectural, to isolate new medical device module and legacy modules. I already talked about this solution and the problem of risks propagation through the framework <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">in another article about standalone software</a>.</p>
<h4>Legacy software is a prototype</h4>
<p>There are dozens of prototypes that are designed by R&D teams, without any consideration to quality and regulatory. That's OK because, they design a prototype, which purpose is to be a proof of concept. But when it happens that the concept can be turned into a medical device placed on the market, trouble begins!<br />
Not so much trouble, though. A prototype always requires lots of changes before it is placed on the market. The prototype is one big input data of the development cycle: input R&D prototype, output validated device.
<br />
<br /></p>
<h4>Conclusion</h4>
<p>The principal underlying idea behind these cases is risk assessment. What are the risks brought by the legacy software, are they already mitigated, how can they be mitigated. The cases I described are classic, if not theoretical. Cases in real life are all different. The cases above are just here to provide clues to define the right action plan for real cases<br />
Edit: <a href="https://blog.cm-dm.com/post/2013/02/27/How-to-bring-legacy-software-into-line-with-IEC-62304-part-3">see next post</a> for some more information.</p>https://blog.cm-dm.com/post/2013/02/15/How-to-bring-legacy-software-into-line-with-IEC-62304-part2#comment-formhttps://blog.cm-dm.com/feed/atom/comments/83How to bring legacy software into line with IEC 62304? - part 1urn:md5:0ce8ba01d4cb1d8d27152dbd09a6f9ed2013-02-22T14:09:00+01:002013-03-08T15:42:43+01:00MitchStandardsClassificationdevelopment processIEC 62304risk management<p>Most of medical devices manufacturers have legacy software that was not designed according to IEC 62304. The devices that embed legacy software were once verified and validated. These devices and their software work well and no major adverse event were raised by software issues.<br />
But one day, the manufacturer decides that it's time to bring that legacy software into line with IEC 62304, to align the technical file of that software (or the contribution of software to technical file content) with up-to-date standard or regulatory requirements.</p> <p>Usually, the reason that triggers this decision is either to design a new version of an existing device or to integrate that software in a new medical device.<br />
<br />
How to do it? The content of the action plan will be different, depending on the type of legacy software or the type of changes made to the legacy software.<br /></p>
<h3>Types of changes made to legacy software</h3>
<p>There are many possible types of changes that can be made to an existing software. One way to to sort them is according to the deepness of changes in design or in functionalities:</p>
<ul>
<li>No changes: neither architecture, nor detailed design, nor functionalities are changed. Some bugs may be fixed, though,</li>
<li>Slight changes: the software architecture is not modified, only detailed design is modified, and/or existing functionalities are enhanced or updated,</li>
<li>Deep changes: the software architecture is deeply modified and/or new functionalities are added.</li>
</ul>
<h4>1st case: Legacy software is not changed</h4>
<p>This case is the most simple, and the answer is straightforward: <strong>treat legacy software as a SOUP</strong>.<br />
<img src="https://blog.cm-dm.com/public/19-legacy-SW/.Slide1_m.jpg" alt="Software in medical devices - Legacy Software as a SOUP" style="display:block; margin:0 auto;" title="Software in medical devices - Legacy Software as a SOUP, fév. 2013" /></p>
<h5>Risk analysis</h5>
<p>The SOUP is an input data of design, first at system level and second at software level. Like any other SOUP, the necessary tasks are focussed on risk assessment:</p>
<ul>
<li>Identify functional and technical requirements managed by the SOUP,</li>
<li>Do a risk analysis of these functional requirements,</li>
<li>Do a risk analysis of SOUP integration in the medical device,</li>
<li>Do a risk analysis of known bugs in the SOUP</li>
</ul>
<h5>Software mitigation actions</h5>
<p>The software mitigation actions output of the risk analysis may be of two types:</p>
<ul>
<li>Either the mitigation actions are made in the architecture of software that integrates the SOUP, for instance with a mitigation layer,</li>
<li>Or the mitigation actions require to modify the legacy software.</li>
</ul>
<p>The first solution is theoretically the best one with a SOUP. But the second solution may be the best to implement, when the manufacturer has the source code - and the knowledge - to modify the legacy software.
<img src="https://blog.cm-dm.com/public/19-legacy-SW/.Slide2-trunc_m.jpg" alt="Software in medical devices - Type of SW mitigations actions on legacy Software as a SOUP" style="display:block; margin:0 auto;" title="Software in medical devices - Type of SW mitigations actions on legacy Software as a SOUP, fév. 2013" />
While the second solution is probably the best, the consequence is to change the legacy software and to exit this case: modified software can't be treated as a SOUP, go to next case.</p>
<h5>Testing and mitigation proofs</h5>
<p>Unchanged legacy software can be seen as a black box. Testing the legacy software integrated in the new device can be seen as black-box tests cases.<br />
Verifying that legacy software runs well in its new environment and collecting the proofs of software mitigations can be made of back-box test cases. The new SW/HW components and their interfaces are tested, with legacy software integrated as a black-box in the system.</p>
<h5>Consequence of SOUP</h5>
<p>If the legacy software is to be used in a family of medical devices, the same problem will happen with the next version of the device or with another device in the products family. The SOUP solution is surely cost-effective at a given time, but the real solution is delayed further.</p>
<h4>2nd case: Legacy software is slightly changed</h4>
<p>This case is borderline, how to define slight changes?<br />
<em>Rule of thumb: if you have to change more that 20% of your software, redesign it!</em><br />
<br />
Slight changes mean that less that 20% of software is modified. With a security margin, if only 10% of functions/components are modified or added and no architecture change is made, then this is a slight change.<br />
If more that 10%-15% of legacy software is modified, then exit this case and go to next one.<br />
<br />
So how to deal with this modified legacy software? Here is a solution:</p>
<ol>
<li>Modify it,</li>
<li>Treat it as a SOUP.</li>
</ol>
<h5>Modify legacy software</h5>
<p>If a new function is added or an existing function is modified, then:</p>
<ul>
<li>Do a risk analysis of the changes,</li>
<li>Design the changes and mitigation actions (if any),</li>
<li>Implement the changes,</li>
<li>Test the modified legacy software with the changes.</li>
</ul>
<p>The result of the risk analysis at step 1 may be to add software mitigation actions. These mitigation actions shouldn't raise the type of changes to: deep. Otherwise exit this case and go to next case.
<img src="https://blog.cm-dm.com/public/19-legacy-SW/.Slide3-trunc_m.jpg" alt="Software in medical devices - Modify legacy Software as a SOUP" style="display:block; margin:0 auto;" title="Software in medical devices - Modify legacy Software as a SOUP, fév. 2013" /></p>
<h5>Treat legacy software as a SOUP</h5>
<p>When changes are complete, treat the new version of the legacy software as a SOUP.<br />
<br />
Those two phases may be planned in parallel. It's not necessary to finish the legacy software modifications to begin the design of the new device!</p>
<h4>3rd case: Legacy software is deeply changed</h4>
<p><em>Rule of thumb (bis repetita): if you have to change more that 20% of your software, redesign it!</em><br />
<br />
This case arises when it's necessary to break the existing architecture or to add a big new set of functions to legacy software.<br />
There is no miracle, the legacy software is so deeply touched that a new development cycle is compulsory. The legacy software is input data of the development cycle but it shall be redesigned along with the rest of the software it is integrated in.</p>
<h4>Other case: Legacy software is ported to a new platform</h4>
<p>This case is peculiar, but very common with discontinued hardware and software! The new platform may be new hardware (new microcontroller) or new software (new OS, new libraries) or both (eg: 32 bits to 64 bits).
Changes made to software are:</p>
<ul>
<li>Technical:
<ul>
<li>Interfaces are redesigned to work with the new platform,</li>
<li>Code is fixed and recompiled to the new platform,</li>
</ul></li>
<li>Not functional:
<ul>
<li>No existing function is modified, no new function is added,</li>
<li>Existing specifications are left untouched.</li>
</ul></li>
</ul>
<p>This case is close to the "slight changes" case, with the major difference that the code can be deeply touched to run on the new platform.<br />
To make it simple, it's possible to follow the same process as the one for slight changes:</p>
<ol>
<li>Port legacy software,</li>
<li>Treat it as a SOUP.</li>
</ol>
<p>The major difference is in the verification of the port: black-box testing is not enough. Unit testing or integration testing with modified interfaces should be necessary to demonstrate that ported software works like before.<br />
<br />
<br />
<br />
The types of changes is not the only way to decide how to deal with legacy software. <a href="https://blog.cm-dm.com/post/2013/02/15/How-to-bring-legacy-software-into-line-with-IEC-62304-part2">In the next post</a> we'll see how to deal with legacy software according to their type: whether it is non-medical device software, software in a lower class or risks ... amongst others.</p>https://blog.cm-dm.com/post/2013/02/06/How-to-bring-legacy-software-into-line-with-IEC-62304-part1#comment-formhttps://blog.cm-dm.com/feed/atom/comments/82Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices?urn:md5:271f627c838c9f07b77aef61837b248b2013-01-21T15:34:00+01:002013-01-25T17:44:56+01:00MitchStandardsClassificationcritical softwareFDAIEC 62304software failuresoftware itemsoftware unit<p>In the last two posts, we've seen <a href="https://blog.cm-dm.com/post/2013/01/11/What-is-a-Software-Unit">what a software unit is</a>, and <a href="https://blog.cm-dm.com/post/2013/01/18/Class-A%2C-B-and-C.-When-to-do-detailed-design-of-software-medical-devices">when to do software detailed design</a>, according to IEC 62304 and FDA Guidances.</p> <p>For Class C software, detailed design can be a very burdensome and time consuming task.<br /></p>
<h4>Detailed conception and its verification</h4>
<p>IEC 62304 standard requires doing the detailed conception of every software unit and to verify this detailed conception.<br />
This means that a lot of time has to be devoted to detailed conception documentation:</p>
<ul>
<li>Component/class/sequence/collaboration/deployment diagrams,</li>
<li>Comments that explain the choices of conception highlighted by these diagrams.</li>
</ul>
<p>This also means that reviews have to be planned to formally verify the conception.<br />
It bet that your managers don't give you enough time and money to do these tasks with the level of scrutiny required by the standard!</p>
<h4>Verification of software units</h4>
<p>IEC 62304 standard requires also verifying the software units. In concrete terms, doing unit tests to show that software units work the way they were designed. And to formally review these unit tests!<br />
OK, most of software development teams do unit tests today, units tests became the custom. But the problem is that for class C, he tests shall be systematic and should consider the following criteria:</p>
<ul>
<li>data flows,</li>
<li>memory allocation,</li>
<li>fault tolerance,</li>
<li>and a few others of the same type.</li>
</ul>
<p>So units tests with this level of scrutiny can become a very burdensome task. Once again, I bet that managers don't give you the necessary time to do all of these tests.<br />
<br />
<br />
<em>I'm a bit provocative, there are medical devices manufacturers that apply the standard to the letter. Ask the infusion pumps manufacturers what they think of <a href="http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/InfusionPumps/ucm202511.htm">FDA research about software failures</a>!</em>
<br />
<br />
Fortunately, it's not necessary to do Class C documentation for the whole software, provided that its architecture has been designed the right way.<br /></p>
<h4>Software Architecture to isolate Class C software items</h4>
<p>Imagine a software system with a Class C software item inside larger software items, like in the diagram below.<br />
<img src="https://blog.cm-dm.com/public/18-SW-units/.Slide4_m.jpg" alt="Software in medical devices - Class C software item forces the whole topmost software item to be in Class C" style="display:block; margin:0 auto;" title="Software in medical devices - Class C software item forces the whole topmost software item to be in Class C, janv. 2013" />
The class C critical item in red propagates its critical characteristics to the whole topmost item and other siblings items. Even a class A item has to be treated as a class C item.<br />
Why? Because it is known that a software failure that happens in an item can propagate to another item and have unexpected consequences. So a class A item, which is more subject to failures, can lead to the failure of a class C item. This make the work on the class C item useless.<br />
To avoid dreadful consequences of software failures of non-critical items on critical items, it's necessary either to do everything in the highest class, or to isolate critical items.<br />
This is what is done in the diagram below:<br />
<img src="https://blog.cm-dm.com/public/18-SW-units/.Slide5_m.jpg" alt="Software in medical devices - Isolate Class C software items to reduce the scope of application of class C requirements" style="display:block; margin:0 auto;" title="Software in medical devices - Isolate Class C software items to reduce the scope of application of class C requirements, janv. 2013" />
The critical item is isolated in a topmost item, with an interface. It communicates with other topmost items through its interface.<br />
The isolation may also be physical, with the class C items running on a separate hardware.<br />
Doing so, the scope of class C items is reduced, other topmost items can be of lower classes.<br />
Though this work of architecture isolation is possible, it shall always be done a as consequence of a risk analysis:</p>
<ol>
<li>Risk analysis and definition of classes of items,</li>
<li>Risk mitigation and isolation with architectural measures.</li>
</ol>
<p>It shall not be done the other way!
<br />
<br />
As a conclusion, I would say that there are not many ways to escape from the work overload due to class C items. The right solution is to isolate Class C items in a subsystem with well defined (and simple) interfaces. If you can't do this kind of architectural separation, you're stuck with class C tasks!</p>https://blog.cm-dm.com/post/2013/01/21/Class-A%2C-B-and-C.-Is-it-possible-to-reduce-the-documentation-of-detailed-design-of-software-medical-devices#comment-formhttps://blog.cm-dm.com/feed/atom/comments/80Prometheus medical podurn:md5:0c49b2a3dd28c33ac5509dd8e98484da2012-06-30T10:13:00+02:002012-07-02T09:37:07+02:00MitchMiscClassification<p>After a long series of posts about agile methods, let's continue with
something less serious!<br />
If you saw Prometheus, the sci-fi movie about a team of astronauts who search
for human origins, you were probably amazed by the <a href="http://www.prometheus-movie.com/gallery/view/img/55">Weyland Corp Medical Pod
720i</a>. Like me.</p> <p>This medical pod (or med pod) is definitely a medical device of the future.
The movie happens in 2100. Science and technology had time to do giant steps
forward since now. The pod is able to do a surgery from A to Z without human
intervention.<br />
Yet, we don't know if it is able to do a diagnosis 100% alone. Elizabeth, the
character who uses it, gives instructions to the pod before beginning the
surgery. However David, another character who is an andoid, is able to take
decisions of its own. So does probably the medical pod. In 2100 artificial
intelligence is advanced enough to have computers do diagnosis.<br /></p>
<h4>Near future?</h4>
<p>Even if the medical pod technology is out of reach for us, poor humans of
2012, it doesn't seem so far from us. Compared to spaceships, which use physics
laws that we've not discovered yet, like time warp, the technology in the
medical pod doesn't need new physics laws.<br />
It uses sensors to see in the body, we have them.<br />
It uses surgery tools, we have them.<br />
It uses computers, we have them.<br />
Look at <a href="http://www.imris.com/">IMRIS machines</a> and you'll see what
I mean. What separates us from a machine of this kind in the future is:</p>
<ul>
<li>surgery tools that are really versatile and multi purpose</li>
<li>the miniaturization of many components</li>
<li>the combination of all components to build an integrated system</li>
<li>the artificial intelligence and the computer system able to control the
whole.</li>
</ul>
<p>Some technology gaps are not so big. For artificial intelligence, I doubt
that we're able to let a computer do the diagnosis instead of a human. We
needed decades to replace subway drivers by computers based on finite state
machines. The gap is also psychic and cultural!<br />
Confidence. This probably what separates us the most from an automatic
diagnosis and surgery tool.</p>https://blog.cm-dm.com/post/2012/06/30/Prometheus-medical-pod#comment-formhttps://blog.cm-dm.com/feed/atom/comments/16Class A, B or C (continued)urn:md5:b1632bd798fb48c6623d67c26b9e5ccf2012-04-23T05:02:00+02:002012-09-04T11:39:16+02:00MitchMiscClassificationIEC 62304risk management <p>I didn't have time to post anything worth it this week.<br />
To give a side view of my <a href="https://blog.cm-dm.com/post/2012/04/23/Class-A%2CB-or-C-%28continued%29">last post about software classes</a>, here is a <a href="http://en.wikipedia.org/wiki/DO-178B">link to DO-178B on wikipedia</a>. It is the reference about software embarked in aircrafts.<br />
If you take time to read this document, you will see that it goes very further than what we have today in IEC 62304. The constraints about design on high classes are very very hard to respect. That's normal, when you think that software is used in flight commands and other stuff in the cockpit.<br />
It has some side effects, mainly to stretch software development projects, and to ban software from some parts of the plane, for cost-driven reasons.<br />
For example, a microcontroler plus software plus electric motors would be perfect to memorize and retreive the position settings of the pilot's seat. But the cost to develop such software is very high, as the pilot's seat is seen as a critical component. Aircraft manufacturers prefer replacing software and microcontroler by good old analogic electronics to do the same task on some models.<br />
In my humble opinion, the constraints of the two highest classes for software in aircrafts would be to high for medical devices. There is always a pratician, or an emergency medical service, able to "catch" the patient if something goes wrong. Whereas there is nobody to "catch" a falling plane if its flight commands fail. The consequences of risks are far higher in aircrafts, with potentially hundreds of victims in an accident.<br />
That is why classes A, B and C, and their design constraints are enough for medical devices.
<br />
<br />
Next week, I'll talk about exemptions of ISO13485 for standalone software medical devices.<br />
Bye.</p>https://blog.cm-dm.com/post/2012/04/23/Class-A%2CB-or-C-%28continued%29#comment-formhttps://blog.cm-dm.com/feed/atom/comments/38Is my software in class A, B or C?urn:md5:c3000acc22c8191b063ee6bb5fb424962012-04-14T23:35:00+02:002016-05-06T15:36:49+02:00MitchStandardsClassificationIEC 62304risk management<p>IEC 62304 defines three safety classes for software:</p>
<ul>
<li>Class A: No injury or damage to health is possible</li>
<li>Class B: Non-SERIOUS INJURY is possible</li>
<li>Class C: Death or SERIOUS INJURY is possible</li>
</ul>
<p>Here comes the eternal question: Which class my software belongs to?
<br /></p> <p>Let’s do a little experience. Imagine a thermometer, which measures body temperature, with a piece of software inside. I could demonstrate that its software is class A or class C.</p>
<ul>
<li>If the thermometer gives a wrong value, then the nurse is going to give a medicine to treat the fever. The wrong medicine may endanger the patient, and eventually cause death. Class C.</li>
<li>If the thermometer gives a wrong value, then the nurse may give a wrong treatment to the patient. However there is no chance that this may endanger the patient. Class B.</li>
<li>If the thermometer gives a wrong value, then the nurse is going to touch the forehead of the patient, or redo the measurement with another thermometer, or check the blood pressure of the patient to confirm the fever. No damage is possible. Class A.</li>
</ul>
<p><br />
This example is a dummy one but it shows that the context is very important. <strong>Class shall be set with the knowledge of physicians and the intended use</strong> of the medical device.
<br />
To make things more complex, there is no one-to-one correspondence between classes of medical devices and classes of software. You may have a class A software in a maintenance function of a class III medical device. It is true however that there is a high probability that low class software are found in low class devices and high class software in high class devices.</p>
<h4>The wheelbarrow</h4>
<p>Let me give you an analogy: the wheelbarrow was invented a long time ago to transport things more easily. The wheelbarrow helps our muscles do their job faster. Software was invented in the 1940’s to do computations faster. Software is the wheelbarrow of our brain. Our brain needs a level of confidence to trust the results given by its software wheelbarrow.<br />
If we had no confidence, we could convert the electric tension of the temperature sensor to a temperature value with an abacus. The radiologist could take every measurement of the MRI and draw the points on a sheet of paper with different color pens to build an image. The surgeon could use manual micrometric screws to move its instruments instead of software controlled instruments, during a surgery.<br />
We don’t because software allows us to do a lot of things in a snap of fingers, and we rely on it to do so. The more we’re stuck to it, without any alternative or possibility to cross its results/actions with something else, the riskier situation.<br />
<strong>The more you have to rely on software to treat the patient, to monitor its vital constants or to give a diagnosis, the higher the class.</strong></p>
<h4>Consequence on design</h4>
<p>Knowing the class has a consequence on design. I sum-up the requirements of IEC 62304 like this:</p>
<ul>
<li>Class A: no design documentation, poor testing,</li>
<li>Class B: design documentation and testing,</li>
<li>Class C: deep design documentation and deep testing.</li>
</ul>
<p>In class C, all paragraphs of the IEC 62304 shall be applied when developing the software inside the thermometer. In class A, only a few paragraphs of the IEC 62304 shall be applied. Class B is in between (no surprise).
<br />
<br />
Outclassing software may lead to unnecessary burden, which eventually won’t enhance the quality and reliability of your software. So, think twice before you assign a class to your software.
<br />
<br />
Edit: I continued the discussion in <a href="https://blog.cm-dm.com/post/2012/04/23/Class-A%2CB-or-C-%28continued%29">this article</a>.<br />
<br />
<br />
<strong>Edit of 2016: read this <a href="https://blog.cm-dm.com/post/2016/05/06/Is-my-software-in-class-A%2C-B-or-C-2015-reloaded">new article about IEC 62304 Amd1 2015</a> where the new software security classification system is explained.</strong></p>https://blog.cm-dm.com/post/2012/04/14/Is-my-software-in-class-A%2C-B-or-C#comment-formhttps://blog.cm-dm.com/feed/atom/comments/26Inflation of software medical devices - part 3urn:md5:cee54941ec4781d599d133efa76c7f252012-04-06T11:08:00+02:002012-04-06T10:39:41+02:00MitchMiscCE MarkClassificationFDAmHealthPACS<p>This article is the last of three articles which deal with the concept of
"inflation" of medical devices. <a href="https://blog.cm-dm.com/post/2012/03/09/Inflation-of-software-medical-devices-part-1">The first
one</a> was on inflation of standards, <a href="https://blog.cm-dm.com/post/2012/03/30/Inflation-of-software-medical-devices-part-2">the second</a>
about inflation of regulations. This one, the most interesting to my eyes, is
about multiplication of apps on mobile devices, especially smartphones and
tablets.<br />
More that 6000 apps are classified in the "heath", "heathcare" or "medical"
categories of the Apple or Android appstores. Many of these apps are classified
as medical devices and are in the scope of regulations like FDA and CE Mark.
Note that some apps may be regulated the FDA but not the CE Mark or
vice-versa.</p> <h4>Medical device apps or not medical device apps</h4>
<p>Apps may be categorized in three big sets: encyclopedic apps, health
lifestyle apps and real medical devices apps.<br />
<strong>Encyclopedic apps</strong> are not medical devices, neither for FDA nor
for CE Mark. They often contain data or knowledge that can be found in books.
They are most of time created by book editors which publish their books in
electronic format.<br />
<strong>Health lifestyle apps</strong> are made for people who are not
physicians, for diet, life hygiene or general health condition. These are most
of times not medical devices. The frontier between general health and medical
devices is sometimes thin. They may fall into the regulations whereas it was
not expected by their manufacturers.<br />
<strong>Medical devices</strong> apps are those with an intended use, which is
clearly in the scope of regulations. “Clearly” is not a clear criterion, you
may object. That’s true, there is no clear boundary between general health apps
and medical devices. A few examples of medical devices are better than endless
theoretical explanations:</p>
<ul>
<li>Apps which compute drugs doses or a dose of any pharmaceutical or medical
substance, are medical devices.</li>
<li>Apps which are connected to Heath IT servers and offer a service higher
than simply displaying data are medical devices.</li>
<li>A PDF viewer used to read a medical report sent by mail is not a software
medical device.</li>
<li>A remote DICOM medical imaging viewer is a medical device.</li>
<li>An app which lists the defibrillators around you is not a medical
device.</li>
<li>Apps which give general recommendations, like smoking increase risks of
cardiovascular pathologies, are not a medical devices.</li>
<li>Apps which contain training information, like memos about first aid are not
medical devices.</li>
</ul>
<h4>Smartphones become medical devices</h4>
<p>When an app is used to communicate with a peripheral connected to the mobile
device, the whole is a medical device. For example, <a href="http://www.withings.fr/en/bloodpressuremonitor">Withings</a> sells a blood
pressure monitor, which is connected to a smartphone to measure the blood
pressure of patients. In this case, the whole thing (customized smartphone with
blood pressure monitor and software) becomes a medical device.<br />
Many new accessories were placed on the market the last two years, to analyse
saliva, urine, to measure glycemy ... The possibilities seem to be
endless!<br />
Even worse, a physician uses an app which takes photos of the patient's body
with the embedded camera of his smartphone to evaluate any medical parameter.
In this case, the smartphone (not customized) and the app are a medical device
as a whole.</p>
<h4>Consumer electronics vs medical device</h4>
<p>What an horror, my smartphone is a medical device??? Don’t be afraid. Being
a medical device is a transitory state, your smartphone remains the little
companion you cherish as soon as you stop the medical device app.<br />
More seriously, there is a kind of contradiction between the level of safety
sought in the medical device industry and the non-stopping pace of evolutions
of the consumer electronics industry. It takes a long time to design reliable
stuff. Smartphones don’t last long (that’s a pity IMHO), smartphone apps don’t
either. Developers of smartphone apps may be tempted to ignore <a href="https://blog.cm-dm.com/post/2011/11/18/Software-Medical-Devices.-How-to-obtain-market-homologation">mandatory
software design activities</a>, event for class I devices.<br />
This is why there is inflation of guidances and standards on standalone
software.<br />
<br />
<br />
PS: Thanks to J. Colombain for its <a href="http://www.franceinfo.fr/high-tech/nouveau-monde/smarpthones-le-boom-de-la-m-sante-562409-2012-03-23">
chronicle on France Info about m-santé</a> (sorry, only in French).</p>https://blog.cm-dm.com/post/2012/04/06/Inflation-of-software-medical-devices-part-3#comment-formhttps://blog.cm-dm.com/feed/atom/comments/30Inflation of software medical devices - part 2urn:md5:498843227c0c4678ece77977f49245b12012-03-30T10:51:00+02:002012-03-30T09:58:00+02:00MitchRegulationsCE MarkClassificationFDAGuidance<p>Today I’m going to talk about the inflation to regulations in the world of
software for medical devices. <a href="https://blog.cm-dm.com/post/2012/03/09/Inflation-of-software-medical-devices-part-1">In my previous
post</a>, I had a look at the inflation of standards for medical devices. As
the medical devices industry is heavily controlled by regulations, they deserve
a dedicated post.</p> <h4>Regulations</h4>
<p>The most well-known (or widespread?) regulations are the 21CFR of the USA
and the 93/42 directive of the European Union. The FDA has recently increased
its number of inspections, mainly in foreigner countries. Even if FDA lacks of
agents to do so, the trend is here. And an inspection of the FDA can be
compared to being sued. If one day you have one, you’re not going to enjoy it!
The regulations themselves don’t change but the FDA will to increase the law
enforcement by foreign companies.<br />
On the other side of the Atlantic Ocean, a new directive on medical devices is
being drafted by the European commission. The content of this directive is
still under construction but some new features are already known. The
classification rules will change, for instance products which contain
biological substances will be class III. The list of essential requirements
will contain new ones, especially about software. This new directive should be
released by 2013 or early 2014 and be active a few years later (remember that
2007/47 directive became mandatory in 2010).<br /></p>
<h4>What about software?</h4>
<p>Focusing on software, we can see the following trend: With the
multiplication of standalone software, the FDA and the European Commission felt
the urgency to release guidance documents about these kinds of medical devices.
The affected types of software are Clinical Decision Support (CDS), like
Medical Device Data Systems (MDDS) and mobile Health (mHealth) apps. In
general, every kind of software, which belongs to Health IT (HIT) is being
watched by regulation agencies.<br />
The excellent article <a href="http://www.fiercehealthit.com/special-reports/fdas-approach-clinical-decision-support-software-brief-summary">
FDA's approach to clinical decision support software</a> depicts the situation
with the FDA and the lack of official position about standalone software. FDA
decides to regulate almost case by case. However, the FDA issued a <a href="http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm263280.htm">
draft guidance document</a> about mobile apps. Needless to say that they
deserved one, given the maelstrom of new medical apps produced by the emergence
of smartphones. The EU hasn’t released an equivalent document to the FDA
guidance on mobile apps yet. Its approach is broader, with the <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">
MEDDEV 2.1/6</a> about qualification and classification of standalone
software.<br /></p>
<h4>An attempt of synthesis</h4>
<p>It’s difficult to quickly do a synthesis on trends about software in a short
blog article. But the web is a source of precious data. The COCIR (a lobby of
European radiological and HIT industry) made a <a href="http://www.amiando.com/eventResources/2/n/b4qkJbkYhsEBOj/1140_Philippe_Lartigue_Industry_Challenges_In_a_Developing_Software_Regulatory_Environment.pdf">
presentation about regulation of medical software</a>, which contains a fair
good attempt of synthesis. Read it, it’s very instructive!<br />
The concept of inflation of regulations should not be seen as the
multiplication of regulations but more as the mix of three phenomena. National
agencies are strengthening the existing regulations. They’re increasing the
monitoring and control of manufacturers and distributors. And in the case of
software, they’re trying to adapt the regulations to the fast moving world of
Health IT.<br />
<br />
It's too early to have a worldwide consensus on how to regulate Health IT. Wait
and see.</p>https://blog.cm-dm.com/post/2012/03/30/Inflation-of-software-medical-devices-part-2#comment-formhttps://blog.cm-dm.com/feed/atom/comments/28MEDDEV 2.1/6 Guidelines on classification of standalone software released!urn:md5:912989a204a7d7344d6857f45fef173d2012-02-06T18:14:00+01:002012-09-10T21:57:41+02:00MitchRegulationsCE MarkClassificationGuidance<p>New! MEDDEV 2.1/6 Guidelines on classification of standalone software released!
<br />
HIS, CIS, PDMS, RIS, PACS, LIMS … Which ones are medical devices, which ones are not?
<br />
To answer this question, the European Commission issued a new Guidelines document: MEDDEV 2.1/6, about the qualification and classification of standalone software as Medical Devices or In Vitro Diagnosis Devices. <br />
<a href="http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf">Download here</a>
<br />
After the <a href="http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm263280.htm">draft guidance of the FDA about mobile apps</a>, after the <a href="http://www.d4.org.uk/research/regulation-of-health-apps-a-practical-guide-January-2012.pdf">guide on regulation of health apps</a> by a UK medical charity, this MEDEV is the third document released in a few months about standalone software.</p> <h4>Content of MEDDEV 2.1/6</h4>
<p>Whereas the last two deal only with mobile medical apps, the MEDDEV 2.1/6 embraces all the categories of software dealing with medical data that can be found in a health care centre or at patients’ home.</p>
<h5>Qualification</h5>
<p>It contains two decision diagrams to assist the qualification of standalone software as MD or IVDD. It contains also an annex with numerous examples about real cases. You’re certainly going to find yours. <br />
Without surprise, information systems like HIS, CIS, PDMS, LIMS, RIS, are not medical devices. Online documentation is not medical device either. Information systems like PACS and Computer Aided Diagnosis, are medical devices.</p>
<h5>Classification</h5>
<p>If the software is qualified as MD or IVDD, then the document refers to the classification rules of the 93/42 CE directive: rules 9 to 12 about active medical devices. For PACS, nothing new, it refers to the manual on borderline classification (<a href="https://blog.cm-dm.com/post/2011/11/25/Device-Classification-Guidance-by-GHTF">see my other post on classification of software</a>).
<br /></p>
<h5>Rules</h5>
<p>One interesting part is about the rules in the decision diagrams to qualify a software as medical device. Every standalone software is an information system, which does at least these three generic operations: receiving, processing and sending data:</p>
<ul>
<li>Receiving data from machines: loading data from mass storage, receiving data from network, receiving data from other devices (medical or not), from sensors …</li>
<li>Receiving data from humans: by keyboard, mouse, camera, microphone, …</li>
<li>Processing data: computing, sorting, extracting, duplicating, erasing, copying, pasting …</li>
<li>Sending data to machines: storing data on mass storage, sending over a network, sending to other devices, to printers …</li>
<li>Sending data to humans: screen, loudspeaker, any human machine interface.</li>
</ul>
<p>I attempted to define a set of rules based on the three generic operations, from the questions in the decision diagram:</p>
<ol>
<li>If data are received from or sent to a medical device to influence its performance, then it is a medical device (whichever the data, embedded or not),</li>
<li>If data are received or processed or sent for the benefit of one patient and for diagnosis or therapeutic purposes, then it is a medical device,</li>
<li>Exception to rule 2, if data processing is for storage, simple query or data transformation without alteration and in a reversible manner (non destructive compression for example), then it is not a medical device.</li>
</ol>
<p><br />
I don’t want to replace the decision diagram! It is the result of long process of redaction of this MEDDEV. What I want to emphasize is that the basic question is whether the software manipulates data for diagnosis or treatment purpose of a single patient, these data being either technical, or clinical, or personal. My rules are not perfect and the exception to rule 2 is not a luxury. It prevents from qualifying, any computer, or router or hard disk in a hospital, as a medical device.</p>
<h4>Modules</h4>
<p>The most interesting part from the point of view of software design is certainly the section 4. It raises the issue about IT systems having some modules being medical devices, some other not. If only a part of the IT system can be qualified as medical device, the boundaries of the modules <strong>shall</strong> be clearly identified by the manufacturer. <br />
I use “shall”, whereas the MEDDEV uses “should”. I think this difference is of most importance; hence not clearly identifying functional boundaries will lead to not clearly identifying technical boundaries. <br />
On top of that, the MEDDEV insists on the conservation of safety and performances, when medical devices modules work in combination with other modules.
<br />
This is only achievable with a rigorous design.
<br />
Let’s imagine an IT system made of 3 main layers:</p>
<ul>
<li>A basic layer on the operating system, it contains Soups</li>
<li>A middle layer organized in modules, which contain module specific software,</li>
<li>A top layer which contains GUI and other elements to “glue” modules one another</li>
</ul>
<p><img src="https://blog.cm-dm.com/public/9-MEDDEV-standalone-soft/.9-Module-simple_m.jpg" alt="9-Module-simple.png" title="Example of IT systems with modules, Feb 2012" /></p>
<p>The module #3 falls into the qualification of medical device. Its functional boundaries shall be clearly identified. Eg: all functional performances listed in the intended use are handled by module 3.
And the design constraints of module 3 are going to have fallouts on other modules or other layers. Especially, the risk analysis may have consequences on other modules, on basic layers and on the main GUI. If the system contains SOUPs, they shall be treated with the constraints of medical devices design.</p>
<p><img src="https://blog.cm-dm.com/public/9-MEDDEV-standalone-soft/.9-Module-risk-propag_m.jpg" alt="9-Module-risk-propag.png" title="Propagation of mitigation actions of risk management to components outside the medical device module, Feb 2012" /></p>
<p>If functional boundaries are important, technical boundaries linked to design constraints are important as well and may be more extended than functional ones. They also may be difficult to determine. Eg: to what extent the services in a basic layer are impacted by medical devices design constraints?</p>
<p><img src="https://blog.cm-dm.com/public/9-MEDDEV-standalone-soft/.9-Module-boundaries_m.jpg" alt="9-Module-boundaries.png" title="Delineating the boundaries of a module can be hard task, Feb 2012" /></p>
<h4>Existing vs new systems</h4>
<p>If the module is a new one added to an existing system, the consequences on design constraints may lead to the redesign/refactoring of the system. Hence there is no proof that the existing system is safe according to the criteria of medical devices. It may need some separation or insulation of some components or any other design technique to ensure the safety. The final consequence may be additional costs of integration not forecasted when the design of the module was begun.</p>
<p>If the module is a part of a brand new system, the consequences are less important. The design is done at the very beginning with the constraints of medical devices. It’s a non-negligible cost but it has more chances to remain in the estimations.</p>
<h4>Classification of modules</h4>
<p>The design constraints range from light for class I to paranoiac for class III medical devices. Class IIa and IIb are at intermediate stages.
In my own opinion, medical devices modules integrated in systems with modules for other purposes shall not be classified more than IIa:</p>
<ul>
<li>If it’s class I or class IIa, it may be part of a system,</li>
<li>If it’s class IIb or class III, forget it.</li>
</ul>
<p>Even if it’s in class I or class IIa, you should be cautious and insulate as far as possible your module from the rest of the system. For example, by running it on a separate process or a separate machine.
Insulating also means taking actions on design. You should separate the module from the rest of the system. It may require duplication of basic layers in specific configuration branch, to ensure that any change in the system will not compromise the safety of the medical device module.</p>
<p><img src="https://blog.cm-dm.com/public/9-MEDDEV-standalone-soft/.9-Module-insulate_m.jpg" alt="9-Module-insulate.png" title="Insulation of a module that is a medical device, Feb 2012" /></p>
<p>Depending on the architecture of the system, this may be seen paranoiac, or too much a precaution, or a source of duplicate code. <strong>But don’t underestimate the growing entropy of successive versions of systems.</strong> When in a few years another module is upgraded and refactored, such a design may save your system.</p>
<h4>Conclusion</h4>
<p>The MEDDEV 2.1/6 Guidelines are a real step forward. They gather in one document the criteria to determine if an IT system is a medical device or not. The document gives a lot of examples and your case is most probably inside. It warns also about constraints on heterogeneous systems, which integrate medical devices. We've seen that there is no specific design recommendation about this kind of system; hence this is not the level of detail of this document.<br />
<br />
A very good guidance on standalone software!</p>https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21#comment-formhttps://blog.cm-dm.com/feed/atom/comments/45