Добавил:
Sekretar
kiopkiopkiop18@yandex.ru
t.me/Prokururor I Вовсе не секретарь, но почту проверяю
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Ординатура / Хирургия / Библиотека им академика М.И. Перельмана / Книга_5432_Библиотеки_им_академика_М_И_Перельмана.pdf
370 Cobert’s Manual of Drug Safety and Pharmacovigilance
https://www.fda.gov/drugs/guidancecompliancereg-
ulatoryinformation/surveillance/adversedrugeffects/
ucm082196.htm.
Approved Risk Evaluation and Mitigation Strategies
are available at https://www.fda.gov/drugs/drugsafety/
rems/default.htm.
Finally, FDA was required by the Food and Drug
(FDAAA) of 2007 to do a periodic review of new drugs
(New Molecular Entity Post-marketing Safety Evalua-
tion), looking at all data within 5 years of first approval.
The FDA also has databases containing clinical
trial information as well as drug-specific information,
including labeling for approved drugs.
The Uppsala Monitoring
Centre
The Uppsala Monitoring Centre maintains one safety
database and two coding “dictionaries” that safety offi-
cers should know about.
VigiBase
VigiBase (https://www.who-umc.org/vigibase/vigibase/)
is the AE database that the UMC maintains on behalf of
the World Health Organization. The data are supplied
by national health authorities. Much of the data is from
the US and are supplied by the FDA. The UMC does
not review or assess the individual cases put into the
database, but it does pharmacovigilance analyses and
signaling based on drug-event pairs.
Certain details, such as case narratives, etc., are not
available for review. Not all of the supplying countries
allow their data to be released. The database does not
contain all the data found in the national databases (e.g.,
FDA’s FAERS, EMA’s EudraVigilance) but rather contains
extracts restricted to domestic data. The UMC notes that
the data are “available to anyone with a health profes-
sional degree-level education (physician, dentist, nurse,
pharmacist)”. The database contains information on mar-
keted drugs as well as OTC products and some herbals.
Three types of reports are available. Ad hoc searches
can also be done if none of the reports below are suitable.
Samples of the output are available. Results can be pre-
sented in either WHO-ART or MedDRA, although there
is a transition to MedDRA since WHO-ART is no longer
being maintained:
Overview Reports give numbers of reported cases
with a specified reaction, a whole organ class, or
all reactions listed for individual drugs. The infor-
mation is grouped by reporting country or by year.
Reactions are listed by preferred term. The sum-
mary gives the result as the total number of reac-
tions for the criteria specified, listed by preferred
term. In the “by year” and “by country” reports, the
reactions are sorted by system organ class.
ADR profiles provide similar information in a
graphical and tabular format.
Detail reports include further details about each
individual case (date of report, case number, type of
report, reporter, country, seriousness, death outcome,
patient demographics, relevant medical history, AEs
[MedDRA and WHO-ART terms], causality where
available, suspect drugs, and concomitant drugs).
Narratives are not provided by the national author-
ities and are not available. The reports are available
as case reports (one case per page or multiple pages
if long), CIOMS line listings (.xls format), or spread-
sheet (.xls format).
Customized searches are available. Costs of searches
run roughly between $500 and $1200. Requests
can be made directly to the UMC by e-mail, fax, or
snail mail. Reports are returned electronically usu-
ally within a week or two. In addition, the UMC
has arrangements with several vendors that provide
web access and tools for using the UMC data, as
well as FDA FAERS data.
The UMC’s coding dictionaries (WHODrug Global
and WHO-ART for AE coding) are discussed elsewhere
in this manual.
EMA EudraVigilance
Database
EudraVigilance is a data-processing network and man-
agement system for reporting and storing suspected
Where Data Reside 371
ADRs from clinical trials and in the post-marketing set-
ting for products in the European Economic Area (EEA).
It was launched in 2001 and has been upgraded many
times. For clinical trials, SUSARs only are recorded and
all spontaneous reports (non-serious and serious) are
recorded for post-marketing ICSRs (since 2010).
EudraVigilance is used for the electronic exchange
of AEs among the European Medicines Agency (EMA),
member states’ health authorities, MA holders, and
sponsors of clinical trials in the EEA; detection of pos-
sible safety signals; and the continuous monitoring and
evaluation of potential safety issues.
There are two modules: The EudraVigilance Clini-
cal Trial Module (EVCTM) and the Post-authorization
Module (EVPM). These merely represent partitions
with somewhat different business rules, but the exter-
nal face of EudraVigilance remains a single transac-
tional database.
The database is maintained by the EMA for the
European Commission. Aggregate data are available
to the public (but see www.adrreports.eu). Companies
are required to obtain data on their own products and
perform signal detection procedures. Data are received
from companies under obligatory reporting require-
ments and voluntary reports from the public, which are
transmitted by member states’ health authorities. Ana-
lytical tools are available.
Health Canada
Health Canada’s drug safety database is available online
for immediate searches. See https://www.canada.ca/
en/health-canada/services/drugs-health-products/
medeffect-canada/adverse-reaction-database.html.
MHRA
The United Kingdom health agency has information
from its Yellow Card Scheme available as interactive
Drug Analysis Profiles (iDAPs), which replaced Drug
Analysis Prints (DAPs). iDAPs contain complete listings
of all suspected ADRs from the Yellow Card Scheme,
organized by active ingredient, and have potential for
use in signal detection. They include healthcare pro-
fessional and consumer reports for a particular med-
icine, as well as manufacturer reports. In addition to
individual listings of suspected adverse reactions, totals
of suspected ADRs, total reports, serious ADRs, and
fatalities can be calculated. Suspected reactions can
be stratified and displayed as tables or graphs using a
series of sorting options. Data can be sorted by demo-
graphics and visualized by MedDRA
®
System Organ
Class, High Level Group Term, High Level Term, and
Preferred Term. There are various other customizable
display options, such as timeframe, etc. The informa-
tion is updated periodically, although there is a time-lag
of about a month from receipt of a suspected ADR by
MHRA to availability in the interactive files. In addition
to digital displays, output is available through a print
function.
In addition, MHRA, along with an independent
advisor (the Commission on Human Medicines), pro-
duces a monthly Drug Safety Update (PDF newsletter)
that contains summary information on new safety con-
cerns for healthcare professionals.
To promote increased awareness of medicine safety
and reporting of suspected ADRs by the public, MHRA
has run a series of public-facing information campaigns
on drug safety. Traditional outlets as well as social
media have been used to encourage Yellow Card report-
ing to facilitate the safe use of prescription and OTC
medicines.
See www.gov.uk/drug-analysis-prints for iDAPs.
Teratology Data
The Teratogen Information System (TERIS) and the
online version of Shepard’s Catalog of Teratogenic
Agents are available at http://depts.washington.edu/
terisdb/. TERIS is an online database (housed at the
University of Washington) containing a series of agent
summaries, each of which is based on a systematic,
well-developed review and analysis of published clin-
ical and experimental literature. Assessment of terato-
genicity is based on reproducibility, consistency, and
biological plausibility of available clinical, epidemi-
ological, and experimental data. Summaries may be
accessed using either generic or brand names (domestic
372 Cobert’s Manual of Drug Safety and Pharmacovigilance
or foreign). Each summary includes a risk assessment
derived by consensus of an advisory board comprising
authorities in clinical teratology.
An updated, automated version of Shepard’s Cat-
alog of Teratogenic Agents is distributed with TERIS.
Users can access both systems simultaneously at the
URL above.
General Practice Research
Database and Clinical
Practice Research Datalink
The General Practice Research Database (GPRD),
managed by the Health Economics Research Centre
(HERC) at the University of Oxford, is a large database
of anonymized longitudinal medical records from pri-
mary care practitioners that can be linked with other
healthcare data via the Clinical Practice Research Data-
link (CPRD). Comprehensive observational data have
been collected on more than 10 million active patients
for research from around 460 primary care practices
throughout the United Kingdom.
The Clinical Practice Research Datalink (CPRD) is
a governmental, not-for-profit eHealth research service
managed by the MHRA, with partial funding from the
UK National Health Service. An important aspect of the
available services is to provide linkages between data-
sets. CPRD combines the expertise and activities asso-
ciated with GPRD with the UK Department of Health’s
Research Capability Program (RCP).
Together these assets are used for queries and
research on drug safety, clinical epidemiology, disease
patterns, pharmacoeconomics, and many other subjects
in healthcare. Results have led to improvements in drug
safety, best practice, and clinical guidelines. In addition
to PGRD data, CPRD also uses primary care data from
clinical trials.
For GPRD see https://www.herc.ox.ac.uk/
downloads/health_datasets/browse-data-sets/general-
practice-research-database-gprd.
For CPRD see https://www.cprd.com/Home/.
Other Registries
and Databases
There are many registries around the world containing
safety data related to drugs. It is often quite difficult to
find these databases and obtain access to data, espe-
cially those that would be useful for obtaining safety
data when preparing Risk Management Plans (RMPs)
or Risk Evaluation and Mitigation Strategies (REMS).
Databases can be located with information on expo-
sure or outcomes, pharmacoepidemiology and phar-
macoeconomic studies, as well as other studies of drug
safety. A paid subscription is required. See its website
for further information (www.bridgetodata.org).
It is likely that drug safety databases will grow
explosively in the near future as various efforts in the
US, the EU, and Asia to create data warehouses, linked
databases, and electronic medical records databases
continue to incorporate advances in interoperability
of IT systems. The collection, standardization, nor-
malization, transmission, and validation of the data,
using approaches developed by Standards Develop-
ment Organizations, such as HL-7 (www.hl7.org) and
CDISC (www.cdisc.org), are moving ahead. When large
amounts of good digital data and analytical tools become
available, the world of drug safety will change markedly.
As of today, the spontaneous reporting system remains
the most valuable, but thanks to machine learning and
artificial intelligence, the systems/databases specified in
this chapter could become, as a first step, an additional
tool to detect safety signals. Some additional databases
may be found using the various AI search apps.
CHAPTER
373
34
Information
Technology and the
Safety Database
A
ny company that receives more
than a handful of adverse events
(AEs), whether for marketed
products or for products only in clin-
ical 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 report-
ing requirements are voluminous and
follow tight standards in terms of con-
tent, format, and timing for reports to
HAs and contractual partners. It is thus
necessary to have an AE database that
allows, at the minimum, manual data
entry, electronic data entry via E2B
or a customized upload and output of
required forms and various aggregate
data, e.g., for PSURs/PBRERs, IND
annual reports, Development Safety
Update Reports (DSURs), and NDA
periodic reports as well as any other
customized or national/local reports.
Export capabilities are also neces-
sary as E2B files or other customized
exports. Many of the databases used
for drug safety also allow for com-
plex analysis and data mining of AEs,
such as increased frequency and dis-
proportionality calculations. Machine
learning is improving the efficiency
of some systems. Some have auto-
mated export and import capabilities,
e.g., the electronic safety gateway for
EudraVigilance.
374 Cobert’s Manual of Drug Safety and Pharmacovigilance
Introduction
Many databases also have workflow and quality com-
ponents built in with email and messaging function-
ality. Some companies customize their databases,
though more and more companies are buying one of
the standard packages (“shrink-wrapped software”
or “commercial off the shelf” systems) 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 data-
base 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 vendor can produce significant head-
aches for the user community if the vendor no lon-
ger supports the database or it is upgraded. This is
changing somewhat with the use of the “cloud” for
data storage and efforts to improve interoperability of
systems. This, however, is just the tip of the iceberg.
This chapter reviews the issues and specialized needs
around safety databases.
Required 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 multi-national drug safety department.
For smaller single-country departments, the needs
may be somewhat less. However, it is wise to consider
future business arrangements, wherein your safety
department may be involved in co-development or co-
marketing with a licensing partner that operates out-
side your country and you must intercalate into their
global PV system. There will surely be other require-
ments needed now or in the future that are not listed
here. Business conditions can change rapidly. Scalabil-
ity and the ability to change and customize the data-
base as requirements change are critical. Note that
there is some duplication and overlap among the fol-
lowing sections as some requirements are common to
multiple areas.
Data Entry
Upload capabilities from other databases, e.g.,
phone center and clinical research databases, via
manual, E2B or other formats;
Case data entry to include all needed fields to pro-
duce a completed MedWatch form, CIOMS I form,
other locally required forms, PSUR/PBRER, PADER,
CIOMS line listings, E2B transmission, and so forth;
Tabular entry of laboratory data as well as manual
entry (lab data often comes to sponsors electronically);
Seriousness, expectedness (labeledness), causality
at case level and adverse event (AE) level by the
investigator, company, CRO, others (that is, multi-
ple entries possible for an AE causality in particular);
Multiple narratives for the same case, e.g., short nar-
rative, long narrative, non-English narrative, case
comments, blinded narrative. Mechanism to handle
follow-up information in the narrative (overwrite
versus append). Size limitations on the field;
Ability to handle multiple labels (e.g., Summary of
Product Characteristics, US Package Insert) produc-
ing different expectedness classification depending
on the local label;
Ability to handle one or more reporters for a single
case;
Versioning, with multiple versions possible for each
case, e.g., by country and submission to HAs;
Tracking of information in and out (case log for
audit);
Support for the Medical Dictionary for Regulatory
Activities (MedDRA
®
) (multiple versions and lan-
guages), WHO-Drug Dictionary (and others);
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 and
in different formats;
Handling of multiple product types such as devices,
drugs, biologics, combination products, injectables,
medication errors, product quality complaints,
blood products as needed;
Duplicate check for cases using multiple fields, e.g.,
name, postal code, age;
Information Technology and the Safety Database 375
Ability to add fields as needed, e.g., new busi-
ness partner case reference numbers or changes in
regulations;
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 (with cau-
tion!) and a controlled process to do so;
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, 2015, or that a male is pregnant;
Ability to handle clinical trial, spontaneous, solic-
ited/unsolicited, named patient use (NPU), litera-
ture, pregnancy, 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; and
Ability to handle combination drugs, drug-device
combination products, OTC products, and so forth.
Workflow
Ability to track and move a case through its pro-
cessing using customized business rules set up by
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 differ-
ent versions existing simultaneously for a case, e.g.,
US 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 process literature reports;
Ability to handle customized case identification
numbering with each case having multiple numbers;
Multiple clock start dates, which may vary by country;
Follow-up letter generation to reporter or patient;
Correspondence tracking and reminders;
Returned product request and tracking; and
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 Germa-
ny’s cases, team handling drug X cannot see drug Y
cases;
Security and passwords — 21CFR11 & EU
compliant;
Scalability (able to add more users, countries, drugs,
business partners easily);
International use (if needed);
Multiple language and character set support;
Tickler (reminder) system;
Audit trails (full unless there is a clear reason not to
have complete audit trails);
Validation and validation scripts for any upgrades;
The US Health Insurance Portability and Account-
ability Act of 1996 (HIPAA), Public Law 104-191,
included privacy provisions for electronic health-
care transactions and code sets. Likewise, the
EU General Data Protection Regulation (GDPR),
2016/679, is a law on data protection and privacy
for all individuals within the EEA. It also addresses
the export of personal data outside the EEA. The
GDPR is more stringent than HIPPA, so many com-
panies based elsewhere but operate in the EEA
have adopted GDPR protections worldwide. Other
jurisdictions have local data privacy laws. Taken
together, this means that the ability to anonymize a
case is quite important because there are penalties
for misbehavior;
Tracking of submissions for expedited and aggre-
gate reports to multiple HAs;
Case cannot be downgraded (serious to non-seri-
ous or unexpected to expected) without senior staff
signoff; and
A Japanese version with the ability to produce the
appropriate E2B file (“the J file”) in the Japanese
language. Other local or regional requirements may
emerge that will expand needs in this regard.
376 Cobert’s Manual of Drug Safety and Pharmacovigilance
Vendor Support and Information
Technology Issues
User groups;
Support from vendor and internal IT colleagues
at home-base and worldwide user sites (ability for
load-sharing);
Ability to customize when new regulations and
requirements are put in place;
IT support capability in-house;
Secure, off-site physical location, e.g., the Cloud;
Upgrade policy and support for older versions;
Hardware needs and compatibility with other hard-
ware and software; and
Backup system, e.g., every hour, nightly, weekly,
with alternate power source, redundancies, and
ability to reconstitute database contents within
24 hours (or less) in case of emergency.
Validation
A fully validated system and validation strategy in
place going forward;
Change control in place; and
Must be acceptable (including documentation) 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 local
labeling, seriousness, and causality (for clinical trial
cases), are 7- and 15-day reports to HAs in various
countries, which go into PADERs/PSURs/PBRERs,
and so forth;
Labels for multiple countries should be storable and
useable in this manner. Strategy on handling label-
ing in non-English languages.
Reporting Functions
Draft and final versions of all usual reports: ICSRs
(electronic or paper forms), PSUR/PBRER 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 automati-
cally inserted into the letter;
Other reports: United Kingdom Yellow Card,
French imputability in French, English, and other
languages;
Export to EudraVigilance for both clinical trial and
post-marketing 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 aggregate
reports, e.g., PSURs/PBRERs, NDA periodic reports,
including follow-ups. Note that ICSRs included in
PBRERs are sent separately from the PBRER in E2B
format;
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 local forms, or line
listings of query or report results in PDF files;
Ability to save queries and reports at the user level;
Ability to anonymize reports and queries (e.g., no
initials, no reporter names or addresses);
EudraVigilance reporting and retrieval; and
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
run edit checks to “accept” a case before adding it
to the database, especially if an earlier MedDRA ver-
sion 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 the same case;
Automated transmission of cases based on busi-
ness rules to internal and external recipients,
Information Technology and the Safety Database 377
e.g., a particular drug’s cases go to licensing com-
pany externally and recipients internally 5 days or
10 days after first receipt date; and
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, e.g., reconciliation of PV
and clinical trial project 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 cus-
tomized 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; and
Signal detection and trend analysis.
Database Support
With a complex safety database in place, the drug safety
group will need dedicated support from the technical
services within the organization (be it a health agency,
a pharmaceutical company, or a service provider). This
will usually require one or more people working full-
time with the drug safety group. This is critical, as the
IT personnel, to better serve, must learn a significant
amount about how the safety business runs.
The IT group (either internal or outsourced to a ven-
dor) will serve multiple functions, including adminis-
tering hardware and software, upgrades, user access and
security, ad hoc queries (by the programmers), ongoing
maintenance, bug fixes, new reports and projects, audit
and inspection support, and validation and change con-
trol. In addition, there will be many behind-the-scenes
personnel, e.g., database administrators, server mainte-
nance, network personnel, involved in support of the
drug safety database. If some or all of these functions
are outsourced, an internal IT expert should oversee the
operations of the outsourced companies and ensure that
all requirements (regulatory, legal, and contractual) are
followed and met.
It is usually good for both the drug safety and the IT
personnel to have “one-stop shopping”. That is, requests
for IT support or for new projects should go through
one person (or single group) within the drug safety
department to one person/group in the IT department
to manage the flow of work and requests, track projects,
clarify needs, and ensure priorities are met. The IT per-
son will then coordinate the behind-the-scenes actions
in the IT department, e.g., network personnel, database
administrators, software vendors, etc. Thus, the drug
safety personnel should be able to go to one IT person
for any computer issues and not have to figure whom
to go to in IT: the database coordinator, the software
support team, or the hardware support team. And the
IT personnel do not have to figure out whom to contact
in drug safety.
The database must support all privacy and secu-
rity requirements from around the world. Changes in
requirements may occur over time in various countries
and they may involve both changes in the IT system/
database and in workflow procedures. Whatever data-
base is used, it must be able to handle multiple and
sometimes conflicting privacy and data protection
requirements. This may involve storing personal iden-
tifier information (names, addresses, reports, etc.) in
separate files in separate servers, sometimes within the
European Union. These rules are complex and chang-
ing. Many companies have dedicated privacy officers
who can assist in these issues.
Data Entry
Companies must make strategic, organizational, and
operational decisions on where data entry should
occur, especially if they are multi-national companies.
Single-country companies are able to have their safety
data entered centrally in one or at most two facilities.
This streamlines operations and allows for standardiza-
tion across all data entry personnel and for backup data
entry if one site should go out of service, e.g., fire, loss
378 Cobert’s Manual of Drug Safety and Pharmacovigilance
of electrical power, etc. Some companies will outsource
some or all of the safety functions.
Multi-national companies must deal with issues of
multiple languages, the need for follow-up on AE cases
by local personnel in the local language, local report-
ing requirements (again, often in the local language),
and the need for consistency and a single message (say-
ing the same thing to all HAs in each AE case or safety
issue). Companies respond to these needs in multiple
ways, depending on their size, geographical location,
number and type of products and indications. Typi-
cally one of three models is chosen when determining
who will conduct data entry and have ownership of the
safety database:
1. Fully In-house model — this is where the com-
pany will purchase or license the database them-
selves, host it directly on their server, and hire
employees to conduct the data entry for all cases.
2. Fully outsourced model — this is where the com-
pany will hire a CRO or vendor, one or multiple,
that will help the company fulfill their obligation
for data entry, collection, and reporting. A com-
pany may choose to select a vendor to house all
of their safety case processing needs or select a
few smaller companies to 1) host the database,
2) conduct case processing and assessment, and
3) conduct expedited reporting.
3. Hybrid Model — This is where the company will
outsource a lot of the heavy lifting to an exter-
nal vendor such as the safety database hosting,
setup, configuration, and maintenance, but may
keep in house the case processing and reporting.
The decision as to which model is right for a com-
pany will (as many times stated) depend on the com-
pany’s size, financial capabilities, and development
goals. For example, a company that desires to only
develop products through Phase 1 and then divest or
sell may choose a fully outsourced model, versus a
company that desires to take their product to market
may initially chose outsourced (due to limited financ-
ing in the early stage of development), then move to
hybrid modeling and further to fully in-house model
of management.
The critical issues, whichever mechanism is cho-
sen, are as follows:
Maintaining standards and consistency across mul-
tiple and diverse data entry sites, often speaking dif-
ferent languages and working under different con-
ditions and time zones, is always challenging;
Organizational reporting may also present issues
if the safety personnel abroad report only locally
and not “dotted line” or directly to the head safety
office;
Training is harder over greater distances even with
online and other high-technology training tools;
Quality is more challenging to measure and
maintain;
IT issues occur in terms of storage, networks, secu-
rity, data transmission speed, continuous supply of
utilities, and other support;
Data privacy issues may arise if data is shipped from
a region with tight data privacy and security rules to
areas of less stringent data protection rules (e.g., the
United States, in the eyes of the European Union);
and
Time zones interfere with workflow: It is almost
impossible to arrange a simultaneous teleconfer-
ence among Asia, the United States/Canada, and
Europe due to time differences without pulling
somebody out of bed. The International Date Line
also presents some dating problems (“This report
came into the United States today from Japan, where
it was received tomorrow”). In addition, business
hours don’t overlap: the day crew working in North
America will have to interact with the night crew
working in Asia. The working day does not over-
lap either, e.g., Sunday is a normal working day In
Saudi Arabia, but not in the UK. The UK has bank
holidays that are not recognized elsewhere. If one
is aware, careful logistical planning can overcome
these seeming impediments.
Data Transmission (E2B)
In this section, the practicalities of setting up E2B for
data import and export are discussed. E2B export of
Information Technology and the Safety Database 379
individual case safety reports is now obligatory for man-
ufacturers to HAs in Japan, the EU, the US, and certain
other countries.
There are several issues in E2B export:
The E2B file differs somewhat in each of the three
major regions due to regional requirements in regu-
lations that pre-date electronic reporting. In partic-
ular, a separate file (“the J file”) for each case must
be prepared for Japanese reporting, as it is required
by the Japanese HA in addition to the standard E2B
file. The EU and the US also have some differences
in requirements that have forced mandatory report-
ers to prepare three separate files, one each for the
United States, Japan, and the European Union. Most
of these differences relate to administrative needs
and the medical portion of ICSRs is essentially the
same for all trading partners.
The database structure of some old databases or
cases is not fully compatible with E2B transmis-
sions. For example, laboratory data may be entered
into structured fields or as free text. Some compa-
nies have dozens of years of laboratory data stored
as free text in their database. It is usually not nec-
essary or worth the effort to reenter the data into
structured tables. However, decisions must be made
on how these data will be entered moving forward.
Electronic data entry or downloading of laboratory
data may alleviate much of this problem, although
uniform “standards” are not in place amongst vari-
ous trading partners.
Technical issues exist on gateways, drug dictionar-
ies, and MedDRA versions.
A process must be set up within a company to verify
that all appropriate reports have been sent to the
appropriate HAs (and/or business partners) on a
timely basis and that they were received and suc-
cessfully uploaded into the receivers’ database(s).
Most of the modern commercially available drug
safety databases handle these issues fairly well and
companies are now expected by the regulatory
agencies to handle these technical differences and
submit cases correctly and on time. Outsourcing
companies (CROs) are able to do E2B submissions
for companies that are not equipped for direct E2B
transmission themselves. There are corresponding
issues in regard to E2B (or database-to-database)
import of files from business partners and other
companies. In addition, there are other issues, tech-
nical and otherwise, that will not be considered
here. All Pharmacovigilance Agreements (PVAs)
should take the above points into consideration.
How to screen and triage a report coming in. Should
it be uploaded automatically into the receiver’s
database or should it be kept in a “holding area”
until drug safety personnel are able to perform edit
checks and review the file for content and format
to ensure that it meets the appropriate criteria for
entry into the database?
How is the file actually reviewed by the staff?
Online? Printed out?
Screening for duplicates may be done in the triage
area or after uploading. Duplicates are defined as
receipt of the same case containing no new informa-
tion whatsoever.
A strategy must be found for identifying, handling,
and versioning follow-up reports for cases already
in the database.
Dictionary incompatibility. If the sender has not
yet upgraded to the latest version of MedDRA or
the drug dictionary and the receiver has, how is the
case handled? If different, and possibly incompat-
ible, drug dictionaries are used, how are the data
handled? Are business partners synchronized (and
employ the same conventions) is there an escalation
process for discrepancies?
How is security handled regarding encryption,
viruses, and so on?
E2B(R3)
Things are changing rapidly. ICH has decided that the
future versions of E2B will be created in collaboration
with “Standards Development Organizations” (SDOs)
to widen use around the world, to promote interoper-
ability, and for use by more than pharmaceutical com-
panies and health agencies. Thus, the International
Organization for Standards (ISO), Health Level 7 (HL7),
the CDISC, the International Health Terminology