What's going on?

How to save on repeated FDA systems validation using browser management software

The following blog was written by Andy Morton, previously Test Manager at a LGP (Large Government Project), the HMRC and Cable & Wireless. Andy is currently Service Delivery and Test PM for APPtechnology on a large Global Medical Diagnostics account.

His views relate to organisations that not only apply verification processes to their projects but undertake FDA Validation on web applications (systems) for FDA 21CFR and other regulations such as FDA 45CRF parts 160-164 (HIPAA).

“January 2016 sees the enforcement of the next IE version, with numerous Java version updates to deal with on the way…

How many times have you seen the dreaded Java update message appear when firing up a web page or web based app and all of a sudden your main browser has yet another update to plan, test and implement to your estate… Arrghhhhhh!!!

Both these issues are increasingly common challenges to be resolved within most companies worldwide. Web Apps (systems), pages and plugin’s, all have a set criteria and dependencies which are required to be implemented throughout a company’s estate across various devices.

In the majority of cases, these Web Based Apps need be verified and in some cases validated against the current Operating system build and core applications (Browser, Java, and Plugins). Here lies my challenge. When all testing phases have been completed and defects resolved against the deployed browser and plugin versions and a new version of ANY of the dependencies occurs. Now my verification and validation process will take more time, resources and cost :(

So why don’t I implement a browser management software solution, then these challenges can be minimised because multiple devices across the estate can run old browser versions to accommodate the various applications and dependencies running on them.

Another advantage I have discovered is that a browser management software solution just needs to be verified once and not per app, this is due to the solution being used as a vessel to deliver these systems. This in turn leads to less work and documentation which would occur if verification was executed per app. However if the actual app version changes then verification would still need to take place i.e. the verification documentation for the solution should be reused as part of the app version change in addition to the other verification documentation created for the actual version change.

Within the world of Validated Systems the single verification method mentioned above can also be implemented to assist with reducing time and costs. Therefore there would only be one single Installation Qualification (IQ) created for the solution, not per Validated System and if required Migration Qualifications (MQ) created or re-validated, depending on the changes to the app or system.

So, as I discovered, it is not as painful as you may think to have verified and validated versions of multiple browsers, Java and plugins deployed throughout your company’s estate, ensuring that the web based apps and systems function correctly.”

I am interested in:

Additional information: