Uwe Trinks

The collection, investigation and monitoring of suspected adverse drug reactions (SADRs), and associated product use and complaint information, is a regulatory requirement for all manufacturers of pharmaceuticals for human use.

 This process, called pharmacovigilance or drug safety, appears to be fairly standardized between different pharmaceutical companies and usually contains the elements outlined in Figure 1.  

 Figure 1 : A simplified drug safety process (the parts in yellow are fairly standardized).			

The systems supporting these tasks must comply with a wealth of regulations, such as 

the US Food and Drug Administration's (FDA's) guidance for the validation of computerized systems

FDA's 21 CFR Parts 11, 310, 312, 314, 600 and 601

the Health Insurance Portability and Accountability Act (HIPAA, 45 CFR 160-164)

the "Rules Governing Medicinal Products in the European Union (Volume 9)" 

European "Safe Harbor Legislation," such as the UK data protection act.

These systems must fulfil robust requirements regarding validated availability and reliability; security and confidentiality; integrity; and access control and audit trails. They also require regular system updates (every 12-18 months) to cope with the changing regulatory requirements and routine updates of the underlying medical and drug dictionaries (6-12 months). Modern systems support the determination of "expectedness" and "seriousness" using code lists and data sheets, both of which require intensive maintenance.

 All these tasks make drug safety systems (DSSs) much more costly than would appear from a superficial examination of the software licence costs. 

Table I : A minimal set of SOPs to maintain the IT environment could look as follows.			

This paper will interest readers trying to decide if it is economically feasible to implement and maintain a state-of-the-art DSS. Small companies with a single or a few products with a very good safety profile will usually deal with the regulatory requirements for reporting SDARs using relatively simple solutions such as paper-based systems,

 spreadsheets or databases (although the latter two may not meet the regulatory requirements). As soon as the number of SADRs per year rises to more than several hundred per product, the preparation of periodic reports (PRs) or periodic safety update reports (PSURs) becomes cumbersome, error-prone and time-consuming.

 It is usually at this point that safety departments evaluate the installation of a state-of-the-art DSS.  

Currently, there are only a handful of such systems available, and at a high cost. As this analysis will show, the price of the licences and their maintenance is a small portion of the total cost of ownership (TCO). It is, therefore, advisable to choose functionality and not price when selecting a DSS. To capture the TCO for a DSS, all necessary components must be listed. However, some or all of these components might already exist in the company. 

Table II : Project and quality management costs.			

The majority of the costs for safety systems have little dependency on the size of the database, the size of the safety department or the required throughput. The few cost factors that do depend on these parameters are marked in the tables with a shaded field. Consequently, large pharmaceutical companies can justify the implementation costs of a DSS, whereas smaller companies have to carefully judge at what point it makes sense to install their own safety system, compared with a simpler less automated solution or an outsourced solution.  

This paper analyses structure, components and cost estimates for the installation, validation, operation, maintenance and support of a midsize DSS. It is assumed that the system supports a safety department of five associates with system access, processing approximately 3000 SADRs per year, covering approximately a dozen drug products and a repository of approximately 5000 SADRs already logged in the database. All installation and validation times are calculated at 2003 industry standard rates for expert consultants. Experience has shown that using in-house labour can prove expensive because of longer times for completion and additional training. 

Table III : An outline for a typical safety systems infrastructure including qualification. 			

Business costs such as workflow mapping, creating the regulatory information for the lists and data sheets, and user training are excluded in the estimates, as are basic information technology (IT) infrastructure costs and all non-safety specific network components such as routers and firewalls. The migration of the existing safety data to the new system is also excluded from these estimates because the magnitude and costs of the task vary depending on the data source and data quality.  			

The ability to support electronic submission and transmission of regulatory information (using Guidance on Data Elements for Transmission of Individual case Safety Reports [E2BM] and Electronic Standards for the Transmission of Regulatory Information [ESTRI]) is not addressed in this paper.

 Although very important, ESTRI adds significant complexity to the DSS. 

Table IV : An outline for the configuration and validation of a mid-sized DSS.			

Basic elements. The following elements must be addressed for the successful implementation and operation of a safety system:  					

creation, review, approval and training of IT standard operating procedures (SOPs)

infrastructure environment and DSS set-up

regular upgrades of underlying dictionaries.

Project and quality management. It can take an experienced team many months to install and validate a DSS. A company should allow at least 6 months from the initiation meeting to the go-live date and have a dedicated, full-time project manager. 							

An area often overlooked is quality management for the IT units supporting a drug safety department. Regulations require the IT department to understand and operate under a set of SOPs that define the internal business processes, and to keep appropriate records for auditing and inspection by the regulatory authorities (Tables I and II).  

Table VI : Summary of installation, configuration and validation costs.			

SOP best practice requires affected teams to be involved in their creation and review, which minimizes training and ensures the SOPs are effective. Those SOPs that are already in place must be reviewed and modified where necessary.  

) technology to make the client server systems easier to maintain, reduce validation costs, allow global operations and add an additional level of security. Such solutions can also allow terminals rather than PCs, further reducing maintenance and validation. For web-based systems, separate web servers running 128 bit secure sockets layer are recommended.

 The advantages of this set-up include  									

Running all the system's intelligence server-side, either on a web server or a Citrix metaframe, avoids the need for installation qualification (IQ) and operational qualification (OQ) on each individual workstation/terminal. All set-up, configuration and validation can be done server-side in a highly controlled, centralized and cost-effective fashion.

Reduced installation of patches and bug fixes.

Encryption of the traffic as well as the auditing capabilities of the firewall complies with European or US privacy legislation.

Both solutions support system access across wide area networks. 

Articles

The collection, investigation and monitoring of suspected adverse drug reactions (SADRs), and associated product use and complaint information, is a regulatory requirement for all manufacturers of pharmaceuticals for human use.1 This process, called pharmacovigilance or drug safety, appears to be fairly standardized between different pharmaceutical companies and usually contains the elements outlined in Figure 1.