# Automagic epi curve plotting: part I

As of 24 May 2018, the underlying data schema of the Github repo from which the epi curve plotter draws its data has changed. Therefore, a lot of the code had to be adjusted. The current code can be found here on Github. This also plots a classical epi curve.

One of the best resources during the 2013-16 West African Ebola outbreak was Caitlin RiversGithub repo, which was probably one of the best ways to stay up to date on the numbers. For the current outbreak, she has also set up a Github repo, with really frequent updates straight from the WHO’s DON data and the information from DRC Ministry of Public Health (MdlS) mailing list.1 Using R, I have set up a simple script that I only have to run every time I want a pre-defined visualisation of the current situation. I am usually doing this on a remote RStudio server, which makes matters quite easy for me to quickly generate data on the fly from RStudio.

### Obtaining the most recent data

Using the following little script, I grab the latest from the ebola-drc Github repo:

# Fetch most recent DRC data.
library(magrittr)
library(curl)
library(dplyr)

current_drc_data <- Sys.time() %>%
format("%d%H%M%S%b%Y") %>%
paste("raw_data/drc/", "drc-", ., ".csv", sep = "") %T>%
curl_fetch_disk("https://raw.githubusercontent.com/cmrivers/ebola_drc/master/drc/data.csv", .) %>%

This uses curl (the R implementation) to fetch the most recent data and save it as a timestamped2 file in the data folder I set up just for that purpose.3 Simply sourcing this script (source("fetch_drc_data.R")) should then load the current DRC dataset into the environment.4

### Data munging

We need to do a little data munging. First, we melt down the data frame using reshape2‘s melt function. Melting takes ‘wide’ data and converumnts it into ‘long’ data – for example, in our case, the original data had a row for each daily report for each health zone, and a column for the various combinations of confirmed/probable/suspected over cases/deaths. Melting the data frame down creates a variable type column (say, confirmed_deaths and a value column (giving the value, e.g. 3). Using lubridate,5 the dates are parsed, and the values are stored in a numeric format.

library(magrittr)
library(reshape2)
library(lubridate)

current_drc_data %<>% melt(value_name = "value", measure.vars = c("confirmed_cases", "confirmed_deaths", "probable_cases", "probable_deaths", "suspect_cases", "suspect_deaths", "ruled_out"))
current_drc_data$event_date <- lubridate::ymd(current_drc_data$event_date)
current_drc_data$report_date <- lubridate::ymd(current_drc_data$report_date)
current_drc_data$value <- as.numeric(current_drc_data$value)

Next, we drop ruled_out cases, as they play no significant role for the current visualisation.

current_drc_data <- current_drc_data[current_drc_data$variable != "ruled_out",] We also need to split the type labels into two different columns, so as to allow plotting them as a matrix. Currently, data type labels (the variable column) has both the certainty status (confirmed, suspected or probable) and the type of indicator (cases vs deaths) in a single variable, separated by an underscore. We’ll use stringr‘s str_split_fixed to split the variable names by underscore, and join them into two separate columns, suspicion and mm, the latter denoting mortality/morbidity status. current_drc_data %<>% cbind(., str_split_fixed(use_series(., variable), "_", 2)) %>% subset(select = -c(variable)) %>% set_colnames(c("event_date", "report_date", "health_zone", "value", "suspicion", "mm")) Let’s filter out the health zones that are being observed but have no relevant data for us yet: relevant_health_zones <- current_drc_data %>% subset(select = c("health_zone", "value")) %>% group_by(health_zone) %>% summarise(totals = sum(value, na.rm=TRUE)) %>% dplyr::filter(totals > 0) %>% use_series(health_zone) This gives us a vector of all health zones that are currently reporting cases. We can filter our DRC data for that: current_drc_data %<>% dplyr::filter(health_zone %in% relevant_health_zones) This whittles down our table by a few rows. Finally, we might want to create a fake health zone that summarises all other health zones’ respective data: totals <- current_drc_data %>% group_by(event_date, report_date, suspicion, mm) %>% summarise(value = sum(value), health_zone=as.factor("DRC total")) # Reorder totals to match the core dataset totals <- totals[,c(1,2,6,5,3,4)] Finally, we bind these together to a single data frame: current_drc_data %<>% rbind.data.frame(totals) ### Visualising it! Of course, all this was in pursuance of cranking out a nice visualisation. For this, we need to do a couple of things, including first ensuring that “DRC total” is treated separately and comes last: regions <- current_drc_data %>% use_series(health_zone) %>% unique() regions[!regions == "DRC total"] regions %<>% c("DRC total") current_drc_data$health_zone_f <- factor(current_drc_data\$health_zone, levels = regions)

I normally start out by declaring the colour scheme I will be using. In general, I tend to use the same few colour schemes, which I keep in a few gists. For simple plots, I prefer to use no more than five colours:

colour_scheme <- c(white = rgb(238, 238, 238, maxColorValue = 255),
light_primary = rgb(236, 231, 216, maxColorValue = 255),
dark_primary = rgb(127, 112, 114, maxColorValue = 255),
accent_red = rgb(240, 97, 114, maxColorValue = 255),
accent_blue = rgb(69, 82, 98, maxColorValue = 255))

With that sorted, I can invoke the ggplot method, storing the plot in an object, p. This is so as to facilitate later retrieval by the ggsave method.

p <- ggplot(current_drc_data, aes(x=event_date, y=value)) +

# Title and subtitle
ggtitle(paste("Daily EBOV status", "DRC", Sys.Date(), sep=" - ")) +
labs(subtitle = "(c) Chris von Csefalvay/CBRD (cbrd.co) - @chrisvcsefalvay") +

# This facets the plot based on the factor vector we created ear
facet_grid(health_zone_f ~ suspicion) +
geom_path(aes(group = mm, colour = mm, alpha = mm), na.rm = TRUE) +
geom_point(aes(colour = mm, alpha = mm)) +

# Axis labels
ylab("Cases") +
xlab("Date") +

# The x-axis is between the first notified case and the last
xlim(c("2018-05-08", Sys.Date())) +
scale_x_date(date_breaks = "7 days", date_labels = "%m/%d") +

# Because often there's an overlap and cases that die on the day of registration
# tend to count here as well, some opacity is useful.
scale_alpha_manual(values = c("cases" = 0.5, "deaths" = 0.8)) +
scale_colour_manual(values = c("cases" = colour_scheme[["accent_blue"]], "deaths" = colour_scheme[["accent_red"]])) +

# Ordinarily, I have these derive from a theme package, but they're very good
# defaults and starting poinnnnnntsssssts
theme(panel.spacing.y = unit(0.6, "lines"),
panel.spacing.x = unit(1, "lines"),
plot.title = element_text(colour = colour_scheme[["accent_blue"]]),
plot.subtitle = element_text(colour = colour_scheme[["accent_blue"]]),
axis.line = element_line(colour = colour_scheme[["dark_primary"]]),
panel.background = element_rect(fill = colour_scheme[["white"]]),
panel.grid.major = element_line(colour = colour_scheme[["light_primary"]]),
panel.grid.minor = element_line(colour = colour_scheme[["light_primary"]]),
strip.background = element_rect(fill = colour_scheme[["accent_blue"]]),
strip.text = element_text(colour = colour_scheme[["light_primary"]])
)

The end result is a fairly appealing plot, although if the epidemic goes on, one might want to consider getting rid of the point markers. All that remains is to insert an automatic call to the ggsave function to save the image:

Sys.time() %>%
format("%d%H%M%S%b%Y") %>%
paste("DRC-EBOV-", ., ".png", sep="") %>%
ggsave(plot = p, device="png", path="visualisations/drc/", width = 8, height = 6)

### Automation

Of course, being a lazy epidemiologist, this is the kind of stuff that just has to be automated! Since I run my entire RStudio instance on a remote machine, it would make perfect sense to regularly run this script. cronR package comes with a nice widget, which will allow you to simply schedule any task. Old-school command line users can, of course, always resort to ye olde command line based scheduling and execution. One important caveat: the context of cron execution will not necessarily be the same as of your R project or indeed of the R user. Therefore, when you source a file or refer to paths, you may want to refer to fully qualified paths, i.e. /home/my_user/my_R_stuff/script.R rather than merely script.R. cronR is very good at logging when things go awry, so if the plots do not start to magically accumulate at the requisite rate, do give the log a check.

The next step is, of course, to automate uploads to Twitter. But that’s for another day.

References   [ + ]

 1 ↑ Disclaimer: Dr Rivers is a friend, former collaborator and someone I hold in very high esteem. I’m also from time to time trying to contribute to these repos. 2 ↑ My convention for timestamps is the military DTG convention of DDHHMMSSMONYEAR, so e.g. 7.15AM on 21 May 2018 would be 21071500MAY2018. 3 ↑ It is, technically, bad form to put the path in the file name for the curl::curl_fetch_disk() function, given that curl::curl_fetch_disk() offers the path parameter just for that. However, due to the intricacies of piping data forward, this is arguably the best way to do it so as to allow the filename to be reused for the read_csv() function, too. 4 ↑ If for whatever reason you would prefer to keep only one copy of the data around and overwrite it every time, quite simply provide a fixed filename into curl_fetch_disk(). 5 ↑ As an informal convention of mine, when using the simple conversion functions of lubridate such as ymd, I tend to note the source package, hence lubridate::ymd over simply ymd.

# SafeGram: visualising drug safety

Update: an RMarkdown notebook explaining the whole process is available here.

Visualising vaccine safety is hard. Doing so from passive (or, as we say it in Britain, ‘spontaneous’!) pharmacovigilance (PhV) sources is even harder. Unlike in active or trial pharmacovigilance, where you are essentially dividing the number of incidents by the person-time or the number of patients in the cohort overall, in passive PhV, only incidents are reported. This makes it quite difficult to figure out their prevalence overall, but fortunately, we have some metrics we can use to better understand the issues with a particular medication or vaccine. The proportional reporting ratio ($PRR$) is a metric that can operate entirely on spontaneous reporting, and reflect how frequent a particular symptom is for a particular treatment versus all other treatments.

#### Defining $PRR$$PRR$

For convenience’s sake, I will use the subscript $*$ operator to mean a row or column sum of a matrix, so that

$N_{i,*} = \displaystyle \sum_{j=1}^{n} N_{i,j}$

and

$N_{*,j} = \displaystyle \sum_{i=1}^{m} N_{i,j}$

and furthermore, I will use the exclusion operator $* \neg$ to mean all entities except the right hand value. So e.g.

$N_{i, * \neg k} = \displaystyle \sum_{j=1, j \neq k}^m N_{i,j}$

Conventionally, the PRR is often defined to with reference to a 2×2 contingency table that cross-tabulates treatments ($m$ axis) with adverse effects ($n$ axis):

($i$)
($\neg i$)
TOTAL
Treatment of interest
($j$)
$a = D_{i,j}$$b = D_{i, * \neg j}$$a + b = D_{i, *} = \displaystyle \sum_{j = 1}^{n} D_{i, j}$
All other treatments
($\neg j$)
$c = D_{* \neg i, j}$$d = D_{* \neg i, * \neg j}$$c + d = D_{* \neg i, *} = \displaystyle \sum_{k=1, k \neq i}^{m} \sum_{l = 1}^{n} D_{k, l}$

With reference to the contingency table, the $PRR$ is usually defined as

$\frac{a / (a+b)}{c / (c+d)} = \frac{a}{a + b} \cdot \frac{c + d}{c}$

However, let’s formally define it over any matrix $D$.

Definition 1. $PRR$. Let $D$ be an $m \times n$ matrix that represents the frequency with which each of the $m$ adverse effects occur for each of the $n$ drugs, so that $D_{i,j}$ ($i \in m$, $j \in n$) represents the number of times the adverse effect $j$ has occurred with the treatment $i$.

For convenience’s sake, let $D_{*,j}$ denote $\sum_{i=1}^{m} D_{i,j}$, let $D_{i,*}$ denote $\sum_{j=1}^{n} D_{i,j}$, and let $D_{*,*}$ denote $\sum_{i=1}^{m} \sum_{j=1}^{n} D_{i,j}$. Furthermore, let $D_{* \neg i, j}$ denote $\sum_{k \neq i}^{m} D_{k,j}$ and $D_{i, * \neg j}$ denote $\sum_{k \neq j}^{n} D_{i, k}$.

Then, $PRR$ can be calculated for each combination $D_{i,j}$ by the following formula:

$PRR_{i,j} = \frac{D_{i,j} / D_{i,*}}{D_{* \neg i, j} / D_{* \neg i, *}} = \frac{D_{i,j}}{D_{i,*}} \cdot \frac{D_{*\neg i, *}}{D_{*\neg i, j}}$

Expanding this, we get

$PRR_{i,j} = \frac{D_{i,j}}{\displaystyle\sum_{q=1}^n D_{i,q}} \cdot \frac{\displaystyle\sum_{r=1, r\ne i}^{m} \displaystyle\sum_{s=1}^{n} D_{r,s}}{\displaystyle\sum_{t=1, t\ne i}^{m} D_{t,j}}$

Which looks and sounds awfully convoluted until we start to think of it as a relatively simple query operation: calculate the sum of each row, then calculate the quotient of the ADR of interest associated with the treatment of interest divided by all uses of the treatment of interest on one hand and the ADR of interest associated with all other drugs ($j \mid \neg i$ or $c$) divided by all ADRs associated with all treatments other than the treatment of interest. Easy peasy!

### Beyond $PRR$$PRR$

However, the PRR only tells part of the story. It does show whether a particular symptom is disproportionately often reported – but does it show whether that particular symptom is frequent at all? Evans (1998) suggested using a combination of an $N$-minimum, a $PRR$ value and a chi-square value to identify a signal.1 In order to represent the overall safety profile of a drug, it’s important to show not only the $PRR$ but also the overall incidence of each risk. The design of the SafeGram is to show exactly that, for every known occurred side effect. To show a better estimate, instead of plotting indiviual points (there are several hundreds, or even thousands, of different side effects), the kernel density is plotted.

The reason why SafeGrams are so intuitive is because they convey two important facts at once. First, the PRR cut-off (set to 3.00 in this case) conclusively excludes statistically insignificant increases of risk.2 Of course, anything above that is not necessarily dangerous or proof of a safety signal. Rather, it allows the clinician to reason about the side effect profile of the particular medication.

• The meningococcal vaccine (left upper corner) had several side effects that occurred frequently (hence the tall, ‘flame-like’ appearance). However, these were largely side effects that were shared among other vaccines (hence the low PRR). This is the epitome of a safe vaccine, with few surprises likely.
• The injectable polio vaccine (IPV) has a similar profile, although the wide disseminated ‘margin’ (blue) indicates that ht has a wider range of side effects compared to the meningococcal vaccine, even though virtually all of these were side effects shared among other vaccines to the same extent.
• The oral polio vaccine (OPV, left bottom corner) shows a flattened pattern typical for vaccines that have a number of ‘peculiar’ side effects. While the disproportionately frequently reported instances are relatively infrequent, the ‘tail-like’ appearance of the OPV SafeGram is a cause for concern. The difference between meningococcal and IPV on one hand and OPV on the other is explained largely by the fact that OPV was a ‘live’ vaccine, and in small susceptible groups (hence the low numbers), they could provoke adverse effects.
• The smallpox vaccine, another live vaccine, was known to have a range of adverse effects, with a significant part of the population (about 20%) having at least one contraindication. The large area covered indicates that there is a rather astonishing diversity of side effects, and many of these – about half of the orange kernel – lies above the significance boundary of 3.00. The large area covered by the kernel density estimate and the reach into the right upper corner indicates a very probable safety signal worth examining.

### Interpretation

A SafeGram for each vaccine shows the two-dimensional density distribution of two things – the frequency and the proportional reporting rate of each vaccine (or drug or device or whatever it is applied to). When considering the safety of a particular product, the most important question is whether a particular adverse effect is serious – a product with a low chance of an irreversible severe side effect is riskier than one with a high probability of a relatively harmless side effect, such as localized soreness after injection. But the relative severity of a side effect is hard to quantify, and a better proxy for that is to assume that in general, most severe side effects will be unique to a particular vaccine. So for instance while injection site reactions and mild pyrexia following inoculation are common to all vaccines and hence the relative reporting rates are relatively low, reflecting roughly the number of inoculations administered, serious adverse effects tend to be more particular to the vaccine (e.g. the association of influenza vaccines with Guillain-Barré syndrome in certain years means that GBS has an elevated PRR, despite the low number of occurrences, for the flu vaccines). Discarding vaccines with a very low number of administered cases, the SafeGram remains robust to differences between the number of vaccines administered. Fig. 1 above shows a number of typical patterns. In general, anything to the left of the vertical significance line can be safely ignored, as they are generally effects shared between most other vaccines in general and exhibit no specific risk signal for the particular vaccine. On the other hand, occurrences to the right of the vertical significance line may – but don’t necessarily do – indicate a safety signal. Of particular concern are right upper quadrant signals – these are frequent and at the same time peculiar to a particular vaccine, suggesting that it is not part of the typical post-inoculation syndrome (fever, fatigue, malaise) arising from immune activation but rather a specific issue created by the antigen or the adjuvant. In rare cases, there is a lower right corner ‘stripe’, such as for the OPV, where a wide range of unique but relatively infrequent effects are produced. These, too, might indicate the need for closer scrutiny. It is crucial to note that merely having a density of signals in the statistically significant range does not automatically mean that there is a PhV concern, but rather that such a concern cannot be excluded. Setting the PRR significance limit is somewhat arbitrary, but Evans et al. (2001) have found a PRR of 2, more than 3 cases over a two year period and a chi-square statistic of 4 or above to be suggestive of a safety signal. Following this lead, the original SafeGram code looks at a PRR of 3.0 and above, and disregards cases with an overall frequency of $3Y$, where $Y$ denotes the number of years considered.

### Limitations

The SafeGram inherently tries to make the best out of imperfect data. Acknowledging that passive reporting data is subject to imperfections, some caveats need to be kept in mind.

• The algorithm assigns equal weight to every ‘symptom’ reported. VAERS uses an unfiltered version of MedDRA, a coding system for regulatory activities, and this includes a shocking array of codes that do not suggest any pathology. For instance, the VAERS implementation of MedDRA contains 530 codes for normal non-pathological states (e.g. “abdomen scan normal”), and almost 18,000 (!) events involve at least one of these ‘everything is fine!’ markers. This may be clinically useful because they may assist in differential diagnosis and excluding other causes of symptoms, but since they’re not treated separately from actually pathological symptoms, they corrupt the data to a minor but not insignificant extent. The only solution is manual filtering, and with tens of thousands of MedDRA codes, one would not necessarily be inclined to do so. The consequence is that some symptoms aren’t symptoms at all – they’re the exact opposite. This is not a problem for the $PRR$ because it compares a symptom among those taking a particular medication against the same symptom among those who are not.
• A lot of VAERS reports are, of course, low quality reports, and there is no way for the SafeGram to differentiate. This is a persistent problem with all passive reporting systems.
• The SafeGram gives an overall picture of a particular drug’s or vaccine’s safety. It does not differentiate between the relative severity of a particular symptom.
• As usual, correlation does not equal causation. As such, none of this proves the actual risk or danger of a vaccine, but rather the correlation or, in other words, potential safety signals that are worth examining.

SafeGrams are a great way to show the safety of vaccines, and to identify which vaccines have frequently occurring and significantly distinct (high-$PRR$) AEFIs that may be potential signals. It is important to note that for most common vaccines, including controversial ones like HPV, the centre of the density kernel estimate are below the margin of the $PRR$ signal limit. The SafeGram is a useful and visually appealing proof of the safety of vaccines that can get actionable intelligence out of VAERS passive reporting evidence that is often disregarded as useless.

References   [ + ]

 1 ↑ Evans, S. J. W. et al. (1998). Proportional reporting ratios: the uses of epidemiological methods for signal generation. Pharmacoepidemiol Drug Saf, 7(Suppl 2), 102. 2 ↑ According to Evans et al., the correct figure for PRR exclusion is 2.00, but they also use N-restriction and a minimum chi-square of 4.0.