Biotech Needs Software Engineers: My Journey Creating Life-Saving Data Visualizations

Last year I was consulting for a biotech company, producing data visualizations for their clinical trials. I had just put together a chart of tumor size over time. I drew a line for each patient, starting when they first got the trial drug. On the chart, I could see many of the lines sloping down— the tumors were shrinking.

It hit me more than I expected: each line was a person, diagnosed with cancer, and the fact that they were trying this experimental drug probably meant that other treatments had not worked. Maybe they’d given up hope?—?I couldn’t tell from the lines?—?but now this new drug was causing tumors to shrink, at least in some patients.

I’m not a scientist. I’m not a doctor. I’m just a simple software engineer, but my consulting experience has convinced me that my particular set of skills can greatly benefit biotech companies and help create much needed drugs. If you’re a software engineer, maybe you’ll want to do the same.

My wife works in biotech, and years ago she and her manager brought me in to help create visualizations for them. My first question was, “Why do you need me? Don’t you have a Biometrics department to do that?” What I learned is that there’s a specific niche that is not currently well-served.

Small biotech companies are startups: there’s more work to do than there are employees, and they haven’t yet built the IT infrastructure that large drug companies take for granted.

The Biometrics department at these companies is tasked with creating official outputs for regulators, partners, and investigators. And because official outputs are “official” they take much longer to produce. A biostats programmer writes the code to generate the output?—?not in Python or Java, but in a validated SAS environment that conforms to 21 CFR Part 11. Then a second programmer independently writes a different program and makes sure that the outputs match. If not, at least one of the programs has a bug, and the two programmers try to figure out the fix.

This rigorous development process is necessary for creating official outputs. A bug in a program could mislead trial scientists and even compromise patient safety. But there’s a vast need for non-critical, ad hoc outputs that are used in the day-to-day monitoring of the trial. Scientists and data managers often need ad hoc outputs that are accurate and useful, but faster and cheaper to create than the gold standard outputs of Biometrics.

For instance, imagine a clinical scientist managing a drug trial. They notice a patient has reported dizziness after taking the drug. They wonder: how many other patients are experiencing that? On average, how long after drug exposure did dizziness present? They ask Biometrics to generate an output, but of course, Biometrics is overloaded. They are working on the outputs for the next quarterly filing, and after that they have to work on the investigator outputs. Biometrics tells them to wait two months.

That’s where I come in. I’m not a scientist?—?I can’t interpret the clinical data at all. And I’m not a biostats programmer?—?I can’t create official outputs for the FDA. But what I can do is use my software engineering skills to efficiently and accurately output data for scientists to interpret. I can help the scientist answer these exploratory questions while minimizing the use of Biometrics resources.

Since my initial work ten years ago, I’ve been hired by other biotech through word-of-mouth to create clinical data visualizations. A scientist uses my visualizations at company A; when they move to company B, they bring me on to create the same visualization system they’re used to.

In that time, I’ve developed a set of software tools to help me do my job. Every clinical trial is slightly different. The databases are different; the schemas are different; and the requested outputs are different. But there are enough commonalities that I can re-use many algorithms and code. It used to take me 80 hours to write the data transforms for a single clinical trial. Now I can do it in 20.

When I started, I wrote various C++ programs to process the data tables. Today I’m using GridWhale, a platform I designed and created specifically to solve these kinds of problems. For example, GridWhale has a built-in connector to Medidata Rave, one of the most popular Electronic Data Capture systems used in clinical trials. With a single command, GridWhale can access the most up-to-date datasets for the clinical trial, transform the data into an appropriate form, and publish the results as visualizations in Spotfire or any other charting software.

I can’t tell you how satisfying it is to be able to generate these outputs for clinical trials. The clinical and safety scientists who run these drug trials know that data is the lifeblood of their operation. Scientists crave data to help them make decisions. Without data they can’t see what’s happening to the patients on the trial. Every scientist I’ve worked for has been deeply appreciative of the outputs I’ve generated, and they’ve valued the agility with which I can render their ideas into charts and graphs.

I’m bragging a bit, of course, but I want my software engineer friends to understand: I am not uniquely good at this. I am valued merely because I’ve acquired software engineering skills to help me tackle these problems. But these are skills that you all have. Any good software engineer would have the same experience.

So if you’re a software engineer who wants to feel valued; a software engineer who is tired of building Yet Another Ad Portal; a software engineer who wants to learn new domains and make a real impact on people’s lives, then consider following this path. Biotech needs software engineers, and perhaps, we need them too.

About: I’m George Moromisato, a software engineer building GridWhale, a new cloud-computing platform. Interested in biotech visualizations? Write to us: [email protected].