General lab safety

The solid basis of safety in the wetlab is good laboratory practice. The best starting point for this purpose are personal safety precautions, such as gloves, safety goggles and lab coats. Besides this, a division of the lab into different areas is crucial, as we were 12 people working in our lab most of the time. We designated separate areas for documentation, which of course did not happen on the benches, for lab-work, where we also worked with genetically modified bacteria and an ethidiumbromide-area where we could perform gel-electrophoresis and gel-analysis.
Furthermore, we shifted working steps with β-mercaptoethanol, organic solvents and corrosives to the available fume cupboard. Naturally, we differentiated regular waste from S1-waste which, of course, is to be autoclaved. This should prevent any contamination of the environment with our bioactive material. We have received basic safety training for S1-work by the safety coordinator Mrs. Dr. Angret Joester before starting our work in the lab.

Wet-Lab-Project Safety

In addition to the general lab safety, we talked to the safety advisor on our campus, Dr. Willi Siller, with whom we double checked the feasibility of the project concerning its safety. One of his first questions was, which biosafety-level our donor- and chassis-organisms were ranked in. For the chassis-organism, this question was easy to answer, as we only used different strains of E. coli K12 and hence they all are ranked S1. As far as the donor organisms are concerned, the list is longer. However, all of them are categorized as S1, except for D. acidovorans, which is ranked S2 in Germany if used as a chassis-organism.
This classification is due to the fact that D. acidovorans is capable of causing inflammatory diseases such as endocarditis. Still, we can well justify the work with D. acidovorans on the strength of two aspects: Firstly, we never use D. acidovorans as chassis-organism and secondly, upon research, we spotted that the pathogenicity of D. acidovorans is based on proteins belonging to the Omp-family. The genes, that encode for those proteins are on a different locus than our genes of interest – the Del-cluster.
Consecutively, we can conclude that the work with either of the organisms we use for our project carries any risks for neither the experimentalist, nor for non-participants, if good laboratory practice is adhered to. As far as the peptides is concerned, we can state confidently that none of the peptides that we synthesize in our project are toxic or in any way hazardous. Tyrocidine is harmful to human blood and reproductive cells, but will never be used as entire peptide (i.e. only several amino acids) and was, besides that, publically available as antibiotic.
Within our project, we however intend to share knowledge with the broad scientific community and introduce a new and efficient way of in vivo production of short peptides via NRPSs. The framework of NRPS of course allows production of various peptides, and hence it is imaginable that this system is accidently or intendedly used for the synthesis of perilous products. There is however a straight-forward justification for either of the aforementioned dangers: Firstly, to avert unintended production of hazardous substances, we intend to include several precautions within our software, which is elaborated on in the according section. Secondly, someone contemplating malicious abuse of our proposed framework, would also have the chance to produce the dangerous substances by chemical synthesis.
As we, in our project intend to offer a more efficient way of recycling gold from electronic waste, we consider the implications of our projects for the environment a central point in our safety considerations. This reaches from the basic avoidance of contamination, which we ensure by good laboratory practice, to learning from and discussing with professionals about biosafety and precautions for the environment during an ABC-defense training (atomic, biological and chemical weapons) at the German Armed Forces.

Download Safety Form

Software-Safety

Our software team developed the NRPSDesigner, a web application capable of suggesting cloning strategies for the creation of artificial NRP-synthetases, which can synthesize a peptide of choice. This software is built upon a database of domains, origins and products. The very nature of this project meant that we were confronted with safety issues all web developers face, as well as by issues specific to the biological underpinnings of our software. The latter overlapped in many cases with our considerations throughout the wetlab projects.
Any web application has to deal with diverse attacks of malicious intent. Dealing with these was simplified by using Django, a stable web framework. Such frameworks try to trivialize common tasks in the work of a web developer and of course safety issues fall into this category. For example, Django provides a mechanism for protection against cross site request forgery attempts, in which a malicious site can cause actions in the server by using the credentials of a logged-in user. The Django development team also uses a very strict process for dealing with new security issues in a timely and safe fashion by initially fixing these through private, confidential channels. Once the patches have been applied, the security issue is publicly disclosed, so that server maintainers can update to the latest Django version. As an example, this September a set of security releases were issued by the Django development team in order to remedy a problem with denial-of-service (DoS) attacks. Of course, after being informed of this release, we immediately updated the Django version running on our server to the latest one.
A second issue arising during web development, is the safety of a user's confidential data. Again Django provides an in-built authentication system which encrypts the password of all registered users using PBKDF2 (Password-Based Key Derivation Function 2). Beyond the Django security features, we also used a password protected storage server for the MySQL NRPSDesigner database.
In regards to the biological background of the NRPSDesigner software, we were particularly troubled about not leading a user astray with the organisms suggested for the cloning, especially in case they were not of the S1 safety level. This is particular important in the case of NRPS, because many interesting NRPS such as Pyoverdine, a fluorescent siderophore, are produced by pathogenic microorganisms (e.g. Pseudomonas aeruginosa). As of the European wiki freeze, the NRPSDesigner database includes only S1 organisms. Nevertheless, as in the future the database may be expanded with S2 organisms, we intend to handle such cases by issuing appropriate alert messages to the end-user and also allowing him to filter the domains available to his constructs based on the safety level.
A second consideration arises from the extensibility of the NRPSDesigner database, which means that any user can enter new NRPS domain sequences. These in turn are fed into the algorithm for the design of synthetic NRPS constructs. Thus it is important to ensure that no malicious sequence can be entered, which could then be returned as the output of the NRPSDesigner to an unsuspecting user. This is achieved by ensuring the correct domains have been entered by use of the automated domain prediction pipeline using Hidden Markov Models. Additionally, a user that wants to be particularly safe, can filter the domains available to the NRPSDesigner algorithm according to curation status. (Curated domains have been entered or validated by an iGEM Heidelberg or Edinburgh 2013 team member or by another NRPS specialist in contrast to domains that have been entered by other end-users.) The other non-NRPS sequences, such as backbones, promoters etc., which can be added to the constructs after the domains have been determined by the software, are specific to the user that entered them (e.g. by the automated interface to the API of the Parts Registry) and hence pose no danger to other users.
Another important safety issue arising from the theoretical underpinnings of the NRPSDesigner is its use for the malicious synthesis of toxic peptides. Thus in a future version we want to integrate information from databases on toxins in order disable the design of NRPS domains for toxic peptides. We also searched for peptide toxicity prediction tools which could be integrated with the NRPSDesigner. One such tool, called ToxinPred [gupta2013], uses machine learning methods and a dataset of 1805 toxic peptides in order to accomplish this very task. Unfortunately, the current implementation only considers peptides consisting of proteinogenic amino acids and not the variety of modified or D-amino acids available to NRP-synthetases.

Download Safety Form