Software in Medical Devices, by MD101 Consulting - Tag - GHTFBlog 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:9c06172e7cd5ed0f5b192883b657eabbDotclearIMDRF published a proposed document on standalone software definitionsurn:md5:af30655c755b5fd5849510ea54d6e94f2013-07-27T09:58:00+02:002013-07-31T08:44:35+02:00MitchRegulationsGHTFIMDRF<p>At be beginning of june 2013, the International Medical Devices Regulators Forum (IMDRF) published a proposed document on standalone software definitions.<br />
The goal of this document is to harmonize the key definitions related to standalone software.</p> <p>It contains proposed definitions of:</p>
<ul>
<li>Standalone medical device software,</li>
<li>Medical purpose for software,</li>
<li>Software Changes,</li>
<li>Standalone Medical Device Software manufacturer, and</li>
<li>Intended use / intended purpose.</li>
</ul>
<p><br />
The document can be downloaded <a href="http://www.imdrf.org/consultations/cons-sskd.asp">here on IMRDF website</a>.<br />
<br />
There are today strong differences of regulatory approaches towards standalone software. For example, the Medical Devices Data Systems (MDDS) are medical devices <a href="http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/MedicalDeviceDataSystems/ucm251906.htm">according to the FDA</a>, whereas they may not, according to <a href="http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf">the European MEDDEV 2.1/6 Guidance</a>.<br />
<br />
Reading the definition of medical purpose, I understand that, according to lines 158 to 160, MDDS are medical devices. The IMDRF definition of standalone software medical device looks closer to FDA's definition that European definition.<br />
<br />
Definitions are useful to define what is what. But they don't make the rules (who has the right/obligation to do what). These definitions <em>are intended to serve as a foundation for further IMDRF work</em>, says the IMDRF. We can expect other documents to be released in the coming months by the IMDRF about standalone software.</p>https://blog.cm-dm.com/post/2013/07/28/IMDRF-published-a-proposed-document-on-standalone-software-definitions#comment-formhttps://blog.cm-dm.com/feed/atom/comments/116New GHTF essential principles: software validation added!urn:md5:20e48a0240c753b1b797d632d03ce3a52012-11-23T13:06:00+01:002012-11-26T18:10:34+01:00MitchRegulationsGHTFSoftware Validation<p>The Global Harmonization Task Force released an update of their guidance on <a href="http://www.imdrf.org/docs/ghtf/final/sg1/technical-docs/ghtf-sg1-n68-2012-safety-performance-medical-devices-121102.pdf">Essential Principles of Safety and Performance of Medical Devices</a>. It supersedes the last version released in 2005.</p> <p>To continue with the discussion about <a href="https://blog.cm-dm.com/post/2012/11/16/VV%3A-verification-validation%2C-where-s-the-truth">software validation in my three last posts</a>, this is a new proof of the rising concept of software validation.<br /></p>
<h4>New section added about software</h4>
<p>A quick diff on both versions of the guidance shows that there is news about software. They've created a new section about software: <em>Medical devices that incorporate software and standalone medical device software</em>.<br />
This section contains two requirements.</p>
<h5>PEMS left unchanged</h5>
<p>The requirement about Programmable Electronic Medical Systems (PEMS) is left unchanged, except a word about standalone software.</p>
<blockquote><p>Devices incorporating electronic programmable systems, including software, <strong>or standalone software that are devices in themselves,</strong> should be designed to ensure repeatability, reliability and performance according to the intended use. In the event of a single fault condition, appropriate means should be adopted to eliminate or reduce as far as reasonably practicable and appropriate consequent risks.</p>
<p></p></blockquote>
<h5>New requirement about software validation</h5>
<p>They added a new requirement about software validation, that is in many ways similar to the one found in the proposal of new EC directive.</p>
<blockquote><p>For devices which incorporate software or for standalone software that are devices in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, verification and validation.</p>
<p></p></blockquote>
<p><br />
IMHO, It's clear that software validation is becoming a hot subject!</p>https://blog.cm-dm.com/post/2012/11/23/New-GHTF-essential-principles%3A-software-validation-added%21#comment-formhttps://blog.cm-dm.com/feed/atom/comments/72New 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/51