Good software engineering practices are essential during the FDA submission process, especially if the software is used in the development, manufacturing, or control of drugs/medical devices.
In plain English, these Good Practices ensure the software systems are safe, reliable, and compliant with regulatory requirements. On the other hand, poor software practices can lead to data integrity issues, security vulnerabilities, and product safety risks, all of which could result in FDA rejections, delays, or costly recalls.
In this section, we’ll introduce you to 7 Good Practices in Software Engineering (and 2 additional areas of focus) and discuss how we as a company implement them when working with Fortune 500 companies from the Pharma sector.
Good Development Practices
Your company’s development team should promote good development practices from day one. It’s the only way to build robust and reliable software in the long run. Without it, you’ll end up with workflows that make it easy to introduce errors, lose track of changes, and be inconsistent in general.
Below, we bring you 4 key areas to take into account.
Definition of Done (DoD)
Every task should be considered “done” in the same standardized way, as much as possible. You should define specific criteria that have to be met before a piece of code or a feature is considered complete, such as passing tests, code reviews, or being documented properly.
In other words, it’s a shared understanding between the Product Owner and the Development Team of what requirements need to be fulfilled before a piece of software can be considered complete.
Version Control
Version control systems like Git are mandatory. It allows you to track every change made in the software, enables multiple developers to work on the same simultaneously, and ensures traceability and accountability.
When it comes to FDA submissions specifically, this is crucial because every modification must be documented and recoverable in case of audits or inspections.
Find out more about Appsilon’s best practices regarding Git and Version Control Systems.
Code Review
Writing code is one thing, but before it’s considered “done,” it has to be reviewed by another, typically more seasoned software developer.
The practice of code reviews helps catch mistakes early and promotes high code quality standards. It also minimizes the risk of introducing alarming bugs that could compromise the product’s safety and integrity.
If you’re an R developer, these best practices will help you write clean code from the start.
Build Automation
Software builds should be consistent and repeatable.
By automating this process and keeping logs of previous builds, you can generate the same version of the software at any time, which is a critical requirement when submitting software for FDA approval.
Good Reproducibility Practices
In regulated environments, reproducibility is essential. The person on the other side of your submission must be able to replicate an exact version of the software you’ve submitted. There’s no way around it.
We believe these 4 key principles will help you bring your reproducibility practices to an enviable level.
Version Control
Put simply, it allows you to reproduce the exact state of the software from any point in the past. This is mandatory during FDA audits, where you may have to demonstrate how the software behaved at a specific time in development.
It also enables you to revert changes if needed.
Change Control
It ensures that every software modification is documented, reviewed, and approved before being implemented.
In the long run, change control prevents unapproved changes that could introduce risks or compromise regulatory compliance. It’s especially important in systems where changes could directly affect patient safety.
Dependency Management
Programming language čibraries and third-party packages have to be managed impeccably to ensure the software can be recreated exactly as it was originally designed.
You should strive to keep strict documentation on all versions of dependencies used in our software, so the environment can be replicated by the submission team.
Documentation
Comprehensive and clear documentation ensures that future developers or regulators can understand how the software was created and how it works. It allows anyone to reproduce the environment and run the code—even years after development with an entirely different development team.
Documentation typically includes user manuals, code comments, and architectural diagrams.
Good Software Validation Practices
Software validation ensures the software works as intended in all conditions, even the ones not predicted in the first place. When it comes to FDA submissions, a range of testing and verification techniques will help you build confidence into your software.
Verification and Validation (V&V)
In short, every phase of development has to meet specified requirements (verification), and the final product must perform as advertised in real-world conditions (validation).
Unit Testing
Changes made to one part of the code shouldn’t impact (or break) the others. That’s where unit testing comes in. It’s an automated process of testing every function in your code base. Sure, it’s a time-consuming process, but definitely not the one you want to glimpse through.
It might be difficult to believe for some, but writing proper unit tests will save you time in the long run. Why? Because you will run into fewer bugs and you’ll have to refactor your code less frequently. Note that we didn’t say “never.”
Integration Testing
This type of testing refers to the process of automatically testing every component in the system.
The goal is to see how the components react with one another and if any bugs need addressing. In the long run, integration testing prevents integration issues that might arise due to incorrect communication between different modules of your app.
End-to-End Testing
The goal of this phase of testing is to mimic the user experience and test the entire system, including user interfaces, APIs, databases, and so on – all done automatically.
This type of testing is particularly important for FDA submissions because you want concrete proof that your software works as a cohesive whole.
There are many ways to approach end-to-end-testing in R. Here are a couple of resources:
Manual Testing
There’s no doubt that automated testing is the way to go. But if your software can have many edge cases, it won’t get you 100% there.
Manual testing performed by QA experts is essential if you want to catch edge cases or potential usability issues that automated tests might miss.
Performance Testing
Poor software performance can lead to downtimes or failures, which can ultimately lead to catastrophes in highly regulated environments. It can also lead to FDA rejections.
The goal of performance testing is to ensure your app performs efficiently and can withstand extreme conditions, such as high traffic and huge volumes of data.
Risk-based Validation
Not every piece of software or every component is equally critical for the end product.
While you should test everything through the methodologies described earlier, you should prioritize components that directly impact product safety, quality, and performance.
If you’re working in the life sciences, this article will help you with R package validation.
Good Cybersecurity Practices
Pharmaceutical and medical sectors are sensitive in nature, so adequate cybersecurity practices are essential.
You should make sure your software is secure from vulnerabilities to protect patient data and data integrity. In this section, we’ll focus on 3 key areas you need to know when working on FDA submissions.
Vulnerability Management
You should regularly scan for vulnerabilities and perform software patches as necessary – that’s the only way to ensure the software remains secure.
If you’re working with medical devices or systems that store patient data, know that you’ll be a frequent target for cyber attacks, so take necessary precautions.
Validating Open-Source Packages
Open-source software offers many benefits, but when it comes to production apps with sensitive data in highly regulated environments, you should only use validated packages.
If possible, conduct security audits for third-party software you want to integrate into your system and make sure it’s free from vulnerabilities and it complies with FDA guidelines.
Secure Software Development
Common vulnerabilities like SQL injections, cross-site scripting (XSS), and buffer overflows can be easily prevented by following secure coding practices.
Good Access Control Practices
A key element of regulatory compliance is controlling who has access to which software and exactly what they can do with it.
In this section, we’ll explore 2 access control good practices.
Access Control (Role-Based Access)
Role-based access control is a good way to restrict who can access, modify, or review software code and data.
Only authorized personnel should be able to make critical changes. Without role-based access mechanisms, you’re risking unauthorized modifications that could jeopardize compliance.
Audit Trails
Every action taken within the software should be logged.
This way, you can identify who accessed or modified the system, code, or data, see what they did, and what was changed. Audit trails ensure complete traceability and accountability, which is a requirement for FDA submissions.
Good Documentation Practices
The benefits of good documentation are two-fold. First, it makes long-term software maintenance easier. And second, comprehensive and accurate documentation is mandatory for FDA submissions.
In this section, we’ll go over 3 focus points.
Complete Documentation
Your project documentation should include every software-related activity, from development and testing to validation. You should document every component and feature and leave no stone unturned.
This is a requirement by the FDA so they can verify that the software development process is thorough and compliant with regulatory requirements.
Understandable Documentation
Documentation must be clear enough for regulatory bodies to review. This includes detailed records of test results, code changes, risk assessments, and validation reports.
We have several articles that will eliminate all guesswork from the documentation writing process, and will highlight our best practices when working with Fortune 500 Pharma companies:
Helping with Reproducibility
Your code must work on other machines.
You should strive to write clear documentation, including manuals, readmes, and code comments that allow you and the reviewers to run the code on any machine.
Not only will this make the FDA submission process smoother, but it will also allow you to run the code many years later, potentially with an entirely different development team.
Good Data Management (Governance) Practices
Most medical and pharmaceutical companies deal with sensitive patient data. For this reason, it’s vital to manage data integrity, accuracy, and security.
This section covers 3 key points regarding good data governance practices.
Data Validation
Data should be accurate, complete, without duplicates, and consistently formatted across all systems.
This step is crucial because if you can’t trust your data, you can’t trust your product. All data generated and shown in your software must be reliable, especially when working in highly regulated environments.
Data Integrity
You should leverage mechanisms such as encryption and hashing to ensure data generated by your software is complete and secure.
These mechanisms are used to ensure data integrity and keep data intact and unaltered during storage and transfers.
Data Security
You should always protect confidential data, such as patient information, through advanced security measures. These typically include data encryption, access control management, and regular security audits (both discussed earlier).
Software Development Life Cycle (SDLC) Management
The term SDLC refers to the process that development teams use when designing and building software. Its goal is to minimize project risks through forward planning with the end goal of exceeding customer expectations during production.
There are several steps that go into SDLC:
- Defining Requirements: The project team gathers all needed requirements to understand the scope of the projects. This also includes regulatory requirements, which are critical for FDA submissions.
- Designing: In this phase, the project team creates a blueprint for how the software will work. This typically includes architecture design, user interface, databases, and overall system structure. It’s essential to design the system in a scalable and secure way so it can meet FDA requirements.
- Coding: This is the phase in which developers start writing code for the software using best practices such as clean code principles, version control, and more.
- Testing: It is an ongoing activity during SDLC, and includes unit testing, integration testing, end-to-end-testing, manual testing, and performance testing – all described earlier in the article.
- Validation: In regulated environments, validation ensures the software meets technical requirements and performs reliably in real-world scenarios. This includes validation testing that aligns with FDA guidelines and demonstrates the software is safe and effective for its intended use.
- Maintenance: Once the software is live, this phase ensures it continues to work properly. It includes bug fixes, implementing updates, and ensuring that any post-launch changes are compliant with FDA regulations.
Every phase of the SDLC must be thoroughly documented, as the FDA requires traceability from requirements to the final product.
Risk Management
This final phase is crucial when working on software for highly-regulated industries. In short, it ensures that potential failures are identified and mitigated before they become a real issue.
Risk management is typically split into two parts: risk assessment and FMEA.
Risk Assessment
All risks related to software development must be identified, assessed, and mitigated. To start, focus on risks that couple impact patient safety, product quality, or regulatory compliance.
Failure Mode and Effects Analysis (FMEA)
Think of FMEA as a key tool in any risk management strategy. It’s a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product/service.
The “Failure mode” represents the ways in which something might fail, while “Effects analysis” refers to studying the consequences of these failures.
If you’re building software for highly regulated industries, FMEA will help you prioritize which issues need immediate attention and will make sure that high-risk areas are thoroughly addressed.
Summing Up Software Engineering Good Practices
To recap, if your company creates software that’s used in the development, manufacturing, or control of drugs or medical devices, there’s no way around GSEP.
Ignoring them or devoting insufficient time typically leads to FDA rejections, delays, and even costly recalls, all because of data integrity issues, security vulnerabilities, and product safety risks introduced by poor software practices. GSEP might require some time to set up properly, but once done, you’ll have far fewer things to worry about.
Still, there are 7 of them! If your company needs assistance in implementing and following GxP, make sure to reach out to Appsilon. We’ve worked with multiple Fortune 500 companies and are happy to help.
How do you validate an R package in Pharma? Read our recent hands-on guide to see how open-source integrates with highly regulated industries.
The post appeared first on appsilon.com/blog/.
Related
 in FDA Submissions – 7 Categories to Follow){kind=link}