Warning Letter: Failure to validate computer software (ucm399519)

Failure to validate computer software for its intended use according to an established protocol when computers or automated data processing systems are used as part of production or the quality system, as required by 21 CFR 820.70(i). For example, during the inspection your firm confirmed that its software program [redacted] version [redacted] released on August 28, 2009, for documenting condom production control tests has not been validated for its intended uses.

View the original warning letter.

FDA Mobile Medical Applications Guidance

“Mobile Medical Applications Guidance for Industry and Food and Drug Administration Staff”, issued by the FDA in September 2013, provides insight to the FDA strategy for overseeing mobile medical applications. If a mobile application is classified as a medical device, it will receive the same FDA scrutiny as currently regulated medical devices, requiring appropriate validation.

Key Points in the Guidance

There are several regulatory requirements that mobile app developers need to consider in their design, development, and marketing strategies:

How you market your app defines whether it constitutes a device.

“When the intended use of a mobile app is for the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or any function of the body of man, the mobile app is a device.”

Mobile medical apps are those having the intended use of:

1. connecting to one or more medical devices to control or otherwise extend device functionality,
2. transforming the mobile platform into a regulated medical device via connected peripherals or included medical device functionalities, or
3. converting the mobile platform into a regulated medical device by providing patient-specific analysis, diagnosis, or treatment recommendations.

FDA focus is on device functionality and risk, not on the platform. Devices subject to regulatory oversight are ones that pose a risk to patients should they fail to operate properly. Manufacturers are expected to comply with regulations for the appropriate device class, including appropriate Quality System controls, cGMP, and 21 CFR 11 requirements.

Qualifying Devices

The FDA intends to focus its enforcement on medical applications with immediate potential health effects. This includes apps that measure or record patient-specific information and exhibit a high potential for risk if they don’t function properly. Example mobile medical apps that merit FDA oversight include those that:

• use a sensor or lead connected to a mobile platform to measure and display, amplify, record, or analyze physiological parameters for diagnostic purposes. Examples: electrocardiograph (ECG), electroencephalograph (EEG), electronic stethoscope, CPR feedback monitor, nystagmograph¸ tremor transducer, limb accelerometer, blood oximeter, or glucometer
• produce controlled tones or signals using tools within the mobile platform (e.g., a speaker) intended for use in diagnostic evaluations of possible otologic disorders (e.g., an audiometer)
• present donor history questions to a potential blood donor and record/transmit responses for a collection facility to determining donor eligibility prior to collection of blood or components
• alter the function or settings of an infusion pump, blood-pressure cuff , implantable neuromuscular stimulator, cochlear implant, computed tomography (CT), or X-Ray machine
• connect to bedside (or cardiac) monitors and transfer data to a central viewing station for display and active patient monitoring

Enforcement Discretion

The FDA has listed a number of mobile medical apps for which it intends to exercise “enforcement discretion” due to low risk imposed on patients. Although these may constitute devices and/or be marketed for diagnosis, cure, mitigation, treatment, or prevention of disease or other conditions, the FDA does not intend to enforce requirements under the Federal, Food, Drug, and Cosmetic Act. Example devices:

• provide educational information, reminders,  planning, or motivational guidance in support of therapy, medication, or healthy behaviors
• use GPS information to advise of environmental risks
• track, trend, or store diet, health events, behavior triggers, symptoms, or health metrics data
• record conversations with medical professionals for later access
• use patient characteristics or symptoms to help recommend or a locate a  health provider
• initiate emergency calls or alert first responders

In spite of the provisions for enforcement discretion, FDA still strongly recommends adherence to Quality System regulation for all medical device software, even that which poses low patient risk. The guidance cites a nine-year FDA study indicating that over ninety percent of software-related device failures were generally due to failure to validate software prior to production.

Some apps are not regulated by the FDA. These would include apps that:

• are not intended for medical or health-related use
• present commonly available information for general education
• present reference or review material for trained professionals
• perform or automate common office tasks
• function as generic aids or general purpose products

Final Thought

With mobile medical applications, software validation remains an important means of guaranteeing product consistency and accuracy of results. It simplifies the risk equation by actively exploring the design integrity of the application and reinforces market-readiness.

Let us help you ensure safe, reliable products. Contact us to find out more about validating your mobile medical applications or with any questions you have about regulatory compliance.

Warning Letter: Medical device company failed to validate computer software (ucm 355751)

Failure to ensure that all inspection, measuring, and test equipment, including mechanical, automated, or electronic inspection and test equipment, is suitable for its intended purposes and is capable of producing valid results, as required by 21 CFR 820.72(a). For example, your firm’s design verification procedure does not require that test equipment and software are fully validated, as needed, and prior to use in design verification activities.

View the original warning letter.

Warning Letter: Missing Validation Testing (ucm 359625)

Your firm does not have a design history file (DHF) for the Meridian DR 200 single panel X-ray system. The system is comprised of a workstation, flat panel detectors, acquisition software and X-ray hardware. Missing elements of the DHF include:
• A design plan for the project
• Established or approved design inputs/outputs for the system
• Verification or Validation testing for the system
• Design Transfer
• Risk Management for the system
• Design Reviews.
Your firm does not have procedures to describe the content of your Device History Records (DHR’s). In addition, eleven of eleven DHR files reviewed showed that all were incomplete as the only record in the files was your testing of the flat panel detectors, which is only one part of the X-ray system. The DHRs do not include installation records; records of any non-conformities; records regarding the X-ray hardware, workstation or acquisition software; or records of final product testing and quality release of your systems.

View the original warning letter.

Warning Letter: Firm not reporting all electronic results obtained (ucm 361553)

We observed and documented practices during the inspection that kept some samples, data and results outside of the local systems for assessing quality. This raises serious concerns regarding the integrity and reliability of the data generated at your Kalyani plant. For example,

a. Our review of the Chromeleon and Empower II software found that your firm was testing samples unofficially, and not reporting all results obtained. Specifically, “test,” “trial” and “demo” injections of intermediate and final API samples were performed, prior to performing the tests that would be reported as the final QC results.

b. Out-of-specification or undesirable results were ignored and not investigated.

c. Samples were retested without a record of the reason for the retest or an investigation. Only passing results were considered valid, and were used to release batches of APIs intended for US distribution.

d. Unacceptable practices in the management of electronic data were also noted. The management of electronic data permitted unauthorized changes, as digital computer folders and files could be easily altered or deleted.

View the original warning letter.

Warning Letter: Hospital stretcher manufacturer failed to validate computer software (ucm 355751)

Failure to validate computer software for its intended use according to an established protocol when computers or automated data processing systems are used as part of production or the quality system, as required by 21 CFR 820.70(i). Specifically, [redacted], developed by [redacted], is used to transfer and make changes to drawings used to manufacture devices. There is no protocol or documentation demonstrating that this software has been validated for its intended use.

View the original warning letter.

Warning Letter: Failure to implement software upgrade (ucm 352318)

CAPA [redacted] was opened on May 25, 2011 to address Plum A+ pump battery failures which can cause a delay or interruption of critical therapy. Your firm has failed to  implement the identified corrective actions in this CAPA, such as a software upgrade to change the risk profile; battery replacement to reduce the probability of occurrence; battery supplier approval with increased controls; and notification to customers, despite the fact that your firm has received 311 complaints for code E321 documenting battery failures and 11 MDRs documenting a stoppage of critical drug delivery as of January 31, 2013. Plum A+ infusion pump: Review of the “analysis” data field for Plum A+ complaints revealed failures of the bubble sensor printed wire assembly within the printed circuit board, battery, touch key pad assembly and front case assembly.

…

In addition, the failed components are not identified as a data source for analysis nor are they trended in your CAPA system to assess whether a preventive or corrective action is indicated and to ensure that components are performing according to infusion pump design specifications.

View the original warning letter.

Warning Letter: Failure to document changes (ucm 348651)

During our inspection, a Red Blood Cell component was identified as being in quarantine according to an electronic inventory inquiry on January 30, 2013. However, the component could not be located in the expected physical quarantine location. After the discrepancy was identified by our investigators, a search was initiated and the component was found in the discard bin. The component had been physically discarded without maintaining a record of the discard as required by TS 500-2, Final Disposition of Blood Components. Failure to check input to and output from the computer or related system of formulas or other records or data for accuracy [21 CFR 211.68(b)].

View the original warning letter.

Warning Letter: Labeling software is not defined in SOP (ucm 352769)

Your firm’s product labeling procedure has not been adequately implemented as required by 21 CFR § 820.120. Specifically, you lack documented approval for your vacuum therapy device; labeling software is not defined in your standard operation procedure; and device history records lack the primary label/labeling.

View the original warning letter.

Warning Letter: Failure to follow procedure (ucm342736)

Failure to establish and maintain adequate procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device’s design development, as required by 21 CFR 820.30(e). For example, the design control procedure (P03 02) requires that design reviews be completed at the end of the completion of all technical documentation. The design review for the Lady Comp device was completed June 16, 2008, prior to the completion of the software qualification for the Lady Comp device, which was completed October 17, 2008. No design review was conducted after the software qualification. The adequacy of your firm’s response, dated October 26, 2012, cannot be determined at this time. Your firm completed a new design review for the Lady Comp device that included software validation. Additionally, your firm stated that training would be conducted on the current design review procedure. However, the evidence of implementation to include the training documentation was not provided in the response.

View the original warning letter.