Meeting FDA Regulatory Requirements While Programming PLCs

by | Oct 9, 2020 | FDA, Medical Devices, PLCs, Programming, Quality, Regulatory, Requirements

Programmable Logic Controllers (PLCs) are the components that are used for interfacing between multiple hardware devices or between a software and a hardware component. PLCs prove to be useful in mission-critical industries where a process is automated, facilitating increased productivity, reliability, and reduced or elimination of labor for device control. PLCs are used in numerous applications in the medical and health field including in the chemical and pharmaceutical industries.1 When used in health care services, these PLC-based devices should meet the FDA regulatory requirements before they are released in the market.

PLCs generally comprises of the I/O, power source, peripherals, and the CPU modules. These modules can be programmed in five programming variants such as Ladder Diagram (LD), Structured Text (ST), and Instruction List (IL). Being a part of the software, along with the hardware, the product should be documented, verified, validated, and tested from a quality and safety perspective. These regulatory practices are provided by FDA and manufacturers should follow protocols like Title 21 CFR Part 11 which regulates electronic records and signatures. Such protocols include elements of best manufacturing practice from a programming perspective and focus on shrewd software management practices such as design review, document control, risk management, and remediation activities.

Every software should be verified and validated irrespective of the device risk categorization class. In the case of PLCs, as they are built using hardware components, verification and validation are quite distinct. Verification applies to the regulation at the unit level such as verification of software requirements. These may include unit-level test cases along with the verification or review of the software architectural design. In Validation, the product may be tested at the system level, that is, when the product is completed and ready for system and integration testing. Risk related requirements indicate the safety-related measures and must be logged in documents such as hazard analysis and risk management plans. The major target of verification and validation is to achieve the intended use ensuring the manufacturer has added measures to ensure PLC device safety and efficiency.2

PLCs may require programming changes in which manufacturers should record the changes using document control strategies such as software versions and software change logs. Also, they should test if the changes in specific program files are affecting a group of program files or the entire system. Using Design Control methods and testing such as regression with integration testing, manufacturers can demonstrate the software meets the intended use.2 In the end, if the product is found to be FDA compliant, it may be approved through 510(k), Premarket Approval (PMA), or the De novo (low to moderate risk-based devices) pathway based on the class of the device.3

To summarize, PLCs make human life easier by automating the industrial process. Also, it is a platform that enables hardware communication with software and therefore should be FDA compliant, which involves design documentation and system verification/validation. Do you have a PLC-based system that needs FDA approval? Our software and regulatory experts at EMMA International can help ensure your system is FDA compliant. Contact us at 248-987-4497 or info@emmainternational.com  for additional information.


1Daron Underwood. (August 2017). Understanding Software PLC Features and Requirements. Retrieved on 10/5/2020 from https://kingstar.com/understanding-soft-plc-features-requirements/.

2FDA (January 2002). General Principles of Software Validation; Final Guidance for Industry and FDA Staff. Retrieved on 10/07/2020 from https://www.fda.gov/media/73141/download.

3FDA (November 2014). Computerized Systems in the Food Processing Industry. Retrieved on 10/8/2020 from https://www.fda.gov/inspections-compliance-enforcement-and-criminal-/investigations/inspection-guides/computerized-systems-food-processing-industry-0.

 

Govind Yatnalkar

Govind Yatnalkar

More Resources

FDA Adverse Event Reporting 

FDA Adverse Event Reporting 

When reporting an Adverse Event to the Food and Drug Administration (FDA) the best method is to utilize the FDA Adverse Event Reporting System (FAERS). FAERS is a database that contains adverse event reports, product quality complaints that led to an adverse event, and medication error reports1. All FAERS reports are easily accessible to the public. 
De Novo Classification

De Novo Classification

A device can be registered for the De Novo pathway if there is evidence of the safety and effectiveness of the device and there is not a previously legally marketed predicate device1. When determining if your device can go through the De Novo process there are two pathways available to determine the device classification.
Abbreviated 510k submission

Abbreviated 510k submission

There are three types of 510K, Premarket Notifications, which can be submitted to the Food and Drug Administration (FDA) traditional, abbreviated, and special. Abbreviated and Special 510K submissions can be utilized when the submissions meet the certain factors presented by the FDA. When submitting an abbreviated 510K the submission must include the elements that are identified in 21CFR 807.87 for the information required in a premarket notification submission.

Ready to learn more about working with us?

Pin It on Pinterest

Share This