Guide to FDA Requirements and Importance of Medical Device Calibration
Engineers Design Color- Changing Compression Bandage
Improved 3D Printing for Patient-Specific Medical Diagnosis
Data, Data Everywhere: Why the Medical Device Industry Must Embrace the Fourth Industrial Revolution
Implantable Islet Cells Come with Their Own Oxygen Supply
Evaluating Electronics Contract Manufacturers for Medical Devices
Two-Component Molding Can Solve Medical Design Challenges and Reduce Costs
Therapeutic Gel Shows Promise Against Cancerous Tumors
Scientists Develop Elastic Metal Rods to Treat Scoliosis
Key Factors for Choosing Silicone Solutions in Medical Device Lubrication
Features

Fig. 3 – The choice of operating system has a lot of ramifications on IEC 62304 compliance.
IEC 62304 requires that all dead code, or code not directly related to the functionality of the medical device, be removed. For an open source OS, this requires extensive examination of the source code and implementation. Even if the dead code can be extracted without disrupting the confidence from use derived from years of active service of this software, IEC 62304 also requires the device manufacturer to maintain the code for as long at the device is in service—meaning that the development team needs to monitor and examine all patches to the open source project to determine if the patches are relevant to the medical device. And, if the patches are relevant, the patches must then be ported to the modified source tree, which has all this dead code removed.

IEC 62304 accounts for the inclusion of off-the-shelf components, like the OS. It’s not expected that the device manufacturer also be an OS company.

If the ultimate goal of a medical device manufacturer is to get the device certified, then a COTS OS offers the path of least resistance. But remember, all operating systems are not created equal. To be truly appropriate for being used in medical devices, the OS vendor’s software must have a well-documented quality management system. And at some point, the software must undergo a complete fault-tree analysis. This will be difficult to do on behalf of the vendor because the device manufacturer won’t know the architecture and design of the OS, so knowing if the vendor has performed this fault-tree analysis will be very relevant. Having access to the fault-tree analysis can greatly reduce the work for the device manufacturer, similarly so for the software being accompanied by a safety manual that supports these claims. If the COTS OS is accompanied by a safety manual, the job of building safety case becomes much easier.

Again, the choice of OS is exactly that—a choice. A criterion in this selection, when arriving at a choice, should be how that OS helps or hinders with the compliance of a medical device. An OS that offers complete pre-integrated components like the Wi-Fi and Bluetooth drivers, the Qt graphics packages, clock synchronization libraries and processes, etc., all integrated and version-aligned, will suit timelines better than one lacking these traits. Better timelines mean faster to market, faster to revenue, and reduced risk.

This article was writtten by Chris Ault, Senior Product Manager, QNX Software Systems, Ottawa, Ontario, Canada. For more information, Click Here.

« Start Prev 1 2 Next End»