Skip to content

Software in Medical Devices – Update July 15, 2015

Software in Medical Devices – Update
This is a continuation of the software updates I have been sending out.  Please check out all of the references to download and/or to purchase.

Software Recalls Q1/2015
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. The following are additional examples of recalls involving software directly:

  • Hospira Plum A+,Plum A+3 Infusion Systems, Class I – The infusion pumps have an alarm that should sound when a therapy is interrupted. Some of the alarms may fail to sound in situations that should trigger it. It is possible for a long delay before a health care professional becomes aware of the need to restore therapy.
  • Baxter Master Drug Library Software, Class II – Loading/Bolus default dose settings in the Master Drug Library and the values shown on the pump during programming may differ.
  • ACCU-CHEK Connect Diabetes Management App, Cl II – Could potentially lead to inaccurate bolus advice being provided to the user. A thorough investigation of the situation revealed that this issue may occur if the user changes the screen orientation of the phone from portrait to landscape or vice versa while looking at the Bolus Advisor or Carbohydrate Entry screens.
  • Philips Computed Tomography X-ray Systems, Cl II – A software defect exists in marketed product wherein the sign indication of the longitudinal position of some types of scan is inverted.
  • plazma, Cl II – Possibly incomplete archived studies during pre-fetch. In a server farm setup, when pre-fetch/retrieve operation is performed for partially archived studies, the series that have not yet been archived, will remain unarchived.
  • Alaris PC units infusion pumps, Cl II – An error code may occur upon power on during the “Power-On Self Test” due to a keypad issue.
  • BrainLab ExacTrac versions x, Cl II – Patient Positioning System may incorrectly position the patient when using the ExacTrac Cone Beam CT (CBCT) with a TrueBeam-specific optional subvolume-CBCT.
  • GE Healthcare, SIGNA Systems, Cl II – Potential safety issue involving MRI systems due to software versions not being maintained properly at some sites.
  • RayStation Radiation Treatment Plan System, Cl II – an issue was found with photon dose calculation for DMLC (Dynamic MLC) plans for machines where the MLC is positioned above the jaws, e.g. some Elekta linacs. The magnitude of the error depends on the beam model output factor corrections and on the individual DMLC plan characteristics.
  • Siemens MAGNETOM systems, Cl II – The gradient outputs could exceed IEC60601-2-33 limits and peripheral nerve stimulation could occur.
  • Passport V Monitor, Cl II – An issue has been identified with Passport V Monitors invasive blood pressure function (IBP) which may provide an incorrect IBP measurement.
  • Siemens LANTIS Oncology Information System, Cl II – There is a potential safety risk when using LANTIS server software with operating systems with which it has not been validated or released which can lead to an incorrect treatment to the patient.
  • Juno DFR x-ray system, Cl II – t has been discovered that the system – does not provide the appropriate audible signal, permanent activation, and manual override, although the system is in high-level control functionality.
  • Alive ECG App 1.2, Cl II – Alive ECG App version 2.1.2 (intended to be used with the AliveCor Heart Monitor) crashed upon use of the application.
  • EPWorks software used in the Protektor 32, Cl II – Software error occurs when using remote monitoring; if the remote user tries to stop the free run waveform group, the system will display a message informing the user that they do not have sufficient privilege.
  • SoftLab with SA HIS, Cl II – The interface fails to send abnormal flags for Reference Lab test results.

Note that there is a smartphone app that was was recalled.. Another recall was due to software versions not being maintained properly at some sites. This now shows you the direction that the authorizes are relating to software problems in medical devices.

There are other recalls where the software did play a passive part where it did not mitigate the problem where it was possible to mitigate it. If the companies would have done the risk analysis covering all bases, then they would have found the risks and mitigated them accordingly using, also, the software.

Warning Letters
Soft Computer Consultants, Inc. – Failure to adequately establish procedures for CAPA as required by 21 CFR 820.100(a). Specifically, Product Change Controls (PCCs) which are corrective and preventive actions for handling software coding defects do not always include investigating the cause of all nonconformities relating to product, processes and the quality system, and identifying action(s) needed to correct and prevent recurrence of nonconforming product and other quality problems.

Quality Electrodynamics, LLC – Failure to document validation activities, as required by 21 CFR 820.75(a). Specifically, The setting (temperature and line speed) used during the validation studies for the reflow oven, which is part of the SMT (Surface Mount Technology) line, to determine the optimum settings were not documented. Therefore, it is unknown if you are currently operating the reflow oven within your validated parameters.

Yunnan Hande Bio-Tech. Co. Ltd Our investigators observed specific deviations during the inspection, including, but not limited to, the following: 1. Failure to prevent unauthorized access or changes to data and to provide adequate controls to prevent omission of data. You lacked controls to prevent the unauthorized manipulation of your laboratory’s electronic raw data. . . . .

Hospira S.p.A. – Your firm failed to exercise appropriate controls over computer or related systems to assure that only authorized personnel institute changes in master production and control records, or other records (21 CFR 211.68(b)).

Specifically, your high-performance liquid chromatography (HPLC) and gas chromatography (GC) data acquisition software, TotalChrom®, did not have sufficient controls to prevent the deletion or alteration of raw data files.

XZeal Technologies, Inc. – 1. Failure to establish and maintain procedures for validating the device design, as required by 21 CFR 820.30(g). For example: b. Your firm has not established and maintained documentation in support of Section 4.6 – Design Validation of the Product – Conception and Development, PR0-04.01, Ver. 00, concerning software validation of the embedded software for the device.

Specifically, you stated to our investigator that your firm is not responsible for the software because your firm does not manufacture it. You also stated to our investigator your firm did not know what, if any, validation activities were performed by your firm’s Chinese supplier for this software. In addition, your firm’s Risk Analysis Report Software, Ver. 00, Technical File, does not adequately access the risk presented by the software controlling the XZeal Dental X-Ray Unit Z70 as a moderate risk to users and patients.

Inovo, Inc – Failure to establish and maintain procedures for validating the device design, as required by 21 CFR 820.30(g). Specifically, a. Your software development/validation: i. does not include written procedures covering the development/ validation of the software used in your devices; ii. documentation for your Evolution

Oxygen Conserver device does not include structural testing at the code level (use of static code checkers, independent code review, etc); and iii. software product testing procedure, Database/Software Controls IQP 030 Rev A dated 10/20/08, does not require structural testing and does not include provisions for the adequate description of regression testing.

IEC 62304 Update

The update for the IEC 62304 (Software Development Life Cycle) has been released on 26 June 2015. This update (listed as IEC 62304:2006+AMD1:2015 and Edition 1.1) adds a flow for determining the Software Safety Classification, relates to validation of legacy software, and other miscellaneous clarifications and minor technical changes. Adoption as an EN is happening concurrently to the release of the standard, so harmonization by the EU should happen later this year or early next year.

Edition 2 of the standard is in early draft stage in the committee and is expected to be released not before 2016.

Georg Heidenreich wrote in his blog: “In the past, manufacturers tried to sneak away from IEC 62304 by just saying, “we only have an FPGA / simple signal- processor / embedded controller and there is no software on this platform”.

There is more clarity on this now. The scope of IEC 62304 will be clarified with respect to processor and memory and delivery form: Every instruction set to be executed on a processor will be considered software with respect to IEC 62304. Similarly, software delivered as web service, or on mobile platforms or removable media is also considered in the scope of IEC 62304 – as long as the product is for medical purposes.”  His blog can be found at:  https://www.linkedin.com/pulse/updates-good-old-iec-62304-georg-heidenreich/

Another change in the standard relates to the Software Safety Classification (SSC). The new classification rule will allow manufacturers to reclassify the SSC, provided that additional risk control measures external to the software system reduction have been implemented.

Additional changes have been made to legacy software, software requirements content (system security/malware protection requirements, requirements related to IT-network aspects, etc.), software system testing (verification & validation), legacy software, etc.

We have to wait for this version to be harmonized by the EU and recognized by the FDA.

Quality System for Software as a Medical Device
The International Medical Device Regulators Forum (IMDRF) SaMD draft of a quality system for Software as a Medical Device is available for public comment on the IMDRF website at the link provided.

http://www.imdrf.org/consultations/cons-samd-aqms-150326.asp

FDA Guidances Released
The FDA has released the following guidances with the corresponding links.

Acceptance of Medical Device Clinical Data from Studies Conducted Outside the United States

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM443133.pdf

Factors to Consider When Making Benefit-Risk Determinations for Medical Device Investigational Device Exemptions (IDEs)

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM451440.pdf?source=govdelivery&utm_medium=email&utm

Benefit-Risk Factors to Consider When Determining Substantial Equivalence in Premarket Notifications [510(k)] with Different Technological Characteristics: Draft Guidance for Industry and Food and Drug Administration Staff

http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm282958.htm

FDA Webinar Slides
On Feb 24, 2015 FDA held a webinar entitled: “Overview of Medical Device Data Systems, General Wellness Devices, and Medical Device Accessories”. The slides are at the link proivded.

https://docs.google.com/viewer?url=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FTraining%2FCDRHLearn%2FUCM435363.pdf

ECRI
ECRI has released their top 10 Patient Safety Concerns for 2015. Second on the list is “Data Integrity: Incorrect or missing data in EHRs and other Health IT systems”. This is a wake-up call for all medical device developers who interact with EHRs and other Health IT systems. The ECRI webpage is listed below.

http://www.ecri.org/press/Pages/Alarms-Health-IT-Patient-Violence-2015-Top-10-Patient-Safety-Concerns.aspx

Mobile Apps Versus Mobile Medical Apps

The FDA has updated the Mobile Medical Apps guidance on 9 February 2015 to be consistent with the MDDS final guidance.

In its final guidance for mobile medical apps, the FDA reiterates plans to actively regulate only certain subsets of mobile apps that actually qualify as medical devices. For the majority of mobile apps, which pose little risk to users, the FDA does not plan to enforce regulatory requirements. Only those mobile medical apps that do function as medical devices—referred to by the agency as mobile medical apps— will be more actively regulated in the US.

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf?source=govdelivery&utm_medium=e  mail&utm_source=govdelivery

FDA Finalizes Guidance Limiting Oversight of Certain Software Devices
On February 9, 2015, FDA issued a final guidance documentMedical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices,” in which the agency finalized a deregulatory policy for certain software devices. FDA’s new guidance document largely confirms the enforcement policies listed in the draft guidance document the FDA issued in July 2014.

The FDA states that it does not intend to enforce compliance with FDA regulatory controls, including registration and listing, premarket review, postmarket reporting, and quality system regulations (QSRs), for the following device types:

  • Medical device data systems (MDDS) (as defined in 21 C.F.R. § 880.6310),
  • Medical image storage devices (as defined in 21 C.F.R. § 892.2010), and
  • Medical image communications devices (as defined in 21 C.F.R. § 892.2020).

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM401996.pdf

FDA Recognizes Medical Device Interoperability Standards
The voluntary standards included under the FDA’s blanket recognition are as follows:

Medical Devices and Medical Systems – Essential safety requirements for equipment comprising the patient-centric integrated clinical environment (ICE) – Part 1: General requirements and conceptual model (ASTM F2761–09)

Systems and software engineering – Systems and software assurance – Part 4: Assurance in the life cycle (ISO/IEC 15026–4 First edition 2012–10–01)

Industrial communication networks—Network and system security – Part 3–1: Security technologies for industrial automation and control systems (IEC/TR 62443– 3–1 Edition 1.0 2009 – 07)

Application of risk management for IT networks incorporating medical devices – Part 1: Roles, responsibilities and activities (IEC 80001 – 1 Edition 1.0 2010 –10)

Application of risk management for IT networks incorporating medical devices – Part 2–3: Guidance for wireless networks (ANSI/AAMI/IEC TIR80001–2–3:2012)

FDA Adds Recognition for Several SW/HIT standards
FDA added the following standards to their recognized standards list and published the new recognitions January 2015.

IEC TR 80001-2-5 2014. Application of risk management for IT networks incorporating medical devices–Part 2-5: Application guidance–Guidance on distributed alarm systems.

IEEE Std 11073-10425- Health informatics 2014. Personal health device comunication, Part 10425: Device Specialization–Continuous Glucose Monitor (CGM).

LOINC 2.48 2014-06-27.Logical Observation Identifiers Names and Codes (LOINC).

Static Code Analysis

Static Code Analysis (SCA) is still a major issue and is being utilized by the FDA in more submissions than in the past. Please contact us for further details.

Software V&V Process
There are many companies putting off the software V&V process. This is a mistake as you can’t add quality to your software. The quality has to be built into the software from the requirements through the design. These companies think that they are saving money but, it is costing them money in the mid to long term. We highly recommend that companies start on the software V&V process early in the development and not later on.

Support Software Validation
According to the FDA and CE, all software used as a component, part, or accessory of a medical device, used in the production of a device, and used in implementation of the device manufacturer’s quality system require validation. These software applications include ERP, CRM, QA, PLM, ALM, PDM, LIMS, HPLC, CAD and CAM applications as well as all software in production equipment.

You may ask if the scope of the validations are the same for all of the application types. The answer is that the scope of the validations may not be the same and there may even be major differences in their scopes of validation.  This should be investigated.

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

Mike

Download the Full Update
Back To Top
Search