Regulatory Open Forum

Stop looking, you don't need a guidance document. Just validate it.

Validate an Excel workbook to prove that it calculates correctly, not to satisfy some regulatory requirement. Develop some test cases with input data for which you know the result. If you have access to the formulas, include tests at the boundary conditions. For example, a "greater than" logic decision could have been put in place instead of a "greater than or equal to". This is positive white box testing.

You also conduct negative tests. Put in known bad data and check that the workbook recognizes it as bad and don't process it as if it were good.

As with any software validation, create protocols and reports, review and approve, and retain as quality records.

Stop looking, you don't need a guidance document. Just validate it.

Validate an Excel workbook to prove that it calculates correctly, not to satisfy some regulatory requirement. Develop some test cases with input data for which you know the result. If you have access to the formulas, include tests at the boundary conditions. For example, a "greater than" logic decision could have been put in place instead of a "greater than or equal to". This is positive white box testing.

You also conduct negative tests. Put in known bad data and check that the workbook recognizes it as bad and don't process it as if it were good.

As with any software validation, create protocols and reports, review and approve, and retain as quality records.

Stop looking, you don't need a guidance document. Just validate it.

Validate an Excel workbook to prove that it calculates correctly, not to satisfy some regulatory requirement. Develop some test cases with input data for which you know the result. If you have access to the formulas, include tests at the boundary conditions. For example, a "greater than" logic decision could have been put in place instead of a "greater than or equal to". This is positive white box testing.

You also conduct negative tests. Put in known bad data and check that the workbook recognizes it as bad and don't process it as if it were good.

As with any software validation, create protocols and reports, review and approve, and retain as quality records.

Stop looking, you don't need a guidance document. Just validate it.

Validate an Excel workbook to prove that it calculates correctly, not to satisfy some regulatory requirement. Develop some test cases with input data for which you know the result. If you have access to the formulas, include tests at the boundary conditions. For example, a "greater than" logic decision could have been put in place instead of a "greater than or equal to". This is positive white box testing.

You also conduct negative tests. Put in known bad data and check that the workbook recognizes it as bad and don't process it as if it were good.

As with any software validation, create protocols and reports, review and approve, and retain as quality records.

Stop looking, you don't need a guidance document. Just validate it.

Validate an Excel workbook to prove that it calculates correctly, not to satisfy some regulatory requirement. Develop some test cases with input data for which you know the result. If you have access to the formulas, include tests at the boundary conditions. For example, a "greater than" logic decision could have been put in place instead of a "greater than or equal to". This is positive white box testing.

You also conduct negative tests. Put in known bad data and check that the workbook recognizes it as bad and don't process it as if it were good.

As with any software validation, create protocols and reports, review and approve, and retain as quality records.

• Lock cells, formulae etc that must not be changed
• write an SOP including how to ensure authenticity and avoid accidental changes (load from template in a location you can not save changes to)
• Design a worst case challenge for key areas
• Work out the correct output from the spreadsheet (results of formulae etc)
• run some tests to confirm in all combinations of worst cases Excel does what you expect
• review your result - do they convince you everything is working as expected

• number rounding in calculations
• borderline classification on conditional formatting
• handling of spaces and special characters (accents etc in patient's name)
• handling in different revs of Excel an OS (test on pc, apple, iPad etc whatever may be use)

• 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); and
• Software used in implementation of the device manufacturer's quality system (e.g., software that records and maintains the device history record).

This document is based on generally recognized software validation principles and, therefore, can be applied to any software. For FDA purposes, this guidance applies to any software related to a regulated medical device, as defined by Section 201(h) of the Federal Food, Drug, and Cosmetic Act (the Act) and by current FDA software and regulatory policy. This document does not specifically identify which software is or is not regulated.

• Lock cells, formulae etc that must not be changed
• write an SOP including how to ensure authenticity and avoid accidental changes (load from template in a location you can not save changes to)
• Design a worst case challenge for key areas
• Work out the correct output from the spreadsheet (results of formulae etc)
• run some tests to confirm in all combinations of worst cases Excel does what you expect
• review your result - do they convince you everything is working as expected

• number rounding in calculations
• borderline classification on conditional formatting
• handling of spaces and special characters (accents etc in patient's name)
• handling in different revs of Excel an OS (test on pc, apple, iPad etc whatever may be use)

Regarding an Excel workbook used to calculate Key Risk Indicator metrics for the centralized monitoring of clinical investigation of products destined for the U.S., FDA may interpret that such metrics are part of the trial-monitoring records called for by FDA trial-monitoring regulations.  If FDA maintained such a stance, and if the associated records and signatures were electronic records/signatures, then 21 CFR Part 11 would apply.

In such an event, it's very important to remember that validation of the associated computerized systems (i.e., "software validation") is in fact a crucial element specifically demanded by Part 11 [but not to be confused with other similar (yet sometimes overlapping) software validation requirements like 21 CFR 820.70(i)].  Indeed, it would not be possible to comply with 21 CFR Part 11 unless its definitive software validation requirements are given due consideration.

This remains true regardless of any FDA enforcement discretion that may be applied.  For example, FDA Part 11 enforcement discretion guidance states that FDA nonetheless still expects that your decision to validate computerized systems (i.e., software) generating electronic records, and the extent of the validation, will take into account the impact the systems have on your ability to meet predicate rule (such as clinical trial monitoring record) requirements.  FDA told me that it will still take enforcement action if Part 11 record safety concerns are identified.

Remember also that for such Part 11 software validation, FDA specifically refers us to its guidance document on general principles of software validation and to GAMP.  Therefore, Anne LeBlanc's corresponding reference to FDA's guidance document is wise indeed.  Moreover, AAMI TIR36 [containing organic and distinct 21 CFR 820.70(i) and Part 11 validation guidance] wisely mentioned by Nicholas Wong was forged with key participation from FDA itself.  Accordingly, the dismissal of such longstanding guidance may not be in everyone's best interest.

Also, if the aforesaid workbooks are part of a trial Sponsor's or User's ISO 13485 quality management system, then the general validation for intended use of such workbooks would be demanded by that standard.  In that case, I've found ISO/TR 80002-2 (the international adaptation of AAMI TIR 36) to be quite useful for answering the specific questions Adam Beauregard raised.

On that note, it seems one final aspect of Adam's question may not yet have been answered (i.e., "…looking for something written for arguing that my workbook needs to be validated because it serves a certain purpose but that not all the workbooks we use internally need to be validated…").  For that, I leverage the GAMP 5 definition for Category 3 Off the Shelf, non-configured software which is generally exempted from validation by GAMP 5.  I also recommend leveraging and adapting the basic principle embodied by FDA's statement that "…validation would not be important for a word processor used only to generate SOPs…"

Hope this helps.

Regarding an Excel workbook used to calculate Key Risk Indicator metrics for the centralized monitoring of clinical investigation of products destined for the U.S., FDA may interpret that such metrics are part of the trial-monitoring records called for by FDA trial-monitoring regulations.  If FDA maintained such a stance, and if the associated records and signatures were electronic records/signatures, then 21 CFR Part 11 would apply.

In such an event, it's very important to remember that validation of the associated computerized systems (i.e., "software validation") is in fact a crucial element specifically demanded by Part 11 [but not to be confused with other similar (yet sometimes overlapping) software validation requirements like 21 CFR 820.70(i)].  Indeed, it would not be possible to comply with 21 CFR Part 11 unless its definitive software validation requirements are given due consideration.

This remains true regardless of any FDA enforcement discretion that may be applied.  For example, FDA Part 11 enforcement discretion guidance states that FDA nonetheless still expects that your decision to validate computerized systems (i.e., software) generating electronic records, and the extent of the validation, will take into account the impact the systems have on your ability to meet predicate rule (such as clinical trial monitoring record) requirements.  FDA told me that it will still take enforcement action if Part 11 record safety concerns are identified.

Remember also that for such Part 11 software validation, FDA specifically refers us to its guidance document on general principles of software validation and to GAMP.  Therefore, Anne LeBlanc's corresponding reference to FDA's guidance document is wise indeed.  Moreover, AAMI TIR36 [containing organic and distinct 21 CFR 820.70(i) and Part 11 validation guidance] wisely mentioned by Nicholas Wong was forged with key participation from FDA itself.  Accordingly, the dismissal of such longstanding guidance may not be in everyone's best interest.

Also, if the aforesaid workbooks are part of a trial Sponsor's or User's ISO 13485 quality management system, then the general validation for intended use of such workbooks would be demanded by that standard.  In that case, I've found ISO/TR 80002-2 (the international adaptation of AAMI TIR 36) to be quite useful for answering the specific questions Adam Beauregard raised.

On that note, it seems one final aspect of Adam's question may not yet have been answered (i.e., "…looking for something written for arguing that my workbook needs to be validated because it serves a certain purpose but that not all the workbooks we use internally need to be validated…").  For that, I leverage the GAMP 5 definition for Category 3 Off the Shelf, non-configured software which is generally exempted from validation by GAMP 5.  I also recommend leveraging and adapting the basic principle embodied by FDA's statement that "…validation would not be important for a word processor used only to generate SOPs…"

Hope this helps.