Software in Medical Devices, by MD101 Consulting - Tag - PACSBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-18T07:25:39+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearConsequences of the 21st Century Cures Act - State of Playurn:md5:33e1334f4fbc66f2d39bae728d52b0532018-01-12T15:00:00+01:002018-01-14T14:29:24+01:00MitchRegulationsClassificationFDAGuidancemHealthmobile medical appPACS<p>Since the <a href="https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types">last blog post</a> on US FDA guidance on software classification, things evolved quickly with the FDA. We know where they want to go with software as medical device, but not exactly how they will implement it.<br />
Let's do a review of what has been done since the publication of the 21st Century Cures Act.</p> <h4>21st Century Cures Act in December 2016</h4>
<p>To begin, we've had the <a href="https://www.congress.gov/bill/114th-congress/house-bill/34/text#toc-H73E766CC72AC4EB8AAF36670EB540164">21st Century Cures Act</a>, with Section 3060 "Clarifying medical software regulation". This is the top-level document as it is regulation voted by the Congress in December 2016.<br />
This Act was published after guidances on <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">general wellness, mobile medical apps, and PACS and MDDS</a> had been published in 2016. They are in final status, but when you download these guidances, the first page contains now an additional cover page stating that these guidances have to be revised.<br /></p>
<h4>Guidance on Section 3060 of the 21st Century Cures Act</h4>
<p>To do so, the FDA published in December 2017 a draft guidance titled <a href="https://www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/documents/document/ucm587820.pdf">"Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act"</a>. This is a guidance on how other guidances will be revised (you follow me?). We call it <em>Section 3060 guidance</em> in this article.<br />
This guidance is organized by software functions, rather than types of platforms. This is to stress that software shall be qualified as medical device, based on its functions, not the platform. For example, the same function present in an mobile app or a web site will have the same regulatory status.<br />
<br />
The Section 3060 guidance is good news, many software functions are removed or are confirmed to be outside the scope of medical device definition. The functions below are NOT medical devices:</p>
<ul>
<li>Laboratory Information Management Software (LIMS),</li>
<li>Electronic Patient Records (EHR) management systems,</li>
<li>Patient Health Records (PHR) management systems,</li>
<li>Medical Image Storage systems, such as Radiological Information System (RIS),</li>
<li>Medical Image Communication systems, and</li>
<li>Medical Device Data Systems (MDDS),</li>
</ul>
<p>Provided that they don't offer functions in the scope of medical device definition, such as aid to diagnosis.<br />
<br />
Note also that there is a footnote on Medical Image Communication devices in the guidance. Some devices will continue to be regulated as medical devices.<br />
<br />
The Section 3060 guidance is also good news for software generating notifications and flags when a value is outside a range, like telemedicine or remote surveillance applications. Provided that these notifications don't require immediate clinical action, the FDA doesn't intend to enforce regulations.<br />
Usually, when immediate clinical action is required, such software functions are named alarms and active patient monitoring.<br />
<br />
The Section 3060 guidance is finally good news for a subset of wellness devices in the grey zone: those with functions for the management of a healthy lifestyle, while addressing chronic diseases or conditions. The FDA doesn't intend to enforce regulation on such devices either.<br />
<br /></p>
<h4>Comparison with European guidance</h4>
<p>The Section 3060 guidance contains a section on software functions for <em>transferring, storing, converting formats, displaying data and results</em>. The wording used to name these functions is close to the one used in the European guidance <a href="http://ec.europa.eu/DocsRoom/documents/17921/attachments/1/translations">MEDDEV 2.1/6 of July 2016</a>.<br />
<br />
The MEDDEV uses the terms <em>storage, archival, communication, simple search or lossless compression</em>. This is equivalent to <em>transferring, storing, converting formats</em> in the FDA guidance. The FDA uses <em>converting formats</em>, which has a broader meaning that <em>lossless compression</em> in MEDDEV guidance. This can be interpreted as: the medical device definition in European regulations exclude medical data conversion unless information is lost during conversion. <br />
For the wording <em>displaying data and results</em> present in the Section 3060 guidance, there is the same approach in the Meddev guidance: as long as software is not used for diagnosis or treatment, such as functions displaying data to a technician, to verify that data are present, it is not a medical device.<br />
<br />
Thus, we have a kind of convergence between the FDA guidance and the European guidance on qualification of software as medical device.<br />
<br /></p>
<h4>Work in progress</h4>
<p>This guidance is still work in progress. First, it is a draft guidance. Second, the guidance refers to other guidances work in progress:</p>
<ul>
<li>The draft guidance on Clinical Decision Support Software (will be the subject of a future blog post),</li>
<li>A future guidance on multi-functionality software combining medical device and non-medical device functions (<a href="https://blog.cm-dm.com/post/2012/02/06/MEDDEV-2.1/6-Guidelines-on-classification-of-standalone-software-released%21">there's an old post</a> on this subject),</li>
<li>A future guidance on Medical Image Communication systems.</li>
</ul>
<p><br />
<br />
<br />
The section 3060 guidance is really good news for many software editors in the field of medical data management on the one hand, and wellness or healthy lifestyle on the other hand. Even if it is a draft guidance, things shouldn't radically change in the final version. The 21st Century Cures Act doesn't give much space to interpretation.</p>https://blog.cm-dm.com/post/2018/01/12/Consequences-of-the-21st-Century-Cures-Act-State-of-Play#comment-formhttps://blog.cm-dm.com/feed/atom/comments/211When the FDA releases guidances in burst modeurn:md5:6cb9deb5e308f637aa7f08f512b333dc2015-03-20T17:03:00+01:002015-03-20T17:59:26+01:00MitchRegulationsFDAGuidancemobile medical appPACS<p>If you watch from time to time the new guidances released by the FDA, you probably noticed that two guidances about software were released in january and february 2015.</p> <p>We have the :</p>
<ul>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM401996">Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices</a> guidance released in February,</li>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM429674">General Wellness: Policy for Low Risk Devices</a> Draft Guidance released in January,</li>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM429672">Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Types</a> Draft Guidance released in January.</li>
</ul>
<p>Add to these very recent guidances, the :</p>
<ul>
<li><a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366">Mobile Medical Applications</a> guidance released in september.</li>
</ul>
<p>That's a lot of stuff to read. I'll try to sum up all of these.</p>
<h4>About MDDS and PACS</h4>
<p>The first guidance <em>Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices</em>, is actually about PACS servers and Health IT systems, without modules performing data processing for diagnostic or treatment purposes.<br />
<strong>The guidance simply says that PACS servers and MDDS are actually medical devices, but the FDA doesn't intend to regulate them</strong>.<br />
This produced a lot of fuss in the medical devices galaxy. But this isn't a scam or a joke. If you want to confirm by yourself that this is true,</p>
<ul>
<li>First, have a look at the recent FDA webinar <a href="http://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm433146.htm">Overview of Medical Device Data Systems, General Wellness Devices, and Medical Device Accessories - February 24, 2015</a>, the question is raised by many attendants and the FDA speaker's answer is clear of this subject,</li>
<li>Second, if you have a doubt, contact the FDA to confirm that your software falls in the scope of this guidance,</li>
<li>Third, enjoy.</li>
</ul>
<p>Anyway, if your system falls in the guidance scope today, this may not be the case tomorrow. If you plan to add advanced modules processing data for clinical purposes, you should anticipate this evolution:</p>
<ul>
<li>Either by insulating advanced modules and concealing the rest of the system in SOUP,</li>
<li>Or, to be safe, by applying the IEC 62304 requirements to have the required documentation when your system is back to the medical device regulated zone.</li>
</ul>
<h4>About Mobile Apps</h4>
<p>The two following guidances are about mobile apps:</p>
<ul>
<li>The Mobile Medical Applications guidance,</li>
<li>The General Wellness draft guidance.</li>
</ul>
<p>The slides of the FDA Webinar contain a simple diagram, which explains at a glance the status of mobile apps.
<img src="https://blog.cm-dm.com/public/.FDA_mobile_apps_categories_m.png" alt="FDA_mobile_apps_categories.png" style="display:block; margin:0 auto;" title="FDA_mobile_apps_categories.png, Mar 2015" />
The triangle symbolizes the volumes of apps available on mobile apps stores: thousands at the bottom, a dozen at the top.<br />
<br />
The triangle is split in three zones:</p>
<ul>
<li>Top: medical devices with no doubt on the intended use,</li>
<li>Bottom: general wellness devices with no doubt on the non-medical intended use,</li>
<li>Middle: the gray area where the intended use or the level of risks of the apps shall (yes, shall) be assessed with the FDA.</li>
</ul>
<p>Thus, if you have doubts about the medical device status of your mobile app, contact the FDA. They will decide whether your device is regulated or not, based on its intended use and risks identified in the use of your device. This is what they call <em>law enforcement discretion</em>.</p>
<h4>About accessories</h4>
<p>The last guidance we haven't commented yet is the Medical Device Accessories draft guidance.<br />
While this guidance is not focussed on software, it has consequences on software. Many mobile apps are used to remotely access a medical device or medical data. Thus, they could be qualified as accessories.<br />
<br />
The guidance gives the definition of an accessory. If your app is an accessory, it is likely to be at the top of the triangle. Based on risk assessment, this accessory may come closer to the tip of the triangle or get closer to the grey zone.<br />
<br />
For innovative mobile medical apps without predicates, the FDA <em>encourages manufacturers and other parties (...) to utilize the de novo classification process</em>. With this guidance, the FDA leaves the door open for a clearance process less painful than a PMA (financially wise).<br />
With the blossom of mobile medical apps, it's probable that some manufacturers will be in this case.<br />
<br />
There's no occurence of the word <em>software</em> in the accessories guidance. But it's clear that it is consistent in its intent with the three other ones.</p>
<h4>And then?</h4>
<p>The accessories guidance and the general wellness guidance are still drafts. The FDA will probably publish another one called <em>Draft Guidance on Medical Device Decision Support Software</em>. It is planned in the <a href="http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/MDUFAIII/ucm321367.htm">A-list of guidances for 2015</a>.<br />
This last one will also have some side effects existing software or future software in the plans of manufacturers.<br />
All these draft guidances are in the B-List of final guidances of 2015. Meaning that the FDA's intent is to publish their final version, if FDA resources are available.<br />
<br />
<br />
Medical software landscape is changing fast. So is the FDA's position, expressed in their guidance.</p>https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode#comment-formhttps://blog.cm-dm.com/feed/atom/comments/164Inflation of software medical devices - part 3urn:md5:cee54941ec4781d599d133efa76c7f252012-04-06T11:08:00+02:002012-04-06T10:39:41+02:00MitchMiscCE MarkClassificationFDAmHealthPACS<p>This article is the last of three articles which deal with the concept of
"inflation" of medical devices. <a href="https://blog.cm-dm.com/post/2012/03/09/Inflation-of-software-medical-devices-part-1">The first
one</a> was on inflation of standards, <a href="https://blog.cm-dm.com/post/2012/03/30/Inflation-of-software-medical-devices-part-2">the second</a>
about inflation of regulations. This one, the most interesting to my eyes, is
about multiplication of apps on mobile devices, especially smartphones and
tablets.<br />
More that 6000 apps are classified in the "heath", "heathcare" or "medical"
categories of the Apple or Android appstores. Many of these apps are classified
as medical devices and are in the scope of regulations like FDA and CE Mark.
Note that some apps may be regulated the FDA but not the CE Mark or
vice-versa.</p> <h4>Medical device apps or not medical device apps</h4>
<p>Apps may be categorized in three big sets: encyclopedic apps, health
lifestyle apps and real medical devices apps.<br />
<strong>Encyclopedic apps</strong> are not medical devices, neither for FDA nor
for CE Mark. They often contain data or knowledge that can be found in books.
They are most of time created by book editors which publish their books in
electronic format.<br />
<strong>Health lifestyle apps</strong> are made for people who are not
physicians, for diet, life hygiene or general health condition. These are most
of times not medical devices. The frontier between general health and medical
devices is sometimes thin. They may fall into the regulations whereas it was
not expected by their manufacturers.<br />
<strong>Medical devices</strong> apps are those with an intended use, which is
clearly in the scope of regulations. “Clearly” is not a clear criterion, you
may object. That’s true, there is no clear boundary between general health apps
and medical devices. A few examples of medical devices are better than endless
theoretical explanations:</p>
<ul>
<li>Apps which compute drugs doses or a dose of any pharmaceutical or medical
substance, are medical devices.</li>
<li>Apps which are connected to Heath IT servers and offer a service higher
than simply displaying data are medical devices.</li>
<li>A PDF viewer used to read a medical report sent by mail is not a software
medical device.</li>
<li>A remote DICOM medical imaging viewer is a medical device.</li>
<li>An app which lists the defibrillators around you is not a medical
device.</li>
<li>Apps which give general recommendations, like smoking increase risks of
cardiovascular pathologies, are not a medical devices.</li>
<li>Apps which contain training information, like memos about first aid are not
medical devices.</li>
</ul>
<h4>Smartphones become medical devices</h4>
<p>When an app is used to communicate with a peripheral connected to the mobile
device, the whole is a medical device. For example, <a href="http://www.withings.fr/en/bloodpressuremonitor">Withings</a> sells a blood
pressure monitor, which is connected to a smartphone to measure the blood
pressure of patients. In this case, the whole thing (customized smartphone with
blood pressure monitor and software) becomes a medical device.<br />
Many new accessories were placed on the market the last two years, to analyse
saliva, urine, to measure glycemy ... The possibilities seem to be
endless!<br />
Even worse, a physician uses an app which takes photos of the patient's body
with the embedded camera of his smartphone to evaluate any medical parameter.
In this case, the smartphone (not customized) and the app are a medical device
as a whole.</p>
<h4>Consumer electronics vs medical device</h4>
<p>What an horror, my smartphone is a medical device??? Don’t be afraid. Being
a medical device is a transitory state, your smartphone remains the little
companion you cherish as soon as you stop the medical device app.<br />
More seriously, there is a kind of contradiction between the level of safety
sought in the medical device industry and the non-stopping pace of evolutions
of the consumer electronics industry. It takes a long time to design reliable
stuff. Smartphones don’t last long (that’s a pity IMHO), smartphone apps don’t
either. Developers of smartphone apps may be tempted to ignore <a href="https://blog.cm-dm.com/post/2011/11/18/Software-Medical-Devices.-How-to-obtain-market-homologation">mandatory
software design activities</a>, event for class I devices.<br />
This is why there is inflation of guidances and standards on standalone
software.<br />
<br />
<br />
PS: Thanks to J. Colombain for its <a href="http://www.franceinfo.fr/high-tech/nouveau-monde/smarpthones-le-boom-de-la-m-sante-562409-2012-03-23">
chronicle on France Info about m-santé</a> (sorry, only in French).</p>https://blog.cm-dm.com/post/2012/04/06/Inflation-of-software-medical-devices-part-3#comment-formhttps://blog.cm-dm.com/feed/atom/comments/30New Device Classification Guidance published by GHTF: consequences for medical imaging softwareurn:md5:cee74660fb14b3102746f7864a37884c2011-11-28T17:19:00+01:002011-12-12T11:37:54+01:00MitchRegulationsClassificationGHTFGuidancePACS<p>The GHTF (Global Harmonization Task Force) issued a draft of a new <a href="http://www.ghtf.org/documents/sg1/pd_sg1_n077r04.pdf">guidance on medical
device classification</a> They recommend to implement four classes for medical
devices based on intended use: from class A (lowest risk) to class D (highest
risk). And they give a set of rules on how to choose the classification of the
devices.</p>
<h4>Comparison with regulations</h4>
<p>Wait, I've already seen this elsewhere. Classification of devices in Europe
(CE mark) and in Canada have systems very similar to what GHTF recommends. This
is a good thing to have an ongoing harmonization process. National regulations
copy what GHTF recommends and GHTF copies what national regulations require.
This is a virtuous circle. Maybe one day the FDA will implement this
classification system.</p> <p>Let's dream of an harmonized world! By the way, the FDA has done a huge work
to classify the medical devices. Just have a look at their <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/PCDSimpleSearch.cfm">product
classification database</a> and you will see that there are almost no shadow
zones, compared to the GHTF rules.<br />
The main difference is that FDA has only 3 levels of classification, with very
different paths to certification (premarket notification and premarket
approval), compared to CE mark for example.</p>
<h4>Classification of software</h4>
<p>The document contains a definition of active medical devices, which includes
software. And there is a paragraph in <em>structure of the classification
rules</em> about how dealing with software: standalone, not standalone,
software driving a device and so on. To sum-up:</p>
<ol>
<li>software are active devices,</li>
<li>if they are not standalone, they fall into the category of the device they
influence/drive/monitor/control,</li>
<li>if they are standalone, apply the rules 9 to 12,</li>
<li>the last rule (rule 12) is a fall-trough rule, which gives class A to every
device, which doesn't match other rules.</li>
</ol>
<p>No very different from CE mark or Canadian regulation.</p>
<h4>Which classification for Medical Imaging Software?</h4>
<p>Now let's have a closer look at Medical Imaging Software or PACS (Picture
Archiving Communication System). The GHTF gives samples for every rule. For
rule 12, you find: "powered equipment for the recording,
<strong>processing</strong>, viewing of diagnostic images". So every PACS and
standalone Medical Imaging Software are class A in the GHTF
recommendation.<br />
Not only the viewers are class A but also software processing diagnostic
images. Canada and CE didn't have those examples in their guidances. More, they
issued notices about medical imaging software giving indications seemingly in
contradiction with those of GHTF:</p>
<ul>
<li>The <a href="http://www.hc-sc.gc.ca/dhp-mps/md-im/activit/announce-annonce/md_notice_software_im_avis_logicels-eng.php">
Canadian notice</a> asserts that patient management software with capabilities
<strong>beyond basic data visualization</strong> is considered a Class II
medical device,</li>
<li>The <a href="http://ec.europa.eu/health/medical-devices/files/wg_minutes_member_lists/version1_4_manual072009_en.pdf">
Manual on Borderline Classification in the EEC Regulatory Framework</a> asserts
that PACS which post-process the images without driving or influencing the
source (i.e. CT, MRI, ultrasound) device and is intended to allow direct
diagnosis is class IIa device.</li>
</ul>
<p>I agree with CE and Canada guidances. Software post-processing images for
diagnosis shall be at level II, not level I. So I think that the samples given
by the GHTF should be redefined to match the CE and Canadian rules. The GHTF
rule 10(i) is about active devices for direct diagnosis. Inserting in the
samples the post-processing imaging software to allow diagnosis would be a
solution. This is not a big issue but it would clarify the situations of post
processing tools.<br />
The harmonzation is ongoing but not for tomorrow!</p>https://blog.cm-dm.com/post/2011/11/25/Device-Classification-Guidance-by-GHTF#comment-formhttps://blog.cm-dm.com/feed/atom/comments/51How to classify and CE mark softwareurn:md5:7ba4dbcee6eef9267f0f3311bebf1c2d2011-11-04T14:20:00+01:002020-08-05T22:26:21+02:00MitchRegulationsCE MarkClassificationPACS<p>Medical devices shall have CE mark before being sold in the EU. The process to have CE mark can be summarized this way:</p>
<ol>
<li>Determining the class of the device,</li>
<li>Choosing the CE procedure to apply,</li>
<li>Declaring CE conformity of the device.</li>
</ol>
<p>Software follows exactly the same process as other devices. Here are the steps to follow to CE mark software.</p> <p><br /></p>
<b><font color="red">Warning: this article was written in 2011 and is obsolete!</font></b>
<br/>
<p><strong><a href="https://blog.cm-dm.com/pages/How-to-qualify%2C-classify-and-CE-mark-software">Go to the version updated with the MDR</a>.</strong>
<br /></p>
<h3>Foreword</h3>
<p>I used the references below to create this article:</p>
<ol>
<li>Consolidated 93/42 EEC Directive: <a href="http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31993L0042:EN:HTML" hreflang="en">In html</a> <a href="http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:1993:169:0001:0043:EN:PDF" hreflang="en">In PDF</a></li>
<li>Guidance on medical devices classification: <a href="http://ec.europa.eu/consumers/sectors/medical-devices/files/meddev/2_4_1_rev_9_classification_en.pdf" hreflang="en">MEDDEV 2.4/1 rev.9</a></li>
<li><a href="http://ec.europa.eu/consumers/sectors/medical-devices/files/wg_minutes_member_lists/version1_7_borderline_manual_en.pdf" hreflang="en">Manual on borderline and classification in the community regulatory framework for medical devices</a></li>
<li><a href="http://www.team-nb.org/Documents/R2_2-4_rev5.pdf" hreflang="en">Recommendation NB-MED/2.2/Rec4 Revision 5, Software and Medical Devices</a></li>
<li><a href="http://ec.europa.eu/enterprise/policies/european-standards/documents/harmonised-standards-legislation/list-references/medical-devices/index_en.htm" hreflang="en">Summary list of titles and references harmonised standards under Directive 93/42/EEC for Medical devices</a></li>
</ol>
<p>They're very useful, without them, I wouldn't have been able to write this. I reference them many times in this article.</p>
<h3>Determining the class of software</h3>
<p>Each medical device shall be classified in one class: class I, class IIa, class IIb or class III. It depends on the level of risk generated by the use of the device. Looking at the EEC directive ref.1 , it is very simple to classify software:</p>
<ul>
<li>Standalone software: Annex IX, §I.1.4 states that all standalone software are classified as active devices. Therefore, rules 9 to 12 of annex IX §III.3 apply to your software.</li>
<li>Software, which drives or influences a medical device: Annex IX, §II.2.3 states that such software falls into the same class as the device.</li>
</ul>
<p>The terms “drives or influence” may be interpreted. Here are some examples:</p>
<ul>
<li>Software with functions modifying the state of the device actually drives it,</li>
<li>Software, which only displays data collected from the device, may not be at first sight seen as “driving” the device. But if the user uses data provided by the software to modify the state of the device, then the software “influences” the device.</li>
<li>Software, which only stores data for archiving purpose doesn’t influence the medical device and may be classified alone, with rules 9 to 12 of annex IX §III.3 .</li>
</ul>
<h4>Rule 9 to 12 of EC directive</h4>
<p>Let’s focus now on these rules 9 to 12. A guidance ref.2 was written by the EC to apply all rules the right way. It is very well constructed, with schema giving decision trees to follow and explanation text about each rule.</p>
<p>Another recommendation document ref. 4 written by Notified Bodies gives good examples in §3.1 about how to classify software.</p>
<p>The table below gives my interpretation of each rule for software, based on what I read in ref. 2 and ref. 4.</p>
<table border="1" style="border-width: 2px; border-color: #CCCCCC; border-style: solid; margin-left: auto; margin-right: auto" rules="all" frame="void">
<tbody>
<tr valign="middle" style="background-color: #98b311;">
<td valign="middle"><span style="color: #000000;">Rule#</span></td>
<td valign="middle"><span style="color: #000000;">Text</span></td>
<td valign="middle"><p><span style="color: #000000;">Software</span></p></td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>9</td>
<td>All active therapeutic devices intended to administer or exchange energy</td>
<td>This rule and its sub rules apply to software connected or integrated into such device or software, which influences or drives the device.
Standalone software doesn’t administer or exchange energy and doesn’t fall into that category, unless it influences or drives such device.</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>10</td>
<td>Active device for diagnosis</td>
<td>This rule and its sub rules may apply to software connected or integrated into such device or software, which influences or drives the device.
Standalone software may fall into that category (see paragraph about PACS below).</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>11</td>
<td>Active devices to administer or remove medicine</td>
<td>This rule and its sub rules apply to software connected or integrated into such device or software, which influences or drives the device.
Standalone software doesn’t administer or remove medicine and doesn’t fall into that category, unless it influences or drives such device.</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>12</td>
<td>All other active devices</td>
<td>This rule is a “fall through” rule, when other rules do not apply, even interpreted extensively.</td>
</tr>
</tbody>
</table>
<p>Some examples:</p>
<p><ins>Rule 9:</ins></p>
<ul>
<li>Software embarked in a muscle stimulator, an incubator, a laser …</li>
<li>Software connected through network (wired or wireless) to a therapeutic device. Eg: remotely monitored physiotherapy equipments,</li>
<li>Software allowing the user to drive or influence such device by any mean or any media</li>
</ul>
<p><ins>Rule 10:</ins></p>
<ul>
<li>Software embarked in any scanner (ultrasound, X-Ray, MRI), an electronic thermometer …</li>
<li>Software connected through network (wired or wireless) to a diagnosis device. Eg: Picture Archiving and Communication System (PACS),</li>
<li>Software allowing the user to drive or influence such device by any mean or any media</li>
</ul>
<p><ins>Rule 11:</ins></p>
<ul>
<li>Software embarked in a dialysis equipment</li>
<li>Software connected through network (wired or wireless) to a device delivering or administering medicine</li>
<li>Software allowing the user to drive or influence such device by any mean or any media</li>
</ul>
<p><ins>Rule 12: Anything else</ins></p>
<ul>
<li>Software embarked in an hospital bed</li>
<li>Software used to monitor or control a class I device</li>
<li>All other standalone software. <ins>Use this rule with economy</ins>, when every other rule has been rejected after extensive interpretation. It may be attractive to have software on smartphones or tablets fall in rule 12. This is often not the case.</li>
</ul>
<h4>Special considerations for Picture Archiving and Communication Systems:</h4>
<p>Classification rules cannot cover every case. The working group on “borderline and classification” was created to give recommendations on such cases.
It edited a manual (ref. 3) on devices, for which there is a difficulty to apply rules of the EC directive. A chapter deals with Picture Archiving and Communication System (PACS). PACS shall be class IIb, IIa or class I, depending on their purpose. Here are some examples. If the PACS:</p>
<ul>
<li>Stores images and doesn’t modifies them, then it is class I,</li>
<li>Is used to monitor and control the scanner, then it has the class of the device,</li>
<li>Is a post-processing tool used to interpret raw images, then it is class IIa.</li>
</ul>
<p>Relying on my own experience, I find their recommendations very useful to classify PACS.</p>
<h3>Choosing the CE procedure to apply</h3>
<p>The EC directive defines several procedures to obtain CE mark on a device. They are described in annexes II of VIII of the directive.
The principle of these procedures is to produce a technical file containing data about the medical devices. Each procedure applies to a given step in the lifecycle of a device (design, production, quality tests …) and requires different data. Given the classification of your software, you can choose the CE procedure to apply.</p>
<table border="1" style="border-width: 2px; border-color: #CCCCCC; border-style: solid; margin-left: auto; margin-right: auto" rules="all" frame="void">
<tbody>
<tr valign="middle" style="background-color: #98b311;">
<td valign="middle"><span style="color: #000000;">Annex</span></td>
<td valign="middle"><span style="color: #000000;">Procedure</span></td>
<td valign="middle"><p><span style="color: #000000;">Explanation</span></p></td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>II</td>
<td>EC DECLARATION OF CONFORMITY
(Full quality assurance system)</td>
<td>The most “powerful” and the longest procedure.
All the relevant processes of the company are certified compliant with ISO 13485 standard.
EC is issued by a notified body</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>III</td>
<td>EC TYPE-EXAMINATION</td>
<td>Verification of technical data about the design of a device. EC Type is issued by a notified body</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>IV</td>
<td>EC VERIFICATION</td>
<td>Verification of each device or batches of devices produced by the manufacturer. EC is issued by a notified body</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>V</td>
<td>EC DECLARATION OF CONFORMITY
(Production quality assurance)</td>
<td>Verification of the quality system of the manufacturer for production, final inspection and testing. EC is issued by a notified body.</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>VI</td>
<td>EC DECLARATION OF CONFORMITY
(Product quality assurance)</td>
<td>Verification of the quality system of the manufacturer for final inspection and testing. EC is issued by a notified body.</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>VII</td>
<td>EC DECLARATION OF CONFORMITY</td>
<td>Verification of technical data about the design of a device, specific for class IIa or class I. EC is issued by the manufacturer.</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>VIII</td>
<td>DEVICES FOR SPECIAL PURPOSES</td>
<td>Verification of technical data about the design of a device, specific for custom-made devices or for devices intended for clinical investigations. </td>
</tr>
</tbody>
</table>
<h4>Valid combinations of procedures</h4>
<p>These procedures shall be combined to obtain the precious CE mark. Given the classification of the device, here are the possible combinations:</p>
<table border="1" style="border-width: 2px; border-color: #CCCCCC; border-style: solid; margin-left: auto; margin-right: auto" rules="all" frame="void">
<tbody>
<tr valign="middle" style="background-color: #98b311;">
<td valign="middle"><span style="color: #000000;">Class</span></td>
<td valign="middle"><span style="color: #000000;">Procedure</span></td>
<td valign="middle"><p><span style="color: #000000;">Combined with</span></p></td>
</tr>
<tr style="background-color: #E0E0E0;">
<td rowspan="2" style="white-space : nowrap">Class III</td>
<td>Annex II, <br/>Full quality management System</td>
<td>None</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>Annex III, <br/>Final design review, with:</td>
<td><p>Annex IV, Unit or sample Review, Or</p><p>Annex V, Production quality procedures</p></td>
</tr>
<tr style="background-color: #F0F0F0;">
<td rowspan="2" style="white-space : nowrap">Class IIb</td>
<td>Annex II (w/o 4), <br/>Full quality management System, <br/>excepted design procedure</td>
<td>None</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>Annex III, <br/>Final design review, with:</td>
<td><p>Annex IV, Unit or sample Review, Or</p><p>Annex V, Production quality procedures, Or</p><p>Annex VI, Final test quality procedures</p></td>
</tr>
<tr style="background-color: #E0E0E0;">
<td rowspan="2" style="white-space : nowrap">Class IIa</td>
<td>Annex II (w/o 4), <br/>Full quality management System, <br/>excepted design procedure</td>
<td>None</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>Annex VII, <br/>Final design review, with:</td>
<td><p>Annex IV, Unit or sample Review, Or</p><p>Annex V, Production quality procedures, Or</p><p>Annex VI, Final test quality procedures</p></td>
</tr>
<tr style="background-color: #F0F0F0;">
<td style="white-space : nowrap">Class I</td>
<td>Annex VII, <br/>Final design review <br/>(less comprehensive than other classes)</td>
<td>None</td>
</tr>
</tbody>
</table>
<p>Annex VIII doesn’t appear in the table. Hence it is a kind of “partial” procedure for devices, mainly before clinical investigations. It has no impact on the procedure to choose for final EC mark in the table above.</p>
<h4>Procedures applicable to software</h4>
<p>Not all of these procedures are applicable to software design. In §3.2 of their document (ref. 4), the notified bodies give recommendations about applying procedures to software.
Software is very specific: initial design, bug fixes and enhancements are the main tasks to release software to a customer. The production step is very reduced, compared to other industries.
Based on this consideration:
<ins>Procedures linked to design are required and/or amplified:</ins></p>
<ul>
<li>Annex II, Full quality management system shall have design control procedures,</li>
<li>Annex III, EC Type examination is amplified with design control procedures highly recommended</li>
<li>Annex VII, design review examination is amplified with design control procedures highly recommended</li>
</ul>
<p><ins>And some procedures are excluded:</ins></p>
<ul>
<li>Annex IV, Unit or sample Review is not applicable</li>
<li>Annex VI, Final product Review is not applicable</li>
</ul>
<p>Based on these recommendations, I modified the table to select procedures applicable to software.</p>
<table border="1" style="border-width: 2px; border-color: #CCCCCC; border-style: solid; margin-left: auto; margin-right: auto" rules="all" frame="void">
<tbody>
<tr valign="middle" style="background-color: #98b311;">
<td valign="middle"><span style="color: #000000;">Class</span></td>
<td valign="middle"><span style="color: #000000;">Procedure</span></td>
<td valign="middle"><p><span style="color: #000000;">Combined with</span></p></td>
<td valign="middle"><p><span style="color: #000000;">Applicable to software?</span></p></td>
</tr>
<tr style="background-color: #E0E0E0;">
<td rowspan="2" style="white-space : nowrap">Class III</td>
<td>Annex II</td>
<td>None</td>
<td style="white-space : nowrap">YES, with design procedure</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>Annex III</td>
<td>Annex IV <br/>Annex V</td>
<td style="white-space : nowrap">NO<br/>YES, with design procedure</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td rowspan="2" style="white-space : nowrap">Class IIb</td>
<td>Annex II (w/o 4)</td>
<td>None</td>
<td style="white-space : nowrap">YES, with design procedure</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>Annex III</td>
<td>Annex IV <br/>Annex V <br/>Annex VI</td>
<td style="white-space : nowrap">NO<br/>YES, with design procedure<br/>NO</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td rowspan="2" style="white-space : nowrap">Class IIa</td>
<td>Annex II (w/o 4)</td>
<td>None</td>
<td style="white-space : nowrap">YES, with design procedure</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>Annex VII</td>
<td>Annex IV <br/>Annex V <br/>Annex VI</td>
<td style="white-space : nowrap">NO<br/>YES, with design procedure<br/>NO</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td style="white-space : nowrap">Class I</td>
<td>Annex VII</td>
<td>None</td>
<td style="white-space : nowrap">YES, with design procedure</td>
</tr>
</tbody>
</table>
<h4>Procedures with design control and application of standards</h4>
<p>I already talked a lot in other articles about standards relevant for software development: IEC 62304, IEC 62366 and IEC60601-1</p>
<p>The EC has its own view of standards. It has selected a set of standards, which are recommended to prove conformity of products to EC requirements: the Harmonized Standards. Manufacturer shall implement them on a voluntary basis. The list of Harmonized Standards is published in the Official Journal of European Commission and can be found at ref. 5.</p>
<p>For software, we find in this list IEC 62304, IEC 62366 and section 14 of IEC 60601-1. All three standards require manufacturers to have a design control procedure for software. Based in this information, and being voluntary (!), we can simplify the table this way, <strong>keeping in mind that design control procedure is mandatory</strong>:</p>
<table border="1" style="border-width: 2px; border-color: #CCCCCC; border-style: solid; margin-left: auto; margin-right: auto" rules="all" frame="void">
<tbody>
<tr valign="middle" style="background-color: #98b311;">
<td valign="middle"><span style="color: #000000;">Class</span></td>
<td valign="middle"><span style="color: #000000;">Procedure</span></td>
<td valign="middle"><p><span style="color: #000000;">Combined with</span></p></td>
</tr>
<tr style="background-color: #E0E0E0;">
<td rowspan="2" style="white-space : nowrap">Class III software</td>
<td>Annex II</td>
<td>None</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>Annex III</td>
<td>Annex V</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td rowspan="2" style="white-space : nowrap">Class IIb software</td>
<td>Annex II</td>
<td>None</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td>Annex III</td>
<td>Annex V</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td rowspan="2" style="white-space : nowrap">Class IIa software</td>
<td>Annex II</td>
<td>None</td>
</tr>
<tr style="background-color: #E0E0E0;">
<td>Annex VII</td>
<td>Annex V</td>
</tr>
<tr style="background-color: #F0F0F0;">
<td style="white-space : nowrap">Class I software</td>
<td>Annex VII</td>
<td>None</td>
</tr>
</tbody>
</table>
<p>Only the level of scrutiny of design will change, given the class of software. IEC 62304 is pretty clear about that. Only a part of the standard is mandatory for software with a low level of risk, , whereas the full standard is mandatory for software with a high level of risks.</p>
<p>The main difference between Annex II and other annexes is linked to the organization of the manufacturer:</p>
<ul>
<li>Annex II is applied to the whole company, for every product (excepted derogations with justification). In most of cases the company is ISO 13485 certified and has an activity in medical devices only,</li>
<li>Annex III, VII and V can be applied to a subset of products delivered by the company. It may be ISO 9000 certified for all its products. A small subset of products is composed medical devices, for which the company applies the relevant annexes of the EC directive.</li>
</ul>
<p>Of course, every case may be found in the nature, like a company manufacturing only medical devices and applying other annexes than annex II. But I personally haven’t found the case yet.</p>
<h4>A word on procedures after design</h4>
<p>Design control procedure is of high importance. But other tasks shall not be neglected.</p>
<p>Annex V is all about production. For software, production is made of installation, configuration, testing:</p>
<ul>
<li>Installation: flashing the software on a micro controller, installation on a server, on clients, etc…</li>
<li>Configuration: defining the good configuration files for the customer, using administrative tools,</li>
<li>Testing: test of the final configuration defined for the customer, test of software integrated in a product item …</li>
</ul>
<p>These steps shall be monitored very carefully. Some may be done by the customer and shall be double-checked. A divergence from nominal behavior is very common with software. It’s mandatory to have procedures to handle these tasks to have software work properly.</p>
<p>Bug fixes and enhancements: A full quality system according to annex II shall have procedures to manage bugs and enhancements. So do procedures according annex III, V and VII.
Collecting bug and enhancements is a mandatory task, based on the interpretation of the EC directive in annex V, §3.1 or VII §4.</p>
<p>The IEC 62304 standard gives a comprehensive list of procedures to implement in order to have software developed and maintained according the state of the art.
I warmly recommend you to implement this standard. This is the best thing to do prior to any EC conformity procedure.</p>
<h3>Declaring CE conformity of the device</h3>
<p>There is no specific issue about software, when declaring CE conformity of a device. Many things may happen between software release for use and CE conformity, especially clinical tests. During these tests, software may be modified and some bugs should certainly be fixed.</p>
<p>When clinical tests are complete and successful, a final validation review is scheduled. The device manufacturer’s team assesses the technical file of the device: conception, verification, risk assessment, and clinical tests.
The content of the software design documentation is screened during this meeting. The specification, architecture and tests documents shall have been verified during a previous meeting, before clinical tests. The validation meeting shall focus on risk management, bugs fixes, version control and mandatory content in the software user manual.</p>
<p>When everything is ok (i.e. the manufacturer estimates that device is ready for placing it on the market), usually after the final validation review, the CE conformity is ready to be issued.</p>
<p>Depending on the class of the device, a notified body or the manufacturer declares the conformity:</p>
<ul>
<li>Class I (sterile or with a measuring function), Class IIa, Class IIb and Class III devices: the notify body declares the conformity,</li>
<li>All other Class I devices : the manufacturer declares the conformity.</li>
</ul>
<p>Of course, the notified body doesn’t declare CE conformity in a snap of a finger. It reviews the whole documentation produced about the device. The process usually takes a couple of months. But if the documentation follows clearly a software design process compliant with the standards quoted above, then the job of the notified body is made easier. It should prevent him from asking troubleshooting questions about software and/or issuing non-conformities.</p>
<p>Write what you do.
Do what you write.
Increase you chances to be CE marked!</p>https://blog.cm-dm.com/post/2011/11/04/How-to-classify-and-CE-mark-software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/6