GxP Support Services
While our work does not fall directly into the realm of (c)GxP, GAMP and other regulations we recognize and honor the need of our customers in the pharmaceutical industry to comply with these regulations. In order to support our customers in their dealings with the various GxP related regulations (GAMP v5, EU GMP guidelines (PIC/S - Annex 15), ICH, FDA cGMP, ...), we provide several specialized services:
- Qualification of the engineering method: review of scientific literature and calculation models (identification of CQAs and CPPs)
- Data & software integrity: we provide electronic signatures for the used software (including the complete source code) and all configuration files
- Data archiving: on customer request we can archive data and software on our servers on several, physically separate locations with access control and suitable backup services
- Change and configuration management: configuration and software customizations can be fully version-controlled
In contrast to closed source software, we provide the full digitally signed source code of the software in compliance with OECD GLP consenus document "Principles Of Good Laboratory Practice And Compliance Monitoring" about the use of computerized systems, point 8(c). If a CAPA or re-qualification is necessary, or if a check is required during an audit process, this change control makes it trivial to review past steps and/or start again from the most current state of the process. Proprietary software (COTS - commercial off the shelf) is in the field of CFD often used together with undocumented user defined functions (UDFs) thereby nullifying the often citet advantage of proprietary software: that it consists of immutable widely-used code (see more below about COTS software).
At Rheologic we use the well established commercial, open-source software package OpenFOAM produced by ESI which provides a number of advantages for our customers from the pharmaceutical and medical industries:
- The digitally signed source code of the simulation software is available and can be re-compiled easily in case of a hardware change or a change in the underlying operating system
- The software can be run without the need for external licenses or any kind of commercial fee
- The archived software is completely self contained: all necessary functions are included in the source code, there is no mix of closed source and user defined function that needs to be version-controlled separately
- All input parameters for various simulation scenarios can be archieved with full version control. All changes are trackable and can be re-constructed at any time.
Closed and open-source CFD simulation software
Two long established enterprises dominate the CFD software market: ESI with OpenFOAM and ANSYS with their ANSYS-Software (formerly: FLUENT). Both products are commercial software (see explanations at Wikipedia and here), but while ANSYS is proprietary closed-source, OpenFOAM is an open-source software. In terms of GAMP both products either belong to categories 4 or 5, depending on how they are used - with or without custom-programmed parts. In the GAMPS v5 classification category 4 software is software that is configured during use, while category 5 software is software customized by scripting and/or programming. While both, ANSYS and OpenFOAM are often used without custom-programmed parts, they are equally often extended with additional program parts (called UDFs in the case of ANSYS).
Independent of the classification of the software, the availability of the source code of OpenFOAM greatly simplifies the required change control and documentation procedures as well as validation / qualification processes. With the source code we can use a full fledged established version control system to control any and all changes of the software and all configurations and customizations. The closed-source ANSYS software does not provide this level of scrutiny. Additionally closed source software who's use is subject to expensive license fees is difficult to handle across upgrades. Last year's version of the software may not be even available any more and therefore - in addition to being expensive in itself - create additional complexity in (re-)validation processes.
There is a similar issue with configuration files (often called case-files in a CFD context): while OpenFOAM uses text-based, standard file formats, the closed formats (mostly in proprietary binary format) used by ANSYS are awkward to track and handle in a change control context. It is not guaranteed that today's configuration file will be accessible using tomorrow's version of ANSYS, while text files are very easy to handle in the same circumstances. Traceability and Change and Configuration management are easy, fast, secure and well established with text-based files and very hard to do with not openly documented proprietary file formats.
Consequently, there is no reason to generally exclude usage of OSS in regulated industries. Increasingly, OSS applications emerge that can be an alternative to commercial software. [...] Other regulated industries like aerospace companies are far ahead, already using OSS even in critical areas.
About COTS and OSS
COTS (commercial off the shelf) software is software that is widely used and can be bought "off-the-shelf" without any specific configuration for its intended use on the customers side. A prime example for this is the Excel calculation software by Microsoft. Using COTS software is sometimes wrongly perceived as being "more secure" owing the fact that the software is used by many people. However in practice the off-the shelf part simply means that not an external company is customizing the software for its intended use, but this is done internally, for examply by programming macros and vba scripts. In the pharmaceutical industry according to GAMP, this basically means that the software needs to be treated like any other custom-programmed software.
So taking the COTS approach for a reasonably complex task means, that not only does one have to treat it like custom programmed software from a QA perspective, but on top of that, part of the software is also closed source which makes things very complicated when the commercial supplier of the closed source part changes something - everything built on top of it runs the risk of not working at all anymore and certainly needs to be re-evaluated.
Conversely when using OSS (open source software) the entire source code is under control and all changes are completely transparent. Even if there should be a change in the underlying code base, it is trivial to fork the code and continue to use it. There simply is no supplier that could go out of business and cause trouble, obsolescence is not a topic for OSS.