Team:Cambridge/Outreach

Overview of Human Practices and Outreach

iGEM criterion: Outline and detail a new approach to an issue of Human Practice in synthetic biology as it relates to your project, such as safety, security, ethics, or ownership, sharing, and innovation.

Our human practices this year has been a driving force of our project from the start, defining many of its key features. This part of our project has drawn on the safety, sharing and innovation criteria in a three part sub-project as well as incorporating outreach. In the safety category, we go beyond the iGEM requirement of the safety questions to present our idea of the standard of obvious safety consciousness that teams should provide. In sharing, we explain how the desire to produce a system that would encourage sharing between iGEM teams and allow collaborative projects with greater ease was one of the factors that helped define our project from the start and how the necessity for this became increasingly obvious as the project continued and we faced problems trying to build on the research of other teams.

Innovation

We took the idea of considering our project as a product. Clearly in its current state it is not a product ready to go to market, but could be considered as a prototype for one that might be. Our system is designed to be used in a huge variety of circumstances, but for the sake of this exercise we have used just one.

The idea was to consider the process of taking our ‘product’ and putting it in a ‘market. We have considered a suitable market for the product – in this case groundwater contamination in rural India, weighed up the strengths and weaknesses of currently available systems that cater for this market and how our system differs.

We then consider the likely problems that would be faced were we attempting to attempt this now, ranging from mistrust of GMOs to bacterial disposal.

Why is this relevant?

The majority of us, whether we pursue careers in research or industry will probably at some point be involved with the production or release of a product. We have tried to use this as a trial run, to show teams what they might expect to come up against. We hope that this might inspire teams to consider human practices as a foundation for their projects as we did. Fluoride contamination was a major factor in the decision to design a system from start to finish that could quantifiably test for fluoride. We hope that this might encourage teams to think innovatively about their project when in the design phase, to consider a real world problem to which their project could be a solution and to consider the problems they might encounter in the course of applying that solution so that they can be tackled in the course of the project.

Our innovation project can be found here.

Safety

Safety is core to the iGEM competition and all teams must complete a series of safety questions on their wiki to qualify for a medal to prove that they have considered the safety implications of their project as a whole and have set about working in compliance with good laboratory practice. In addition to this criterion we have also produced protocols for reference for all of the techniques we use in the lab. These also have risk assessments for the major risks associated with them and precaution suggestion where appropriate as well as MSDS sheets for all reagents used available in the safety section of our wiki.

We assume that, like us, most iGEMers do not relish the thought of vast quantities of paperwork to accompany their projects. Our safety criteria do not impose this, but do demand further proof of safety consciousness than current requirements.

Why is this relevant?

The current team has found having this information readily accessible on the wiki (where it cannot be lost or tidied away) to be extremely useful and we consider it the duty of iGEM teams to leave their project in a sufficiently well documented state that future teams could pick up more or less where the previous team stopped.

Where teams choose to modularise their project into several sub-projects, different teams may be working with different experiments at any given time. It may be weeks before certain teams use techniques that others utilised on their first day. This is where having reliably accessible information comes into its own. Which reagent comes next? It’s on the wiki. Waste disposal? On the wiki. Do I need a mask for this? On the wiki. Is it supposed to go that colour? It’s on the wiki.

Perhaps more importantly, we have found that constantly updating and adding to the safety element of our project prevented it from slipping to the back of mind. We have found that we spent more time than anticipated considering the safety implications of experiments as we were planning and doing them, in the knowledge that we would be written up formally.

The provision of detailed protocols, MSDS and at least basic risk assessments can be hugely helpful to future teams, especially students coming to the iGEM competition from non-biological disciplines. Even those of us thoroughly familiar with techniques like PCR found the last team’s notes useful for reference in the early weeks of our project. Many excellent projects have been stopped short because of time constraints. If another team wanted to build on it, they might be able to ask the previous team if it is the next year and at the same institution, but if it is several years before the project catches the imagination of another team, then the wiki is probably all they’ll have to work with.

Sharing

Early in the summer, when we were trying to define our project, we started thinking about what we wanted it to do. We eventually settled on one of the key principles of synthetic biology – standardisation (strongly promoted by the engineers on the team). Biological research is currently a highly bespoke process with predominantly non-standardised biosensors – a multitude of output systems with a plethora of sensitivity curves exist. This renders individual sets of results amost meaningless as research from different teams is not directly comparable. This limits the capacity for sharing and collaboration as teams are effectively working on their own and this in turn limits the rate of progress.

To this end our project was focussed on producing a standardised output system with instrumentation for biosensor experiments to promote facilitate sharing and collaboration between iGEM teams, with a myriad of possible applications. A ratiometric system was chosen to provide a reliable quantification system, it was decided that the system should be portable so that it could be used for field research as well as laboratory based research and relatively cheap, to make it accessible to other iGEM teams. We felt it important that the code used in the instrumentation be open source like the rest of the project, so that it could be tweaked by future users to match their needs.

Why is this relevant?

iGEM is open source and high value is placed on sharing, collaboration and building on the work of previous teams. Where there is a lack of standardisation however, it is hard for teams to know what they can expect when working with another team’s project. We have attributed at least some of the problems we have experienced when trying to work with previous teams’ biobricks this summer to this problem.

We believe that a standardised output for biosensor experiments would be of enormous help to teams, giving them the tools to compare results, share and collaborate more effectively.

Outreach

Traditionally, this section of a wiki is labelled outreach and features teams promoting the iGEM competition and trying to improve public understanding and perceptions of synthetic biology as a whole. We have not had the time to do this as the vast majority of our project has been lab based; we have however written an article for the Cambridge University Graduate

A copy of this article can be found here.