In the interview, we focused more on what Sage Bionetworks has already done rather than what we might do with AWS in the future; however the breadth of offerings from Amazon keeps expanding along with our potential applications.  One very interesting service to us is Amazon’s recently launched Glacier product, which is designed for data archival.  With S3, you are essentially paying Amazon to make your data continually available and protected from loss; many machines must have the data live on disc to provide S3′s level of service.  Therefore, even though Amazon may be operating the service on pretty thin margins, it’s still a relatively expensive way to store data for some use cases.  Glacier complements S3 because it lets you trade off cost for availability: by agreeing to wait 3-5 hours for a request for data to be serviced, you can significantly cut the cost of storing that data.  Biomedical research is full of examples where large amounts of data are actively analyzed for a period of time, but quickly give way to processed versions of the same data that will be used for downstream analyses, e.g. processing a raw genetic sequence to a series of varients compared to a reference genome. While the reference genome or the processing algorithm does occasionally change, once the variants are called this occurs relatively infrequently.  This sort of use case makes Glacier a very interesting proposition.

Along with genomics, imaging is another common source of large data volumes in the medical research space. Sage is planning to enter this space shortly by launching ”Melanoma Hunt” project, intended to aid in the early detection of melanoma through images of skin lesions captured from mobile phones.  We’d like to create a publicly accessible database of suspicious and  benign images to catalyze the development of better image processing and machine learning algorithms.  Feature extraction from raw images might be performed only occasionally, feeding into downstream work to build a classification model.  The project will also aim to engage the average citizen in the research process, crowdsourcing much of the effort that goes into developing these classifiers. Citizen scientists may learn to classify the images manually, or remove potentially identifying information from the images. The organization of such efforts could benefit immensely from technologies such as Mechanical Turk, with data ultimately relased to researchers through Synapse.

As the Synapse system itself scales to handle these sorts of projects, we are going to need additional technologies on the back end to scale appropriately as well. Given that there will always be a category of application data where we need real-time concurrent updates, we will probably always have some of our services running off of RDS.  We’re already using Cloud Search to support a standard search feature, but there are other sorts of queries where we might need higher query performance and scalability.  We’ve started looking at DynamoDB (a noSQL db) and ElastiCache for some of our future needs, or for refactoring current services to support higher scales.  In this type of architecture, we will likely end up using Amazon SQS as a  message queue between synchronous and asynchronous logic in Synapse.

We’ve also been investing recently in automating the deployment of new instances of Synapse.  As the application has grown in complexity, the configuration of the AWS components it’s built upon has become increasing difficult to manage manually.  Fortunately, several approaches are possible to automate provisioning these components and installing software into them.  The one we took was to simply write a program (See Sage Bionetworks / Synapse Stack Builder on GitHub) using the AWS SDK for Java that automates these tasks; the approach works for us because we are a very Java-centric shop and don’t have clear boundaries between developers and operations personnel.  You could easily do the same in other languages, or though the use of Amazon’s Cloud Formation templates.  The end result is a blue-green deployment system, where we will be continually building new instances, operating them in staging mode for a test period, and then using Route 53 to manage the cut-over as a staging system is promoted to production.

Finally, I’ll end by noting that we have been looking at the cloud computing space more generally.  In particular, we’ve had a great relationship with Google, who’s very generously provided 2,000 virtual cores of support for our public challenge in the predictive modeling of breast cancer, as well as hosting the clinical and genomic data the challenge is built upon.  We’ve recently taken the “Tour de France” strategy of awarding an intermediate stage win to the currently best preforming classification model of aggressive vs. nonaggressive disease.  It’s important to remain flexible in our support for scientific computing; the cloud computing market is still young and ultimately, scientists will move to the computing platforms that provide the mix of compute services appropriate for their applications.  Another force that will catalize the formation of communities of scientists working with particular technologies is the presence of large, interesting scientific data sets to work with.  If those data sets can be open to the full scientific community, so much the better.

However, is this the best way to spend $27M to shake up and rally support for science?  Of course Mr. Milner is free to spend his money any way he wishes but I see some potential problems with his approach.  Quoting from the NY times article referenced above “Mr. Milner personally selected the inaugural group, but future recipients of the Fundamental Physics Prize, to be awarded annually, will be decided by previous winners.”  I don’t know how well a Russian billionaire can select the best work in theoretical physics, but let’s assume he did his due diligence as well as the experts in Stolckholm.  Past the first year the process turns into a bunch of self-anointed experts picking their own colleagues.  Nothing particularly wrong with this, but not that much different than the Nobel Prize.

The other fact in the article that really caught my attention was the condition that theoretical predictions don’t need experimental evidence to be considered breakthroughs.  No sitting around for decades waiting for messy difficult to acquire data to roll in here, this prize gets straight to rewarding breakthough ideas.  According to Milner “This intellectual quest to understand the universe really defines us as human beings,”. What could be wrong here?

Well, I’m reminded of the quote by Thomas Huxley which was posted on my thesis adviser’s door: “The great tragedy of Science — the slaying of a beautiful hypothesis by an ugly fact.”  I think the lack of a requirement for experimental validation for the Fundamental Physics Prize shows a fundamental lack of understanding of what science is.  Science is not philosophy.  It is based in a belief that there is in fact a real world which behaves a certain way, and that the way to uncover the way this universe works is though empirical evidence, not the scientist’s opinion of the beauty of the theory explaining it.

But maybe I’m just a cranky science dropout.  Let’s check the news post again “Dr. Arkani-Hamed, for example, has worked on theories about the origin of the Higgs boson… None of his theories have been proved yet. He said several were ‘under strain’ because of the new data.”… Wow.  Tough break.  Even in the short interval between when these winners were decided and when they were announced, one of the winner’s ideas is “under strain”, or in layman’s terms “wrong”.

I don’t have the billion dollars to fund a competitor to the Nobel, but I do have the $18 it took to acquire the sciencereengineered domain, and in this world I am the boss.  So, here’s my proposal for a Nobel alternative:

First of all, I’m not going after the Physics prize.  I’m targeting the one for Physiology and Medicine.  But I’m not giving the power to award it to a group of experts, I’m going to let patients vote on it.  My guess is that unproven theoretical ideas decades away from experimental validation won’t make the top spots.  Instead, the award will go to the projects that have the biggest impact on people’s lives.  Doing this in practice might be difficult so maybe I’d pick a different disease every year and go to that patient community to get a more involved and knowledgeable subset of voters.  To make sure the voters are knowledgeable, part of the process of awarding the prize will be having the candidate projects present their work to the lay audience.  I’d build some sort of online environment for the projects to build presentations of their work, and for patients and scientists to discuss over the course of several months before the vote.  Of course, the data, code, and other materials used to comprise the project have to be open and available to those who want to validate the work.

Secondly, I’m not giving the award to individuals.  This propagates the false belief that science advances due the unique and rare break-through insights of a small group of geniuses (see On the Shoulders of Giants).  Instead the award goes to projects, and is shared by every member of the project team equally.  Say a flat prize of $100,000 per team member…. I want to give the winners enough to be a noticeable Thank-You but not be so large that they retire!  However, unlike the Nobel, I have no limit on the number of people on the team.  It doesn’t matter if you’re the PI, the lab rat doing the pipetting, the data analyst, or the marketing guy putting together the project description for the lay audience.  The award goes to the whole team, identified in alphabetical order.  For $27M that means that the winning team size could hit 270 people.  That’s big, but if you’ve seen some of the massive author lists on 4 page journal articles it’s not that far off the mark for modern science.

So, that’s a first pass at the Kellen prize in Physiology or Medicine.  Of course, if there’s one thing that’s clear from studies of human behavior, it’s that incentive structures often motivate people in ways unintended by those who create the incentives.  So, I reserve the right to modify the rules of the prize based on empirical evidence acquired as the prizes unfold.  After all, that’s what being a scientist means.

Our task now is how to best harness this energy to motivate researchers, and also form a community where people not only compete, but also collaborate and build off each other’s work effectively.  Many of my recent discussions with the challenge organizers have drawn analogies to the Tour de France, and how multiple dimensions of awards and glory motivate different riders to focus on achieving different objectives in the race.  Every year there’s only a handful of guys who can realistically hope to win the yellow jersey, but many other riders that compete to take home other awards.

Multiple Jerseys – In the tour, there’s not only an overall winner of the yellow jersey, but several other jerseys that award different riding styles.  The green jersey is awarded by points obtained by sprints to stage and intermediate race points, and the polka-dotted king of the mountains awards the rider who does the best on the major climbs of the tour.  Breast cancer is not really a single disease; in reality many different molecular defects give rise to a heterogeneous collection of diseases.  A prognostic test, particularly one focused on detailed genetic data, is unlikely to perform well across all types of breast cancer.  It would be interesting to award sub-category awards for particular types of cancer, based on things like ER, PR, and HER2 status.

Stage Winners – An awful lot of the tactics of a bike race involve the dynamic between riders who are trying to win an individual stage, and riders or teams that are more concerned with the overall standings.  The glory of a stage win is enough to cause riders to attempt to break away from the peloton even though they have no hope of competing for the overall lead.  With our challenge we’d like to reward people for submitting ideas early and allowing others to incorporate and modify their models, instead of waiting to the the last minute to submit an entry.  One way to do this would be to have defined intermediate points where we had some sort of recognition of the leader.  Maybe we could introduce new validation data at set periods to score the models, and then allow contestants to incorporate previous validation data as new training data in subsequent rounds.  Another approach we’ve discussed is to reward people for time spent on top of the leaderboard and for the amount of improvement they make over the previous best score.  The person who makes many submissions that improve the top score over the competition may have contributed more to the competition than someone who sneaks in a marginally better model right at the end of the challenge.

Visible Leaderboard – In the tour, everyone knows what everyone is doing.  Riders have their coaches in their ears, giving them information on what other riders are doing, and the team constantly replan strategy as the race unfolds over several weeks.  We’ve got a basic leaderboard up giving real-time feedback on the challenge and it seems to be a good way to engage people.  I’m sure with more time and resources we could do a better job of making this resource more exciting for the challengers.  Maybe we should pull in contestants Synapse profiles and try to connect the contestants to an audience. Math and statistics might not be as sexy as bike racing, but there’s got to be some cancer survivors out there that would be interested in seeing people compete to better understand the disease.

So what do you think?  Do you have any better ideas on how to organize these scientific challenges?  We are open to experimentation.

The higher level experiment that Sage is running though is really on the social structures governing how science is done, and if other non-traditional incentives and structures can accelerate the discovery process itself.  The traditional way this research would be performed is for a high-powered company or academic group to organize and execute a clinical study: an enormously expensive undertaking as it involves managing care and collecting data on a statistically significant number of patients.  The data used in our challenge was gathered over 10 years and comes from about 2,000 patients.  Once collected, this data becomes a valuable commodity.  The group running the trial will typically hold it while analyzing it, and only release their high-level conclusions in the form of publications, or in support of FDA approval for the sale of a new drug.  The data may be shared long after the generators believe they have extracted all value from it, or used as a trading chip as a few high-powered labs form closed collaborations.

Sage’s hypothesis is that getting this data into the public domain as quickly as possible is in the best interests of patients and society as a whole. Last week we finally had a big public launch of the challenge and got a phenomenal response from the community.  So far, we’ve had over 160 people register to attempt the modeling challenges, and over 100 attend last week’s opening on-line launch.  We’ve already had at a few people submit models, and even have one that beats the simple base-line approach we used as an example.  Compared to other research efforts I’ve seen, the wide open approach of the challenge seems to have generated far more interest from the community.  We’ll see by this fall if this turns into better science.

Of course, the idea of framing scientific challenges and posting rewards for their completion is not a new one.  Our partner DREAM has been doing this in the academic setting for 7 years, and there’s some interesting commercial sites out there like Kaggle and Innocentive.  However, I think some of the things we’re doing in the course of this challenge are pushing the envelop on this format:

• Generating experimental validation data – In parallel with running the challenge we’ve identified another 350 or so frozen samples obtained in one of the studies providing the underlying data for the challenge.  Sage has raised funding for generating new molecular data off these samples in parallel with running the modeling challenge. One of the big problems in this space is that statistical models produced in one study don’t hold up when applied to data not used to generate them.  It will be interesting to see if the best models during the competition phase hold up and generalize to this new data used to determine the final winner.
• Publishing the winner in a premier journal – Science Translation Medicine has agreed to publish an article written by the winner.  Instead of the usual system of blind peer review by two experts, for this article the fact that the challenge is run on a completely open platform will provide a broader and hopefully more rigorous method of ensuring the winning approach is reviewed and understood by the community.
• Requiring participants submit reusable code – Computational experts often complain about a lack of access to high-powered data sets, but can be less willing to invest the time to make their own analytical code open to use by others.  Unlike many other challenges in which analysts simply submit a vector of predictions for the validation data, in our challenge analysts will have to submit code that we can run to score the model.
• Providing participants dedicated compute space – Through a generous donation by Google, we are providing all participants use of a Google virtual machine running on Google’s new Compute Engine service.  Besides providing raw compute power (currently 2,000 cores dedicated for community use), this approach helps ensure reproducibility by providing commonly configured infrastructure.

I’m really excited to get this project off the ground, and am sure I’ll have more detailed posts on specific aspects of it over the coming months.

As our week off approached and people started heading out to start their vacations early, we got a first warning that shutting down completely is probably not an option if you’re operating an online service, even an early-stage beta that’s currently supporting a handful of users.  The week before our break we had a brief service outage caused by a security certificate expiring on the Crowd server backing out authentication services.  Although we corrected the problem quickly, that incident got our attention enough to decide that pushing out a new release with only minor bug fixes right before the break was probably not worth the risk.  We decided to just leave everything alone and resume work once everyone was back in town.

Unfortunately, that first incident was only the precursor to the main event.  Friday night, Amazon suffered a power outage at their Virginia data center, which also affected a number of other much higher profile sites like Netflix, Heroku, and Instagram.  Saturday morning I woke to the realization that Synapse was completely non-functional.  It took the better part of the day for us to trace the problem to our AWS RDS service being down, and recover the live system using a backup taken shortly before the event. 

So, does this incident bring into question the decision to use cloud services and particularly Amazon as the foundation of our own service?  What’s the alternative?  In my previous job my team built a service using a stack of our own selected servers installed in a local colo facility.  Several months in, after a couple power outages had taken us down, we were able to determine that this facility did not in fact have redundant power wired to our cage as they had promised us when we moved in.  Instead, they had just plugged us straight into Seattle City light.  Stung by this we found a new, more reputable hosting partner, located in a quality facility also serving the local ABC news affiliate.  They had a big bank of UPS devices, multiple redundant connections to the power grid, and the ability to run the site indefinitely off backup generators in case of emergency.  Still, at that facility we had a couple day outage caused by an electrical fire that cut power to our servers for a couple days.  At Sage, I could buy physical servers and put them in the data center right next to my office at the Hutch.  It might give me a warm fuzzy safe feeling, but I think that’s mostly due to a psychological tendency to imagine that bad things only happen to other people.  I doubt they’d really be any safer than rented servers sitting in an AWS facility in Virginia.

So, I think the lesson here is not that cloud services are unreliable and you should build everything yourself.  Rather, I think it’s a reminder to not believe the cloud marketing hype too strongly, and remember that cloud services are a leaky abstraction over the fact that you are programming someone else’s data center.  Most of the time that abstraction is a useful simplification which allows you to work more efficiently, but occasionally, like last Saturday, that simplification breaks down.  However, what I took out of responding to the crisis wasn’t a desire to move elsewhere, it was a set of improvements to the way we configure and maintain our service that could greatly improve our ability to respond to things like this in the future.  There’s no magic here, just a set of engineering tasks that we need to triage against other work like adding new features or improving documentation to provide the best experience for our users.  For example:

• When creating a service off a set of AWS services, it’s best to wire components together though cnames instead of directly to the public name of the service.  We had done this with our app and web tiers running on Elastic Beanstalk, but not with RDS and our Cloud Search instances.  Consequently, we had to change configuration on the production server instead of just swap in new services, slowing our response and increasing risk. 
• We need better monitoring of our services.  Both more extensive use of Cloud Watch metrics on key components of our services, as well as an external periodic smoke test of the application would have gotten us information about the problem more quickly.
• We need better automation of provisioning new environments.  Some Synapse components require a manual set up process, documented via a wiki.  Like most wikis we try to keep ours up to date, but things occasionally get missed.  An automated script to build a new environment checked into version control is self documenting and accurate if you continuously use it to create new environments.
• We should think hard about the number of different components comprising our service.  Some, like the Crowd server, offer only a bit of value for us, at the cost of making our overall environment more complex to administer and trouble-shoot.  We need to continuously watch our environment and make sure we are engineering for reliability and ease of maintenance as we expand functionality.

However, in the end, I still think the flexibility and development speed we get from building off of Amazon’s building blocks is worth the cost.  More days like last Saturday could change my mind about Amazon, but I’d likely be shopping for a more reliable vendor, not trying to bring more low level IT maintenance in house.

Well, in retrospect maybe we should have started that way from the very beginning.  I doubt it would have hurt anything, and it may have actually facilitated a collaboration or two that we missed out on over the initial stages of the project.  In our initial months at Sage, our team didn’t know what we had, or what we were doing, or if people would care at all about our vision.  We picked a set of development tools that were familiar and powerful (Atlassian’s hosted suite) and just focused on prototyping ideas and evaluating base technologies.  At the beginning our co-workers didn’t even pay much attention to what we were doing even though they were the customers we were supposed to be supporting.  It took some time for the vision of Synapse to form, and for us to start getting people interested in what we were building.

Once the project was underway, adding more functionality always seemed to take precedence over taking time to think about how to effectively get other to collaborate on development.   It was really only at the Sage Congress last April where we started demoing the product and felt enough traction forming within the community that we started believing we were seriously on to something. There’s still an awful lot of new functionality we desperately want to start working on and it’s quite tempting to dive straight into coding again.

However, we’ve now bitten the bullet and taken the last month to focus on not just moving code to Git, but also trying to structure our codebase and development practices to facilitate having other developers come on to the code base.  We’ve refactored the code base into smaller pieces, are putting more effort into developer docs, and thinking about how to review and incorporate check-ins from external developers.  We’ve had our first of a three new engineers start recently: a great young student on internship which is a good chance to do a dry run with a fresh set of eyes.  We’ve got more open positions I’m working hard to fill, but even more ideas than people who can implement them.  Hopefully taking the time to do this right now will let us more fully engage the community on the development front in the future.

The central issue we faced was how to manage data collected from people in clinical trials or other medical settings: in particular, data which have broad utility to seed future medical advances though research.  There’s been a pretty dismal history of medical research in this country, ranging from the cases of directly harmful experiments in the Tuskegee syphilis experiment to the much more common type of neglect and dehumanizing treatment described in Rebecca Skloot’s book The Immortal Life Henrietta Lacks.  This history resulted in the development of ethical rules and procedures to govern clinical trials, including a strong emphasis on patient privacy that greatly limits access to the data generated by those trials.  As part of enrolling in a clinical trial, patients sign an “informed consent” agreement in which they agree to participate in the research and are informed about the potential dangers and side effects of their participation, and give their consent for the trial to be conducted and data used in certain pre-defined ways.

However, many at this meeting felt that while the concerns around patient privacy and rights are real, many of the current rules do not serve the public well.  Current consent agreements typically limit who can access the data to ensure patient privacy and protect patients against those who might use the data against them.  Unfortunately, this arrangement also prevents widespread distribution of the data among researchers who could use that information to better advance treatments for diseases.  In fact, in many cases the researchers running trials use narrowly-framed consents as a shield to prevent data from being distributed to their scientific or corporate competitors.  Having a monopoly on data is good for individual scientific careers, but bad for future patients.

If you’re wondering why you should care about something that seems rather abstract and academic, just remember that that odds are very high that you or someone you love will someday come down with one of these sorts of diseases.  People usually get involved with groups like Army of Women or Michael J Fox Foundation when they or someone they love is touched by a particular disease. These groups are great, and the specifics of targeting a particular disease gives them incredible focus and energy.   However, we also think there’s a lot of general purpose infrastructure that doesn’t need to be reinvented in every disease area, and hope to partner with these sorts of groups to build it.  It’s a founding belief of Sage Bionetworks that open research will be faster and more effective research, and it’s our job to find ways to make open systems work with human health data.

An example of this infrastructure is an attempt to create a standard legal clause that can be dropped into informed consent agreements, giving patients the ability to opt in to broad sharing of their data for research purposes.  The Portable Legal Consent will act much like an open source software license: it will provide a standard way for patients to choose to place their data into the public domain for research purposes under terms that ensure the data will be easily and broadly shared among all researchers, not just those conducting the trial.

Of course, we don’t advocate changing clinical trials without the informed understanding and cooperation of patients.  As people at the meeting discussed the issue, the topic moved from issues of privacy to issues of respect.  Fundamentally, the problem with previous ethical lapses is that researchers stopped thinking of the people in the trials as actual people, and started thinking of them more like any other object of scientific scrutiny.  While it’s probably not feasible or productive to have researchers completely engaged in continuous dialog with patients, we feel the research community would benefit from more active engagement of the community they are ostensibly trying to help.   It’s not enough to simply ask patients to submit to research; we must find new ways to encourage patients to increase their involvement in medical research, and make that research as open and transparent as possible.

With Synapse, one of the areas we are being driven to develop more fully is the notion of attribution tracking.  The basic argument I get is “Papers are too coarse grained and slow to be published.  We need finer grained attribution tracking in real time so we can see everyone’s contribution.  That will allow people to get credit for smaller pieces of work, driving faster science.”  When I’ve used the “GitHub for Biology” analogy when explaining Synapse to scientists, the thing many latch on to is the notion that a digital record of their work could be used to drive career advancements like tenure decisions.  There’s a lot of interest in features allowing users to pull together the full history of their work and quantify its impact.  For example, what if on every Synapse project page you could get to the list of all people who contributed to generating and processing data before it entered the project, sort of an automatic generation of references? The knowledge that the software would drive complete attribution for downstream work might draw a lot more interest in contributing well-curated data to the Synapse Commons.

Of course this idea can be carried to extremes.  One of the worrying comments I actually got recently was that we should try to extend attribution tracking upstream to the point where we could capture the “generation of the key ideas” that could drive future work.  Basically, I had a scientist wanting to record pure ideas so that anytime anyone else did work to actually do something in that area; he could take the credit for coming up with the idea.  I had a flashback to an old Onion story about Microsoft patenting “Ones and Zeros”.  Pure ideas are cheap; making them work is hard.  If genius is “1% inspiration and 99% perspiration”, I think attribution clearly needs to be focused on the 99%.

I’m also a little worried that we’re over-emphasizing the notion that work needs to be clearly attributed to a single author.  GitHub, like other software development tools, emphasizes tracking work not primarily for the purpose of creating attribution but for the simple fact that fine grained tracking of code changes is often useful in resolving issues and getting work done more efficiently.  People were using code version control systems long before GitHub took the lead in connecting your check-in history to your online profile.  Even today, building a profile is a side-effect of doing actual work writing software.  Many of the most effective engineers I know contribute far more to a project indirectly through their interactions with their teammates than directly though lines of code added to the code base.

Much of a software engineer’s reputation and career advancement comes from the projects he’s worked on and companies for which he’s worked.  The best ones put the overall success of the project before their own need to attach their name to the work because they get excited by the potential of the project to change the world.  This is not unique to software engineering: I’m sure the engineers on the Apollo or Manhattan projects were also driven by the enormous vision and scope of the projects.  Trying to cut these projects up into “publishable units” where everyone got a few pieces would only have prevented their success.  I feel this is something we desperately need in the area of human health research.   Hopefully, our recently launched Sage / DREAM challenge on predictive modeling of breast cancer will help us start figure out how to create these sorts of driver projects around human health research.

With a bit of time to decompress I can now say I’m really proud of how far our team got, and the good reception we got from so many at the Congress. My full talk is now posted on the Congress website, including the nice bit in the R Studio portion of my demo where I am completely defeated by a podium with a slanted surface and no lip at the bottom.  I guess Isaac Newton wasn’t happy with my quote and the laws of motion took revenge.

We are starting to get real users kicking the tires now which is great, but also is highlighting all the work left to do.  May is now bug fixing time: no more new features until we solidify what we have. It’s also planning time at Sage, as we set development priorities for the summer.  If you dig into Synapse and have ideas of how to improve the system please let us know.  Even better, if you can write code we are looking to hire good software engineers.  We’ll also be taking steps to start pushing code into the open source community.  The past year things have not felt well-formed enough to nucleate any external contributions, but we’re now seeing signs that is starting to change.

In closing, my favorite talks of the Congress:

• Larry Lessing on Ingredients for Innovation – I which I could speak half this well.  A powerful talk on copyright issues leading into larger issues of corruption in our political system.
• Adrien Treuille on Crowdsourcing in Science – Wish I could think of something half as cool as his Fold It and Eterna games to engage users.  Will start by taking his advice on the magic of forums.
• Jaime Heywood on Patients Like Me and new ways to think about disease research.  Great approach to science, and a cool technology platform.