Software in Medical Devices – Update for Q1/Q2 2022

Software in Medical Devices – Update for Q1/Q2 2022

The past year has been exceedingly difficult for all of us, from many distinct aspects. Not much has been happening in releasing new standards and the MDR has finally happened.

This is a continuation of the software updates I have been sending out. Please check out all the references to download and/or to purchase. If you have any questions, please contact us.

Software is everywhere in medical devices and IVDs. The FDA and CE are becoming more pedantic on how they review and relate to software. The number of companies getting into the field is growing and the amount of software being developed for medical is exceptionally large.

The is an emphasis on “digital health” where the FDA is fast-tracking many devices (even though it is only software, it is still a medical device). Just because it is software only, this doesn’t mean that you are free from all the regulations, including a quality management system, risk analysis, etc.

Software Recalls Q1-Q2 /2022

We have been following the recalls and there were a growing number of recalls that are listed where software played a role in the recall. It is interesting to note that software is the leading cause of recalls in the FDA for the past 10 years. This trend does not look like it will change.

The following are additional examples of recalls involving software directly as listed on the FDA website, including Israeli developed software. There may be more but classified not under software. There are a number of class I recalls after patients were severely injured and even died. The descriptions given for the recall are taken from the FDA database. For further details on the recalls, you can check them out on the FDA’s recall database.

• Baxter Healthcare, SIGMA Spectrum Infusion Pump with Master Drug Library, Class I – There is the potential for reduced or non-delivery of medication, in some cases without alerting the user via pump alarm. This may occur as a result of incorrect administration set setup and/or incomplete resolution of upstream occlusion alarms when using Spectrum V8 and Spectrum IQ infusion pumps.
• Vyaire Medical, bellavista 1000 ventilator, Class I – Potential cessation in ventilation can occur under specific conditions.
• Smiths Medical ASD, Medfusion Syringe Pump, Class I – Multiple issues with the potential for interruption of therapy or over-infusion: 1. Primary Audible Alarm (PAA), 2. Unanticipated Depleted Battery Alarms, 3. Time Base Alarm, 4. Intermittent Volume Over Time (IVOT) – Infusion Continues after System Failure, 5. Clearing of Program Volume Delivered (PVD), 6. False Alarm for Rate Below Recommended Minimum for Syringe Size, 7. Incorrect Bolus or Loading Dose Time Display, 8. Domain Name Server (DNS) Port 1001.
• Abiomed, OXY-1 System, Class I – The firm has received complaints of the OXY-1 System Console experiencing a power interruption while in use, which disrupts therapy delivered to a patient on support. Disruption of therapy could lead to prolonged hypoxia.
• Spectranetics Corporation, LAS-100, Class II – The LAS-100 Laser system may detect an inoperable hardware component during power up, which results in an error code and the system not being operable until code is cleared.
• Abbott, TactiCath Sensor Enabled Contact Force Ablation Catheter, Class II – When connected to the EnSite Precision Navigation System, an affected TactiCath Contact Force Ablation Catheter, Sensor Enabled may present the error message: “invalid catheter, or “expired catheter.”
• Ortho-Clinical Diagnostics, VITROS Immunodiagnostic Products Prolactin Reagent Pack, Class II – Falsely high or delayed patient and QC results may occur due to low end imprecision. VITROS Immunodiagnostic Products FSH, LH and Prol Reagents Low End Imprecision. Low-level quality control (QC) and patient samples at the low end of the Measuring (Reportable) Range when using VITROS FSH, LH and Prol Reagent. Calibration failures, driven by imprecision observed with Calibrator Level 1.
• Volcano Corporation, SyncVision Systems, Class II – If FFR measurement(s) are made prior to an iFR/FFR co-registration/pullback in the same procedural session, this could result in incorrect iFR/FFR Co-Registration results to be displayed, that may cause users to mistakenly use incorrect measurements, leading to inappropriate patient treatment. Image acquisition and processing system operator’s manual to be updated to include workflow alternatives.
• Raysearch Laboratories, RayStation 11B, Class II – This notice concerns two issues found related to the display of Linear Energy Transfer (LET) in RayStation 11B including some service packs. First, when using a dose threshold for an evaluation dose, LET display might be misleading. Second, a displayed beam-specific LET distribution can sometimes be out of sync with the selected beam.
• GE Healthcare, SIGNA Excite 3T, Class II – There is potential for the images to be flipped left to right.
• R. Bard, Sensica Urine Output System, Class II – Complaints relating to urine output measurement accuracy.
• RAYSEARCH LABORATORIES, RayStation/RayPlan, Class II – An issue where the combined density in a dose grid voxel partially covered by the External ROI and also partially covered by an ROI of type Bolus, Support or Fixation may be unexpected.The density in the voxel can be both under– and overestimated.
• Ion Beam Applications, ProteusPLUS and ProteusONE, Class II – When resuming from a beam pause, the Proton Therapy System does not verify whether the beam range has not been manually modified during the pause and is still the prescribed one. Therefore, if an operator manually modified the range during a pause, there is a risk that a portion of the treatment beam after the resume is delivered with an error in range.
• Abbott Molecular, Alinity s System, Class II – Software error associated with the immunoassay analyzer wash cycle which is using 1 mL of wash buffer instead of the intended 3 mL of wash buffer to wash the exterior of the probe.
• Ion Beam Applications, Proteus 235, Class II – Proton Therapy System (PTS) software can be started in the clinical environment (clinical user) while some processes are still running in the test environment (tcs user). Initiating the startup of the clinical processes in the environment is not prevented even if some processes of the test environment (tcs) are still running. It may lead to situations where the system is using test processes without notifying the clinical user. If the versions of the processes are different between both environments, this could have an impact on patient treatments.
• Baxter Healthcare, NaviCare Nurse Call/Voalte Nurse Call, Class II – An issue has been identified with Phillips (Emergin) and Longleaf non relay (Connexall, Vocera, Cerner) wireless integrations used with NaviCare/Voalte Nurse Call, software versions 3.9.100 through 3.9.300. Calls placed from a push button call device, such as a push button switch, call cord, or from the push buttons on a room audio station, will be canceled on the nurse call system when the call is answered at the wireless phone, regardless of the call priority.
• Siemens Medical Solutions, Sensis, Class II – Siemens has become aware of three potential software issues with AXIOM Sensis or Sensis/ Sensis Lite systems. This may lead to a hazardous situation for patients if treatment cannot be continued on the system and treatment needs to be continued on an alternate system.
• Bio-Rad Laboratories, VARIANTnbs Sickle Cell Program Reorder Pack, Class II – The problem is with the Bio-Rad VARIANT nbs Sickle Cell Program Resin Update CD-ROM software; Model Number: 250-3020, included in VARIANT nbs Sickle Cell Program Reorder Pack #250-3000. This CD-ROM software included in specific lots of VARIANT nbs Sickle Cell Program Reorder Pack causes all customized settings in the Setup/Test/Data Setup subscreen and Setup/Test/Pattern Setting subscreen to be overwritten with the default settings when the Update Kit procedure is performed. The VARIANTnbs Sickle Cell Program has been validated using the default Resin Update CD¿ROM parameters for the intended use. However, there is a risk that the customer’s custom pattern settings may be different than the default settings, resulting in a different pattern being assigned to some samples that the laboratory has validated. Following the complaints from 4 customers who experienced these issues, the firm initiated this recall.
• Stryker Corporation, 1688 Camera Control Unit (CCU), Class II – A software defect in the camera control unit (CCU) will cause the image on the monitor to flip upside-down into an incorrect orientation. The potential of harms are conversion to open procedure, additional medical intervention, or a revision surgery.
• Medtronic Xomed, NIM Vital Console, Class II – Software anomaly was identified.
• Daavlin Distributing, 1 Series CX phototherapy units equipped with Daavlin’s ClearLink Control System, Class II – Software issue, resuming an interrupted treatment will result in swap of utilized calibration treatment distance 0″ inches to “9. Resulting in over or under dosing.
• Medtronic Neuromodulation, NTERSTIM THERAPY SYSTEM FOR URINARY CONTROL, Class II – There is a software anomaly with the InterStim X Clinician software application with results in the data entered in the Patient Information fields not retained and a ” Data Lost” notification being displayed.
• Siemens Medical Solutions, Artis Icono, Class II – Five potential software issues affecting Artis pheno and Artis icono systems in combination with a Siemens Healthineers table or Trumpf/MAQUET table (OEM). The potential software errors are related to the block movement function and manual rotation of the flat detector. Depending on the status of the intervention, the limited functionality may not be sufficient to continue with treatment as planned. This may result in a situation where clinical treatment may be delayed until an additional restart is performed.
• Varian Medical Systems Imaging Laboratory, ARIA Radiation Therapy Management, Class II – Software issue for treatment plan and image management application may result in mismatch values which could result in treatment in the wrong location.
• Siemens Medical Solutions, SOMATOM Definition Edge, Class II – Software version VB20_SP5 my lead to a relevant degradation of head image quality, a potential risk to patients is misdiagnosis.
• GE Healthcare, MUSE Cardiology Information System, Class II – Two scenarios may cause edits to measurements and diagnosis statements can be lost after a test is Signed in the MUSE NX web client.
• Cytocell, Del(5q) Deletion FISH Probe Kit, Class II – Individual components have been labelled with incorrect colors. The red and green colours are opposite to those specified in the product labelling. The EGR1 probe is labelled in green rather than red and the control probe labelled in red rather than green. The expected positive signal pattern in the case of 1x deleted 5q will be 1G2R instead of 1R2G, an incorrect result.
• Shanghai United Imaging Healthcare, Digital Medical X-ray Imaging System, Class II – X-ray imaging system positioning image and protocol label is reversed for Flexion and Extension on C-Spine and L-Spine, this will cause the image to be incorrectly labeled and may cause the patient to have a repeat exposure.
• Siemens Medical Solutions, syngo.via RT Image Suite, Class II – Upgraded software version makes an automatic change in laser configuration settings for “markerless workflow” which may lead to the wrong laser offset coordinates being displayed in the Patient Marking step.
• Haag-Streit, OCT-Camera 211 01 A3, Class II – Malfunction of the automatic laser beam shut-off, the OCT unit might not recognize whether the laser beam is safely switched off.
• Siemens Medical Solutions, syngo Application software, Class II – After CT image data from Toshiba is loaded, image mirroring can occur along the horizontal and vertical image axes. If this error occurs, the patient orientation/position may be misinterpreted and result in inappropriate treatment, even if the incorrect visualization is obvious.
• GE Healthcare, GE Centricity Universal Viewer Zero Footprint, Class II – Potential to display inaccurate measurements on images in Centricity Universal Viewer Zero Footprint Client (ZFP).
• Radiometer Medical, ABL800 Flex Analyzer, Class II – There is a potential for sporadic incidents of positive and negative biases for analyzer systems configured with cNa+, cCa+, and cK+.
• Haemonetics Corporation, TEG5000 Analyzer with TEG Analytical Software, Class II – When the TEG 5000 Analyzer including TEG Analytical Software is used with Platelet Mapping (ADP or AA) Assays and TEG Management Software, incorrect values of the PlateletMapping ADP or AA % Inhibition and % Aggregation may be displayed on TEG Manager for the affected assays.
• Dain Technology, ProudP Everyday Uroflow Tracker, Class II – Due to interference with the Live Listen feature of hearing aid or AirPods, the user’s iPhone may perform automatic processing of the urination sound signal, resulting in lower urination volume and velocity values than expected.
• Canon Medical System, Alphenix 4D CT in combination with CAS-930A, Class II – CT operation may be restricted by an interlock which is a result of a system error and the CT system may stop operating properly after an attempt to cancel the error message has been initiated.
• Medtronic, Crome and Cobalt Models loaded with CareLink SmartSync Device Manager, Class II – Telemetry error that may occur with Medtronic Cobalt and Crome implantable cardioverter defibrillators (ICDs) and cardiac resynchronization therapy defibrillators (CRT-Ds).
• Tandem Diabetes Care, t:slim X2 Insulin Pump with Dexcom G5 Mobile CGM, Class II – Insulin pumps may display unexpected fluctuation of the remaining battery life so ensure pump battery life does not fall below 25% remaining power. If the battery life drops to less than 5%, insulin delivery will continue for 30 minutes and then the pump will power off and insulin delivery will stop. If the battery reaches 1%, then insulin delivery will stop, which could lead to hyperglycemia.
• GE Healthcare, Centricity Universal Viewer Zero Footprint Client, Class II – Potential for Distance and Area measurements to display inaccurate measurement values when performed on magnified images, and specific to ZFP, Distance and Area measurements can display inaccurate measurement values when performed on lossy images that are scaled down from their original resolution.
• Dynex Technologies, DYNEX Agility, Class II – Control samples aspirated from wrong SmartKit on the Agility. Agility software was updated to v1.4.7 to resolve the issue. This leads to a risk that a control from another assay’s SmartKit will be used instead of the correct control, which may lead to delayed patient results.
• Baxter Healthcare Corporation, Voalte Nurse Call, Class II – Firm discovered a firmware memory leak with a supplier-manufactured component.
• bioMerieux, VITEK 2 Systems and VITEK 2 with MYLA, Class II – Software issue where results sent to the LIS via HL7 format for antibiotic screen tests and synergy tests do not include the user-corrected or AES-corrected interpretation. This can potentially lead to incorrect final screen/synergy test results at the LIS.
• Philips Medical Systems, Azurion systems, Class II – In the Azurion system, the user can add a new study to a patient by selecting the option Add Study . The Add Study dialogue box is then displayed where the Patient Type is selected to perform the study. Due to a software defect, when the study is initiated by pressing Start Procedure , the Patient Type changes inadvertently to a Patient Type different than the one selected as shown in the Table below. Patient type is one of the factors involved in the dose control process. The incorrect patient type changes the technique factors to be used by the system without notification to the user.
• DePuy Orthopaedics, VELYS Robotic-Assisted Solution Base, Class II – System software v1.5.1 has a system software issue related to the Daylight Savings Time (DST) change that can cause a system error, requiring the user to restart the system and potentially cause a delay in treatment.
• Draegar Medical Systems, Drager Infinity CentralStation, Class II – Software issue resulting in temporary loss of central monitoring functionality.
• Roche Diabetes Care, RocheDiabetes Care Platform, Class II – Potential for patient data mismatch when using browser “back” button to navigate between patients when using the diabetes management software.
• Sight Diagnostics, Sight OLO, Class II – In instances where custom reference ranges were configured on the device post installation, a possibility to inadvertently apply changes to reference range values was found on software versions 2.59.3 and all earlier versions, which can potentially lead to displaying and printing incorrectly-configured reference range values.
• Jude Medical, Merlin PCS 3650 programmer Model 3330, Class II – Due to a programmer software anomaly under very specific circumstance when executing a pacing capture Decrement Test in-clinic on implantable cardioverter and cardiac resynchronization therapy defibrillator devices, the programmer may continue to execute the Decrement Test instead of terminating the test and restoring the permanent programmed pacing parameters.
• Siemens Medical Solutions, Siemens SOMATOM, Class II – Software error may result in sporadic problems causing scanning workflow interruptions, unexpected user notifications and image artifacts. Sporadic software errors may also occur during interventional workflows. Results in potential patient issues: Possible rescan , Unexpected X-Ray dose and additional contrast media, Delay in diagnosis, scan abort, and patient rescan.
• Shimadzu Medical Systems, X-RAY TV SYSTEM SONIALVISION G4, Class II – It was found that the irradiated x-ray may exceed the x-ray radiation dose rate specified in CFR 1020.32 in some specific case of fluoroscopic mode due to inadequate adjusting criteria in installation.
• Siemens Medical Solutions, YSIO X.Pree, Class II – For the automated multi-image-acquisition procedure Ortho x-ray collimation is set in a preparative stage for the entire examination area prior to the exam. During acquisition of each individual x-ray image, the x-ray collimator is automatically positioned in a way that the subsequent series of acquisition covers the defined field of view needed for each step. However, during the acquisition the collimation area displayed to the operator on the User Interface does not correctly represent the collimation area specified by the system. It indicates to the user an open collimator instead, e.g., the information displayed on the User Interface shows wider area of collimation than values preset prior to the examination. However, the collimation of the x-ray is performed correctly and always matches the examination area predefined by the user.
• GE Healthcare, CARESCAPE Central Station, Class II – If the CARESCAPE Central Station v2.0 is used with an unapproved keyboard, the audio can be muted resulting in loss of audible alarms.
• Siemens Medical Solutions, Diagnostic Ultrasound System ACUSON Juniper, Class II – The clip store function in the ultrasound imaging system does not work when the system has a disk full error. This could cause a delay in treatment if the ultrasound system is unable to save clips as study documentation during a high risk procedure, such as a stress echo exam.
• Raysearch Laboratories, RayStation/RayPlan, Class II – If a new primary image set is selected while the cine loop is running, the primary image set will be displayed as both primary and secondary image set in all side-by-side views. This will also be true for any new patient or case opened while the cine loop is running.
• Brainlab, ExacTrac Dynamic, Class II – The yaw angle may be incorrect for CBCT positioning workflows using setup beams with Varian LINACs.
• Siemens Medical Solutions, ACUSON Sequoia Ultrasound Imaging System, Class II – Due to a calculation error in the measurement when using 2D trace (manual trace) tool. The trace circumference value is overestimated and may potentially result in misdiagnosis of a patient’s condition.
• Siemens Medical Solutions, Artis icono biplane, Class II – Four potential software issues with Artis pheno and Artis icono systems with software VE20C: 1. Updated calibration data not saved with measurement after scene+/-; 2. No x-ray possible, system shutdown/restart might be required during intervention; 3. Corrupted Image during Roadmap; 4. Unintended shutdown of Imaging System with UPS (Uninterruptable Power Supply) option.
• Siemens Medical Solutions, Sensis Vibe Hemo/Combo, Class II – Software error which affects Sensis Vibe Hemo, Sensis and Sensis Vibe Combo systems with software version VD12A, which could cause possible hazard to patients, operators, or other persons and equipment. Under certain sporadic circumstances, the CO (Cardiac Output) measurement using the Thermodilution method will temporarily no longer be possible.
• PTW North America Corporation, Software BeamAdjust, Class II – When a measurement with a PTW detector array is performed with the software BeamAdjust 2.2 or VeriSoft 8.0, a measurement error can occur under specific conditions. This error can lead to a too-low or too-high measured absolute dose which affects patient plan verification results.
• Philips North America, Philips Azurion Interventional Fluoroscopic X-ray System, Class II – (1) Start-up problem: Intermittently at start-up of the system, the communication of the control unit that manages the movement of the stand is not established; (2) Emergency stop recovery problem-warm restart is not executed correctly and movement functionality is not available.
• Reflexion Medical, RefleXion Medical Radiotherapy System, Class II – Due to dose discrepancy when delivering a plan to a patient in a Non-HFS (Head First Supine) orientation specifically in Feet First Supine (FFS).
• Abbott Molecular, Alinity m System, Class II – There is an issue with the installation of updated camera firmware on the system.
• Siemens Healthcare Diagnostics, Atellica CH 930 Analyzer, Class II – (1) Software versions V1.25.1 and lower may result in TDef (Test Definition) Parameters for Open Channel Assays reverting to Default Value would shift test results by the magnitude of the implemented Assay Correlation factor; (2) On Board Stability (OBS) Not Updating with Manual Change for Open Channel Assays may continue to use the reagent past its expiration date leading to potential erroneous patient sample results.
• Invacare Corporation, Invacare AVIVA FX, Class II – Power Wheelchairs with a LiNX Gyro component running firmware version 6.1.2 can experience a more aggressive deceleration rate than the programmed rate due to the system following the incorrect deceleration profile, resulting in potential injury.
• Haag-Streit, OCT-Camera 211, Class II – Malfunction of the automatic laser beam shut-off, the OCT unit might not recognize whether the laser beam is safely switched off.
• Illumina, NextSeq 550, Class II – Cybersecurity vulnerability.
• Edwards Lifesciences, FORE-SIGHT ELITE Absolute Tissue Oximeter, Class II – The StO2 values may be inaccurately low when using either the FORE-SIGHT ELITE Tissue Oximeter Module or the FORE-SIGHT ELITE Absolute Tissue Oximeter Monitor with the Fore-Sight Elite large sensor in certain somatic locations (arms and legs). While the StO2 absolute values are impacted, the directional trend remains accurate, but may have a larger magnitude change. Low StO2 values may lead to unintended or inappropriate treatment.
• Stryker, 1688 Camera Control Unit, Class II – A software defect in the camera control unit (CCU) will cause the image on the monitor to flip upside-down into an incorrect orientation. The potential of harms are conversion to open procedure, additional medical intervention, or a revision surgery.

Europe recognizes ISO 14971:2019, Application of risk management to medical devices

With the recent May publication of Commission Implementing Decision 2022/757 in the Official Journal of the European Union, EN ISO 14971:2019 is labeled as “Harmonized” and listed to the European Union’s Medical Device Regulation (EU 2017/745).

Guidance on the Application of ISO 14971 to Artificial Intelligence and Machine Learning (AAMI CR34971:2022)

The AAMI released the consensus report “Guidance on the Application of ISO 14971 to Artificial Intelligence and Machine Learning” (AAMI CR34971:2022). The report provides guidance to assist those who are applying ISO 14971 to regulated AI medical technologies. It can be purchased at the AAMI store.

Appropriate Use of Public Cloud Computing for Quality Systems and Medical Devices (AAMI CR510:2021)

The AAMI released the consensus report “Appropriate Use of Public Cloud Computing for Quality Systems and Medical Devices” (AAMI CR510:2021). The purpose of this document is to provide guidance to multiple stakeholders regarding the appropriate use of public cloud computing both as a component of medical devices and in support of quality systems. It can be purchased at the AAMI store.

ANSI/AAMI/UL 2800 Standards

The following standards of the AAMI/UL 2800 series have been released:

• Standard for Medical Device Interoperability (ANSI/AAMI/UL 2800-1:2022)
• Standard for Interoperable Item Development Life Cycle (ANSI/AAMI/UL 2800-1-2:2022)
• Standard for Interoperable Item Integration Life Cycle (ANSI/AAMI/UL 2800-1-3:2022)

The AAMI/UL 2800 series of standards covers the interoperability of medical products. AAMI/UL 2800-1 is the general standard that specifies a baseline set of requirements for assuring safe and secure interoperability for interoperable medical systems. The requirements in the AAMI/UL 2800-1 standard are supplemented by the requirements in additional AAMI/UL 2800 standards.

Medical devices and medical systems—Essential safety and performance requirements for equipment comprising the patient-centric integrated clinical environment (ICE): Part 2-1: Particular requirements for forensic data logging (ANSI/AAMI 2700-2-1:2022)

ANSI/AAMI released this part of the AAMI 2700 family of standards to achieve safe integrated clinical environments (ICE). This document supports safe and secure device interoperability by providing general functional, performance, security, and interoperability requirements of ICE data logging systems.

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

The FDA released a draft guidance on Digital Health Technologies for Remote Data Acquisition in Clinical Investigations – Guidance for Industry, Investigators, and Other Stakeholders, December 2021. This guidance provides recommendations for sponsors, investigators, and other interested parties on the use of  digital health technology for remote data acquisition from participants in clinical investigations evaluating medical products.

https://www.fda.gov/media/155022/download

Cybersecurity in Medical Devices

The FDA released a draft guidance on  Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions – Guidance for Industry, Investigators, and Other Stakeholders, April 8, 2021. This guidance has completed its 90 day review by industry and we are awaiting the final guidance to be released by the FDA. This may happen anytime soon till the end of the year.

One of those changes in the updated draft includes asking manufacturers to provide a software bill of materials (SBOM) instead of a cybersecurity bill of materials (CBOM) which was a major sticking point for the medtech industry.

https://www.fda.gov/media/119933/download

Cybersecurity in Medical Devices – Highlights from FDA June 14th Webinar

On June 14th, the FDA held a webinar to present the changes to the cyber security guidance and distribute the draft for comments and questions from industry. This is the first update since the last draft guidance which was released for comment in 2018 and remained only distributed for comment.

The webinar can be download at the following site:

https://www.fda.gov/media/159200/download

AI and ML in Radiological Medical Devices

The FDA has finalized the guidance on the regulation of software as a medical device (SaMD) that utilizes artificial intelligence or machine learning (AI/ML) in components for radiological medical devices, e.g.,  x-ray machines and MRI equipment. This guidance, Technical Performance Assessment of Quantitative Imaging in Radiological Device Premarket Submissions Guidance for Industry and Food and Drug Administration Staff was issued on June 16, 2022.

https://www.fda.gov/media/123271/download

Machine Learning-enabled Medical Devices

The IMDRF has issued the Machine Learning-enabled Medical Devices: Key Terms and Definitions on 6 May 2022. The IMDRF (International Medical Device Regulators Forum) is comprised of the following member sites: Australia’s TGA, Brazil’s ANVISA, Health Canada, China’s National Medial Products Admin, EU, Japan’s PMDA, Russian MOH, Singapore Health Science Authority, South Korea Ministry of Food and Drug Safety, UK’s MHRA and the US FDA.

https://www.imdrf.org/documents/machine-learning-enabled-medical-devices-key-terms-and-definitions

Artificial Intelligence and Machine Learning in Medical Devices

The FDA/CDRH/Digital Health Center for Excellence gave a presentation on Artificial Intelligence/ Machine Learning (AI/ML)-Enabled Medical Devices: Tailoring a Regulatory Framework to Encourage Responsible Innovation in AI/ML. A copy of the presentation can be downloaded from the following link.

https://www.fda.gov/media/160125/download

Whitepaper: Machine Learning Best Practices in Healthcare and Life Sciences

The whitepaper provides an overview of security and good ML compliance practices and guidance on building GxP-regulated AI/ML systems using AWS services.

https://d1.awsstatic.com/whitepapers/ML-best-practices-health-science.pdf?did=wp_card&trk=wp_card&quot

IEC 62304 Update

As mentioned last couple of updates, the IEC 62304 draft that was in the works has been rejected. The working group disbanded itself and there is a new working group being organized. This means that IEC 62304:2006 + Amd1:2015 will remain valid for some more years to come. So, in other words, nothing new to report.

Content of Premarket Submissions for Device Software Functions

We are expecting that this guidance will soon be approved and will come into effect and replace the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices from May 2005.

This guidance is intended to cover:

• Firmware and other means for software-based control of medical devices
• Stand-alone software applications
• Software intended to be operated on general-purpose computing platforms
• Dedicated hardware/software medical devices
• Accessories to medical devices when those accessories contain or are composed of software

The draft guidance applies to the following submissions of software (either as part of a device or as the device):

• Premarket Notification (510(k))
• De Novo Classification Request
• Premarket Approval Application (PMA)
• Investigational Device Exemption (IDE)
• Humanitarian Device Exemption (HDE)
• Biologics License Application (BLA).

The level of documentation is based on the device’s intended use and does away with the Level of Concern (LOC). There are two levels of documentation:

• Basic Documentation
• Enhanced Documentation

According to the guidance, Enhanced Documentation should be provided for any premarket submission that includes device software functions, where any of the following factors apply:

• The device is a constituent part of a combination product.
• The device (a) is intended to test blood donations for transfusion-transmitted infections; or (b) is used to determine donor and recipient compatibility or (c) is a Blood Establishment Computer Software.
• The device is classified as class III.
• A failure or latent flaw of the device software function(s) could present a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. These risk(s) should be assessed prior to implementation of risk control measures.

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions

Expected Guidance Documents to be Published in FY 2022

Final Guidance Topics:

• Clinical Decision Support Software

Draft Guidance Topics:

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
• Content of Premarket Submissions for Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD)

Document Management

Many companies are working with various document management systems. Some are better than others and some are just bad. We recommend companies looking into these tools to evaluate the tools by speaking to real users (not the ones who purchased the tool as they are committed regardless how good or bad the tool is). Make sure that you have support and the capability to customize the tool for your processes. Remember, these tools together with their customizations, must be validated. All updates require a re-validation (at least on the changes).

When and How to Use Sub-Contractors for Software Development

There are pluses and minuses in using sub-contractors to develop the software of a medical device. If the company is a start-up, it usually doesn’t have the resources to develop quality software. In this case, the decision to use a sub-contractor comes easy. It makes sense to use a good sub-contractor to develop the software. The question arises, what to allow the sub-contractor to do and how to control the work being done.

When discussing the project with the sub-contractor, he will swear that he knows what the regulatory bodies want, he knows the standards, he knows how to develop the code according to required guidelines, he knows how to write the documents, he knows how to validate the software, etc.

It’s very probable that the sub-contractor has worked on a few projects that have cleared the FDA/CE. The clearance can be due to good software documentation produced or due to more luck than experience, as the reviewer did not review the documentation in depth.

Additionally, the sub-contractor will tell you he can write the software requirements and validate them. Would you let the cat watch the cream? As you know what is required, you should write the software requirements specifications. If the sub-contractor writes the software requirements, they will reflect what the software does and not what you require from the software.

Accordingly, you should also validate the software according to the requirements. You know what is expected and this way, you can make sure the software meets the formal requirements defined.

You should also have a SOW (Statement of Work) with the sub-contractor detailing the scope of work, documentation standards, participation in audits (internal, external) if required, implementation documentation (unit test summaries, integration test summaries, code review summaries, verification testing summaries, etc.) on your forms (not the sub-contractor’s forms), etc.

The sub-contractor should be trained according to your SDLC procedure (even if they tell you that they are certified). You do not want your external auditor (FDA/NB) deciding that they want to audit your sub-contractor.

Sub-contractors developing software (firmware, mobile, cloud, AI, etc.) who are looking to expand their portfolio and get deeper into medical devices are invited to contact me to find out what is required from them and how they can get their message to the companies looking for software development.

FDA Responses to 510K Submissions – Software

We are still receiving responses from the FDA concerning their software. This means that this is becoming the state of the practice for the FDA. These responses relate to the run-time testing, and cybersecurity. Below is shown the wording received from the FDA in most of the cases:

1. The submission did not include information on the tools, such as static analysis tools, that you used to detect run-time errors. This information is needed to assess whether good coding practices have been implemented to prevent common coding errors which may adversely affect the safety of the device. Please provide this information. For any such tool used, please identify what error types the tool detects, your method and process of applying the tool(s), and a summary report and/or conclusion about the results. Note: some common run-time errors are:
   1. Un-initialized variables
   2. Type mismatches
   3. Memory leaks
   4. Buffer over/under flow
   5. Dead and unreachable code
   6. Memory/heap corruption
   7. Unexpected termination
   8. Non-terminating loops
   9. Dangerous Functions Cast
   10. Illegal manipulation of pointers
   11. Division by zero
   12. Race conditions

 

2. The information security and cybersecurity of the device is needed to evaluate the cybersecurity risks and the associated controls. The FDA has been asking for the cybersecurity even from devices that have no connectivity.
   1. Please discuss in detail, information on your design considerations, including mitigations pertaining to intentional and unintentional cybersecurity risks including:
   2. A specific list of all cybersecurity risks that were considered in your design.
   3. A specific list and justification for all cybersecurity controls that you established, and the justification as to why such controls are adequate. Please provide the evidence that the controls perform as intended.
   4. Please ensure that you address information confidentiality, integrity, and availability.
   5. Please incorporate, as appropriate, the information identified here in your Hazard Analysis.

 

3. The FDA has been reading the software documentation, including the Risk Analysis, SRS, SDD, STD, STR, Traceability Report, OTS Report, Cybersecurity, etc. They have been raising issues as shown in the following:
   1. SRS: contradictions and not containing information necessary to understand the requirements for your device software; requirements related to programming language requirements or to the interfaces.
   2. SDD: high-level architecture and does not include the level of detail expected for software architecture; does not include information necessary to ensure that your software is safe and effective for the intended use of the device; missing information for all the third-party devices used by your system.
   3. Traceability Report: traceability documentation does not link between requirements to the hazards
   4. Testing: it doesn’t include a summary of the static analysis, examples of unit integration testing, and a summary of the results.

 

We are highly recommending to clients several remediations:

• SSC Class B/Moderate LOC – software require tools to test the software for run-time errors. We are recommending using static code analysis tools. There are low end tools that should be used, e.g., Source Code Analysis package for medical device companies from Parasoft (C/C++, Java, C#/VB.NET), Microsoft Visual Studio Static Code Analysis (C/C++), IAR C-STAT static analysis (C/C++), etc.
• SSC Class C/Major LOC/Special Guidance/PMA – FDA will ask for a SCA report. We highly recommend using one of the tools that we know the FDA has evaluated. A partial list of these tools is Parasoft, Coverity, Polyspace, PQRA, Klocwork, Grammatech, LDRA, etc.
• A cybersecurity report should be prepared for submission to the FDA based upon the threat analysis.
• Using tools for cybersecurity testing, penetration testing, etc.

When choosing SCA and cybersecurity tools, check the local support. Even though everyone offers Internet support, nothing beats having the support done locally by someone who has the experience and speaks your language.

Summary

There are many ways to screw up your software in the medical device whether it is embedded in dedicated hardware (also known as SiMD – Software in a Medical Device) or stand-alone health software (also known as SaMD – Software as a Medical Device). It doesn’t take too much talent to do this (as we all know) and companies are doing it daily. Many companies mess up royally and don’t know how to get out of the mess. In many cases, they don’t even know that they are in deep trouble until the recall is issued.

You can work properly without breaking the bank. There are many ways to handle the software development/maintenance life cycle and the software validation.

If there are any questions or requests, please feel free to contact us.

Mike

Download the Full Update