Information Technology, Databases, and Computers


20


Information Technology, Databases, and Computers



Any company that receives more than a handful of AEs, whether for marketed products or for products only in clinical trials, needs a database to collect, assemble, and report on these AEs. As the rest of the chapters in this book indicate, the regulations and reporting requirements are voluminous and follow tight standards in terms of content, format, and timing for reports to HAs. It is thus necessary to have an AE database that allows, at the minimum, either easy data entry manually and by E2B or a customized upload, preparation, and printing of MedWatch and CIOMS I forms and various other aggregate data reports for PSURs, IND annual reports, Development Safety Update Reports (DSURs) (soon), and NDA periodic reports as well as any other customized or national/local reports. Export capabilities are also necessary as E2B files or other customized exports. Many of the databases used for drug safety also allow for complex analysis and data mining of AEs, such as increased frequency and disproportionality calculations (see Chapter 19). Some have Eudravigilance export capabilities.



Many databases also have workflow and quality components built in with e-mail and messaging functionality. Some companies customize their databases, though more and more companies are buying one of the standard packages (“shrink-wrapped software”) available from various vendors. As databases get larger and larger and more and more complex, the ease and ability of transferring data from one database to another database becomes more difficult and costly. Thus, once a company commits to one database, it often will use that database “forever.” Mergers and acquisitions of the database company can produce significant headaches for the user community if the database is no longer supported or upgraded. This, however, is just the tip of the iceberg. Many more functions are needed for a modern drug safety department, especially if the department has worldwide data input and reporting obligations. This chapter reviews the issues and specialized needs around safety databases.



imagesRequired Safety Database Functionality


The following list represents a high-level view of the functions that a safety database must have to meet the needs of a multinational drug safety department. For smaller single-country departments, the needs may be somewhat less. There will surely be other requirements needed now or in the future that are not listed here. The ability to change and customize the database as requirements change is critical. Note there is some duplication and overlap among the sections below as some requirements are common to multiple areas.



  • Data Entry

    • Upload capabilities from other databases (e.g., phone center and clinical research databases) via E2B or other formats.
    • Case data entry to include all needed fields to produce a completed MedWatch form, CIOMS I form, PSUR, CIOMS line listing, E2B transmission, and so forth.
    • Tabular entry of laboratory data as well as manual entry.
    • Seriousness, expectedness (labeledness), causality at the case, and AE level by the investigator, company, CRO, others. (That is, multiple entries possible for causality in particular.)
    • Multiple narratives for the same case (e.g., short narrative, long narrative, non-English narrative, case comments, blinded narrative). Mechanism to handle follow-up information in the narrative (overwrite vs. append). Size limitations on the field.
    • Ability to handle multiple labels (e.g., Summary of Product Characteristics, U.S. Package Insert) producing different expectedness classification depending on label.
    • Ability to handle one or more reporters for a single case.
    • Versioning, with multiple versions possible for each case (e.g., by country).
    • Tracking of information in and out (case log).
    • Support of the Medical Dictionary for Regulatory Activities (MedDRA) (multiple versions and languages), WHO-ART (and other) drug dictionaries, as well as dictionaries for other functions (such as abbreviations, laboratory units, SNOMED, etc.).
    • Tight link to a MedDRA browser to allow easy coding.
    • Tight link to the drug database.
    • Ability to handle central and computerized lab data imports (uploads) with multiple normal ranges.
    • Handling of devices, drugs, biologics, medication errors, product quality complaints, blood products as needed.
    • Duplicate check for cases using multiple fields (e.g., name, postal code, age).
    • Ability to add fields as needed (e.g., new business partner case reference numbers).
    • Ability to close/complete a case and reopen it as needed.
    • Ability to have scanned source documents attached or linked to cases.
    • Required fields customizable by users.
    • Edit checks (e.g., system will not allow entry of data to show that a 50-year-old patient has a birth date of January 12, 2005, or that a male is pregnant).
    • Ability to handle clinical trial, spontaneous, solicited, named patient, literature, and other types of cases.
    • Ability to handle multiple doses of each drug (to account for starting, stopping, restarting, dose change, etc.).
    • Spell check in multiple languages.
    • Automated case narrative.
    • Ability to handle combination drugs, drug–devices, OTC, and so forth.

  • Work Flow

    • Ability to track and move a case through its processing using customized business rules set up by the users.
    • Communication ability at the user and case level (e.g., a reviewer can electronically ask a question of the person who entered the case data via email, SMS, etc.).
    • Version tracking of each case with multiple different versions existing simultaneously for a case (e.g., U.S. version 2, EMA version 3, Japanese version 4).
    • Metrics to measure status of groups of cases with groups customized by the user (e.g., each work team has its own metrics and management has aggregate metrics).
    • Duplicate checking and ability to duplicate a case or archive a case.
    • Ability to handle customized case identification numbering with each case having multiple numbers.
    • Multiple clock start dates (e.g., varies by country).
    • Follow-up letter generation to reporter or patient.
    • Correspondence tracking.
    • Returned product request and tracking.
    • Ability to use external software tools, bolt-ons, apps.

  • Administration

    • Customized access limits at user, country, group, case, drug level (e.g., France cannot read Germany’s cases, team handling drug X cannot see drug Y cases).
    • Security and passwords—21CFR11 compliant.
    • Scalability (able to add more users, countries, drugs easily).
    • International use (if needed).
    • Multiple language support.
    • Tickler (reminder) system.
    • Audit trails (full unless there is a clear reason not to have complete audit trails).
    • Validation.
    • HIPAA and European Union 95/46 (data privacy) compliant—ability to anonymize a case.
    • Tracking of submissions for expedited and aggregate reports to multiple HAs.
    • Case cannot be downgraded (serious to nonserious or unexpected to expected) without senior signoff.
    • A Japanese version with the ability to produce the appropriate E2B file (“the J file”) in the Japanese language.

  • Vendor Support and Information Technology Issues

    • User groups.
    • Support from vendor and internal IT colleagues at home-base and worldwide user sites.
    • Ability to customize when new regulations and requirements are put in place
    • IT support capability in-house.
    • Upgrade policy and support for older versions.
    • Hardware needs and compatibility with other hardware and software.
    • Backup system (e.g., every hour, nightly, weekly) with ability to reconstitute database contents within 24 hours in case of emergency.

  • Validation

    • A fully validated system and validation strategy in place going forward.
    • Change control in place.
    • Acceptable to United States, European Union, MHRA, and other inspectors.

  • Labeling Functions

    • The database should be able to store the AEs that are labeled/listed for each drug and formulation, and to identify which cases, based on the labeling, seriousness, and causality (for clinical trial cases), are 7- and 15-day reports to HAs in various countries, which go into PSURs, and so forth.
    • Labels for multiple countries should be storable and useable in this manner. Strategy on handling labeling in non-English languages.

  • Reporting Functions

    • Draft and final versions of all usual reports: MedWatch, CIOMS I, PSUR tables, listings, NDA periodic, and IND annual tables, Investigator Letters, cover letters to regulatory agencies in English or other languages with the agency address, case number and drug automatically inserted into the letter.
    • Other reports: United Kingdom Yellow Card, French inputability in French, English, and other languages.
    • Export to EudraVigilance for both clinical trial and postmarketing cases.
    • Ability to identify, based on algorithms that are entered into the database, which cases are 7-day and 15-day reports and which cases go into PSURs, NDA periodic reports, including follow-ups.
    • Ability to import E2B files and data from other database and place into templates (e.g., insert case numbers, drug name, and dates into MS Word documents).
    • Ability to query easily (e.g., Query By Example) on all fields to produce queries that can be made into reports without the need of a programmer to develop an SQL query.
    • Batch printing, transmission of MedWatch forms, or line listings of query or report results in PDF files.
    • Ability to save queries and reports at the user level.
    • Ability to do SQL queries.
    • Ability to anonymize reports and queries (e.g., no initials, no reporter names or addresses).
    • Eudravigilance reporting.
    • Epidemiologic, data-mining, and other reports using internal functions or add-on (“bolt-on”) tools.

  • Data Export and Import

    • E2B import with strategy on how to triage, flag, or “accept” a case before adding it to the database, especially if an earlier MedDRA version or different drug dictionary was used.
    • E2B export to multiple sources with automated receipt acknowledgment and multiple headers or content changes (e.g., different file for Japan, United States, and European Union for each case).
    • Automated transmission of cases based on business rules to internal and external recipients (e.g., a particular drug’s cases go to licensing company externally and recipients internally 10 calendar days after first receipt date).
    • Ability to generate other formats for data export (Excel, PDF, etc.).

  • Pharmacovigilance Functions

    • Note that some or all of these functions may be done by external software or databases separate from the PV/drug safety database. The external operations may or may not be tightly linked to the safety database.
    • Ability to produce pharmacovigilance reports and data-mining, both defined in the software and customized by the user.
    • Ability to use add-on statistical, epidemiologic, and other tools and reports
    • Drug usage data stored and used in queries and reports.
    • Ability to use a third party’s software.
    • Signal detection and trend analysis.


imagesDatabase Support

Only gold members can continue reading. Log In or Register to continue

Stay updated, free articles. Join our Telegram channel

Oct 1, 2016 | Posted by in GENERAL SURGERY | Comments Off on Information Technology, Databases, and Computers

Full access? Get Clinical Tree

Get Clinical Tree app for offline access