DA Audit Completed in 90 Minutes Using SpiraPlan

March 18th, 2024 by Adam Sandman

Since SpiraPlan is considered a validated platform to plan, develop, manage and test solutions for the life sciences industry, we are required to undergo an annual external audit of our quality and security systems. This audit has to comply with 21 CFR Part 11 as well as the ISO:9001 and ISO:27001 standards. Normally a desk audit of a software provider like Inflectra would take about 5 hours. However because we use SpiraPlan ourselves, it only took 90 minutes, and even better, it ended with no observations or issues!

What is an FDA Desk Audit?

An FDA Desk Audit for a software company, particularly those operating within the healthcare, medical devices, or pharmaceutical sectors, involves a review process by the U.S. Food and Drug Administration (FDA) to ensure compliance with regulatory standards and requirements. This type of audit is focused on assessing the company's documentation, processes, software development lifecycle, quality assurance practices, and any other relevant procedures or records that pertain to the design, development, production, and maintenance of software that may be used in medical devices or health-related applications.

Here are key points about an FDA Desk Audit for a software company:

Documentation Review: The FDA will request and review various documents that the company should maintain as part of its quality management system (QMS) and software development processes. This can include software design documents, development and testing methodologies, risk management files, and change control records.
Compliance with Regulations: The audit checks for compliance with relevant FDA regulations such as 21 CFR Part 11 (Electronic Records; Electronic Signatures), 21 CFR Part 820 (Quality System Regulation) for medical device manufacturers, and guidance on software validation, cybersecurity, and software contained in medical devices.
Remote Process: Unlike traditional on-site inspections, a desk audit is conducted remotely. The FDA reviews the provided documentation and may follow up with requests for additional information, clarifications, or virtual meetings to discuss findings.
Purpose: The primary goal is to ensure that the software developed and used by the company in healthcare applications meets safety, effectiveness, and quality standards, protecting public health.
Outcomes: Following the audit, the FDA can provide feedback, identify areas of non-compliance that need to be addressed, and in some cases, it can lead to further actions if significant compliance issues are found.

For software companies in the health sector, preparing for an FDA Desk Audit involves ensuring that their documentation is thorough, up-to-date, and readily accessible, and that their processes align with FDA expectations and regulations. It's an essential part of regulatory compliance for companies that contribute to medical technology and healthcare services.

Simplifying FDA Audits With SpiraPlan

Normally when a software company has to prepare for an audit, it will mean creating a lot of extra documentation and paperwork. In addition, during the audit itself, the team will have to find data from multiple different systems to prove to the auditor that they have followed their processes, and that each requirement/feature has all the necessary supporting information. For example, without using SpiraPlan, a team would need to provide the following information:

The formal requirements for the system (which could be MS-Word documents, Confluence pages, Sharepoint documents, or a formal requirements system such as DOORS)
The software development activities and tasks, often stored in a tool such as Jira, Azure DevOps, or Trello.
The software code, pull requests, code reviews and documentation on what was released. This is often in a combination of tools such as GitHub, GitLab, BitBucket, and Jenkins
The company/product risk register, which is usually in an Excel sheet or similar format
The release checklists, retrospectives and reports that show what was developed, tested and verified in a release. This may be in Jira, MS-Excel or multiple separate places
The documentation for the product, including any release validation certificates and associated reports, typically stored in a document management system such as Sharepoint, OneDrive or Google Drive
The quality assurance plan and associated testing artifacts, which could be in a Jira plugin like Zephyr or a separate test management system such as TestRail or qTest (or Excel sadly!)
The list of any bugs/defects that were raised either by users or internally during testing for the release. These would be in a bug tracker such as Jira, Bugzilla, Mantis or Azure DevOps
Any change management requests for infrastructure or services. These might be in a tool like Jira/ServiceNow or in a simple spreadsheet.
Any customer complaints and how those complaints get handled within the company. If the complaints relate to the product, traceability for how those complaints become product features/changes. The complaints are often in a support system like ZenDesk, FreshDesk or Jira ServiceDesk.

Typically reviewing all this information (as well as supporting processes and policies) will take anywhere from 5 hours to a whole day (depending on the maturity of the organization). The auditor will often pick a specific requirement from a release and follow it all the way through the process. Similarly they will pick a random customer complaint and follow its progression through the systems to make sure it was handled according to the process. For this reason, our auditor scheduled a 5 hour meeting with us.

However, on the day itself, using SpiraPlan, KronoDesk and some additional tools such as GitHub and SecureFrame, we completed the audit in 90 minutes. This was mainly due to the powerful traceability, auditability and compliance features of the Inflectra suite. Instead of navigating all the different tools listed above, everyone was available seamlessly in a single pane of glass in real-time.

Tracing a Requirement

Our auditor reviewed our recent release Spira v7.12 and viewed the requirements backlog for the release, picking a requirement at random:

In this case, they picked requirement [RQ:4700] which was part of the release. They wanted to make sure we had well-defined requirements in line with our software development lifecycle (SDLC) process. We were able to easily show that we had a user story defined for each of the features, along with a set of BDD Gherkin style scenarios that describe the different use cases of the requirement:

Next they wanted to make sure that we were following our development processes, with all code changes associated with this feature clearly defined and all code reviews and branch merges performed in accordance with our SLDC. In SpiraPlan this was just a matter of clicking on the Associations tab to show the code commits associated with the requirement as well as the different builds. You can see that this feature was merged from its feature branch to the GitFlow develop branch and then prior to release, the main branch:

Our auditor wanted to drill down to see what specific lines of code were included in the commit and what had actually changed. This was as easy as clicking on the commit link inside SpiraPlan:

Choosing one of the three files, we were then able to drill-down one level further and show the specific lines that had changed in the commit:

If we wanted to view the code reviews and pull requests, they are also just a click away inside SpiraPlan:

In our case, we manage the pull requests inside GitHub and use the SpiraPlan data synchronization with GitHub to see all of them in one place.

Next we were asked to prove that this specific feature had been fully tested. By simply clicking on the Test Coverage tab we could show the tests that had been run (and passed) prior to release:

In this example we have one automated unit test that is executing daily against the code in question (as part of our normal DevOps pipeline) as well as one manual (functional) test that a human QA tester performed on the feature.

Viewing the Release Details

Next our auditor wanted us to show her what was included in this release (and used to generate our public release notes). By simply choosing the release in question, we could use the Reqs & Tasks tab to show her all the pre-planned features that were included in the release:

Similarly, by clicking on the Incidents tab we could show all the bugs and minor enhancements also included.

This is what is used to generate the public SpiraDoc release notes:

We also use the Releases in SpiraPlan to manage our agile retrospective process. This is how we continually improve the quality of our process.

At the end of every release we conduct a Zoom meeting to review the release and capture what we should:

Start doing
Stop doing
Keep doing

Generating Validation Documentation

Now that we had traced a single requirement from ideation all the way through to release and then shown how we capture all of the items that will be included in the release, the final step was to show where all of the generated validation document is stored. At the end of every release we run the following reports, and store them inside the SpiraPlan document control system:

Requirements traceability matrix for all features
Requirements detailed report for the release
Test case detailed report for the release

This means that we can show any of the generated validation reports (current or historical) at the click on a button in SpiraPlan:

We also use this system to store our Product Validation Certificate which is supported by these documents.

Tracing a Customer Complaint

The final part of the audit was to demonstrate how we follow our defined customer complaint process. We chose the example of a customer complaint regarding a custom reporting feature that did not work correctly.

This was one of the incident that was included in the v7.12 release page that we showed previously. Clicking on the defect in question:

We were able to show that this defect originated from a support ticket logged by a specific customer in our KronoDesk help desk:

By clicking on the hyperlink inside SpiraPlan we could quickly show the originating customer support ticket / complaint:

This was the evidence necessary to show that we follow our customer complaint process and there is a mechanism for corrective actions to be tracked and ultimately be reflected in the product.

Conclusion

As you can see in the screenshots, using SpiraPlan (and KronoDesk) allowed us to conduct our FDA desk audit in less than a third of the time it would take using other tools and platforms - a 300% improvement! The best thing about using SpiraPlan is that it allows to you conduct your everyday tasks faster and more easily than a hodgepodge of other tools, yet integrates seamlessly with your DevOps pipelines, test automation tools and developer IDEs. When it's time for an audit, with no extra work, you are audit-ready out of the box.