Software in Medical Devices – Update for Q1/Q2 2024 The past year, as in previous…
Software in Medical Devices – Update October 8, 2014
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 2014
Last update we noted the FDA report and recalls for the beginning of 2014. We have been following the recalls for 2014 and there were a number of recalls that are listed for 2014 where software played a role in the recall. The following are additional examples of recalls for 2014 involving software directly:
- ICU Medical, ConMed Stat2 Flow Controller – Delivers Higher Flow Rate than Intended.
- Diabetic Supply of Suncoast, Advocate Redi-Code+ BMB-BA006A Blood Glucose Test Strips – Labeling Error May Lead to Use of Incorrect Glucose Meters.
- Omni Micro-electrode/reference electrode for cobas b221 analyzer – The default references for normal values are inconsistent between cobas b 221 and other blood gas instruments. In addition, the reference ranges are different when comparing with corresponding ranges listed in the Instructions for Use for the analyzer and the reference literature source.
- GE Healthcare Carescape Patient Data Module – potential safety issue to the ECG calculations following a disconnect/reconnect cycle with the Patient Data Module, when used with the Carescape Bx50 monitors.
- McKesson Cardiology Hemo – Software Error: The McKesson Cardiology Hemo calculation section incorrectly converts the Hemoglobin value before it is utilized in the applicable formula calculations.
- Siemens Medical Solutions Ysio Systems – an unlikely error may occur on the Ysio system with fixed detector in the wall stand. This error may result in line artifacts in the image. If these artifacts appear in the region of interest, the examination may need to be repeated.
- Siemens CentraLink Data Management System – the issue may cause the software to stop executing commands, including uploading validated results to the LIS. The issue is related to an internal software timer that overflows after 24 days.
- Philips Medical Systems, Brilliance CT Big Bore – the system opens estop while sitting idle causing all movements and scan to stop. The problem has only occurred one time when the scan was out of Ready for Scanor scanning mode.
- Philips Medical Systems, Brilliance 64 and Ingenuity CT – during the recon during ready stage of reconstruction, images may be overlapped with, or superimposed on other images.
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.FDA Cybersecurity Final Guidance The final guidance, titled “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” recommends that manufacturers consider cybersecurity risks as part of the design and development of a medical device, and submit documentation to the FDA about the risks identified and controls in place to mitigate those risks. The guidance also recommends that manufacturers submit their plans for providing patches and updates to operating systems and medical software.
Software as a Medical Device
The IMDRF working group on Software as a Medical Device (SaMD) has a working draft of their final classification document and has submitted their presentation slides for the IMDRF meeting in Washington in September. It is interesting that in the current draft a standard alone software could be embedded in a medical device provided it is running on a general purpose computer platform.
http://www.imdrf.org/docs/imdrf/final/meetings/imdrf-meet-140313-sanfranpresentation-samd-framework.pdf
TIR 38 – Medical Device Safety Assurance Case Report Guidance
AAMI has circulated for vote the draft technical information report TIR 38, Medical Device Safety Assurance Case Report Guidance. The TIR provides guidance for the development of safety cases for the design of a medical device. It includes include a detailed but strictly hypothetical example from the medical device domain.
Medical Device Development Tools (MDDT)
Medical Design Technology (www.mdtmag.com) reports that the FDA’s Medical Device Development Tools (MDDT) program is a way for the FDA to qualify tools that medical device sponsors can use in the development and evaluation of medical devices. Qualification means that the FDA has evaluated the tool and concurs with available supporting evidence that the tool produces scientifically-plausible measurements and works as intended within the specified context of use. The context of use depends on the product area, the stage of medical device development, and the role of the tool in device evaluation. More information about the context of use is in the draft guidance on Medical Device Development Tools.
FDA Guidance Home Use Design Considerations
The FDA has issued the final guidance “Design Considerations for Devices Intended for Home Use” (August 5, 2014). Section VII, Design Considerations, addresses software by stating the following and then referencing IEC 62304 and FDA’s general software guidances: “Software plays a critical role in the operation of some devices. For these devices, you should focus on developing device and software architecture and algorithms for performance, error detection, control, and recovery. When developing a home use device, you should broaden your existing concept development and preliminary testing processes to account for the needs of home users and requirements for straightforward device operation, obvious interface layouts, and appropriate alarm methods. If software upgrades are required, you should consider how this will be performed in the home environment with the lowest risk to the user and least burden on you.”
FDA’s Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices
FDA issued a draft guidance: Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices. This draft exercises FDA enforcement discretion to essentially deregulate MDDS and Imaging Storage and Communication systems despite their classification rules. The guidance is at the link provided and proposes the new policy and provides specific wording changes to the Mobile Medical Apps Guidance to accommodate this change. The changes including deregulation of Mobile Medical Apps that serve as a secondary display of data rather than the primary device display such as an App for a doctor that receives data from a nursing station monitor.
Top 10 Patient Safety Concerns for Healthcare Organizations
The ECRI Institute published its Top 10 Patient Safety Concerns for Healthcare Organizations to give healthcare organizations a gauge to check their track record concerning patient safety. The list originally appeared in its Healthcare Risk Control (HRC) System newsletter, the Risk Management Reporter, and is reprinted in this report. The list is partly based on more than 300,000 patient safety events, custom research requests, and root- cause analyses submitted to our federally designated patient safety organization, ECRI Institute PSO, for evaluation and analysis. Please note that the number 1 issue on the list is data integrity failures with Health IT systems.
The ECRI Institute intends to publish its top 10 list of patient safety concerns on an annual basis and recommends using it along with ECRI Institute’s other two top 10 lists: list of health technology hazards and ar list of technologies to watch to stay informed in all areas of patient safety.
https://www.ecri.org/EmailResources/PSRQ/Top10/Top10PSRQ.pdf
AAMI TIR50:2014, Post-Market Surveillance of Use Error Management
AAMI has released AAMI TIR50:2014, Post-market surveillance of use error management. This document addresses the issue of use error detection for medical devices from the clinical, manufacturer, patient, user and regulatory perspective. The goal is to provide guidance on how these individuals can best collect, assess, and leverage post-market use error data to mitigate product risk, and to improve product safety and usability.
Can be purchased from AAMI at:
http://my.aami.org/store/SearchResults.aspx?searchterm=tir50&searchoption=ALL
Ford Recall
On Friday September 26, 2014, Ford was ordered to recall about 850,000 cars to fix a software glitch that could lead to a short circuit, delaying the deployment of airbags in the event of a crash. So its not only medical devices!
IEC 62304 Update
The update for the IEC 62304 (Software Development Life Cycle) has passed (SII has voted to approve it based upon my recommendation) and should be issued sometime in 2015. This update (listed as 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.
A capability assessment for meeting the standard should be released as a separate Technical Report late 2014. Edition 2 of the standard is in early draft stage in the committee and is expected to be released not before 2016.
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. SCA is an effective tool for cleaning up software bugs and enforcing your coding standard. Using a SCA on your code could free you from performing code reviews (if your SDLC Procedure covers it).
Accordingly, whether you are a high-risk project (Major LOC, PMA, 510/K De Novo, infusion pump, or any other special case) or not, you should use the SCA during the development phase, with or without formal reports. Also, if you are a high-risk project, we recommend that you use a FDA recognized SCA at around the code freeze to clean up the software and output a formal report to be sent to FDA as part of the submission.
We feel that in the future, the FDA will require the SCA report as a standard for all submissions (it saves them the trouble of asking for it and also asking for the source code).
mHealth App Developer Economics 2014
R2G has released its yearly study on the state and the future of mobile healthcare. The free report contains an in-depth market analysis on the current status and future impact of mHealth app publishing, a breakdown of different app stores, breakdowns of who is publishing mHealth apps today, the business aspect of publishing healthcare apps and outlook of how the market will look like in the future.
The report can be downloaded at:
http://mhealtheconomics.com/mhealth-developer-economics-report
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.
There are also many companies maintaining the software documents as an afterthought after preparing the software documents properly. This afterthought is not in accordance with the regulatory requirements and makes the software maintenance process difficult to show. We are still noticing Risk Analysis relating to software defects as a risk hazard cause. Potential software defects are not proper hazards as they do not yet exist. The only mitigation for this risk hazard would be to code review every line of source code.
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, 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
Related Posts
