Updates

Software in Medical Devices – Update for Q3/Q4 2020

Software in Medical Devices – Update for Q3/Q4 2020

The past few months have been very difficult, from many aspects. Not much has been happening in releasing new standards and the MDR has been postponed for a year. I do not want to miss out on this update, so you will get what there is.

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 very 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.

There are rumors that the FDA will get rid of the differences in the documentation to submit for the Level Of Concern (LOC). If this happens, all submissions will probably be like a Major LOC of today, including the static code analysis report.

Software Recalls Q3-Q4 /2020

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 5 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. There were about 200 recalls in this period relating to software, including numerous class 1 recalls. There may be more but classified not under software. 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.

  • CME America, BodyGuard Infusion Pump System, Class I – Infusion Pump Systems may have a delivery inaccuracy of up to 13%, which may result in 1) faster than expected drug delivery when infusing at a very low rate (0.1 mL/h), or 2) slower than expected drug delivery when infusing at high flow rates.
  • Smiths Medical ASD, Medfusion Syringe Pump Model 4000, Class I – Inaccurate delivery can occur following an interrupted Bolus or Loading dose, if a specific sequence of events occurs.
  • CareUsion, B D Alaris System PC Unit Model 8100, Class I – Pump Module keypad may exhibit keys that are unresponsive or stuck as a result of fluid ingress potentially resulting in a delay to the start of infusion or interruption of infusion. Delays in an infusion or interruption can cause serious injury or death in high-risk patient populations.
  • Novarad Corporation, NovaPACS Diagnostic Viewer, Class II – The firm received a report of an atypical dataset being generated. When using the cross-localization feature and images from a modality that generates asymmetrical images, the cross-localization reference line may be inaccurately placed on any of the corresponding images that are open.
  • Materialise N.V., Match Point Systemm Class II – The procedure side indicated in the top header of the Shoulder Case Planning Report incorrectly indicated the procedure side as “Left” for surgical plans for a “right” procedure side.
  • GE Healthcare, CARESCAPE ONE Physiological Patient Monitor – CARESCAPE ONE may not provide visual and audible alarms for Ventricular Fibrillation (V Fib), if V Fib occurs at the time CARESCAPE ONE is docked to a CARESCAPE B450/B650/B850 host monitor.
  • Vitalconnect Inc., VistaSolution Version 2.1, Class II – A software defect leading to potential hazards. A patient may have hypoxia and the designated health care provider may not be notified. The firm will be turning off the ability to set custom notifications containing continuous SP02 until the issue is resolved. The firm tells customers to monitor the patients for SPO2, as if the patients are not connected to the recalled device.
  • Siemens Medical Solutions, Artis zee or Artis Q systems, Class II – Potential exists for the collision supervision not to work properly following loss of the individual room configuration data settings causing danger of collision with fix mounted room equipment, walls or floor may occur. This might cause components of the system to fall or tilt which could result in crushing of patients, operators or staff, collision of system parts with patients, as well as result in delay or interruption of the clinical procedure.
  • Skytron, SkyVision SDS System – Video Integration, Class II – Intermittent failure of a signal being sent to a monitor from the touch panel display causing the displaying monitor to go Blank and the touch panel to display a Blank image when reviewing the target display. If this issue were to happen during a case, cause increase risk to patient due to hospital losing the visual image.
  • Fujifilm Medical Systems, Synapse PACS Software Version 5.6.1, Class II – There is a possibility that certain CT studies may report a much higher 3D Sphere MAX value than expected. This issue is specific to 3D Sphere – other density tools are not affected.
  • Roche Molecular Systems, MagNA Pure 96 Instrument, Class II – When using Sample Transfer protocol version 3.0, the drop catcher is not activated on the MagNA Pure 96 instrument, which introduces a potential risk for cross-contamination leading to erroneous results.
  • Remote Diagnostic Technologies, Manual Defibrillator, Class II – A software error was detected within software version 1.3.4 for the Tempus LS device. When exiting pacer back into manual mode the pacer pulse wave may put the ECG calibration out of calibration. This software error may result in a delay in therapy, as the clinician is not provided an ECG waveform on which a shockable rhythm decision can be made. The device is still able to deliver a manual defibrillation shock.
  • Shimadzu Medical Systems, MH-200S system with Ceiling Suspended C-arm Support, Class II – The firm has identified a problem with the control software for the celling arm of the X-Ray System. This software issue could cause the ceiling arm of the device to move after the operator has released the movement lever. This could result in possible collision or harm to the patient or system operator.
  • Spacelabs Healthcare, Sentinel V10.x & V11.x, Class II – During system upgrade incorrect comments may be added to existing tests. In such instance: Resting ECG and ABP tests which did not contain comments at the time of the upgrade, may have unrelated comments added. Existing comments will not be overwritten or removed. Rhythm ECG Tests may have comments overwritten with unrelated comments. Any tests created after the upgrade are not affected.
  • Welch Allyn, ELI 380 Electrocardiograph, Class II – The radio within the device can become disassociated with the wireless access point.
  • Canon Medical System, Aquilion Prime SP Multislice Helical CT Scanner, Class II – A software problem has been identified which could result in the CT Scanner not proceeding to the next actual scan even though automatic start of the next scan is specified. This could result in the CT scan failing resulting in rescanning and reinjection of contrast medium.
  • Covidien, Capnostream 35 Portable Respiratory Monitor, Class II – The firm has released software update V01.05.02.16 (also known as V1.5.2) in response to customer reports of a false display of the message, “Temperature Exceeds Limits” followed by automatic shutdown of the monitor with no accompanying alarm.
  • Biomeme, SARS-CoV-2 Real-Time RT-PCR Test, Class II – The firm has become aware of nine reports by a single customer that the software made false positive calls. The investigation determined that the root cause is the higher than expected amber-to-red co-excitation in the assay.
  • RAYSEARCH LABORATORIES, RayStation standalone software treatment planning system, Class II – If a region of interest (ROI) or point of interest (POI) that is referenced from an imported plan is missing in the imported RT Structure Set, the reference may become linked to the wrong ROI or POI.
  • Roche Diagnostics Operations, cobas infinity central lab/cobas infinity, Class II – Potential Incorrect Validation of Results Due to an Erroneous QC Status When Using Status Expiration Control Rule.
  • Shanghai United Imaging Healthcare Co., Positron Emission Tomography and Computed Tomography System, Class II – A potential issue of an incorrect CT scan delay timer to be displayed on the gantry Digital Display Panel (DDP) during multi-phase contrast scanning. This could lead the operator to receive unnecessary exposure to radiation.
  • Inpeco, Aptio Automation System with the Aliquoter Module/ FlexLab (FLX) Automation System with the Aliquoter Module, Class II – When a Clot Detection Error is generated during the sample aspiration from the Primary Sample Tube the aspirated volume is dispensed into the first empty Secondary Sample Tube. This Secondary Sample Tube is flagged with error 2132 or 1442 and sent to IOM Priority Output Racks to be manually managed. The current error message associated to error 2132 or 1442 recommends that the operator manages these Secondary Sample Tubes according to Laboratory Practice, but it does not clarify that these Secondary Sample Tubes may be diluted with water from the hydraulic circuit of the Aliquoter Module this may lead to reporting of erroneous results if the diluted sample is used for testing.
  • Siemens Medical Solutions, ARTIS Icono Interventional Fluoroscopic X-Ray system, Class II – There is a software problem which affects the DSA Roadmap application on ARTIS Icono and ARTIS Pheno systems with software version VE20B. In rare cases, when the DSA acquisition has been started while the C-Arm or table is moving, there may be a shift between the image acquired at the start position and the image (i.e., DSA vessel map) taken at the reference position. This may lead to a DSA vessel map being overlaid to a subtracted fluoro image at a position that is not accurate. However, if the displacement is slight or at an unfavorable plane, the user might rely on incorrect visualization of the catheter relative to the vessel map. This could imply danger to the patient.
  • Boston Scientific Corporation, Model 3300 LATITUDE Programming System, Class II – There is potential when a user changes an EGM trace channel with a Manual Pace Threshold test in progress that the newly modified trace channel may change to a flat line.
  • Merge Healthcare, Merge LIS, Class II – A defect in the software resulted in medications that are not associated with the patient (i.e., medications that the patient is not currently taking) appearing on their report.
  • Pentax of America, 9372HD Digital Capturec , Class II – There is an intermittent software issue that could affect the systems, in which an exam video for one patient (Patient A) might be copied to another patient (Patient B). This does not occur at the time the user performs and initially reviews an exam; it is not evident until a follow-up review occurs.
  • Skytron, VGDF-SKY (R4-010-06) VGA TO FIBER CONVERTER Single Format Faceplate, Class II – VGDF (VGA) Faceplate failure results in failure of video signal for SkyVision Linx 300, a secondary display. Video would continue on the primary source device display.
  • Brainlab, Ultrasound Navigation Software 1.0, Class II – Brainlab Ultrasound Navigation Software does not support the modification of the probe’s image width.
  • Siemens Medical Solutions, Software versions syngo.CT , Class II – Sporadic problems with the current software may result in scanning workflow interruptions and unexpected user notifications causing delay in diagnosis or patient rescan.
  • Medtronic, The Guardian Connect App CSS7200 iOS, Class II – As a result of the release of new software version to CareLink Personal website, the IOS app for the Continuous Monitoring Glucose system stopped automatically uploading data to the website.
  • Inpeco, Aptio Automation systems with Sysmex XN-9000/XN-9100 Interface Module, Class II – Firmware of the Sysmex XN-9000/XN-9100 Interface Module (IM) and of the Track to Rack Module has the potential to mis-associate sample IDs leading to incorrect results or delayed results.
  • SICAT, SICAT IMPLANT V2.0, Class II – A dentist found implant positions are not correctly exported from the implant planning software SICAT IMPLANT V2.0 – for the specific export format CMG.DXD.
  • Siemens Medical Solutions, E.cam or Symbia systems that use foresight detectors, Class II – E. CAM and Symbia system with foresight detectors performing gated or dynamic acquisition may lose some detector time information. Our risk analysis indicates that the probability of occurrence is remote. SPECT: To detect or image the distribution of radionuclides in the body or organ, using the following techniques: planar imaging, whole body imaging, tomographic imaging for isotopes with energies up to 588keV. CT: The CT component is intended to produce cross sectional images of the body by computer reconstruction of x-ray transmission data from either the same axial place taken at different angles or spiral planes taken at different angles. SPECT+CT: Perform CT scans and nuclear imaging studies within the same instrument. To obtain attenuation corrected images and to provide registration of anatomical and physiological images within the patient’s anatomy.
  • Canon Medical System, Ultimax-i DREX-UI80, Class II – During a procedure, when images were acquired, and these images were transferred to PACS /image archival system, the number of images displayed were not the same as originally acquired.
  • Biosense Webster, CARTO 3 System, Class II – Software defect may result in disappearance of tag sites during recalculation and lead to additional ablation sites. This may lead to prolongation of the procedure and, in extremely rare circumstances, cardiac perforation.
  • Shanghai United Imaging Healthcare Co., Positron Emission Tomography and Computed Tomography System, Class II – In affected software version, of Positron emission tomography and computed tomography system, the CT Hounsfield unit curve may not display in real time when using the bolus tracking protocol with the tracker scan function. If this occurs, the subsequent clinical scanning protocols will need to be started manually, which may effect image enhancement, and may result in patient rescan.
  • Precision Valve & Automation, PREVENT, Class II – While operating the machine in “Run” mode an unexcepted event may occur during the error-checking for stepper movements and pressure values. The result of this event is a false alarm being thrown and in rare cases results in an incomplete move which will affect the current inhale/exhale cycle.
  • Ion Beam Applications, Proteus 235, Class II – Signature from the user is necessary to proceed with specific actions in the Proton Therapy System (PTS). IBA became aware that the PTS does not accept user names with more than ten characters. It is an issue when the user has no other choice than resuming an aborted treatment field based on the overall delivered dose displayed on the Dose Counter Electronic Unit (DCEU). User s signature is required to perform this action. If the signature contains more than ten characters, the user will not be able to complete the aborted treatment field. An additional issue applies to Electronic Medical Record (EMR) centric sites and may increase the probability of not being able to complete an aborted treatment field. It is not possible, in a new session, to resume from a local partial archive if the Patient Positioning System (PPS) position has changed. If the user captures the PPS position at every session in the Oncology Information System (OIS) just after the setup process, the prescribed PPS position is changed for the next session in the OIS. This includes the partial continuation session. Therefore, when comparing the prescribed PPS position between OIS and local database, the PTS sees a difference and rejects the local partial archive. This problem forces the user to resume the interrupted irradiation based on the overall delivered dose displayed on the DCEU instead of resuming from the full details of the interrupted beam.
  • Smiths Medical ASD, Medfusion Syringe Pump Model 4000/Model 3500, Class II – Inaccurate delivery can occur following an interrupted Bolus or Loading dose, if a specific sequence of events occurs.
  • Normand-Info, Remisol Advance, Class II – Results from repeated run for WBC (White Bloodcell Count), UWBC (Urine Whit Bloodcell Count) and PLT (Platelets) are deleted in RADV. Use may lead to erroneous results.
  • Philips North America, IntelliVue G7m Anesthesia Gas Module, Class II – The device may experience an interruption of gas measurement due to a firmware issue, ceasing measurement and display of gas levels and generating one or more technical or INOP alarms.
  • Siemens Medical Solutions, syngo.via RT Image Suite, Class II – If the user modifies for any reason (e.g. reduction of artifacts) the original image orientation of a standard MR protocol to acquire images in a different orientation for further processing in Synthetic CT , the software does not recognize the adapted acquisition plane. This may result in images with wrong geometry. When this distortion remains unnoticed and the images are subsequently exported to a treatment planning system (TPS), an incorrect calculated radiation treatment plan cannot be excluded. The occurrence of this issue is very unlikely and has never been reported so far.
  • Sysmex America, Sysmex PS-10 Sample Preparation System, Class II – Insufficient amount of antibody without an error message or alarm.
  • Medtronic Xomed, Software 1898072 IPC upgrade v 2.7.3.0, Class II – During internal testing execution of the next generation of Integrated Power Console (IPC) prototype it was noted that the M5 Microdebrider was rotating at a higher speed than the set value in the console.
  • Shanghai United Imaging Healthcare Co., Computed Tomography X-ray System Model: uCT 550, Class II – Two issues were identified with the computed tomography x-ray system including a service function which may cause false marking of a bad channel resulting in ring artifacts, and potential intermittent scout scanning interruption due to occasional angle signal drift. If these problems occur, it may be necessary to rescan the patient resulting in an additional dose of radiation and the possible need for additional contrast medium.
  • Medtronic, CareLink SmartSync Device Manager/Patient Connector, Class II – There is a rare communication sequence during the first device interrogation with a SmartSync Device Manager that may result in the temporary suspension of some device features (i.e., battery measurements, Capture Management”, Atrial Lead Position Check”, EffectivCRT” algorithms, and AdaptivCRT”). This rare interaction results in temporary suspension of automatic threshold testing and output adjustments, and suspension of auto-optimization of CRT therapy. The issue is unlikely to result in clinical impact to the patient, and features are restored upon next programmer device interrogation or presence of a magnet.
  • Ra Medical Systems, DABRA Laser, Class II – A software issue was identified which could result in user or patient injury, or may adversely impact laser performance. It is possible that an unintended release of laser light (radiation) may occur, injuring the user or patient.
  • Radiometer Medical, Blood gases (PCO2, PO2) and blood pH test system, Class II – Potential risk of patient mix-up on analyzers due to software issues.
  • Tomtec Imaging Systems, TOMTEC-ARENA TTA2, Class II – The firm discovered a software issue associated with the Image-Com module/clinical application package (CAP) interface for 3D application in the ARENA software, where measurements from one study might be stored to another study.
  • Preventice Services, BodyGuardian Heart Remote Monitoring Kit, Class II – The device data being collected and transferred to the monitoring center may not be accurate due to nonvalidated association between the phone software and the heart monitors, therefore, the patient’s report should not be used to evaluate their condition.
  • LivaNova USA, VNS Therapy SENTIVA DUO # 1000-D, Class II – During internal testing, it was found that upon a device reset, the Generator exhibits the incorrect Model Number when interrogated.
  • Mevion Medical Systems, MEVION S250i/MEVION S250, Class II – Treatment beam information disappears on Treatment Console screen while beam delivery continues potential for harm to a patient could occur.
  • Fresenius Medical Care Holdings, Liberty Select Cycler, Class II – The device may detect an incorrect Heater Bag volume which may lead to a ‘Supply Bag Line Blocked’ alarm during treatment. This alarm may cause the Heater Bag to contain more fluid than expected and the cycler does not recognize the extra fluid is present and it will not make it available for treatment. Not having enough solution to complete treatment may lead to inadequate dialysis which could result in the accumulation of toxins and fluid. Symptoms may include shortness of breath, increased weight gain, and increased blood pressure.
  • GE Healthcare, Revolution Apex/Revolution CT with Apex Edition, Class II – There is a potential for a smudge artifact that could be suspect for pathology in some images due to incorrect settings.
  • Shanghai United Imaging Healthcare Co., uMI 550 PET/CT Diagnostic Imaging System, Class II – Issues were identified with the PET/CT diagnostic imaging systems including: a potential intermittent issue leading to image artifacts; potential intermittent scout scanning interruption; a problem with one of the service functions which may cause false marking of a bad channel resulting in ring artifacts; and the possibility of unevenness of the metal edge which overlaps the mylar strip in the gantry which may create a sharp edge. These issues may require rescanning of the patient resulting in additional radiation exposure, and possible abrasion to the patient’s arm from a sharp metal edge.
  • Luminex Corporation, Verigene Processor SP with assay, Class II – An instrument failure mode that may result in a Blood Culture Gram Positive (BC-GP) or Gram Negative (BC-GN) false negative call.
  • Siemens Medical Solutions, Healthineers Luminos dRF Max, Class II – Two software issues (1) Using the override function in case of blocked system movements affecting Luminos dRF Max, Luminos Agile Max and Uroskop Omnia Max systems may cause collision of the system under operator control with obstacles or persons . (2) Incorrectly assigned image affecting Ysio Max, Luminos dRF Max and Luminos Agile Max systems with detector MAX Static causing incorrect base for diagnosis.
  • B Braun Medical, APEX Compounding System Control Panel Module, Class II – There is the potential for the compounding system to not immediately interrupt compounding and alert user to the presence of an air bubble exceeding 3% of the ordered volume for an ingredient. This could result in a compounded drug that does not meet the specified accuracy range for an individual ingredient.
  • Roche Diagnostics Operations, Roche cobas pro integrated solutions Chemistry Analyzer, Class II – Potential for Changed Configuration Settings on the cobas 8000 modular analyzer series/cobas pro integrated solutions, may cause incorrect results in several affected parameters. In the case of poor sample quality, discrepant results may remain undetected due to the absence of associated data flags.
  • Haag-Streit, Surgical Floor stands FS 2-11 and FS 2-15, Class II – Software error -Software REF 615 588 versions 2.0 to 3.3, movement of the focusing is triggered by pressing the button of the footswitch it might occur that the movement does not stop when releasing the button, result in potential risk to the patient’s eye.
  • Medtronic Neuromodulation, Percept PC Implantable Neurostimulator (INS), Class II – A software anomaly in the A620 Patient Programmer application was identified that results in failure to connect with the Percept PC device.

 

IEC/DIS 81001-5-1 Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle

Draft released on 9/12/20. The voting ends on 3/3/21. This draft is meant for understanding and commenting on it.

 

Cybersecurity Standards for Medical Devices Which Can Be Used for Conducting Gap Analysis

The following is a list of standards that can be used when performing a gap analysis on the cybersecurity situation for your device:

  • ISO/IEC 81001-1 Health software and health IT systems safety, effectiveness, and security – Part 1: Foundational principles, concepts and terms
  • IEC 80001-5-1 Safety, effectiveness, and security in the implementation and use of connected medical devices or connected health software – Part 5: Security – Part 5-1: Activities in the product lifecycle (Current status: Approved project, kick-off Feb 4-6, 2019)
  • IEC 60601-4-5 Guidance and interpretation – Safety related technical security specifications for medical devices (Call for Experts in IEC SC 62A)
  • IEC 62304 Medical device software – Software life cycle processes (Current status: under revision)
  • AAMI TIR97/Ed. 1, Principles for medical device security – Post-market security management for device manufacturers (Current status: completing comment resolution process)
  • AAMI SW96/Ed. 1, Medical Devices – Application of security risk management to medical devices (Current status: approved project, on hold while group finishes AAMI TIR 97)

 

FDA on AI/ML (Artificial Intelligence/Machine Learning)

The FDA released a Discussion Paper and Request for Feedback called Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) at the end of 2020. The document contains a discussion of the AI/ML development and update process. The document ends with a series of questions that each development group (using AI/ML) should ponder.

 

The state of artificial intelligence-based FDA-approved medical devices and algorithms: an online database

This paper was released in September 2020 and the authors identified 29 companies who submitted and received FDA clearance for their AI/ML based medical devices. The interesting point of this is that there are at least 5 companies with R&D in Israel in this list.

 

FDA Release – Potential Cyber Vulnerabilities in BLE

The FDA released on 3/3/20: FDA Informs Patients, Providers and Manufacturers About Potential Cybersecurity Vulnerabilities in Certain Medical Devices with Bluetooth Low Energy. This is a set of cybersecurity vulnerabilities, referred to as “SweynTooth,” that – if exploited – may introduce risks for certain medical devices. SweynTooth affects the wireless communication technology known as Bluetooth Low Energy (BLE). BLE allows two devices to “pair” and exchange information to perform their intended functions while preserving battery life and can be found in medical devices as well as other devices, such as consumer wearables and Internet of Things (IoT) devices. These cybersecurity vulnerabilities may allow an unauthorized user to wirelessly crash the device, stop it from working, or access device functions normally only available to the authorized user.

 

Principles and Practices for Medical Device Cybersecurity

The IMDRF issued the final version of Principles and Practices for Medical Device Cybersecurity on 18/3/20.  The purpose of this document is to provide concrete recommendations to all responsible stakeholders on the general principles and best practices for medical device cybersecurity (including in vitro diagnostic (IVD) medical devices).

 

FDA CDER releases Guidance Platform Software

The FDA, CDER, release the draft guidance Type V DMFs for CDER-Led Combination Products Using Device Constituent Parts With Electronics or Software in October 2019. For various reasons, we overlooked this draft guidance and are mentioning it now.

 

FDA’s Software Related Prioritized Medical Device Guidance Documents to Publish in FY 2021

A-List Final Guidance Topics:

  • Safer Technologies Program for Medical Devices
  • Clinical Decision Support Software
  • Device-Specific Criteria Guidance(s) for Safety and Performance Based Pathway Implementation

A-List Draft Guidance Topics:

  • Content of Premarket Submissions for Software Contained in Medical Devices
  • Content of Premarket Submissions for Cybersecurity of Medical Devices
  • Computer Software Assurance for Manufacturing, Operations, and Quality System Software

B-List Draft Guidance Topics:

  • Risk Categorization for Software as a Medical Device: FDA Interpretation, Policy and Considerations

 

It’s imperative to see the direction that the FDA is going with software regulation, including software submissions. The emphasis will be on handling clinical decision support software (until now this type of software has mainly flown under the radar), upgrades in cybersecurity requirements and software used in the organization.

 

FDA Electronic Submissions

The FDA issued on July 15, 2020 the guidance: Providing Regulatory Submissions for Medical Devices in Electronic Format — Submissions Under Section 745A(b) of the Federal Food, Drug, and Cosmetic Act.

Electronic submissions to the FDA will soon no longer be optional – the new guidance document, “Providing Regulatory Submissions for Medical Devices in Electronic Format – Submissions Under Section 745A(b) of the Federal Food, Drug, and Cosmetic Act,” requires e-submission for these submissions:

  • 510(k)
  • De Novo
  • PMA
  • PDP
  • IDE
  • HDE
  • EUA
  • Pre-submissions

 

Ransomware Hackers – Patient Dies

A patient has died after ransomware hackers hit a German hospital. This is the first ever case of a fatality being linked to a cyberattack. The MIT Technology Review from 8/9/20 reported: For the first time ever, a patient’s death has been linked directly to a cyberattack. Police have launched a “negligent homicide” investigation after ransomware disrupted emergency care at Düsseldorf University Hospital in Germany.

 

FDA Recognized Consensus Standards (since last update)

FIRST CVSS v3.0 Common Vulnerability Scoring System version 3.0

ISO 7010 Third edition 2019-07 Graphical symbols – Safety colours and safety signs – Registered safety signs

IEC TR 63183 Edition 1.0 2019-12 Guidance on error and warning messages for software used in radiotherapy

IEEE Std 11073-20601-2019 Health informatics – Personal health device communication – Part 20601: Application profile – Optimized exchange protocol

IEEE Std 11073-10101-2019 Health informatics – Point-of-care medical device communication. Part 10101: Nomenclature

IEC IEEE ISO 29119-1 First edition 2013-09-01 Software and systems engineering – Software testing – Part 1: Concepts and definitions

IEC 62366-1 Edition 1.1 2020-06 CONSOLIDATED VERSION Medical devices – Part 1: Application of usability engineering to medical devices

 

FIRST CVSS v3.0 Common Vulnerability Scoring System

The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS consists of three metric groups: Base, Temporal, and Environmental. The Base group represents the intrinsic qualities of a vulnerability, the Temporal group reflects the characteristics of a vulnerability that change over time, and the Environmental group represents the characteristics of a vulnerability that are unique to a user’s environment. The Base metrics produce a score ranging from 0 to 10, which can then be modified by scoring the Temporal and Environmental metrics. A CVSS score is also represented as a vector string, a compressed textual representation of the values used to derive the score.

This standard, when used with the FDA qualified Medical Device Development Tool titled “The Mitre Rubric version 0.12.04 Sept-3, 2019,” provides medical device manufacturers and others in the medical device supply chain a common reference framework for discussing the severity and impact of cyber vulnerabilities in already fielded devices.

 

FDA Releases Update on Digital Health Software Precertification Pilot Program

In September 2020, the FDA released the report: Developing the Software Precertification Program: Summary of Learnings and Ongoing Activities. This is an update on the Pre-Cert Pilot Program test phase started by the FDA in 2019.  The update details the learnings to date from the building and testing of the pre-cert pilot program. The update also underscores that the COVID-19 pandemic further highlights the importance of enabling rapid access to safe and effective devices for public health.

 

FDA’s Cybersecurity Guidance Update

According to sources, the FDA will not release a new guidance for cybersecurity in 2020. Additionally, when the new guidance (based on the draft version from 2018) is released (probably late Q1 or Q2 2021), it will be in draft form where there will a duration for accepting comments. Accordingly, the final guidance should be released early 2022.

 

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 number of 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 actually does and not what you required.

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.

 

Software Safety Classes (IEC 62304) versus Levels of Concern (FDA)

Both, IEC 62304 and the FDA (Content of Premarket Submissions for Software Contained in Medical Devices) distinguish three different categories of medical device software. The IEC 62304 uses the software safety classes (SSC) and the FDA guideline uses the Level of Concern (LOC). This causes much confusion.

The SSC is defined as follows in IEC 62304:2006 + A1:2015:

  • The software system is software safety class A if:
    • the software system cannot contribute to a hazardous situation; or
    • the software system can contribute to a hazardous situation which does not result in unacceptable risk after consideration of risk control measures external to the software system.
  • The software system is software safety class B if:
    • the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system and the resulting possible harm is non-serious injury.
  • The software system is software safety class C if:
    • the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system and the resulting possible harm is death or serious injury.

The LOC is determined as follows in the FDA’s Content of Premarket Submissions for Software Contained in Medical Devices:

  • Major: We believe the level of concern is Major if a failure or latent flaw could directly result in death or serious injury to the patient or operator. The level of concern is also Major if a failure or latent flaw could indirectly result in death or serious injury of the patient or operator through incorrect or delayed information or through the action of a care provider.
  • Moderate: We believe the level of concern is Moderate if a failure or latent design flaw could directly result in minor injury to the patient or operator. The level of concern is also Moderate if a failure or latent flaw could indirectly result in minor injury to the patient or operator through incorrect or delayed information or through the action of a care provider.
  • Minor: We believe the level of concern is Minor if failures or latent design flaws are unlikely to cause any injury to the patient or operator.

The SSC classes determine the software life-cycle development processes to be performed and documented.  Class A has the least processes and documentation required and Class C has the most. The SSC is determined at the beginning in the project.

The LOC determines the document to be submitted as part of the submission (and not as part of the development process). The LOC must be determined before the submission. It has been known in numerous cases, that the FDA has determined the LOC is different than what the company determined (the FDA always wins).

There is a virtual connection between the SSC and the LOC, but they both relate to different aspects (processes and documentation vs. documentation to be submitted) and should be handled accordingly.

 

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 all 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 and LDRA.
  • 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

Related Posts

Back To Top
Search