CASE REPORT

Sharing Adverse Drug Event Data Using Business

Intelligence Technology
Monica M. Horvath, PhD,* Heidi Cozart, RPh,* Asif Ahmad, MS, MBA,*
Matthew K. Langman, and Jeffrey Ferranti, MD, MS*
Introduction: Duke University Health System uses computerized
adverse drug event surveillance as an integral part of medication safety
at 2 community hospitals and an academic medical center. This information must be swiftly communicated to organizational patient safety
stakeholders to nd opportunities to improve patient care; however,
this process is encumbered by highly manual methods of preparing
the data.
Description of Case: Following the examples of other industries,
we deployed a business intelligence tool to provide dynamic safety reports on adverse drug events. Once data were migrated into the health
system data warehouse, we developed census-adjusted reports with userdriven prompts. Drill down functionality enables navigation from aggregate trends to event details by clicking report graphics. Reports can be
accessed by patient safety leadership either through an existing safety reporting portal or the health system performance improvement
Web site.
Discussion: Elaborate prompt screens allow many varieties of reports
to be created quickly by patient safety personnel without consultation
with the research analyst. The reduction in research analyst workload
because of business intelligence implementation made this individual
available to additional patient safety projects thereby leveraging their
talents more effectively.
Conclusions: Dedicated liaisons are essential to ensure clear communication between clinical and technical staff throughout the development life cycle. Design and development of the business intelligence
model for adverse drug event data must reect the eccentricities of the
operational system, especially as new areas of emphasis evolve. Future
usability studies examining the data presentation and access model are
needed.
Key Words: business intelligence, patient safety, adverse drug event
surveillance
(J Patient Saf 2009;5: 35Y41)

key component of successful patient safety models is the

ability to share aggregate data on adverse events back to
those responsible for improvement in patient care. It is estimated that at least 1.5 million preventable adverse drug events
(ADEs) occur each year in the United States, and they affect
over one quarter of all inpatients at tertiary care teaching hospitals.1,2 Duke University Health System (DUHS) has increasingly invested in health information technology, which provides
a massive volume of electronic data in support of quality im-

From the *Duke University Health System; Duke University School of

Medicine; and Department of Pediatrics, Duke University School of Medicine, Durham, NC.
Correspondence: Jeffrey Ferranti MD, MS, Duke Health Technology
Solutions, 2424 Erwin Rd, DUMC 2718, Durham, North Carolina 27705
(e-mail: monica.horvath@duke.edu).
This study was supported by grant no. 5UC1HS014882-03 from the Agency
for Healthcare Research and Quality, National Institute of Health.
The authors do not have any competing or conicting nancial interests.
Copyright * 2009 by Lippincott Williams & Wilkins

J Patient Saf

&

provement (QI) research. Unfortunately, our ability to generate

and store this magnitude of health care information has outpaced
our ability to effectively analyze it.
Duke University Health System is composes 3 hospitals
and numerous outpatient clinics that serve the Raleigh-Durham,
North Carolina environs. Duke University Hospital is a large,
academic, tertiary care facility with 924 beds. Duke Raleigh
Hospital and Durham Regional Hospital are tertiary care community hospitals (186 and 369 beds, respectively). All 3 facilities use computerized ADE surveillance (ADE-S) as part of
daily operations. This approach is acknowledged as an effective means to obtain consistent data on ADEs occurring in highrisk areas over time.3Y7 Adverse drug event surveillance uses
a rules engine to query all inpatient electronic health records of
each of the 3 DUHS hospitals to search for potential ADEs
and evolving unsafe conditions that may indicate patient
harm. Such rules evaluate combinations of medication orders,
laboratory results, diagnoses, or patient demographics. When a
rule condition is met, the surveillance system sends an alert, or
Btrigger[ to clinical pharmacists, and a chart review is performed to determine if an ADE occurred. A full description of
the operational aspects of this system is available elsewhere.8Y11
In order to improve the medication safety prole of
DUHS, it is essential that QI leaders have prompt aggregate
reports on ADE trends. Traditionally, longitudinal reports are
manually created in Microsoft Excel (Redmond, WA) by a
dedicated research analyst. Events are extracted from the source
system, annotated with additional clinical information, and aggregated as ADEs per 100 admissions and per 1000 patient
days. The most time-consuming step is the merging of multiple
data extracts including ADE-S data, census, hospital encounter
details, and demographics. These data are spread across 2 systems, the clinical data repository (CDR), which houses information relevant to daily hospital operations, and the archival
DUHS data warehouse, which stores patient care information
long-term for research access. As an operational system, the
CDR is not designed to support retrospective clinical studies,
and researchers cannot query it for specic questions. The data
warehouse, on the other hand, is purposed for long-term data
storage and retrospective retrieval, but its complicated technical architecture limits clinician accessibility. Frontline users
must be highly skilled in Structured Query Language (SQL) and
have intimate knowledge of the warehouse relational database
structure.
Another reporting challenge involves the transactional nature of clinical systems that permit data eccentricities to emerge.
For example, export of ADE-S data creates stray ASCII characters that must be manually removed before analysis can
occur. In some cases, numerical data are stored as text, which
causes unexpected behavior when loaded into Excel. Housekeeping values are not standardized, creating opportunity for
confusion in recognizing Bnull[ versus Bzero[ values. Even
more frustrating, nursing station locations codes can be added,
eliminated, or repurposed within the CDR without notice. Because data quality depends on the entire process by which it is

Volume 5, Number 1, March 2009

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

35

J Patient Saf

Horvath et al

generated, stored, and used, there are clearly many opportunities

for data integrity to be breached. Disparate data streams can only
be integrated once they are made to conform to the same dimensions and are assigned consistent yet meaningful housekeeping values.
Finally, the third obstacle is the ad hoc nature of the reports, which limits standardization and adds the potential for
human error. Reports cannot be automatically updated nor can
QI ofcers examine only subsets of trended data, such as subpopulations or drug categories. These tasks require new sets
of manual reports. Fast, accurate, and scalable aggregate ADE
trending is an unachievable goal using the manual report generation model.
Many other industries solve similar reporting problems by
using business intelligence (BI), an information management
philosophy to transform raw data from operational systems
into a coherent package to spur analysis and gain knowledge.12
IBM rst described a BI system in 1958 as an automatic process
to identify key information, determine who needs to know it,
and disseminate it efciently to the correct parties.13 Since
then, BI methods have increasingly been part of strategic
approaches to use data as an enterprise asset, and the scope of
BI tools has broadened to incorporate data warehousing, business analytics, and knowledge management.14 The 3 most
widely used BI products are Business Objects XI (San Jose,
CA ), SAS Enterprise BI Server (Cary, NC), and COGNOS
BI (Ottawa, Ontario), all of which helped cultivate a $6.25 billion dollar market in 2006, worldwide.12
Although many health systems have applied BI principles to their analytical needs, few share the lessons learned from
the technology implementation outside the scope of a short
white article. Brigham and Womens Hospital (Boston, MA) is
a 755-bed teaching hospital using SAS BI solutions to integrate 29 separate data sources into its balanced scorecard.15
This integrated reporting system hastens identication of metric anomalies, such as spikes in length of stay, without requiring ad hoc reports.16 Similarly, Middletown Regional Hospital,
a 310-bed acute care facility in southwestern OH, applied
COGNOS BI tools to track and analyze patient census, revenues, and expenditures for monthly reports.17 Data analysts
had previously created an information bottleneck as they
merged large, disparate spreadsheets to ask nancial questions.
However, streamlined reporting allowed completion of monthly
accounting requirements in 1/5 the original time.17 Some hospitals use home-grown systems, such as the University Medical Center Utrecht, a 1042-bed academic medical center located
in Utrecht, Netherlands. Their relational database infrastructure,
the Utrecht Patient Oriented Database, was designed to spur
research in outcomes and clinical epidemiology.18 The database
includes demographics, laboratory results, medication orders,
hospital discharge diagnoses, and procedures. Researchers can
access these data using several standardized SQL queries or custom scripts. One project used ADE data to uncovered scenarios
where drugs interfere with interpretation of laboratory results.18

DESCRIPTION OF CASE
At DUHS, we applied a BI strategy to share ADE-S data
with patient safety ofcers and QI specialists. This approach
would allow standardization of the user interface to accommodate customers with varying levels of computer experience. We
sought to integrate ADE-S with other databases within the
DUHS data warehouse to enable aggregate reporting functionality using COGNOS BI 8.2 (Fig. 1). This platform enables
data querying, reporting, analysis, and event management

36

&

Volume 5, Number 1, March 2009

FIGURE 1. Duke University Health System strategy for ADE-S

(adverse drug event surveillance) reporting using BI technology.
Adverse drug event surveillance data from 3 key subject areas
(hospital encounters, patient information, and ADE-S event
tracking) are extracted from the CDR and brought into the data
warehouse, the health system archive. An automated process
extracts data from the CDR, transforms it into standardized elds,
and loads it into the warehouse (ETL). Transformed data is
organized into 4 reporting packages. With this new
architecture, extensive detail becomes available on each ADE.
Representative data elds for each package are shown.

under a single integrated architecture. We chose COGNOS because several data warehouse team members had extensive experience using this platform. Our end goal was to develop a set
of dynamic reports where the user could navigate from aggregate ADE trends to detailed event information. Because of
differing safety concerns between patient care areas, we also
desired reports that would subset aggregate rates into userchosen categories, including nursing station, event severity, and
drug class. We assigned report creation and maintenance duties
to the existing ADE-S research analyst, who had partial knowledge of both the clinical and technical realms as well as being
skilled in analytics. The report customers were to be QI leaders
at the hospital and health system levels that are charged with
developing patient safety quality initiatives.

ADVERSE DRUG EVENT SURVEILLANCE

This project required 12 months of collaboration between
clinicians who advise on the ongoing development of ADE-S
and the DUHS data warehouse group, who archives and manages information from DUHS clinical systems, including the
CDR. The ADE-S system was deployed November 1, 2004 by
an internal team of technical and safety experts. Adverse drug
event surveillance data reside in an IBM (Armonk, NY) DB2
database and interfaces with the DUHS CDR that supports
ongoing patient care. For the 3 DUHS hospitals, ADE-S
examines pharmacy orders and drug dispenses from a 30-day
* 2009 Lippincott Williams & Wilkins

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

J Patient Saf

&

Volume 5, Number 1, March 2009

period in a nightly batch job. Using a set of 103 clinical rules,

the system identies potential ADEs and creates a report of
Btriggers[ to be subsequently evaluated by clinical pharmacists
(5 across the health system) for patient harm. All evaluations
are logged in a custom web application. Only inpatient ADE-S
information is currently available, although events that originate in the outpatient setting are captured if the individual is
admitted to 1 of the 3 DUHS hospitals.

DATA WAREHOUSE INTEGRATION

The DUHS data warehouse resides in an Oracle 9.2 (Redwood Shores, CA ) database running on a 4-processor Sun
Solaris (Santa Clara, CA ) server. An information technology
analyst performed extensive data proling on the ADE-S operational system and worked with the data warehouse group
database architect to develop the most parsimonious set of
new tables for addition to the warehouse. Database keys were
created allowing integration of ADE-S trigger evaluations with
existing data on patient demographics and hospital encounters.
An extract, transform, load (ETL) process was designed to extract the ADE-S data from the operational system, transform
it for integration with other clinical databases, and load it into
the DUHS data warehouse. The ETL process was performed
using IBM WebSphere DataStage 7.5.2 EE (Armonk, NY).
During this phase, much of the ADE-S data was cleansed and
standardized before warehouse loading. From scores of disparate clinician notes and e-mails, an ADE-S rule version history
table was created for the rst time to track rule modications.
After the initial backload of ADE-S operational data, we congured a differential ETL job to run nightly and look for new
and updated records.

IMPLEMENTATION OF BI REPORTING
Because nearly all end users of the BI reporting portal
were clinicians, the design goal was to enable execution of reports without needing knowledge of SQL scripting or the underlying database schema. To this end, COGNOS required
data organized into packages, which are groups of metadata
logically linked as dened by the current business problem.
For this project, ADE-S relevant information was organized
into 4 core packages: adverse event surveillance, patient, encounter, and census. The patient package included data tied
to anindividuals medical record number (i.e., name and demographics), but not to a hospital visit. The encounter package data was specic to a patient stay at 1 of the 3 hospitals and
included details on the admission, discharge, and clinical services. Census data were dened as admissions and inpatient
service days on a per nursing station, per day level.
Adverse drug event surveillance reports were created
using the COGNOS Report Studio web tool. From a technical
perspective, a COGNOS report is a specied collection of
SQL database queries, prompts, layouts, and styles arranged
together during the design phase to create interactive charts and
tables. Reports were created by combining the data elds from
different packages through a drag-and-drop web interface. The
combination of data elds as built by the report author creates
a series of SQL commands invisible to the end user. This
SQL script queries the data warehouse when the report is
run. Reports were constructed with maximal exibility in order to generate a wide variety of results dependent on the
prompt selections of the end user. For example, COGNOS report execution creates a report view, which displays a static instance of data based on the prompt choices (i.e., nursing station,
event severity, drug class) as selected by the user. Neither report

Business Intelligence and Adverse Drug Events

authors nor executors require knowledge of the underlying data

warehouse structure to use this BI reporting approach.

DATA SECURITY AND USER RESTRICTION

At DUHS, all employees have Microsoft Windows Server
2003 Active Directory (Redmond, WA) accounts as their primary means of accessing workstations and clinical applications.
COGNOS uses this existing authorization method where administrators grant active directory users one of the predened roles
for the ADE-S package: author, executor, or viewer. Authors
have the authority to develop and modify ADE-S reports, and
this role was granted to the projects research analyst. Executors
have permissions to run reports created by authors, but are not
authorized to develop reports themselves. This role was assigned
to QI clinicians and patient safety ofcers across DUHS.
Viewers are only authorized to see report views previously saved
by report authors. Beyond these roles, authors may further
restrict report dissemination to ensure only approved users have
access to specic levels of protected health information.

REPORT CREATION AND DISSEMINATION

Although numerous reports were created to accommodate
a wide range of user requests, Table 1 details the core reports
available to patient safety ofcers. A list report was designed
for retrieval of granular ADE information dependent on
selections from an elaborate prompt screen (Fig. 2). Two core
aggregate trending reports were designed: ADE rate per month
with a different series for each drug category (Fig. 3AYB) and
ADE rate per month with a different series for each nursing
station (Fig. 3C). All reports may be viewed in html, PDF, or
Microsoft Excel. A substantial benet of BI reporting is the
ability to add drill downs, that is, embed additional report
architecture that gives the user granular data derived from the
aggregate report. For example, clicking on the bars graphs in
Figure 3 runs a new BI report in a separate web browser window
that returns a detailed list of all ADEs comprising that bar. This
ability to perform exploratory analysis can be extremely valuable when trying to identify root causes of changing ADE rates.
Business intelligence reports were released to QI and
patient safety ofcers with positions throughout DUHS at the
health system, hospital, clinical service, and nursing station
levels. They can gain access in 1 of 3 ways. First, they can
navigate directly to the reports by reaching Cognos from a
web browser. However, this method of access is not integrated
into most users work ow and is not commonly used. A more
popular approach is to gain access through the safety reporting
system, our organizations portal for the voluntary reporting
of safety incidents across DUHS. Leadership visit this site regularly to examine recently-reported safety events; as a result,
links to the ADE-S Cognos reports were placed on the safety
reporting system BAnalysis Reports[ tab. This sets the previously unavailable ADE-S reports directly within leadership
work ow. Finally, users can nd aggregate data on ADE-S
ADEs by accessing the DUHS performance services Web site.
Performance services is a branch of DUHS dedicated to displaying organizational performance metrics involving patient
safety, customer service, nance, and work culture. We have
used their web portal to post ADE-S rate reports across 3 highrisk drug categories (hypoglycemia, narcotics and benzodiazepines, and anticoagulants) for each of the hospitals and their
clinical service units within DUHS.

DISCUSSION
The immediate benet of BI implementation was a reduction in the research analysts workload, which allowed that

* 2009 Lippincott Williams & Wilkins

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

37

J Patient Saf

Horvath et al

&

Volume 5, Number 1, March 2009

TABLE 1. Business Intelligence Reports Developed to Display Aggregate Adverse Drug Event Surveillance (ADE-S) Rates
Report Description
ADE list reportV
event details

Prompts
Hospital

Event date
Event location (nursing station)
Surveillance drug rule*
Surveillance drug category*
Event causality*
Event severity*
Medical record number*
Duke employee ID

ADE ratesVby month,

per drug category

Hospital

Event date

Report Output

Drill Downs

List report showing prompted items and:

Hyperlink on medical record number

will rerun list report to show all
historical ADEs for that patient

Lab value (if applicable)

Intervention
Event comments
Patient gender
Patient race
Encounter number
Patient name
Patient age
Patient DOB
Admission date
Discharge date
Admitting service
Discharge service
Length of stay
Length of stay to date
Chart 1, Table 1: ADEs per 100 admissions, by month. Series = drug
categories
Chart 2, Table 2: ADEs per 1000 patient
days, by month. Series = drug
categories

Charts: Clicking on bars gives the

ADE list report (event details) for
all ADEs that compose the bar.
Tables: Clicking on hyperlinks give an
ADE list report (event details) for
all ADEs that correspond to that
table cell

Chart 1, Table 1: ADEs per 100 admissions, by month. Series = nursing

station
Chart 2, Table 2: ADEs per 1000 patient
days, by month. Series = nursing
station

Charts: Clicking on bars gives the

ADE list report (event details) for
all ADEs that compose the bar.
Tables: Clicking on hyperlinks give an
ADE list report (event details) for
all ADEs that correspond to that
table cell

Event location (nursing station)

Surveillance drug category*
Event severity*
ADE ratesVby month,
per nursing station

Hospital

Event date

Event location (nursing station)

Surveillance drug category*
Event severity*
*Optional prompt, default = all.

Unique ID of the pharmacist reviewer.

DOB, date of birth.

time to be allocated to additional patient safety projects. Previously, a research analyst created a set of twelve reports per
hospital to plot monthly ADE rates for high-risk drug categories. This exercise took approximately 4 to 6 hours each month
per DUHS hospital. This highly manual, labor-intensive process
created many opportunities for errors meaning double and
triple data checks were required to ensure reporting integrity.
However, using a BI application, patient safety ofcers could
now retrieve each of these reports themselves in less than 10
minutes for 2 years of trended data. In addition, user-driven
prompts on the front end of the reports allowed rapid change
of a reports parameters, such as changing the severity level of
ADEs included in the aggregate rate graph. Similarly, the ADE
list report offers access to highly customizable ADE extracts

38

through a simple web interface and no prior knowledge of

the underlying DUHS data warehouse is required. Previously,
extracts that match patient demographics and hospital encounter information with ADE details were completely unavailable to QI ofcers. The research analyst had to consult with
a database programmer for each extract request. The analysts
responsibilities shifted from creating ad hoc reports to minimal
maintenance and routine quality assurance checks of the BI
infrastructure.
In addition to providing increased efciency, the Cognos
reporting method revealed slight errors in the original, manual
reports. These issues included contamination of an inpatient
report with data from outpatient locations and miscategorization of events. The BI approach also aids standardization as
* 2009 Lippincott Williams & Wilkins

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

J Patient Saf

&

Volume 5, Number 1, March 2009

Business Intelligence and Adverse Drug Events

FIGURE 2. Prompt page for ADE-S reporting. Variations of this prompt page are present in all core reports. These prompt
selections create hidden SQL lters in the report architecture which allow users to obtain aggregate trending reports tailored to
their QI needs.
* 2009 Lippincott Williams & Wilkins

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

39

Horvath et al

J Patient Saf

&

Volume 5, Number 1, March 2009

FIGURE 3. Adverse drug event surveillance aggregate trending reports. Although a large number of reports have been developed,
most are variations of 2 core reports: ADE rates by month per unit and ADE rates by month per drug category. All reports begin with
a prompt screen allowing selection of date range, hospital, nursing station, drug category, and event severity. When the ADE rates
by month, per drug category report is run, the next 4 successive web pages show a bar chart of ADEs per 100 admissions, a table of
ADEs per 100 admissions, a chart of ADEs per 1000 patient days (A), and a table of ADEs per 1000 patient days (B). The ADE rates by
month, per nursing station report brings up 4 similar web pages (C). Clicking on the graphics or links launches a new window
giving a list report of all ADEs that compose the bars or table cells.

it provides safety reports with a uniform look and feel to aid in

cross-comparison and analysis. The most notable, though unanticipated, consequence of the BI reporting deployment was
an increase in patient safety leaders level of energy as indicated
by many follow-up requests after using the dynamic reports.
Leaders wanted to ask new questions about their safety data
in hopes of identifying interventional opportunities and root
causes, which were previously unexplored. We are currently in
the process of prioritizing the requests across DUHS in order
to expand our report sets. In addition, we are pursuing the
resources required to conduct a formal usability study of the
ADE-S reports as accessed through the Safety Reporting System
portal.
Users communicated a few technical challenges in BI reporting. First, COGNOS runs as a web application so if there
are many simultaneous users accessing the portal, response
times will slow. This was partially alleviated by upgrading
the server hardware to accommodate the expanding COGNOS
user base. We also congured some reports to run automatically during nonpeak usage hours. A second issue was that BI

40

reports would not run successfully without precise browser security settings. Each workstation accessing the portal had to be
individually congured for staff members, requiring an unanticipated amount of time from technical personnel. Finally, as
QI ofcers explored the tool, they desired to trend ADE rates
by the specic medication involved, not just the drug category. The ADE-S source system treats the medication eld as
free text meaning these data are plagued with spelling errors,
brand names, and inconsistent medication codes. Given that
DUHS has yet to choose standardized medication taxonomy
to link drug information from disparate clinical system vocabularies within the data warehouse, we left development and
cleanup of the ADE-S medication dimension to a future enhancement phase.

CONCLUSIONS AND LESSONS LEARNED

In this report, we have presented a case study of a safety
application designed to report ADEs found by computerized
surveillance. Much of this projects success lay in having 2
* 2009 Lippincott Williams & Wilkins

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

J Patient Saf

&

Volume 5, Number 1, March 2009

dedicated employees, a research analyst and a pharmacist, translate between clinical staff familiar with the ADE-S operational
system and the technical staff that maintain the DUHS data
warehouse. This model ensured that solutions were approached
in a manner consistent with clinician needs. Because of personnel issues, it is common that no one can be allocated to
these positions as they require meeting attendance, availability
for consultation, and quality assurance duties. However, without
these individuals, critical design aws may not have been
corrected before full implementation. We would not embark on
any future project that seeks to warehouse the information from
clinical operations without allocating such resources.
Second, we found that although the needs of the ADE-S
operational system differed from those of the warehoused data,
the design of both systems must complement each other. For
example, a pharmacist reviewer may enter the ADE-S operational system and update a previously nalized evaluation at
any time. As a result, the data warehouse ETL must be sophisticated enough to detect updates, not just the presence of
new ADE-S records. Similarly, ETL development made us realize
that aspects of the operational system require standardization to
ensure data cleanliness. For example, certain data elds could be
manually overtyped by pharmacist reviewers in the ADE-S
operational web application, which creates the potential for
incorporation of stray keystrokes. To alleviate future data integrity
infringements, we write protected those elds during development.
Based on the impressions from this case study, we hope
to perform formal usability studies of the BI reporting methods in the future as to maximize clinician acceptance. This will
help us to understand how the reports should be ideally structured as well as which method of user access is the best. We
expect that complementary methods of report access will be
needed to serve all relevant care providers. At that time, we
will also revisit the issue as to whether all staff members involved in frontline care should be able to see aggregate ADE
rates. This would require substantial redesign of the existing
security model; however, such a project is already underway
to serve the voluntary Safety Reporting System which provides
1 method of access to ADE-S reports.
To our knowledge, DUHS has the only ADE surveillance
system in the United States that functions in both community
hospitals and academic medical centers in support of
performance improvement metrics and QI initiatives. Those
seeking to implement any set of ADE detection methodologies
should also ensure that strategic information technology plans
are in place to share the resulting data with QI stakeholders.
Our hope is that other health systems will similarly report their
experiences in the management, sharing, and analysis of large
clinical data sets within their organizations. Biomedical
informatics, human factors engineers, and information technology staff should be encouraged to take a leading role in
those publications as well.
ACKNOWLEDGMENTS
The authors thank the data warehouse group at Duke
Health Technology Solutions for technical support in developing
the COGNOS reporting portal.

Business Intelligence and Adverse Drug Events

REFERENCES
1. Nebeker JR, Hoffman JM, Weir CR, et al. High rates of adverse drug
events in a highly computerized hospital. Arch Intern Med. 2005;
165:1111Y1116.
2. Institute of medicine. Preventing Medication Errors: Quality Chasm
Series. Washington, DC: National Academy Press; 2006.
3. Bates DW, Evans RS, Murff H, et al. Detecting adverse events using
information technology. J Am Med Inform Assoc. 2003;
10:115Y128.
4. Classen DC, Pestotnik SL, Evans RS, et al. Computerized
surveillance of adverse drug events in hospital patients. JAMA. 1991;
266:2847Y2851.
5. Forster AJ, Fung I, Caughey S, et al. Adverse events detected by
clinical surveillance on an obstetric service. Obstet Gynecol. 2006;108:
1073Y1083.
6. Lee YH, Choi JE, Cha GE, et al. An architectural framework for an
adverse drug event surveillance system. AMIA Annu Symp Proc.
2006:1000.
7. Szekendi MK, Sullivan C, Bobb A, et al. Active surveillance using
electronic triggers to detect adverse events in hospitalized patients.
Qual Saf Health Care. 2006;15:184Y190.
8. Kilbridge PM, Alexander L, Ahmad A. Implementation of a system
for computerized adverse drug event surveillance and intervention
at an academic medical center. J Clin Outcome Manage. 2006;13:
94Y100.
9. Kilbridge PM, Campbell UC, Cozart HB, et al. Automated
surveillance for adverse drug events at a community hospital and an
academic medical center. J Am Med Inform Assoc.
2006;13:372Y377.
10. Ferranti J, Horvath M, Cozart H, et al. Re-evaluating the safety profile
of pediatrics: a comparison of computerized adverse drug event
surveillance and voluntary reporting in the pediatric environment.
Pediatrics. 2008;121:e1201Ye1207.
11. Ferranti J, Horvath M, Cozart H, et al. A multifaceted approach to
safety: the synergistic detection of adverse drug events in adult
inpatients. J Patient Saf. 2008:In press.
12. Vesset D, McDonough B. Worldwide Business Intelligence Tools
2006 Vendor Share. Framingham: IDC; 2007:1Y15.
13. Luhn HP. A business intelligence system. IBM J Res Dev. 1958;2:
314Y319.
14. Loshin D. Business Intelligence, the Savvy Managers Guide: Getting
Onboard With Emerging It. Boston: Morgan Kaufmann;
2003.
15. Fitzpatrick MA. Creating an Evidence-Based Practice Culture With
Business Intelligence. White paper: SAS Incorporated; 2004.
16. SAS. Brigham and womens hospital using SAS to align all
departments with strategy. 2008. Available from: http://www.sas.com/
success/brighamwomen.html.
17. Cognos Incorporated. Middletown regional hospital. 2006. Available
from: http://www.cognos.com/pdfs/success_stories/
ss_middletown_hospital.pdf.
18. ten Berg MJ, Huisman A, van den Bemt PMLA, et al. Linking
laboratory and medication data: New opportunities for
pharmacoepidemiological research. Clinical Chem Lab Med.
2007;45:13Y19.

* 2009 Lippincott Williams & Wilkins

Copyright @ 2009 Lippincott Williams & Wilkins. Unauthorized reproduction of this article is prohibited.

41