Designing for Mechanical and Signal Integrity in Handheld Medical Treatment Applications
New Device Helps Diagnose and Treat Neurodegenerative Diseases
ADHESIVES: The Importance of CTE for Assembly Reliability
Hydrogel Material Improves Success of Transplanting Islet Cells
Skin-worn Wearable Devices: Tomorrow’s Vision, Today’s Realities
New 3D Printing Method Promises New Era for Medical Implants
New Method Manufactures Heart Valves in Minutes
Lasers: The Perfect Tool for Industry 4.0
Sonic Cyber Attack Shows Security Holes in Ubiquitous Sensors

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»