Whitepaper: Medical Device Software Development – Following FDA Guidelines for Software Validation

Developing software for medical devices compliant with the FDA’s quality system regulation is a challenging endeavor. Simplify the process with Parasoft recommendations and automated defection prevention solutions.

Learn how to overcome medical device software development challenges using an integrated SDLC approach.

Parasoft FDA Compliance Dashboard

Download the whitepaper for a point-to-point index of FDA principles and the Parasoft capabilities that support them.


Key takeaways:
  • Understanding FDA prescribed “Least Burdensome Approach”
  • Associated software engineering challenges
  • The role of policy-driven development
  • How Parasoft supports FDA principles of software validation
  • The General Principles of Software Validation outlines principles for validating medical device software and the software used to design, develop or manufacture medical devices, that the FDA considers acceptable.
  • Organizations that produce software within these categories are subject to FDA regulation and must comply with the General Principles of Software Validation.
  • Devices categorized as class II and III, as well as some class I devices, are subject to design controls. Of these, the following types of software must be validated for FDA approval:
    • Software used as a component, part, or accessory of a medical device
    • Software that is itself a medical device (e.g., blood establishment software)
    • Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment)
    • Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains the device history record)
  • The FDA recommends that medical device software development teams take a software development lifecycle (SDLC) approach that integrates risk management strategies with principles for software validation. This way, teams will place greater emphasis on planning, verification, testing, traceability and configuration management.
  • Developing software for medical devices that complies with the FDA’s Quality System regulation is a challenging endeavor. It’s a business issue as much as it’s an engineering feat.
  • In this approach, organizations control and stringently adhere to self-defined validation and verification processes.
  • Development activities and outcomes must be clearly defined, documented, verified and validated against the organization’s process. The goal is to give medical device makers the flexibility to determine how to best ensure public safety.
  • For some organizations, compliance burdens have only increased. The organization has become responsible for validating and verifying software with extensive testing and developing the basis upon which software is considered safe for use at the same time.

The best way to overcome these challenges while satisfying the FDA’s requirements for medical device software development is to operate the development process within a platform based on policy-driven development.

Policy-driven development involves:

  1. Clearly defining expectations and documenting them in understandable policies
  2. Training engineers on the business objectives driving those policies
  3. Monitoring policy adherence in an automated, unobtrusive way

 Parasoft solutions for medical device software development feature the fol­lowing technologies:

  • Code analysis configurations that enforce coding best prac­tices according to CWE, OWASP, MISRA and other sources
  • Integrated defect prevention, validation and verification
  • A continuous, policy-driven com­pliance process with real-time visibility
  • Correlation of all key artifacts, including tests, code and test coverage, requirements, source code, analysis violations, metrics analysis, project tasks, etc. for comprehensive requirements traceability

Software testing is one of many verification activities intended to confirm that software development output meets its input requirements. However, quality software can’t be delivered by testing alone. Quality software is delivered consistently via a solid, repeatable process, which requires an integrated system that assists with defining requirements, ensuring good coding practices and testing effectively. This process needs to be visible, measurable, and — most importantly — repeatable.

The following table matches several FDA principles with Parasoft features and functionalities that help organizations achieve compliance. For the complete index, download the white paper.

FDA principle Parasoft support
4.1 Requirements 
 
A documented software requirements specification provides a baseline for both validation and verification. 
 
The software validation process cannot be completed without an established software requirements specification.

 
• A system for mapping requirements to development tasks and monitoring the implementation and validation of each requirement. 
• An open API and out-of-the-box configurations for the most popular resource management and bug management systems and tools like Excel, Word and MS Project. 
• Requirements testing--highlights which requirements need to be tested. 
• Requirements traceability correlates requirements to iterations, tasks, code, tests, builds, and artifacts. 
• Graphical reporting of requirement status as indicated by developers. 
4.2 Defect Prevention
 
Software quality assurance needs to focus on preventing the introduction of defects into the software development process rather than trying to “test quality into” the software code after it is written. 
 
Software testing is limited in its ability to surface all latent defects in code. 
Software testing by itself is not enough to establish confidence that the software is fit for its intended use.
The industry’s most comprehensive automated defect prevention system. 
• A proven automated defect prevention system that can be implemented into any software development environment 
• Technologies that automate defect prevention practices to ensure their consistent and comprehensive application. 
• An automated infrastructure that drives the defect prevention process to ensure that it remains on track and does not disrupt the team’s workflow. 
• A system that monitors adherence to defect prevention policies. 
• Capabilities include: quality policy management, static code analysis (pattern-based, flow-based, metric-based), automated peer code review, contextual peer code review, unit testing framework, code coverage analysis
 
4.3 Time and Effort 
 
Preparation of software validation should begin early, i.e., during design and development planning and design input.
 
• Preconfigured FDA templates. 
• A central system that documents and defines requirements, expected tasks, timelines and outcomes — as well as manages by exception to ensure that the project is meeting expectations. 
• A continuous, end-to-end quality process that ensures defect prevention and detection tasks are not only deployed across every stage of the SDLC, but also ingrained into the team’s workflow. 
• A system that answers in real-time: 
-Will I be on time? 
-Will I be on budget? 
-Will I have the expected functionality? 
-Will it work? 

 

 

About Parasoft

Parasoft’s software testing solutions support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way. Parasoft's unique analytics platform aggregates data from across all testing practices, providing insights up and down the testing pyramid to enable organizations to succeed in today's most strategic development initiatives, including Agile/DevOps, Continuous Testing, and the complexities of IoT. Parasoft’s automated software testing innovations fuel software development organizations, helping teams reduce the time, cost, and effort of delivering high-quality software to the market.