Implementing and Maintaining a Drug Safety System

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.^2-7

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,^1,6 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.^8,9 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.

Out of scope

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 approach

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

• user requirements and system evaluation

• installation and validation

• project management

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

• infrastructure environment and DSS set-up

• environment qualification

• system and workflow configuration

• system validation

• vendor assessment and audit

• operations and maintenance

• maintenance of DSSs and infrastructure

• operations of DSSs

• support of DSSs and safety departments

• regular upgrade of DSSs

• regular upgrades of underlying dictionaries.

Table V : Vendor audit costs.

Installation and validation

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.

Infrastructure environment

Many pharmaceutical companies are using

Citrix metaframe

(

www.citrix.com

) 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.

Table VII : System maintenance - annual costs.

The database server for a DSS requires a fail-safe or emergency server. If the infrastructure does not have a fail-safe, enough reserve capacity must be planned for the safety department to ensure that reports are submitted far enough ahead of regulatory deadlines to allow for system failure and time for recovery. Safety systems usually require powerful servers, although the database size is usually small (<10 GB), unless the company chooses to attach source documents as digitized images, in which case the size can grow substantially. The database must be backed up daily and the tapes stored in a secure, alternative, fireproof location.

Figure 2 : The basic network and systems infrastructure.

Security and validation

Personalized drug safety data are neither of specific value nor are their reporting extremely time-critical (15 day for alert reports). However, they contain very sensitive, personalized medical information (the reporting of which is excluded from the HIPAA regulations, but not the storage and processing) and as such, they put strict requirements on data security. It is recommended that an additional firewall is installed.

Figure 3 : Summary of installation, configuration and validation costs.

Because of the consequences of late reports, safety systems also have higher uptime requirements, particularly for restoration after a catastrophic failure. The entire drug safety infrastructure has to undergo IQ, OQ and performance qualification (PQ), and the respective change management procedures. An optimal standard safety systems environment that meets the basic security requirements is outlined in Figure 2.

Installation and qualification

To cope with all the requirements, it is advisable to implement a redundant database cluster connected to an external disk array with the clients served by two redundant metaframe or web servers. The database servers and disk array must accommodate at least three database instances, a production instance, a training instance (copy of production) and a validation instance. In addition, a backup solution must be in place. One possibility is a dedicated backup server with digital linear tape (DLT) tape-array, but less expensive solutions are also available. It is not recommended to try to economize on hardware and software because these are a small part of the entire cost, yet have the largest impact on performance and reliability. The DSS's licences as well as the ORACLE licences can vary by as much as 50% depending on the approach and the system. An outline for a typical DSS's infrastructure is shown in Table III.

Figure 4 : Summary of annual recurring costs.

Configuration and validation

Depending on the complexity of the company's product portfolio and the chosen workflow, configuration can differ significantly. Some effort is usually required to understand the system's capabilities and limitations, particularly in cases where reporting in more than one country is required. This effort can range from 2 weeks to several months. Once the process is understood, it usually takes between 4-6 h to configure lists and datasheets for one product and 24-48 h to configure a workflow. Validation is largely independent of the database size, but is dependent on the size and amount of standard reports. The greatest cost is the creation of PQ scripts. Most vendors sell a standard PQ script package, which usually has to be amended in-house. It is strongly advised to perform a "dry run" of the scripts to identify any inconsistencies or errors before letting users execute them. An outline for configuration and validation of a mid-size DSS is shown in Table IV.

Vendor audit

A vendor audit ensures that the safety system's vendor is aware of, and complies with, the appropriate FDA guidelines. It also ensures it is a well-managed company with a robust quality management system (Table V).

Figure 5 : Costs of SADRs/year by numbers of SADRs/year processed.

Installation and validation

The total costs amount to $515500 and, as previously stated, these costs could be significantly higher if more complex reporting was required from the system (Table VI and Figure 3). This is a substantial investment and could be unaffordable for a small and medium-sized enterprise (SME). It is important to note that the costs for installation, configuration, validation and the SOPs are as great as the hardware and software costs combined and, for more complex systems, could be greater.

Maintenance and operation

Maintenance and infrastructure. Most of the components mentioned require annual maintenance payments for upgrades, bug fixes and new versions, ranging between 15-20% of the list price. In addition, certain annual payments occur including off-site tape storage and licences for dictionaries such as MedDRA and WHODrug (Table VII).

^12,13

Operation and support. DSSs are support-intensive applications and support personnel should have in-depth knowledge of them and be an ORACLE database administrator (DBA). In addition, the personnel responsible for the system should understand the statutory and regulatory requirements of pharmacovigilance. Changes to the systems are not only regular bug fixes and patches, but more importantly regular updates to compound lists, datasheets and workflow components.

Table IX : Regular system upgrades.

Updates are required whenever a new compound licence in a country is acquired or changed; when package inserts change; or to comply with recent regulatory changes. For an SME these changes range from 2-10 per month and they usually require hours of work for implementation, testing and change control. In addition, complex reports usually require system support. The server and network environment needs standard operational support as does the customer support. On average, the systems, database operations and support require approximately 0.25 full time equivalents ([FTEs] equal to one person) of an ORACLE DBA/DSS specialist, while the server infrastructure itself requires approximately 0.25 FTE of a server administrator (Table VIII).

Systems and dictionaries

To keep current with rapidly changing regulations, safety systems must be upgraded as should the underlying dictionaries (Tables IX-XI). These upgrades are complicated and costly depending on the complexity of the drug safety database. System upgrades usually require an upgrade of the underlying infrastructure, the installation and configuration of the new version, and complete revalidation of the system. Then, the existing data must be migrated to the new system in a quality-controlled manner, requiring a statistically relevant random set of cases to be manually checked by a safety monitor (before and after) to verify successful migration.

Table X : Regular MedDRA dictionary upgrades.

The two main dictionaries for safety systems are based on the MedDRA and the WHODrug dictionary. Both publish regular upgrades every 6 months, and it is recommended to perform at least every second upgrade to stay current. Dictionary upgrades do not need to be co-ordinated with system upgrades, but are better scheduled around major quarterly or annual reports such as PSURs.

A MedDRA upgrade is usually performed in four phases

• analysis

• autocoding

• manual coding

• impact assessment.

During the analysis phase, a list of unique terms or whose assignments that have changed is created. Terms, whose text but not assignment or scope has changed are then automatically recoded, as are all so-called "direct hits" (verbatim equivalent to a lowest term level [the lowest hierarchy level in MedDRA]). The remaining unique terms must be manually recoded and the new codes re-entered into the system. A statistically relevant sample is then manually checked for verification and validation. The last step is an impact analysis on all reported cases for "open" PRs and PSURs. The upgrade of the WHODrug dictionary is usually much easier because it only impacts on the company's drugs; concomitant medications do not usually require substantial manual recoding and have little impact on the PSURs (Table IX). To simplify the total of annual recurring costs, it is approximated that one system upgrade and one upgrade of both dictionaries is performed per year (Table XII and Figure 4).

Table XI : Regular WHODrug dictionary upgrades.

Dictionary management

Most companies will also need a thesaurus tool to manage dictionaries and synonyms. Unfortunately, these tools are not yet part of most DSSs and must be evaluated, implemented and maintained separately.

Complete solution

TCO over 5 years; estimating the lifetime of a safety system to be 5 years, the TCO for this period (3000 SADRs/year) is calculated (Table XIII). As a comparison, the same costs for a department twice the size are also estimated, with additional costs in bold. Very large systems, processing more than 50000 SADRs/year, have a substantial cost advantage. The price per SADR for the processing system would drop to $40-$70 (Figure 5).

Table XII : Total annual recurring costs.

Conclusions

Tracking and reporting SADRs is an irrevocable business cost in the pharmaceutical industry. It keeps the drug franchise healthy, it complies with the regulations and it protects public health. However, implementing and maintaining a DSS is a much larger burden for an SME than for a large pharmaceutical company as it would cost the smaller company as much as five times more per SADR per year. Simple solutions usually cannot cope with the requirements for coding and reporting past a certain number of SADRs.

Table XIII : Total system costs for a 5 year lifetime and approximately 3000 SADRs/year.

The number of suitable "off-the-shelf" vendors is small and their costs are comparable as the highest costs are not for the licence, but for delivery consulting — mainly installation, configuration and validation of the system during set-up, and regular systems and dictionary upgrades during operations.

SMEs must carefully evaluate and plan their systems. It is advisable to negotiate licensing, maintenance and delivery consulting upfront and to acknowledge the large annual cost block in the operational phase.

As for other specialized systems solutions in the pharmaceutical arena (for example, customer relationship management, statistical analysis and visualization software), partnering with other companies or exploiting the outsourced provision of hosting services has become attractive, cost-effective alternatives for pharma SMEs.¹⁴ The fairly standardized business process of the drug safety discipline further facilitates this.

References

1.

www.fda.gov/OHRMS/DOCKETS/98fr/03-5204.pdf

2. www.fda.gov/ora/compliance_ref/bimo/ffinalcct.htm

3. www.fda.gov/ora/compliance_ref/part11/frs/background/11cfr-fr.htm

4. Code of Federal Regulations, Title 21, Food and Drugs, Parts 310, 312, 314, 600 and 601.

5. Code of Federal Regulations, Title 45, Department of Health and Human Services, Office of Civil Rights, The Health Insurance Portability and Accountability Act (HIPAA), Parts 160-164.

6. http://pharmacos.eudra.org/F2/eudralex/vol-9/home.htm

7. www.dataprotection.gov.uk

8. www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm

9. www.fda.gov/medwatch/report/051997.pdf

10. www.fda.gov/cber/gdlns/elecadverse.htm

11. Secure Sockets Layer, a standard protocol for transmitting private documents securely via the Internet.

12. www.meddramsso.com

13. www.who-umc.org

14. J.C.M. Wise, "Key R&D Informatics Challenges Facing Small/Medium-Sized Pharmaceutical and Biotech Companies," Drug Discovery World Spring (2002).