I am seeing a growing trend of 100% electronic documentation for verification and validation. Software-based devices are leading the trend, but the requirement to provide traceability between design inputs/outputs and V&V testing is pushing companies to automate the documentation and streamline the approvals.
Some companies are going a little too far and lacking sufficient documentation explaining what the tools are intended to do, but this is a more efficient approach that becomes possible when you learn to document and validate the tools. It's especially convenient for releasing patches for bugs that modify the software code, but will not require 100% of re-execution of the V&V testing and may not require a new regulatory submission.

Thanks for the reply Rob. What would your definition of "electronic documentation" cover? I will use a Requirement Specification as an example. If a software tool is used to write, review and approve (each individual) requirement. Is there then a need to PDF and attach to the DMS, it would just be leg work for the sake of it! It is good to hear that there is a growing trend and agree that sufficient documentation is required to verify the tool is fit for purpose and that adequate tracing is performed.

My definition of "electronic documentation" includes protocols, test reports and the raw data from executing protocols. In your description you state, "software tool is used to write, review and approve (each individual) requirement." However, that tool needs a protocol, report and data to demonstrate that the tool itself has been validated. In addition, summaries of the results from using the tool are typically created in a combination of manual and automated reports and reviewed and approved by another person(s). The FDA and auditors want to know how many times you had to repeat the verification tests and debug software before 100% of the unit tests pass. Then the cycle is repeated for integration testing, and finally for system testing. I see lots of automated tools being used for unit test cases, but the automation of system tests is rare.

For whichever tool we choose, I would ensure that it is validated for the purpose that we require.
We are currently looking at tools for automation testing, this would be separate from our requirements / quality system and again this would be subject to tool validation.

Just to close out the pdf question. As long as there is a validated tool for e-signature and a history/audit trail, there is no reason why one must store those instances in .pdf format. That being said, each instance of 'approval' (and it's change summary/rationale) must remain available (for both design history evaluation and audit).
Rob, does this also align with your point "The FDA and auditors want to know how many times you had to repeat the verification tests and debug software before 100% of the unit tests pass."?

Christine, yes it aligns with my point. To clarify, records of results from design verification must be retained. Therefore, any software verification performed to patch a bug must have records of the verification test results included in the DHF--not just the approval of the change.