Software in Medical Devices, by MD101 Consulting - Tag - CE MarkBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearNIS2 Directive: are you involved or concerned?urn:md5:19b7f5ddba4cf0ace27fb1bb8d1262942022-09-30T14:01:00+02:002022-12-28T21:49:23+01:00MitchRegulationsCE MarkCybersecurity<p>That’s the story of the pig and the hen for breakfast: the pig is involved (ham) and the hen is concerned (eggs). With the NIS2 directive in preparation, a medical device manufacturer will be in either situation.<br /></p> <p>A <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2020:823:FIN">proposal for the NIS2 directive</a> has been published in December 2020. Its goal is <em>ensuring a high level of cybersecurity within the Union</em>. Like any other regulation, it brings its own constraints and overhead to targeted organizations. Fortunately, it is not applicable to micro or small entreprises. However, some additional criteria exist. Let’s see how medical device manufacturers are involved or concerned.</p>
<h4>NIS directive and NIS2 directive</h4>
<p>By the way, subject matter experts call it the NIS2 directive. Its real official name is the <em>directive on measures for a high common level of cybersecurity across the Union</em>. It will replace the <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG&toc=OJ:L:2016:194:TOC">Directive on security of network and information systems</a> (aka NIS directive, <a href="https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations">mentioned on this blog 6 years ago</a>) in force since 2016. NIS2 is used as a nickname, reminder of the replacement of the NIS directive.</p>
<h4>Essential Entities and Important Entities</h4>
<p>The NIS2 directive defines two types of entities:</p>
<ul>
<li><strong>Essential Entities</strong>: Medical Device manufacturers of critical medical devices, according to Annex I of the NIS2 directive. The annex references the regulation on European Medicines Agency in crisis preparedness. It is in draft state, and defines what “critical” medical devices are,</li>
<li><strong>Important Entities</strong>: All medical device manufacturers, according to annex II of the NIS2 directive.</li>
</ul>
<p>We can conclude that all medical device manufacturers, other than small businesses, are at least in the scope of the NIS2 directive and categorized as Important Entities.<br />
<br />
However, some other criteria exist at article 2. Like if the manufacturer is the sole provider of a service in the EU or if it is of importance at regional or national level. Especially, the NIS2 directive references yet another regulation in preparation, the Resilience and critical entities directive, which defines a list of critical entities.<br />
<br />
If a manufacturer matches one of these criteria at article 2, it can be an Essential Entity or Important Entity. Small business or not.<br />
<br />
Examples of medical devices manufacturers, that could be in scope of the NIS2 Directive:</p>
<ul>
<li>A manufacturer of telehealth / teleradiology solution when their software is deployed at regional or national level (criteria at article 2),</li>
<li>A manufacturer of patient file management software, not a medical device but usually editors of such software have medical devices in their product portfolio, when their software is deployed at regional or national level (criteria at article 2),</li>
<li>A manufacturer of a cloud-based SaMD with a large user base, where a potential disruption of the service provided by the entity could have an impact on public safety (criteria at article 2),</li>
<li>A manufacturer of ventilators used to cure patients with covid-19, probably in the future list of critical devices of the EMA crisis preparedness regulation (criteria at annex I),</li>
<li>Another manufacturer of medical devices, not small business (criteria at annex II).</li>
</ul>
<p>To sum-up: to know if a manufacturer is an Essential Entity, or Important Entity, or none of these, it is necessary to read three documents:</p>
<ul>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2020:823:FIN">NIS2 directive</a>, with criteria defined at article 2,</li>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A52020PC0725">EMA crisis preparedness regulation</a>, referenced in annex I of the NIS2 directive,</li>
<li>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52020PC0829">Resilience of critical entities directive</a>, referenced in article 2 of the NIS2 directive.</li>
</ul>
<p>Piece of cake! Isn’t it?<br />
<br />
One important thing: The list of entities matching the criteria found in article 2 will be established by Member States. Thus, small businesses won’t decide by themselves if they match these criteria. Such list isn’t defined on the back of an envelope. Member States will need to collaborate with presumed entities to establish the list. Such entities will know well in advance that they will be in the list!<br />
This is also the case for the list of critical entities according to the EMA crisis preparedness regulation and the Resilience of critical entities directive.<br /></p>
<h4>You are Involved!</h4>
<p>If your company is in the scope of the NIS2 directive, you are involved. Essential Entity or Important Entity, you have to establish (article 1):</p>
<ul>
<li>A cybersecurity risk management process,</li>
<li>A reporting process,</li>
<li>An information sharing process.</li>
</ul>
<p>Article 18 defines the requirements on <em>Cybersecurity risk management measures</em>. Article 20, the <em>Reporting obligations</em>, and article 26 the <em>Cybersecurity information sharing arrangements</em>.<br />
<br />
To do so, technical specifications or methodological specifications can be adopted by the European Commission. The European Union Agency for Cybersecurity (<a href="https://www.enisa.europa.eu">ENISA</a>) can also publish guidelines. There is no mention of harmonized standards, though. Only a requirement for Member States to encourage the use of international or European standards. (articles 18 and 22).<br />
<br />
This is going to consume a significant part of enterprises resources. It is wise to put non-critical small businesses out of scope!<br />
These processes will be monitored by a Competent Authority, at Member State level. Obviously, different from the Competent Authority for MD/IVD. I don’t explain further the network of agencies in charge of cybersecurity and crisis management (ENISA, <a href="https://csirtsnetwork.eu" title="CSIRTS Network">CSIRT</a>, <a href="https://www.enisa.europa.eu/news/enisa-news/blue-olex-2020-the-european-union-member-states-launch-the-cyber-crisis-liaison-organisation-network-cyclone">CyCLONe</a>…).<br />
<br />
It is important to note that the NIS2 directive has an impact on entities’ organization. The most straightforward (and expensive) compliance pathway is an Information Security Management System (ISMS) implemented according to ISO 27001.<br />
<br />
MDR and IVDR target products with ISO 13485 and ISO 14971 (plus cybersecurity harmonized / recognized standards).<br />
Thus, a solution for MD manufacturers in the scope of the NIS2 directive could be to have an integrated QMS, compliant to ISO 27001 and ISO 13845.</p>
<h4>Difference between Essential Entities and Important Entities</h4>
<p>Accustomed to MDR/IVDR rules, we can see Important Entities a bit like class I, and Essential Entities as Class II+. This is visible in articles 29 and 30, about supervision of Essential Entities and Important Entities, respectively.<br />
<br />
Essential Entities are subject to <em>regular audits</em> and <em>random checks</em> (sort of unannounced audits). Important Entities can be subject to <em>ex-post</em> inspection by Competent Authorities, after a cyber adverse event occurred. No regular audit, then.<br />
<br />
The NIS2 directive also leaves the possibility to impose certification schemes to Essential Entities and Important Entities (article 21). Hello ISO 27001! Hello, also, future <a href="https://www.enisa.europa.eu/topics/standards/certification">certification schemes</a> that ENISA could elaborate or adopt.<br />
Curiously, the suspension of certification is a sanction only present for Essential Entities.</p>
<h4>You are Concerned!</h4>
<p>Even though a company doesn’t match any criteria of article 2 and isn’t in the scope of the NIS2 directive, it can be impacted by the supply chain. As a manufacturer, you are in the supply chain of healthcare providers, which <ins>will</ins> be essential or important entities, according to article 2. Keep reading, you are concerned!<br />
<br />
Article 18 requires to implement cybersecurity risk management measures in the <em>supply chain security including security-related aspects concerning the relationships between each entity and its suppliers or service providers</em>.<br />
Thus, as a medical device manufacturer, hardware, or software, or software as a service, we have to implement such measures, either in the QMS (for non-active devices), or in the QMS and the devices (for active devices). MDR CE marked devices shall already be compliant to general requirements at annex I of MD / IVDR.<br />
<br />
Article 18 also requires to implement <em>policies and procedures (testing and auditing) to assess the effectiveness of cybersecurity risk management measures</em>.<br />
It means that our clients, who are happy to be Essential or Important Entities, will audit our QMS and/or our products. They will verify that cybersecurity provisions in the QMS and in the device design and post-market are appropriate.<br />
<br />
Last, article 18 adds <em>entities shall take into account the vulnerabilities specific to each supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures</em>.<br />
Cherry on the cake, client’s audits will take into account vulnerabilities in products and the secure development process, like the one described in IEC 81001-5-1.<br />
<br />
That’s a bit like a sterilization service supplier, who is audited by its clients. As a supplier of devices or ICT services considered as critical by your clients, you will be audited by your clients. Of course, with auditors qualified in cybersecurity management.<br />
<br />
Here are some examples:</p>
<ul>
<li>A hospital, registered as Essential Entity, could audit their hardware MD suppliers, when these MD are considered as critical devices for patient care,</li>
<li>A big pharma company, registered as Essential Entity, could audit their suppliers of companion apps (qualified as SaMDs), when these companions apps deliver a service considered as critical for patient management,</li>
<li>A medical imaging manufacturer, registered as Important Entity, could audit their suppliers of medical imaging libraries (themselves MD or not), when these libraires are considered as a critical part of the integrated system.</li>
</ul>
<p>So, we are concerned!</p>
<h4>Consumer electronics is not left apart</h4>
<p>A last proposal for regulation as been issued in September 2022. This is the <a href="https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM:2022:454:FIN">Regulation on horizontal cybersecurity requirements for products with digital elements</a>. Its scope is <em>products with digital elements</em>. It excludes MD and IVD who are already regulated by the MDR and IVDR.<br />
However, the Annex I of this proposal contains a list of general requirements. It's worth reading them, to see what detailed requirements on cybersecurity could be for medical devices!<br />
<br />
We see with this last proposal for regulation that the EU takes cybersecurity seriously, by putting some pressure on all electronic devices.<br /></p>
<h4>And the MDR?</h4>
<p>Let's end with the running-gag of 2022 on this blog: some MDR-bashing!<br />
<br />
As of today, the MDR is a dead-end. It drains all the energies of medical devices manufacturers towards poorly useful QMS updates, technical files updates, and endless Notified Bodies reviews.<br />
<br />
But the geopolitical landscape has changed. Cybersecurity is a real concern. Probably a concern stronger than the safety and performance of medical devices.<br />
<br />
Practically speaking, I feel like I'm doing something useful when I work on securing the design of medical devices. And I feel like I'm doing something useless (even sometimes pointless), when I work on filling some heavy MDR technical file template.<br />
Fortunately, this is only sometimes true for new devices. Unfortunately, this is always true for legacy devices transitioning to the MDR.<br />
What a waste of manufacturers' resources!<br />
<br />
The MDR should be updated to alleviate the burden on MD manufacturers. Their resources shall be set in order of battle to strengthen the security of their products and processes. This is the purpose of a directive like NIS2. We’ve seen that it requires a lot of resources to do it right.<br />
<br />
<strong>We shall not fight the wrong battle: more Cyber, less MDR</strong><br />
<br />
<br />
<strong>Edit 2022/12/28</strong>: <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555">the NIS2 directive, named Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union </a> has been published the 2022/12/27. It shall be transposed in National law no later than September 2024. Articles of the draft version discussed above were shifted by 3 digits in the final version. E.g.: article 18 is now article 21.</p>https://blog.cm-dm.com/post/2022/09/30/NIS2-Directive%3A-are-you-involved-or-concerned#comment-formhttps://blog.cm-dm.com/feed/atom/comments/264Software as a Medical Device Post-Market Surveillanceurn:md5:3984b97a1d40ed26511a05d098b828942022-05-13T13:55:00+02:002022-05-13T13:55:00+02:00MitchRegulationsCE MarkMDR<p>Post-Market Surveillance (PMS) is one of the strengthened requirements of the Medical Device Regulation (MDR). Performing an effective PMS can be a time consuming task, shared by several departments of MD manufacturers. This is also true for SaMD.</p> <h4>SaMD PMS data</h4>
<p>Types data that can be gathered with a SaMD contain data common to all medical devices, not covered by this blog, such as:</p>
<ul>
<li>Customer feedback,</li>
<li>Customer claims,</li>
<li>Vigilance events,</li>
<li>Trend reports,</li>
<li>Usability data and usage statistics,</li>
<li>Clinical data...</li>
</ul>
<p>They also contain data specific to SaMD, managed through the software maintenance plan and the problem resolution process, required by clauses 6.1 and 9 of IEC 62304:</p>
<ul>
<li>Software issues, coming from the field or found internally,</li>
<li>SOUP issues, new SOUP versions, SOUP obsolescence,</li>
<li>Cybersecurity issues, from software items developed by the manufacturer or from SOUP.</li>
</ul>
<p>Of course, customer claims or customer feedback can give rise to software issues. Thus, these data categories aren't separated.<br />
<br />
The advantage with software is to be able to partially automate the data collection and analysis. The functions described below are not specific to SaMD and can be present in non-regulated software. What makes them specific to SaMD is the regulatory requirements behind these functions.</p>
<h4>Customer satisfaction questionnaire</h4>
<p>You've already seen these questionnaires popping out, while you're using a website (the FDA does that) or a mobile app, trying to grab some stars from you. This is some PMS; a proactive task, according to article 2.60 of the MDR.<br />
It is possible for SaMD applications to request end-user feedback inside the application. This function should be subject to a risk-based approach. Popping out a questionnaire while a doctor is with their patients is probably not a good idea.<br />
This kind of function is probably more suitable to software used by the general public. Usually, manufacturers prefer meeting with medical professionals to get their feedback. They also prefer sending them questionnaires by mail or by e-mail.</p>
<h4>Issue reporting</h4>
<p>Another option is to have a function allowing end-users to report issues directly from the SaMD application. It allows the user to file the issue in the context of use. This offers the advantage of avoiding changing of context, like having to send a mail, retrieve the mail address and copy-paste data or images.<br />
It could also automatically allow to send log files or dump files with the issue. Provided that theses files don't contain confidential data.</p>
<h4>Use statistics</h4>
<p>Use statistics are required by the Periodic Safety Update Report (PSUR). They can also be used by usability and trend reporting.<br />
Use statistics can be easily generated by software, to monitor its use. Software can report the number of user accounts, the frequency of use by accounts, the access to some specific functions. Almost all kind of use statistics can be reported.</p>
<h4>End-user clinical data</h4>
<p>A more specific function is the ability to send user's clinical data to the manufacturer. Then, the manufacturer shall obtain the user's consent to send and process such information for PMS purposes or other purposes. The consent form may be displayed by the SaMD as well, provided that the legal department considers this is enough for an informed consent, and provided that the electronic signature in the consent form is validated (GDPR, HIPAA and 21 CFR part 11 are haunting this small bit of software!).<br />
<br />
Event though this function looks like a validation nightmare, use statistics and clinical data can be source of highly valuable information for the manufacturer:</p>
<ul>
<li>Data to better train their ML pipelines and models,</li>
<li>Data for future ML pipelines and models,</li>
<li>Usability data to monitor end user's way of using the application,</li>
<li>Data used for trend reports,</li>
<li>Clinical data during a clinical investigation,</li>
<li>Clinical data for PMCF,</li>
<li>And some other data specific to the SaMD intended use.</li>
</ul>
<h4>PMS software functions</h4>
<p>These functions won't be qualified as medical devices, as they don't give results for the benefit of a single person. We can split them into two categories: generating data and analysing data.</p>
<h5>Functions generating data</h5>
<p>These functions generate aggregates of data, that can be anonymized, if possible.<br />
However, it may be difficult to separate these non-MD functions from MD functions. Is it possible to isolate logging functions from other components? Probably not for the logging points disseminated through the software. Probably yes for the logging system, like a logging server.<br />
Thus, validating these functions can be partially part of the SaMD validation, when data generation is inside the SaMD.</p>
<h5>Functions analysing data</h5>
<p>Data analysis consists in processing data aggregates coming from several patients. The computers performing these analyses are managed by the manufacturer and are software used in the PMS process. Thus, they are QMS software, subject to a passionate and exciting QMS software validation, like IQ/OQ/PQ.</p>
<h5>Architectural separation</h5>
<p>As we've seen <a href="https://blog.cm-dm.com/post/2022/04/15/SaMD-decommissioning%2C-recall%2C-removal-and-withdrawal">in the previous article</a>, separating non-MD functions from MD functions is a good option. When feasible, it allows to reduce the burden of validation on the SaMD, and leave it to the less stringent QMS SW validation process.
<br />
<br /></p>
<h4>Conclusion</h4>
<p>A complete PMS process requires user data and clinical data from the field. Automating this data collection with some PMS functions in a SaMD is a good option. It will result in a validation covering the requirements, when applicable, of SaMD, of GDPR or HIPAA and 21 CFR part 11. That validation can be a burdensome task when all these regulations are simultaneously applicable. But it can be worth the effort, when manual data collection is a too burdensome task on its own.</p>https://blog.cm-dm.com/post/2022/05/13/Software-as-a-Medical-Device-Post-Market-Surveillance#comment-formhttps://blog.cm-dm.com/feed/atom/comments/258SaMD decommissioning, recall, removal and withdrawalurn:md5:4108ef511635793e8f0b82de191883292022-04-15T14:26:00+02:002022-04-15T14:26:00+02:00MitchRegulationsCE MarkRecallSaMD<p>We saw <a href="https://blog.cm-dm.com/post/2022/02/25/Medical-Device-lifetime-and-SaMD">in the previous post</a> how the lifetime of a SaMD can be defined. Let's continue with the operations that can affect this lifetime.</p> <h4>Decommissioning</h4>
<p>Decommissioning software can happen at the expected end of life of the SaMD, or earlier. In both cases, the end-user or a technician in charge of the device have to be informed. Users are supposed to cease using the SaMD. If no provision is taken by the legal manufacturer, end-users will continue to use it, for sure!<br /></p>
<h5>Case 1: Warning the user</h5>
<p>The bare minimum is to send a mail (either paper or electronic) to the end-users to warn them that the device has reached its end-of-life. Doing this is what is required from a legal point of view, the responsibility of the legal manufacturer ends with this letter. It will work with professional users like health care providers. But, from a risk-based approach or a usability engineering approach, that won't work with the general public or lay persons.</p>
<h5>Case 2: Software Licence</h5>
<p>A more strigent solution is to have a license manager included in the SaMD. When the SaMD is installed, a license is allocated to the software instance or several software instances, depending on the license scheme. The license is valid until one of the following two terms is reached: either the end of license contract, or the SaMD end-of-life (which will also be part of the contract anyway).It means that that the licenses are managed by some operations department of the manufacturer, with a license generator and a registry of all licenses.<br />
The way the software behaves when the license expires can be assessed with risk management. Having a stubborn SaMD refusing to open when the license expires can be a hazardous situation in some clinical contexts. Then, it will be preferable to display a warning to let the user continue use the SaMD anyway. Patient safety is one thing, legal matters are another.<br />
Some licensing librairies don't require an internet connection. This is something better within a HCP network. But it requires to have periodic maintenance of the SaMD, with updates of the licenses when the contract is renewed.</p>
<h5>Case 3: User account</h5>
<p>A third solution, suitable with the general public, with lay persons, but also with mobile apps, is to manage user accounts. When the software starts, it sends a request to a server managed by the SaMD manufacturer, to verify whether the user can use the SaMD or not.<br />
The server will answer "no" when the user account license expires or when the SaMD reaches its end of life. Then a warning can be displayed to the user with, if appropriate, an invite to update the SaMD version.<br />
It means that the manufacturer has to implement and maintain such server. It means also that this server is subject to an exciting and joyful QMS software validation.</p>
<h4>Recall</h4>
<p>Recall of hardware devices is easy to understand. The manufacturer takes actions to either ship back the devices to their premises to decommission them (removal) or to fix the problem by maintenance operations (correction).<br />
With SaMD, correction is the preferred way. The manufacturer makes the users or technicians install a bug fix, a new version. Users are informed that this new version exists, either by mail (cases 1 and 2), or by server notification (case 3).<br />
In some rare cases, a removal is required. Then, case 3 is a lot easier than cases 1 or 2, which require manual interventions. In case 2, if the license manager isn't connected to the internet, it cannot be informed of the removal. Taking <a href="https://www.fda.gov/medical-devices/postmarket-requirements-devices/recalls-corrections-and-removals-devices">FDA wording</a>, an effectiveness check will surely give better results in case 3.<br />
<br />
Remark: in all cases, a recall requires some paperwork, and at least a recall letter of the manufacturer to the users. A fully automated solution like case 3 isn't enough, unless a function to display such letter and manage user's acknowledgment exists in the SaMD. Remark in the remark: Such function will be interesting to validate, at the border of QMS SW and SaMD, with electronic records management and probably some other traps.</p>
<h4>Removal or Withdrawal</h4>
<p>This is the decision of the SaMD manufacturer or the regulatory authority to remove a device from the market. The regulatory difference between the two:</p>
<ul>
<li>Removal the device is defective,</li>
<li>Withdrawal the device is not necessarily defective.</li>
</ul>
<p>Technically speaking, both are equivalent. Case 3 will be more effective than cases 1 and 2.<br />
In all cases, the manufacturer has to send letters to the users to inform them of the withdrawal. In case 1, they cannot do anything else. In case 2, if the license manager is not connected to the internet, they cannot do anything else either. In case 2 with internet connection and in case 3, it is possible to inform the software of its status.</p>
<h4>SaMD product specifications</h4>
<p>If we are in cases 2 or 3, we can draft the following product specifications about lifecycle management:</p>
<ul>
<li>Case 2:
<ul>
<li>Lifecycle requirement 1: A license manager is present in the SaMD,</li>
<li>Lifecycle requirement 2: If an internet connection is present, the SaMD requests the license server about license status,</li>
<li>Lifecycle requirement 3: At startup the SaMD checks the license. When the license expires, the SaMD displays a warning to the user (or something else, choose your behaviour).</li>
</ul></li>
<li>Case 3:
<ul>
<li>Lifecycle requirement 1: At startup, the SaMD send a request to a server to know the current user account status and software status: valid license, expired licence, expired version, software update required, device recall,</li>
<li>Lifecycle requirement 2: When a software update is required, the user has to download and update the version prior to using it,</li>
<li>Lifecycle requirement 3: if the device is in recall, then a recall letter is displayed to the user. it is possible to send the letter to another device (mail, BT...) to let the user store it elsewhere or print it,</li>
<li>Lifecycle requirement 4: if the software version has expired, a message is displayed to the user with the reason of the expiration (enf-of-life, withdrawal...)</li>
<li>Lifecycle requirement 5: if the user account is not valid, a message is displayed to the user with an invite to renew it.</li>
</ul></li>
</ul>
<p>These kinds of product specifications are mostly suitable for mobile apps connected to the internet. But we could imagine that a SaMD manufacturer installs such server on the HCP network, with control on the server.<br />
Then we have to consider whether this server is a SaMD or not. If yes, it is quite a good option to reorganize its architecture to isolate the license server software items from other software functions qualified as medical device.<br />
We end with the requirement to validate that server as a QMS software, installed in the client premises (beware of IQ!). Such a valdilation is worth the effort, only if allows to ease all the processes described above.<br />
<br />
<br />
Anyway, SaMD decommissioning, recall, removal and withdrawal can be performed like any other devices. This article proposed some other solutions taking the opportunity to use communication capabilities of software. They ease the process, once validated but they’re not mandatory.</p>https://blog.cm-dm.com/post/2022/04/15/SaMD-decommissioning%2C-recall%2C-removal-and-withdrawal#comment-formhttps://blog.cm-dm.com/feed/atom/comments/256Medical Device lifetime and SaMDurn:md5:426824fa4bf694b5d16e8659f7b808e92022-02-25T14:28:00+01:002022-02-25T14:28:00+01:00MitchRegulationsCE MarkSaMD<p>Medical device regulations require the manufacturers to define lifetime for their devices. In the case of SaMD, this requirement needs some interpretation.</p> <h4>Lifetime in hardware medical device</h4>
<p>Hardware parts can rust, degrade, fatigue, any kind of ageing phenomenon that you can imagine. For example, the lifetime of an electromedical device can be based on the weakest component impossible to change, like capacitors soldered on the printed circuit board.<br />
Remark: batteries are actually the weakest component, but they can be changed during maintenance operations.</p>
<h4>SaMD Lifetime</h4>
<p>Nothing rusts or degrades in software. Degradations of performance can be seen more as bugs than ageing. E.g.: if a software slows down, it’s because the memory or hard drive are full. It can be corrected by maintenance (emptying the HD) or by bug fix (fixing the memory leak).<br />
<br />
Lifetime of software shall then be based on the context of use: when this context changes, the software turns out to be unusable.</p>
<h5>Hardware</h5>
<p>SaMD runs on hardware. When this hardware is obsolete, namely when the hardware manufacturer ceases its support, the software running on this hardware cannot be used any more. That rationale can be used with specific off-the-shelf hardware, like a medicalized PC, made to be used in the operating room.<br />
<br />
SaMD also runs on consumer electronics hardware. In this case, the obsolescence can be estimated, based on hardware generation lifetime. E.g.: the technical characteristics of a PC of today can still be found in a PC in five years’ time.</p>
<h5>SOUP, OS, browsers</h5>
<p>SaMD needs SOUP to run. When the SOUP versions used by SaMD are obsolete, this SaMD cannot be maintained any more by its manufacturer. This is especially the case with security issues that won’t be fixed by the SOUP vendor or the open-source project.<br />
SaMD can live with an obsolete version of a SOUP as long as there is no critical issue published on this SOUP. However, when that SOUP is an OS or a browser, it is almost impossible to continue using the SaMD on a new major OS/browser version, without revalidating the SaMD.<br /></p>
<h5>Clinical practice, clinical data</h5>
<p>Hardware and SOUP obsolescence are classical rationale to define SaMD lifetime. Clinical practice is a newcomer in this domain.<br />
SaMD is designed with the help of clinicals, where their practice is translated into a SaMD intended use and products requirements. Practices can evolve quite quickly in the world of digital health.<br />
Thus clinical practice can be a good reason to limit the lifetime of a SaMD to something shorter than hardware or software obsolescence. This is the case for machine learning algorithms. Clinical practice generates clinical data, which ML algorithms aren’t trained to. Then, the ML needs to be retrained and revalidated.</p>
<h4>Usual lifetime</h4>
<p>The usual lifetime that can be defined for SaMD depends on the technology used:</p>
<ul>
<li>SaMD running on a Windows PC could have a lifetime of 3 to 5 years,</li>
<li>SaMD running on a Linux LTS distribution could have a lifetime of 5 to 10 years (10 is optimistic),</li>
<li>SaMD mobile application lifetime could be limited to 2 years.</li>
</ul>
<h5>Mobile apps</h5>
<p>IT could be even more tempting to define a shorter lifetime for mobile apps, like 1 year. This is not appropriate for SaMD, when the time needed to CE mark it with a Notified Body can be more than 1 year! Given how burdensome CE marking SaMD can be, less than 3 years means being in a perpetual conformity verification process.</p>
<h5>Lifetime vs Release</h5>
<p>Lifetime and release versions aren’t equal. The lifetime starts when a major version is released. Then, you can have several minor release versions within the lifetime of a SaMD. You can refer to <a href="https://blog.cm-dm.com/post/2020/05/15/Software-release-vs-design-transfer">that article on release</a> to see what a release is and when it happens.</p>
<h4>Regulation vs technology</h4>
<p>Medical device regulation isn’t well adapted to the frantic pace of technology changes. OS’es are updated with major changes on a yearly basis, browsers are continuously updated (can you remember the last major update of Firefox?).<br />
The regulatory life rhythm looks like geological times, from a software point of view!<br />
<br />
As a consequence, defining a lifetime compatible with regulatory ages requires monitoring SOUP, their updates, their obsolescence, in order to assess if SOUP changes trigger major SaMD updates and revalidation.<br />
This is what you find in clause 6.1.f of IEC 62304.</p>
<h4>Cloud software</h4>
<p>What you read above is even more subject to interpretation with cloud software. Updating cloud software monthly or quarterly is necessary, to follow the pace of continuous changes of the underlying cloud infrastructure.<br />
However, lifetime is still a requirement for cloud software. The only solution is to define a major version, a milestone in the cloud software lifecycle. All subsequent versions will be minor changes, until a new major version is released.<br />
<br />
The game is to validate, CE mark and launch this new major version before the end of life of the previous one!</p>https://blog.cm-dm.com/post/2022/02/25/Medical-Device-lifetime-and-SaMD#comment-formhttps://blog.cm-dm.com/feed/atom/comments/255Is 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/219EU Medical Device Regulation - Changes for softwareurn:md5:66da40965545618edfc9e4225ef5e0532016-09-02T13:27:00+02:002019-11-09T20:27:46+01:00MitchRegulationsCE Mark<p>We've seen 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">the previous article</a> the revolution in the regulatory classification brought by the new rule 10a for standalone software.<br />
Let's see now the other changes. These changes are relevant for all software: standalone, embedded, device or accessory.<br />
They're not as big as the new rule 10a, but they will deserve a significant amount of man-hours and documentation.</p> <p><strong>Edit November 2019</strong>: rule 10a is named rule 11 in the final version of the MDR.</p>
<h4>Unique Device Identification</h4>
<p>The new MDR contains requirements on the UDI. Simply, these requirements are synchronized with those, which are ready applicable in the USA. Likewise, they add some specific requirements for software.<br />
The optimistic way is to consider that both regulations agree on the content of UDI. But this is the optimistic way.<br />
We have to take UDI for what it is: an information system. Fatally, there will be discrepancies between the EU and the USA: in specifications (the regulations), in implementation (the EUDAMED database), and in support (if we can talk about support).<br />
There will be bugs in UDI.</p>
<h4>Essential Requirements</h4>
<p>The essential requirements are updated for software. The requirement #14.2 is the successor of requirement #12.1.bis of the directive. New criteria are introduced on:</p>
<ul>
<li>IT environment in #11.2,</li>
<li>Interoperability in #11.5,</li>
<li>Cybersecurity in #14.2,</li>
<li>Mobile platforms in #14.3, and</li>
<li>IT network and IT security in #14.3a.</li>
</ul>
<p>While the software validation requirement in #14.2 has seen minor changes compared to the directive, the other requirements are brand new and are there to cover subjects, which were not be anticipated in the directive, even in the last update of 2007. These requirements are a regulatory catch-up, compared to the FDA's early oversight on these subjects.</p>
<h4>Harmonized standards</h4>
<p>If we look at the harmonized standards as methods of conformity to these requirements, IEC 62304 will be the most relevant standard. For 14.2, 14.3, 14.3a, and 11.2, IEC 62304 only has a requirement in section 5.2, to include software requirements on these subjects.<br />
IEC 62366 is also a method of conformity for requirements 14.3.<br />
IEC 82304-1 is still in draft. If it is harmonized, it will bring new requirements on the environment, interoperability, and validation. It will help begin compliant to 11.5, 14.3.a and 14.2 for the validation.</p>
<h4>And cybersecurity?</h4>
<p>The few words included in 11.5, 14.1 and 14.3 add a lot: nowhere before we could find such requirements in the EU MD regulations.<br />
There is no harmonized standard for cybersecurity. More generally, there are standards on IT security for hospital networks, medical communication <a href="https://blog.cm-dm.com/post/2013/08/09/FDA-recognizes-25-standards-about-interoperability-and-cybersecurity">in the IEC 80001-x series and other FDA-recognized standards</a>. But there is no standard covering the lifecycle of software medical devices.<br />
The only way to be compliant with cybersecurity requirements, is to rely on the existing FDA guidances on <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">cybersecurity during design</a> and <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">during post-market surveillance</a>.</p>
<h4>Conclusion</h4>
<p>The new essential requirements on software require new evidence of conformity, which current harmonized standards don't cover entirely. We can then expect IEC 82304-1 to be harmonized. It is less likely to see a new standard dealing exclusively with cybersecurity in medical devices. There's no such project in standardization committees.<br />
Another solution could be that EU creates Common Technical Specifications on cybersecurity, as set out in article 7 of the MDR. But we have no clue on this process solely used for IVDs up to now and expanded to all MDs.
<br />
<br />
<strong>Edit November 2019</strong>:<br />
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/09/02/EU-Medical-Device-Regulation-changes-for-software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/193MEDDEV 2.1/6 2016urn:md5:cdca59af59cd92ed5caabecdbe3763d72016-08-10T10:09:00+02:002016-08-10T09:20:25+02:00MitchRegulationsCE MarkGuidance <p>A new version of the <a href="http://ec.europa.eu/DocsRoom/documents/10362/attachments/1/translations">MEDDEV 2.1/6 was published in July 2016</a>.<br />
<br />
The <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">first version of 2012</a> was a major breakthrough. The new version won't change you life. Almost nothing new, excepted a few definitions on software, input data, output data, a remarkable reference to IMDRF definitions, and a non-significant update of the first decision tree.<br />
<br />
Add to that a few typos, and you have the new version of the MEDDEV:</p>
<ul>
<li>"lossless compression" disappeared from the decision tree (was it intentional?) but is still present in the explanations of decision step 3,</li>
<li>Decision step 7 doesn't have any explanation.</li>
</ul>
<p><br />
MEDDEV for nothing ♫ and tips for free ♬.</p>https://blog.cm-dm.com/post/2016/08/10/MEDDEV-2.1/6-2016#comment-formhttps://blog.cm-dm.com/feed/atom/comments/194Is 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/187IEC 82304-1 - latest news about the standard on Health Softwareurn:md5:d4d8fc396a6bed4f074197a72573b42a2016-01-15T14:30:00+01:002016-06-23T20:01:45+02:00MitchStandardsCE MarkFDAIEC 62304IEC 82304ISO 14971Software Validation<p>IEC 82304-1 <em>Health software -- Part 1: General requirements for product safety</em> standard is still under development. Its status is visible on the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59543">page of ISO website, dedicated to IEC 82304-1</a>. There is even a preview of the first three pages of this draft standard.</p> <p>The last draft of IEC 82304-1 was published for comments in July 2015. It is a DIS (draft international standard) and should pass a step early 2016, by being accepted by the drafting committee. It means that a FDIS (final draft international standard) should be published in S1 2016. If it is accepted, the final version should be published by the end of 2016.</p>
<h4>What is the scope of IEC 82304-1?</h4>
<p>The scope of IEC 82304-1 intersects the scope of IEC 62304 but is not identical. It includes different types of software and different steps of the software lifecycle.
IEC 82304-1 deals with health software. The definition of health software is given in the section 3.6 of the standard:</p>
<blockquote><p>HEALTH SOFTWARE<br />
software intended to be used specifically for maintaining or improving health of individual persons, or the delivery of care.</p>
<p></p></blockquote>
<p>It is completed with the definition of health software product in the section 3.7 of the standard:</p>
<blockquote><p>HEALTH SOFTWARE PRODUCT<br />
combination of HEALTH SOFTWARE and ACCOMPANYING DOCUMENTS</p>
<p></p></blockquote>
<p>The definition of medical device software, given at section 3.x of IEC 62304-2015 is different from the definition of health software:</p>
<blockquote><p>MEDICAL DEVICE SOFTWARE<br />
SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE<br />
NOTE: This includes a MEDICAL DEVICE software product, which then is a MEDICAL DEVICE in its own right.</p>
<p></p></blockquote>
<p>The definition of SOFTWARE PRODUCT, which was used in IEC 62304:2006, was removed from IEC 62304:2015. We now have the definition of HEALTH SOFTWARE PRODUCT in IEC 82304-1. This is one proof, amongst others, to make IEC 82304-1 and IEC 62304 a two-standard team.</p>
<h4>Types of software</h4>
<h5>Types of software regarding the medical intended use</h5>
<p>The first main difference between both definitions is the intended use. IEC 62304 deals only with software with medical intended use, whereas IEC 82304-1 deals with any kind of software, which directly or indirectly has an effect on health.<br />
The scope of IEC 82304-1 is broader than the scope of IEC 62304. The following types of software are in the scope of IEC 82304-1 but not IEC 62304:</p>
<ul>
<li>Radiology Information Systems (RIS),</li>
<li>Prescription Management Systems (PMS),</li>
<li>Laboratory Information Management Systems (LIMS),</li>
<li>Mobile Apps, which are not Mobile Medical Apps, according to the <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">FDA Guidances on this subject</a>,</li>
<li>Software, which are not qualified as medical devices, according to the <a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">MEDDEV 2.1/6 EU Guidance</a>.</li>
</ul>
<p>Thus IEC 82304-1 includes in its scope standalone software, which are not regulated as medical devices.</p>
<h5>Types of software regarding the platform</h5>
<p>IEC 82304-1 deals only with standalone software. Contrary to IEC 62304, it doesn't deal with software embedded in medical devices or embedded in devices with specific hardware. Only software running on a standard PC, server, tablet, or smartphone with a general purpose Operating System are in the scope of IEC 82304-1.<br />
The graphic below, borrowed from IEC 82304-1, shows the scope of this standard versus the scope of IEC 62304.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.Scope_of_IEC_82304-1_m.png" alt="Scope_of_IEC_82304-1.png" style="display:table; margin:0 auto;" title="Scope_of_IEC_82304-1.png, Dec 2015" />
Note: the rectangle in green is not present in the graphic of the standard. It was added here for clarification to show the scope of IEC 62304.</p>
<h4>Steps of the software lifecycle</h4>
<p>IEC 82304-1 deals with standalone health software product. It defines requirements at the system/product level like:</p>
<ul>
<li>Product Requirements,</li>
<li>Product Validation,</li>
<li>Product Identification and Instructions For Use,</li>
<li>Post-market activities.</li>
</ul>
<p>And it references IEC 62304:2015 for requirements at software level.<br />
IEC 82304-1 kind of takes the place of IEC 60601-1 or IEC 61010 for standalone software. IEC 60601-1 defines requirements at system level for Programmable Electric Medical Systems (PEMS), and references IEC 62304 for the software lifecycle.<br />
<br />
Likewise, IEC 82304-1 defines requirements at system level for health software systems, and references a subset of IEC 62304 for the software lifecycle.<br />
The graphic below sums up this.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.scope_of_IEC_82304-1_in_lifecycle_m.png" alt="scope_of_IEC_82304-1_in_lifecycle.png" style="display:table; margin:0 auto;" title="scope_of_IEC_82304-1_in_lifecycle.png, Dec 2015" />
Consequence: if you want to apply IEC 82304-1 to your software, you have to apply a subset of IEC 62304 at the same time.</p>
<h4>Relationships with other standards</h4>
<p>Another way of putting this standard in the picture, it to draw the relationships of this standard with other standards, like we already did <a href="https://blog.cm-dm.com/post/2013/04/04/IEC-62304-vs-IEC-60601-1-and-IEC-61010">here for IEC 62304</a>.
<img src="https://blog.cm-dm.com/public/22-IEC-82304-1/.relationship_of_IEC_82304-1_with_other_standards_m.png" alt="relationship_of_IEC_82304-1_with_other_standards.png" style="display:table; margin:0 auto;" title="relationship_of_IEC_82304-1_with_other_standards.png, Dec 2015" />
This graphic anticipates a bit what is explained in the next article: ISO 14971 is not required by IEC 82304-1 but is still required by IEC 62304.</p>
<h4>Is it mandatory?</h4>
<h5>Short answer:</h5>
<p>No. A standard is never mandatory, expected in very rare cases, but surely not for health software!<br /></p>
<h5>Not so long answer:</h5>
<p>Standards are never mandatory but when they are recognized by regulation authorities, like the FDA, they become "gold standards" de facto.<br />
So, for standalone software regulated as medical devices (eg. mobile medical apps), it could become recognized by the regulations authorities as soon as the final version is published. It would make it almost mandatory.<br />
But for standalone software NOT regulated as medical devices, since they are out of the scope of regulations authorities, the manufacturers of such software could show very little willingness to implement IEC 82304-1!<br />
<br />
In a nutshell:</p>
<ul>
<li>if you develop standalone software medical devices, be prepared to see IEC 82304-1 recognized by the FDA and harmonized by the European Commission when it is published. Probably not before late 2016,</li>
<li>if you develop standalone health software not qualified as medical device, we don't know what regulation authorities will make of this standard. But odds are low that it will become mandatory<br /></li>
</ul>
<p><br />
<a href="https://blog.cm-dm.com/post/2016/03/11/IEC-82304-1-Overview-of-requirements">Next time</a> we'll see more in details the requirements of this standard.</p>https://blog.cm-dm.com/post/2016/01/15/IEC-82304-1-latest-news-about-the-standard-on-Health-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/178IEC 62366-1 becomes recognized by the FDAurn:md5:3effac067a845d68db20b7ff35f9fc762015-09-23T09:57:00+02:002015-09-25T08:41:57+02:00MitchStandardsCE MarkFDAIEC 60601-1IEC 62366<p>Long time no see. For those of you guys who have been following this blog for a long time.<br />
Today I have time to write a short article on the new version of IEC 62366 standard: IEC 62366-1:2105 <em>Application of usability engineering to medical devices</em>.</p> <p>It was first published by the IEC at the beginning of 2015. Then the FDA was quick to add it to its list of recognized standards. It was published in <a href="http://www.gpo.gov/fdsys/pkg/FR-2015-08-14/html/2015-19991.htm">the Federal Register in August 2015</a> and the old version was marked withdrawn.<br />
It looks like the FDA wasn’t happy with the previous version to be so prompt to add the new one and withdraw the old one (pure speculation of mine).<br /></p>
<h4>Difference between US and EU</h4>
<p>We are now in a situation where the FDA recognizes the IEC 62366-1:2015 while the European Commission still references the IEC 62366:2007 in the list of harmonized standards. Discrepancies between standards versions can be difficult to handle.<br />
For those of you who know the changes in versions of IEC 60601-1 <em>Medical electrical equipment - Part 1: General requirements for basic safety and essential performance</em>, you know the hassle it can be. Fortunately, the case is more simple with IEC 62366.<br />
<br />
If your company designs products to be sold on the US and European markets, you’d better choose IEC 62366-1 than the old version. Why? Because it’s probably easier to bring evidence that you’re compliant with European regulations with the new standard (namely essential requirements about usability) than to bring evidence that you’re compliant with US regulations with the old standard that was withdrawn.<br />
Add to this that IEC 62366-1 should be referenced in the list of harmonized standards sooner or later. Thus there’s really no use to continue applying IEC 62366:2007 for new designs.</p>
<h4>Consequence on IEC 60601-1-6</h4>
<p>Coming back to IEC 60601-1, the IEC 60601-1-6 <em>Part 1-6: General requirements for basic safety and essential performance – Collateral standard: Usability</em> references IEC 62366. It basically takes IEC 62366 as is and adds some changes on the scope of products and some requirements on instructions for use.<br />
Even if IEC 60601-1-6 references the old version of IEC 62366, it is easy to apply the changes required by IEC 60601-1-6 to IEC 62366-1:2015 hence the wording of IEC 62366 hasn't changed. Thus, there's once again no use to continue applying the old version of IEC 62366.</p>
<h4>IEC 62366:2007 is dead</h4>
<p>As a consequence you have now to rely on the new usability engineering process defined in the requirements of IEC 62366-1. It is not easy to implement as it brings new concepts: formative evaluation and summative evaluation.<br />
We already talked about that <a href="https://blog.cm-dm.com/post/2015/01/09/IEC/FDIS-62366-1-released-in-November-2014">in a previous article</a>. Just to say that if you’ve been waiting for the last moment to change your design procedures to be in line with IEC 62366-1, uh, now, it’s time.<br />
<br />
<br />
Edit: fixed dates of IEC 62366 thanks to remarks of <a href="http://www.dm-experts.fr">Denys Durand Viel of DM Experts</a>.</p>https://blog.cm-dm.com/post/2015/09/23/IEC-62366-1-becomes-recognized-by-the-FDA#comment-formhttps://blog.cm-dm.com/feed/atom/comments/174Validation of software used in production and QMS - Part 3 Validation Protocol and Reportsurn:md5:454ac87f96e4f76d598958a75fa3e7d62015-08-28T12:54:00+02:002015-08-28T12:54:00+02:00MitchRegulationsCE MarkFDAISO 13485Software Validation<p>We continue this <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">series on validation of software used in production</a> and QMS with the Validation Protocol and Reports.</p> <p>The Validation Master Plan (VMP) comes with other documents:</p>
<ul>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-VMP-template.docx">Validation Master Plan template</a> itself, it contains general provisions for software validation,</li>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-Validation-Protocol-template.docx">Validation Protocol template</a>, it contains the application of the VMP for a given system,</li>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-Validation-Report-template.docx">Validation Report template</a>, it contains results of the validation protocol for a system,</li>
<li>The <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-Final-Validation-Report-template.docx">Final Validation Report</a>, it contains the conclusion of the validation of a system.</li>
</ul>
<p>I share these templates with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/fr/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/">Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License</a>.
<br />
<br />
<h4>Content of the Validation Protocol</h4>
<p>The validation protocol is the instanciation of the provisions of the Validation Master Plan (VMP). You will have one validation protocol per system needing validation.<br />
The content of the validation protocol repeats the phases found in the VMP, with specific provisions, if needed.<br />
<br />
For example, a system of low level of concern may have a validation protocol with IQ and PQ only, considering that OQ is not mandatory given the system features. Of course, skipping OQ shall be documented!
<br /></p>
<h4>Content of the Validation Reports</h4>
<p>The validation reports are simply the records of validation protocol.</p>
<h5>Validation Report</h5>
<p>The validation report is filled with data gathered during qualification phases. There may be a single report recording all phases or multiple reports. When qualification phases are long or verbose, having a report per phase is a good option.<br />
The validation report ends with a conclusion about the conformity of the product versus requirements verified during the phase. It's important to keep this part hence it inks the status of the system at the end of the phase. That's also a cultural way of doing this in the world of physical equipment qualification!</p>
<h5>Final Validation Report</h5>
<p>The final validation report contains:</p>
<ul>
<li>The identification of the system that is validated,</li>
<li>The final conclusion about the validation.</li>
</ul>
<p>The identification is important, to be sure which version is validated and who can use what in routine. This is also a favorite way of auditors to search for pitfalls in the identification of the validated system.<br />
The final conclusion is about the compliance of the system versus regulatory requirements. Note the difference between validation reports (compliance to requirements in the scope of the phase) and the final validation report (compliance to regulatory requirements).
<br />
<br />
<br />
That's the end of this <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">series about computerized systems validations</a>.<br />
With all this templates and explanations, you should be ready to perform you own computerized systems validations. Feel free to ask questions in comments!<br /></p>https://blog.cm-dm.com/post/2015/08/28/Validation-of-software-used-in-production-and-QMS-Part-3-Validation-Protocol-and-Reports#comment-formhttps://blog.cm-dm.com/feed/atom/comments/170Validation of software used in production and QMS - Part 2 Validation Master Planurn:md5:e2e9ba9415c539ce2786e41b6f47b7c22015-07-24T11:57:00+02:002015-09-03T07:43:53+02:00MitchRegulationsCE MarkFDAISO 13485ISO 14971Software Validation<p>We continue this <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">series on validation of software used in production</a> and QMS with the Validation Master Plan (VMP).<br />
Better than endless explanations, I added a Validation Master Plan template to my <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates repository page</a>.</p> <p>The Validation Master Plan (VMP) is here: <a href="https://blog.cm-dm.com/public/Templates/CSV/2015-VMP-template.docx">Validation Master Plan template</a>. It contains general provisions for software validation.<br />
<br />
It comes with other documents that we'll see in the next post:</p>
<ul>
<li>The Validation Protocol template, it contains the application of the VMP for a given system,</li>
<li>The Validation Report template, it contains results of the validation protocol for a system,</li>
<li>The Final Validation Report, it contains the conclusion of the validation of a system.</li>
</ul>
<p>I share these templates with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/fr/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/">Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License</a>.
<br />
<br />
<h4>Content of the VMP</h4>
<p>The Validation Master Plan contains the provisions for:</p>
<ul>
<li>Identifying systems that require validation,</li>
<li>Defining the level of scrutiny of the validation.</li>
</ul>
<h5>Selecting systems</h5>
<p>Not all systems used by a company should be validated. As we already saw <a href="https://blog.cm-dm.com/post/2015/06/19/Validation-of-software-used-in-production-and-QMS-Part-1-introduction">in the previous article</a>, only those in the scope of requirements found in applicable regulations and standards shall be validated.<br />
The VMP template gives hints to define the selection criteria and to present the results of the selection.</p>
<h5>Level of concern</h5>
<p>The VMP template introduces the concept of "level of concern", to help validation team define the steps required by validation.<br />
The level of concern is borrowed from the FDA concept found in its guidances on medical device software. It is here adapted to the context of computerized system validation.</p>
<h5>Validation steps</h5>
<p>The validation steps are the very classical ones found in every validation protocol:</p>
<ul>
<li>Design Qualification (DQ),</li>
<li>Installation Qualification (IQ),</li>
<li>Operations Qualification (OQ),</li>
<li>Performance Qualification (PQ).</li>
</ul>
<p>These concepts don't mach well those found in software validation. But some links can be drawn between them.</p>
<h5>Design Qualification</h5>
<p>Design qualification is applicable only to a subset of selected systems. DQ is applicable when software is internally developed or when its configuration is complex, with scripting and the like. See VMP template for hints on DQ applicability.<br />
DQ is simply a software development project. The most obvious model of software development is the waterfall model but any other kind of model is possible.<br />
The DQ should contain the classical documents and records found in a software development project:</p>
<ul>
<li>Development plan,</li>
<li>Software Requirements Specifications,</li>
<li>Design review.</li>
<li>Software Test Plan,</li>
<li>Software Test Report,</li>
<li>Final review.</li>
</ul>
<p>You may use the "all-in-one template" in the <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">templates repository page</a> to document the development projet of a software tool.<br /></p>
<h5>DQ is not IQ / OQ / PQ</h5>
<p>Don't miss the point about DQ. It's a phase which is different from IQ / OQ / PQ.<br />
To make things simple, DQ is made on a test platform or pilot platform, IQ/OQ/PQ are made on the target platform.<br />
There may be cases where the test platform is also the target platform. But, to make things clear and catch the concepts, remember <em>DQ equals test platform</em> and <em>IQ / OQ / PQ equals target platform</em>.
<img src="https://blog.cm-dm.com/public/Templates/CSV/.DQ-IQ-OQ-PQ_m.png" alt="DQ-IQ-OQ-PQ.png" style="display:block; margin:0 auto;" title="DQ-IQ-OQ-PQ.png, Jul 2015" />
Using the language of software development teams, the version output of DQ is like a Release Candidate version ready to be tested by other people than the software development team.</p>
<h5>Installation Qualification</h5>
<p>Installation qualification is the verification of the installation of software on its target platform. The IQ can be made either during the installation or after the installation.<br />
<br />
When it is done during the installation, the tester runs the installation and verifies at the same time that the installation is running well. The IQ is then a mix of installation tests (eg: running the installer) and of inspections (eg: checking the hardware version, the OS version, the documentation...)<br />
<br />
When it is done after the installation, the verification is an inspection of the installation records. The tester goes through all installation records and checks that the installation was correct.<br />
<br />
Note that the IQ happens on the target platform. It shouldn't be confused with the installation of software on a test platform during DQ. Verifying that software can be installed and run on the test platform is a part of Design Qualification or of preliminary tests before the IQ.<br />
<br />
Using the language of software development teams, the version installed in IQ is the Release Candidate.</p>
<h5>Operations Qualification</h5>
<p>Operations Qualification is the verification of software functions on its target platform. The OQ is made after the IQ (I can't verify software if it wasn't properly installed before).<br />
OQ is a set of tests verifying the functional requirements of software. The functional requirements can be either user requirements or technical requirements. These requirement are input data of the validation process.<br />
<br />
When OQ is preceded by DQ, DQ tests and OQ tests may overlap. The most simple solution is to redo all the tests passed during DQ. OQ test can also be a reduced set of DQ tests - like typical user scenarios. OQ tests can also be completely different tests if DQ was oriented to verification of technical requirements.<br />
<br />
When OQ is not preceded by DQ, a test protocol verifying the requirements shall be written.<br />
<br />
Using the language of software development teams, the version output of OQ is like RC2 or RC3, where most of bugs found by users have been removed.</p>
<h5>Performance Qualification</h5>
<p>Performance Qualification is the verification of software in routine use. The PQ is made after the OQ (I can't verify in routine use if software functions haven't been properly tested before).<br />
<br />
PQ can be a set of structured tests verifying user scenarios. It can also be made of free tests by end-users. The PQ should contain a predefined period of surveillance of software used in routine by the end-users.<br />
<br />
Using the language of software development teams, the version output of PQ is the Final Release of software.</p>
<h4>Latitude in DQ / IQ / OQ / PQ content</h4>
<p>These four steps are heavy to implement, but we have escape plans.<br />
<br />
The VMP gives latitude to the validation team in the exclusion of the validation steps and in their content. Provided that rationale and evidence are brought, it is possible to make the validation more simple than these four steps.<br />
DQ is obviously not required for purchased software with minimal configuration settings. It's possible to simplify IQ, OQ and PQ steps when the context allows it. Likewise it's possible to exclude IQ or OQ with justification. It looks difficult to exclude PQ. But it may be possible to have OQ and PQ merged in a single step.</p>
<h4>Retrospective validation</h4>
<p>With legacy system, it's possible to do a retrospective validation. This is another kind of escape plan.<br />
It is based on the analysis of historical data of a system already used in routine. The retrospective validation consists in assessing the conformity of the system to regulations by analyzing:</p>
<ul>
<li>Records output by the system,</li>
<li>Non-conformities linked to the system or to processes involving the system,</li>
<li>Customer complaints linked to the system or to processes involving the system,</li>
<li>Any other relevant data (argh, can't be more precise ...).</li>
</ul>
<p>Be careful with retrospective validation hence it is not "appreciated" by auditors and inspectors. They're going to search for the pitfall in this kind of validation.<br />
The easiest pitfall to find is if you modify the system after you've validated it retrospectively. How to convince the auditor that a complete revalidation is not necessary? A tiny software change can have dire side effects.<br />
<br />
Anyway, retrospective validation is sometimes the only way to validate a legacy system that has been used for a long time without any bugs, and without any will of the users to modify it.<br />
<br />
<br />
<br />
Next time, we'll see the <a href="https://blog.cm-dm.com/post/2015/08/28/Validation-of-software-used-in-production-and-QMS-Part-3-Validation-Protocol-and-Reports">Validation Protocol and Validation Reports</a>.</p>https://blog.cm-dm.com/post/2015/07/24/Validation-of-software-used-in-production-and-QMS-Part-2-Validation-Master-Plan#comment-formhttps://blog.cm-dm.com/feed/atom/comments/169NBOG’s Best Practice Guide 2014-3: all you wanted to know about reporting software design changesurn:md5:f753972ee3fbf992838409bb55e367ed2014-12-12T21:42:00+01:002014-12-12T23:53:52+01:00MitchRegulationsCE MarkGuidance<p>When should a manufacturer report devices changes or QMS changes to notified bodies, according to the 93/42/CE directive?<br />
There hasn't been clear criteria, until the Notified Bodies Operating Group (NBOG) published the <a href="http://www.nbog.eu/resources/NBOG_BPG_2014_3.pdf">Best Practice Guide 2014-3</a> : <em>Guidance for manufacturers and Notified Bodies on reporting of Design Changes and Changes of the Quality System</em>.</p> <p>This guidance is the third of a <a href="http://www.nbog.eu/2.html">series of 3 guidances</a> published in november 2014 by the NBOG. The first two are more intended to be followed by notified bodies and should be known by manufacturers for their information.<br />
The third one is the purpose of this post.</p>
<h4>Change control</h4>
<p>The guidance begins with a reminder of the EU regulations, a few definitions (pay attention to the definition of "critical supplier"). It then gives the recommended <em>Steps of the manufacturer for the change assessment procedure</em>.<br />
Needless to say that you should review your Change Control procedure(s), in the light of these recommendations!<br />
<br />
The recommendations insists on reporting substantial changes of the QMS or in the design of devices to notified bodies. The notified bodies made sure for a long time that manufacturers communicate on substantial changes, either by contract, or during audits, or through non-conformities. This guidance just sets a frame, which ensures that practices are harmonized between notified bodies.<br />
This is good, but not the best part of the guidance.</p>
<h4>Criteria for "substantial changes"</h4>
<p>Section 5 of the guidances entitled Criteria for "substantial changes" is really the gem hidden inside the document.<br />
For the first time, a European organization has established a set of criteria and listed examples to assess what a substantial design change is for a medical device and for a QMS.<br />
The set of criteria is not closed. Hence the word <em>should</em> is employed on the introductory sentence of sections 5.1 Product changes, 5.2 Quality system changes, and 5.3 Changes to the product ranges. E.g. in 5.1: <em>Product changes should be considered substantial if the change may affect ...</em>. But these criteria are still precise.<br />
Precisions are given in the section 5.4 <em>Particular cases, examples</em>, with a section entitled <em>Changes to software</em>.</p>
<h4>Ah, ah, changes to software</h4>
<p>I don't know how many times I was asked the question: We've modified our software, should we report the change to our notified body? And I don't know how many times I answered: it depends. With the uneasy feeling that I passed for a consultant specialized in air fan! Thanks to this guidance I shouldn't.<br />
The guidance addresses the vast majority of possible software changes, either in specifications, or usability, or algorithms, or bug fixes of different levels. The rationale behind the cases listed in the guidance is the calling into question of the intended use or of the risk assessment, caused by software change.<br />
Based on the examples given in the guidance, it should (and I'm sure that it will) be easier to decide if software changes are substantial or not.</p>
<h4>The curious case of operating system</h4>
<p>The guidance considers that <em>a software change that incorporates a significant change to the operating system on which the software runs</em> should be considered a substantial change.<br />
Needless to say that a variant of the question above is: We've installed our software on Windows <choose your version>, it runs perfect, should we report the change to our notified body? I think I'm going to continue to answer: it depends.<br />
More seriously, by experience, the change of operating system is absolutely the most recurring case, for which deciding whether it is a substantial change or not, is not obvious.<br />
It's true that change of OS should be questioned. But this case should have been extended to any SOUP the software uses to run.</p>
<h4>What about the FDA?</h4>
<p>For once, we can congratulate the NBOG for having succeeded in publishing a guidance with no equivalent on the US side!<br />
The FDA published in 1997 <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm080235.htm">the guidance: Deciding When to Submit a 510(k) for a Change to an Existing Device</a>, with its famous decision-tree and its question B8, B8.1, B8.2, and B8.3 with considerations similar to those found in the NBOG’s Best Practice Guide 2014-3. But examples given are not as articulate as those found in NBOG's guide about software.<br />
However, the FDA guidance is 17 years old! An eternity for software. Software wasn't as ubiquitous as today.<br />
<br />
Anyway, NBOG’s Best Practice Guide 2014-3 is a very useful guidance, for software but more generally for all types of medical devices.</p>https://blog.cm-dm.com/post/2014/12/12/NBOG%E2%80%99s-Best-Practice-Guide-2014-3%3A-all-you-wanted-to-know-about-reporting-software-design-changes#comment-formhttps://blog.cm-dm.com/feed/atom/comments/159How to develop a smartphone App to be FDA-cleared or CE Marked? - part 6 Conclusionurn:md5:b51f7fc7fd48b7dbb5ea3dd9c949e0982014-02-14T12:48:00+01:002014-02-14T12:48:00+01:00MitchMiscCE MarkFDAGuidancemHealthmobile medical app<p>To conclude <a href="https://blog.cm-dm.com/post/2013/11/08/How-to-develop-a-smartphone-App-to-be-FDA-cleared-or-CE-Marked-part-1">this series about clearance of mobile medical apps</a>, here are a few tips to newcomers in the world in medical devices.</p> <p>There aren't so many things to pay attention to. the list is quite straightforward:</p>
<ol>
<li>Verify if your app is deemed a medical device, according to regulations. To quote the most obvious case, FDA is notoriously more strict than European Union,</li>
<li>Choose the standards that you're going to apply (see <a href="https://blog.cm-dm.com/post/2011/11/01/ISO-and-IEC-standards-explained-to-software-engineers-and-quality-managers">this post about standards</a> to have some more tips),</li>
<li>Have a look at guidances provided by regulation authorities, FDA guidances (see <a href="https://blog.cm-dm.com/pages/The-essential-list-of-guidances-for-software-medical-devices">this page about guidances</a>) and EU MEDDEV Guidances (not so interesting though, see <a href="https://blog.cm-dm.com/post/2011/11/04/How-to-classify-and-CE-mark-software">this article about CE marking software</a> instead),</li>
<li>Manage your company processes to be ready to pass a clearance process, should it be 510k or CE mark audit by notified body, even if at the very beginning, you thought this wasn't applicable to you,</li>
<li>Be careful with constraints imposed by owners of mobile applications stores.</li>
</ol>
<p>And before launching the development of a new app, take some time to make a feasibility study with:</p>
<ul>
<li>Preliminary functional specification inc. intended use,</li>
<li>Preliminary risks analysis.</li>
</ul>
<p>Output of both preliminary studies will help a lot in the realization of steps 1 to 5.</p>
<p>Have a nice journey in the world of mobile medical apps!</p>https://blog.cm-dm.com/post/2014/02/14/How-to-develop-a-smartphone-App-to-be-FDA-cleared-or-CE-Marked-part-6-Conclusion#comment-formhttps://blog.cm-dm.com/feed/atom/comments/129How to develop a smartphone App to be FDA-cleared or CE Marked? - part 1 regulationsurn:md5:8e1443cbe91f7ea077a2640646c5b6d22013-11-15T13:51:00+01:002013-12-03T09:54:24+01:00MitchRegulationsCE MarkFDAGuidancemobile medical app<p>Today I begin a new series of articles about developing (or more broadly designing) a smartphone App that is a medical device.<br /></p>
<h4>The very first question is:<br /></h4>
<p><strong>Is your App a medical device and does it need to be CE Marked or FDA cleared ?</strong><br /></p> <h4>Short answer</h4>
<p><strong>That depends on the intended use of the App.</strong><br />
:-)</p>
<h4>Long answer</h4>
<p>Some mobile apps, like PACS viewers on tablets, easily qualify as medical devices. But there are many mobile apps that are at the border of medical purpose. It is usually not easy to qualify these apps as medical devices, without any further explanation about the analysis of the intended use.<br />
The long answer relies on guidances published by the FDA or the European Commission. These guidances give many clues about the interpretation of regulations to qualify mobile apps as medical devices or not.</p>
<h5>FDA Guidances</h5>
<p>The FDA published in september 2013 a <a href="http://www.fda.gov/downloads/MedicalDevices/.../UCM263366.pdf">Guidance on Mobile Medical Applications</a>.<br />
This guidance clarifies a lot the qualification of mobile apps as medical devices in the USA. It gives the criteria to determine wether an app is a medical device.<br />
The intent of the FDA is to define the <em>Subset of mobile apps that are the focus of FDA’s regulatory oversight</em>. Others apps outside the subset are not regulated.<br />
<br />
However, the subset is not so easy to define, hence the FDA expects that some apps <em>may</em> be medical devices.<br />
If you think your app falls into the blurred zone, you'd better contact the FDA to know what they expect of your company!</p>
<h5>European MEDDEV</h5>
<p>In the European Union, there is no such guidance as the FDA one. The guidance that is the closest to our need is the <a href="http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf">MEDDEV 2.1/6 - Guidance on the qualification and classification of standalone software</a>.<br />
It embraces a larger spectrum than the FDA guidance: standalone software. Mobile medical apps are standalone software, but standalone software include other software installed on fixed (contrary to mobile) platforms, like servers.<br />
<br />
Unlike the FDA guidance, the MEDDEV doesn't contain specific criteria for mobile apps. It contains a decision tree which is supposed to help you to determine wether a standalone software (including your mobile apps) is a medical device.<br />
<br />
However, you'll see that if you follow the decision tree, you will bump into the question: Is <em>the software to be used for any of the purposes listed in Article 1(2)a of Directive 93/42/EEC</em>. (Translation: does it fall into the definition of a medical device in the european regulation).<br />
<br />
It's actually the answer to this question that we are seeking in a guidance. We're going in a circle!<br />
Fortunately, there are a lot of thoughtful examples in the guidance, which help to exclude a good many of software from medical devices.<br />
<br />
If your mobile app doesn't fit the examples of this guidance, you'd better contact your notified body (if you have one), or even the regulation authority of your country (or of your european representative) to know what they expect of your company.</p>
<h4>To go further</h4>
<p>Regulations of mobile medical apps in other countries like Canada, Brazil, Japan, or Australia are not as articulate as the american and (to some extent) the european regulations.<br />
As usual, the FDA sets the tone about the regulation of medical devices but <strong>the US regulation is more stringent that regulations in other countries</strong>.<br />
<br />
Thus, don't rely on the FDA guidance to qualify your mobile app as a medical device in other countries. Use the regulations and guidances of each country.<br />
<br />
Next time, we'll see <a href="https://blog.cm-dm.com/post/2013/12/03/How-to-develop-a-smartphone-App-to-be-FDA-cleared-or-CE-Marked-part-2-IEC-62304-and-agile-methods">the development standard applied to mobile medical devices</a>.</p>https://blog.cm-dm.com/post/2013/11/08/How-to-develop-a-smartphone-App-to-be-FDA-cleared-or-CE-Marked-part-1#comment-formhttps://blog.cm-dm.com/feed/atom/comments/105EU Guidances - What's new?urn:md5:d37238c8e045fac05a313f9cf86167532013-03-22T11:59:00+01:002013-03-24T00:22:26+01:00MitchRegulationsCE MarkGuidance<p>A few words about guidances in Europe. News are rare enough to point them out.<br />
First, the guidance on electronic labelling came into force on 1st march 2013, see <a href="http://www.mhra.gov.uk/Howweregulate/Devices/Devicesregulatorynews/CON222581">the MHRA website</a> for some explanations and the original decision <a href="http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:072:0028:031:EN:PDF">on the EU website</a>.</p> <p>Second, the guidance on vigilance and field safety notifications. The <a href="http://ec.europa.eu/health/medical-devices/files/meddev/2_12_1_ol_en.pdf">last version of this guidance aka MEDDEV 2.12-1</a> was released by the EU. It will come into force in july 2013.<br />
This the revision 8 of this guidance. Height revisions! It proves that the vigilance management is a concern of EU authorities and that the system is obviously perfectible.<br />
<br />
The change visible is in the title of section 3.1.2 in the document. <em>For manufacturers of IVD</em>, was replaced by <em>For manufacturers of devices that are not intended to act directly on the individual</em>.<br />
The guidance adds two new types of products in its sight: in vitro fertilisation (IVF) and assisted reproduction technology (ART). It also namely adds <em>software qualified as medical devices</em> in its sight. Hence standalone software can be the cause of indirect harm to patients.<br />
By extension, software that are accessories to IVD, IVF, and ART, also are in the sight of this guidance.<br />
<br />
Section 4.6 of the document defines what a field safety corrective action (FSCA) is. It's interesting to notice that the notes under the definition add a few informations about software. These informations were not present in the last version of the guidance. A proof that software becomes a truly visible cause of incidents.</p>https://blog.cm-dm.com/post/2013/03/22/EU-Guidances-What-s-new#comment-formhttps://blog.cm-dm.com/feed/atom/comments/90