Bench Press

It is unfortunate that much of what we need to do to the human body to treat it requires that we cut it open, as this creates a whole set of risks and complications for science and medicine. Thankfully, science and technology march on in the quest to reduce our dependence on invasive surgeries. An interesting Economist article takes a look into some of the more unconventional tools that are being explored as potential non-invasive replacements.

Let’s take a classic problem which often has a surgical solution: the removal of a cancerous tumor. How could we solve this without resorting to the use of a scalpel?

• Of course, there’s radiation – which, as we’ve discussed before, is potentially dangerous if the radiation dosage isn’t calculated sufficiently well.
• The use of ultrasound as a means to visualize what’s going on under the skin is commonly known. But a small startup in Washington called Mirabilis Medica came up with a means to use ultrasound not only to see a tumor or blood clot, but also to focus it and generate enough heat to destroy the tumor/blood clot (what they’ve called High-Intensity Focused Ultrasound or HIFU; explanatory diagram below).

• Professor Weihong Tan at the University of Florida published a paper in PNAS in early 2009 a means of using light as a way of non-invasively activating blood clotting. The system is described in the picture below, but relies on a means of inhibiting the activity of Thrombin (a protein that helps control blood clotting) with short stretches of DNA (which they’ve cutely termed “Thrombin-binding Aptamers” or TBA) that have been chemically modified to be able to change shape in the light (cis-trans isomerization under photon stimulation). The vision is to one day be able to inject a patient with these Thrombin-TBA “molecular clasps” and hit the patient with a light source, cutting off the blood flow to the tumor and all without needing invasive surgery!

These only scratch the surface of what new technologies and scientific advances might be capable of. Son et lumiere (sound and light) as surgical tools indeed!

(Image credit) (Image credit – Mirabilis Medica) (Image credit – PNAS publication)

My talented girlfriend is both a science aficionado (currently a med student) and an avid knitter. So when she showed me the science-inspired knitting creations of one Etsy user CraftyHedgehog, I knew I just had to blog about it:

After all, who wouldn’t want knitted replicas of their favorite dissection specimens? And, the creative Ms. CraftyHedgeHog has taken her art a step beyond – behold, a knitted dissection of an Easter Bunny:

The fetal pig is 100% wool. The frog is made from a silk/wool blend with the organs made from 100% wool (and yes, that’s a real aluminum tray – don’t worry, Ms. CraftyHedgeHog assures us that they’re unused). The rat is hand-knit from an acrylic mohair, also with 100% wool organs. The Easter Bunny is made from soft nylon yarn and the insides are made from 100% wool (for the eggs) and the plastic grass used to line Easter baskets.

You can buy the specimens and learn more from CraftyHedgeHog’s Etsy page!

(Image credits – CraftyHedgeHog’s Etsy page)

While Bench Press is a big fan of open source, we realize that it can be intimidating for the lay-scientist (or layperson for that matter) to build code from an open source repository when asking a question might quickly get the asker labeled a n00b and not taken seriously. This problem is especially relevant to us Windows users who don’t have ready access to UNIX-style command line-fu and are dependent on kind open source community members to create Windows-specific installers.

This weekend, while working on integrating the open source database SQLite into some code I was writing for Benchside, I realized that the only way to integrate SQLite’s Full Text Search capability was to recompile it from source code, something I had never done before. As I ran a Windows system, I wasn’t able to use the UNIX command line instructions on from Michael Trier’s post on how to integrate SQLite’s Full Text Search capability into a Python program.

A few hours of research and trial and error later, I finally came up with how to do it on Windows in a way which hopefully generalizes to building other open source projects out there. Hopefully I can lay these out so that other “n00bs” out there no longer need to feel left out when someone gives them some source code:

1. Install MinGW and MSYS – MinGW is the Minimalist GNU for Windows software pack which allows Windows computers to implement the development tools (like gcc and make) that UNIX-style operating system users (Linux, Mac) take for granted. MSYS provides a command line interface which emulates directly the UNIX command line, at least up to the point where it is needed to build from source code. Both packages are open source and have Windows installers for download at their respective pages (to keep things simple). These installers are probably a sub-version or two behind (as the updated tools need to be packaged together in Windows installers), but with MinGW and MSYS, it should be relatively easy to download and build from source the new tools! In any event, install MinGW first, and afterwards when you install MSYS, it will ask where you placed the MinGW install and be able to link directly to those compiler tools
   • (optional step) Install GnuWin32 – GnuWin32 is, like MinGW, a set of tools which emulate many of the other commands that UNIX-style operating systems have. The primary use for these would be to do other command line tricks which the UNIX guys have access to (i.e. downloading and de-compressing source code files from the command line). This is unnecessary as most commercial compression software (or open source like 7zip) can handle most of the de-compressing that you need
   • (optional step) Install the Windows Open Command Window Here PowerToy which will let you right-click on a folder and open a command line window right there. Makes things more convenient many times.
2. Add MinGW and MSYS to your system path – Now that you’ve installed MinGW and MSYS (and possibly GnuWin32), you need to make sure that your tools can be accessed from anywhere by command line and not just in the folders that you installed them to. To do this, pull up the “System” panel in your Control Panel. You can do this by clicking on “Start”, “Run”, and typing in “control sysdm.cpl” and hitting [ENTER]. A window should pop up called “System Properties”. Click on the “Advanced” tab and then click on the “Environment Variables” button. Another window should pop up. In the System variables panel (the one on the bottom, see image below), select the row that has “Path” in the Variable column and click on the “Edit” button. This should bring up a text-editing dialog box where you should add the full directory paths to the MinGW bin and MSYS 1.0 folders separated by semicolons there. In my case, for instance, the paths to the bin folders were “C:\MinGW\bin” and “C:\msys\1.0” and so I added “C:\MinGW\bin;C:\msys\1.0;” to the end of the Variable Value text box.
3. Download and de-compress the source code – This usually comes in the form of a gzipped tarball file (*.tar.gz) which you can unpack with software like 7zip or at the command line (if you have the appropriate tools installed) using gzip and tar commands.
4. Run MSYS and use the cd command to go to the directory where you’ve de-compressed the source code – You should be able to do this, assuming you added MSYS to your path properly, from anywhere in the command line by just typing msys and hitting [ENTER]. Use the cd command (syntax: “cd <name of directory>”) to move to the directory where you unzipped the source code. In my case it was: “cd C:/sqlite3/sqlite-3.6.22/”
5. Set any compiler flags that need to be set and run ./configure: For SQLite, I had to set the DSQLITE_ENABLE_FTS3 and DSQLITE_ENABLE_FTS3_PARENTHESIS flags before compiling. To do this, I simply typed in: CFLAGS="-DSQLITE_ENABLE_FTS3=1 -DSQLITE_ENABLE_FTS3_PARENTHESIS =1" ./configure and hit [ENTER]. What this does is first, set the environment variable CFLAGS, which is what the compiler will look at to set any preprocessor flags (setting -DXXX=Y sets the preprocessor variable XXX the value of Y) that it needs before building, and second call ./configure which runs a quick diagnostic to see if your system has all the development tools it needs to compile. If an error pops up, this might be a sign that your MinGW installation is incomplete or that you did not set the system path correctly.
6. Follow any instructions in the README – Source code packs usually come with a README text file which gives instructions for how to build the software package. You should definitely read those (as they may also provide instructions for which compiler flags that you might want to set in step 5). These usually end with you entering the instruction “make” (and then [ENTER]) and subsequently “make install” (and then [ENTER]) to make sure that the compiled code is embedded in the system at its proper location.
7. Post-setup – Depending on the software, there may be further configuration/setup steps that need to take place. In the case of my custom SQLite build, I had to copy the Windows DLL file from the ./lib folder that was created by the build process (libsqlite3-0.dll) into my Python installation’s DLL folder and rename it sqlite3.dll to replace my old built-in Python-SQLite setup.

The process above is probably not 100% fool-proof and skims over some details which may be important for different source code types, but hopefully my painfully self-taught lessons in building from source in Windows-land will be helpful to those of you out there who find yourself needing to build something by compiling from source code.

(Image credit)

The Open Science movement is driven by the idea that collaboration and openness are good for innovation and discovery. After all, the logic goes, who is more likely to discover a cure for cancer: five research groups with different sets of skills and specializations who don’t share any information with one another, or five identical groups who actively pool their knowledge?

Ironically, that reasoning seems to have completely skipped over the biotech/pharmaceutical industry who seem intent on pursuing the “divided we fall” approach despite the escalating costs of drug development. The application of openness itself is especially relevant here, as a significant piece of the $800 million – $1.2 billion price tag that goes with bringing one drug to market is the cost of failed R&D projects.

This problem is one that is not only a burden on the shareholders and executives at these companies, but also a burden on the healthcare systems of people around the world, which end up paying more and waiting longer for drugs to make it through a company’s pipeline.

About a month ago, the New York Times cast a spotlight on this problem:

Although many companies have committed to publishing the results of clinical trials, whether or not they succeed, drug makers don’t typically publish information about projects that fail at an earlier stage. A result is that companies waste many millions going down experimental paths that their competitors have already found to be dead ends.

M.I.T. is proposing dead-end drug disclosure, a concept that goes by a euphemistic mouthful: “precompetitive information sharing.”

Drug makers may realize that the financial and medical value of sharing such information outweighs the competitive risk, said Dr. Gigi Hirsch, the executive director of the M.I.T. Center for Biomedical Innovation, the locus of the drug project. “There should be more information available about failed compounds in the interest of the greater good,” Dr. Hirsch said.

The traditional response from the pharmaceutical industry is one that is familiar to Open advocates – that intellectual property and proprietary platforms are necessary for the returns which drive investment in these spaces. But, this ignores two things.

First, the act of sharing information on failed assay hits helps to reduce the cost and time of development. The decision to invest in a particular R&D project is driven by returns, and returns are driven by development costs and the time it takes to get “money back”. While being more open about internal failures and successes will do little to change the cost of marketing, clinical trials, and many aspects of development, it will reduce a large portion of the time and cost of initial R&D (because of the wider availability of information) and the cost of failure (as there would be no need to pursue avenues of research on paths that have already been deemed a failure). So even if the prices and number of drugs sold diminish slightly due to the inability of a company to hold on to some early-stage proprietary advantage or the release of some of the details on their compound library, the time to market and cost of development diminish as well, helping to preserve the return on investment necessary to provide for the level of drug innovation and discovery that patients and doctors want.

Secondly, a move to openness does not necessitate unprofitability. It wouldn’t be realistic to ask companies to pursue a path which destroys the shareholder value they’ve been entrusted to protect. But, the fact that technology companies like Google and Nokia have been able to push open standards and open source yet retain profitability and innovation should hopefully signal to bio/pharmaceutical companies that it is possible to have both shareholder value and openness.

The path to profitable openness that technology industry practitioners like Google pursue is no different than the path that any company pursues: specialization. Google, for example, has specialized on high quality search results, effective advertisement targeting, and IT infrastructure management. As a result, there’s no reason for Google to prevent the broader technology industry from having access to the source code for its Chrome web browser, Android mobile operating system, or Google’s rich APIs to access the information you can find on its websites. In fact, Google seems to have understood that keeping its information closed would reduce innovation on the web, which would in the long-run hurt its own growth and profitability prospects.

I’d humbly wager that the value of protecting early stage failure and platform information is relatively minor in the grand scheme of pharmaceutical company value (and in fact some companies do publish failures, albeit only years after the experiment). I’d even humbly bet that major drug companies probably have much more significant expertise and differentiation in the steps after initial R&D, such as in compound refinement, clinical trials operation, process development, and computational analysis, etc. All of this should, at the minimum, shield existing drug companies from the “risks” of opening up on early-stage R&D failures and could even help existing drug companies compete by emphasizing these new capabilities as the determinants of success.

Nobody is saying that this path will magically materialize and produce awe-inspiring levels of profitability and growth overnight. But, when an industry is on the edge of a patent cliff (most blockbuster drugs are expected to become generic in the next couple of years), when its primary source of “value creation” seems to be in buying smaller companies, and when nations around the world are struggling with healthcare costs, I’d assert that the bio/pharmaceutical industry needs to change its practices.

As for how – I would propose the following compromise.

1. First, the NIH, PhRMA, or some other neutral authority should define a set of standards for what information should be contributed (balancing the desire to foster innovation through openness and the desire for companies to maintain the closedness they need to build proprietary advantages along other dimensions), create a standard for secure information sharing (which protects any individuals and patients and proprietary pipeline-related information) and govern compliance.
2. This body should then set up an information exchange/database for participating companies, academic institutions, government research centers, and medical institutions to share information and prevent non-compliant companies from gaining access (it’s not a perfect solution, but it could help assure companies who are worried that they will give up all of their information but not receive any in return).

This road would likely be a long and difficult one, but given the stakes and the potential benefits, I think it is one well worth taking.

(Image credit) (Image credit)