Computer Chemistry Consultancy - XML4Pharma, Katzelbachweg 18, A-8052 Thal, Austria,

Web enabling and Validation for Pharmaceutical companies

Within Pharmaceutical companies, software must be validated in many cases, as software errors can result in a risk for human health (search the websites of the FDA and EMEA for specific guidelines for specific applications).
Computer Chemistry Consultancy has a good amount of experience with the special requirements that authorities have for software in a pharmaceutical environment.

From our practice, we have observed that web-enabling makes validation of an application much easier:

  • In a web-based system, every user is using the same version of the software
  • Only the (web)server has to be validated, not the individual PC's (the user only uses a browser)
  • When using applications located on individual PC's (classic client-server system), applications can (erroneously) interact, leading to false results (e.g. the DLL replacement problem).
  • On the working place, PC's can be replaced by (much) cheaper, light browser-terminals, which do not have to be validated or where the validation is much easier than for a PC.

Ultimately, web-enabling makes validation easier

With our experience in the Pharmaceutical Industry, Computer Chemistry Consultancy can advice you on how to develop and implement web-based, validated applications.

When developing web-applications, in order to have our software "validation-friendly" we use the following methodologies:
  • The classic model: starting from the "User Requirements" (UR) a "Functional Design" (FD) is made, describing all the functionality the application must have. This is then used to construct a "Technical Design" describing how the requirements from the UR and FD will be technically realised. These documents are then used to actually build the application. For validation purposes, also a test protocal need to be written. It describes the tests that the software has to undergo successfully in order to get a validated status. Then the tests themselves have to be performed and documented. If all this is done and all documents are available, the software can be validated.
  • The RAD model (Rapid Application Development model). This is a very different way of working: Starting from interviews with the commisionars and future users a prototype is build. The users then test the prototype and steer the further development very actively (e.g. by weekly users - developers meetings). A strict timeframe is usually present for each of the modules. RAD means that all documentation is constantly updated. It also requires a serious envolvement from the commisionars and the future users (which is often lacking in the classic model). Constant updating of documentation seems to be a nightmare for developers but isn't if the following modern development methods are used:
  • Design by Contract (DBC): the software is constructed modular (and object oriented) with each module (class) having a contract. A contract means that it is strictly described what the module delivers under which conditions and within which limits. The contract itself is described within the software, and can easily and automatically be derived from the software into a separate document. More information about and an excellent introduction to "Design by Contract" can be found here.
  • Writing software documentation within the software. Some programming languages like Java enable to add comments in the source code which can then be automatically retrieved to generate the API (Application Programming Interface) which can easily be converted to the software documentation. For example in Java it is good practice to add special comments just before each class declaration and each method declaration. Using "javadoc" the documentation (API) is then automatically retrieved and put into an HTML file.
    This good practice frees the developer from writing separate documentation. Moreover, if additionally a source version controll system is used which generates the javadoc, the documentation is always up-to-date. Click here for an example.

Computer Chemistry Consultancy, June 2001

Note: User Requirements

Computer Chemistry can also help you with setting up "User Requirements". We then perform interviews with the commisionars and the future users, and prepare a "User Requirements Report", which of course has to be approved by the commisionars. Our knowledge of Chemistry, Pharmacy, and of Informatics makes us very competent in this area.

Note: The DLL replacement problem

Think about a software installation that installs a new DLL-file, whereas another program is (also) using the same DLL-file: the old program will now use the new DLL whereas it should use the old one. Is there any guarantee that both DLL's do the same ? Does anyone realise that something has changed ? Probably not !