Line 74: | Line 74: | ||
<h1 class=topOfPage>Our Safety Case</h1> | <h1 class=topOfPage>Our Safety Case</h1> | ||
− | <img src="" style=" | + | <img src="https://static.igem.org/mediawiki/2017/thumb/9/95/T--UNebraska-Lincoln--NitrateSafetyCaseFull2017.png/1200px-T--UNebraska-Lincoln--NitrateSafetyCaseFull2017.png" style="width:100%;height:auto;"></img> |
<img src="" style="height:;width:auto;"></img> | <img src="" style="height:;width:auto;"></img> | ||
<a class=land name=general></a> | <a class=land name=general></a> |
Revision as of 02:05, 26 September 2017
UNL 2017
Helping reduce methane emissions from livestock
Safety Cases and
Their Use in iGEM Competitions
Introduction:
With a field like synthetic biology making leaps and bounds every year towards a realization of industrial and commercial use, safety is at the forefront of the minds of individuals deciding whether or not to start incorporating genetically modified organisms into their daily routines. Whether it be executives of large drug companies and industrial leaders looking for a cheaper solution in biosynthesis or simply a consumer debating the pros and cons of buying a product with a “GMO” label, people want to be certain that this new and exciting opportunity will be safe for both them and their community. Synthetic biologists are no strangers to safety themselves while working with biohazardous materials and inside high-tech biology labs, but sometimes the safety of the end-goal, products and processes utilized by people everyday, can elude the most well thought-out projects. This page hopes to help these projects work towards a safe implementation by logically breaking down and analyzing their safety concerns using Safety Cases.
Safety Cases take their design strategy from the aeronautics and software engineering communities where they can also be seen under the title Assurance Arguments using Goal Structuring Notation (GSN). There they are used to ensure the safety of various parts of the aircraft as a whole and target certain problem areas in the functions and dangers of the process of flight. As one can imagine, airplanes are a complex system of software and sensors that allow the pilot to traverse the skies safely, and in such cases, a systematic approach to addressing and solving every safety concern must be used. Unlike aeronautics, synthetic biologists do not have to worry about engine and wing design or console displays, but they do have to worry about accidental release of bacteria and plasmid conjugation just to name a few. As synthetic biology grows to new heights and levels of complexity, the number of safety concerns a single project or application needs to address will also grow. Just as people trust the engineering of an airplane despite the many risks, Safety Cases can help people who use genetically modified organisms feel confident that what they are using is safe.
Safety Case Units and Structure:
Safety Cases use an organized combination of structural units to help build arguments that prove the root goal of a project is safe. These units include Goal, Strategy, Context, Justification, Assumption, and Solution. As seen in Figure 1, each safety case begins with a single root Goal (usually stating that some project is safe) with Context units for the intended environmental conditions of the organism and the species and strain of the organism in use.
Figure 1
A Strategy (usually beginning with the word “Argument”) is then used to break that Goal down into smaller sub-Goals that each address a particular aspect of the project. A few examples of Strategies include “Argument over safety of distinct life stages of the product” and “Argument over identified hazards” (Many times one can’t explore all of the identified hazards in a situation. In this case, one would use a diamond (mentioned below) to symbolize the fact that there may be things in this area that need to be considered further.).
Justifications can be used to provide reasoning for a certain Strategy or Goal by reminding the viewer of certain facts established elsewhere. An example is provided in Figure 2. If a Strategy is “Argument over kill-switch parts” and it is used with the Goal “Organism is safe in case of accidental release” and a sub-Goal “Organism is killed in the presence of 0.5 mM of HCl”, a Justification could further enhance the sub-Goal by stating “0.5 mM of HCl is not found in the intended environment”. Likewise, Assumptions can be used to narrow the scope of a Strategy or Goal. A good use of this might be to state that one is assuming that some toxic chemical is not going to be added to the intended environment. One should also include these parameters in the initial Context units at the root of the Safety Case.
Figure 2
Solutions are used to provide closure to Goals, their parent-Goals, and Safety Cases themselves. A few examples can be seen in Figure 3. They can take the form of experimental data, modeling data, etc. The specific type of Solution that should be used is determined by the Goal they are solving and ultimately, the person filling out the Safety Case. A Goal is considered solved if there is a Solution unit directly following it, and a parent-Goal is considered solved if every one of its child-Goals is solved. Solved Goals can also serve as a valid Solution unit.
A Safety Case is considered solved if its root Goal is solved. If a possible solution can be identified but no evidence exists to support it, a Future Solution can be used a placeholder until it can be confirmed with sufficient evidence.
If a creator of a Safety Case wishes to convey that a certain Goal or Strategy is not fully developed and needs more consideration before finalization, they attach a diamond onto the unit. A diamond on a Goal can denote a need to think of more Strategies, and a diamond on a Strategy can denote a need to think of more sub-Goals. Diamonds do not necessarily mean that a creator did not think about a particular branch of a Safety Case. It only means that the creator of the Safety Case is addressing a need for more consideration.
Figure 3
In GSN, each type of unit has its own unique shape to better organize the information. Goals are represented by rectangles, Strategies are parallelograms, Contexts are shown with rectangles with rounded corners, and Solutions are circles. Both Justifications and Assumptions are represented by elipses with subscript “J” and “A” respectively. Future Solutions, not found in GSN formatters, are shown with rounded triangles.
Safety Cases provide flexibility in structure. Two different teams working on the same project could structure their Safety Cases very differently while still maintaining a high level of safety. However, there are certain rules that should be followed when developing the structure of a Safety Case. First and foremost, the first unit should be a Goal with two Context units describing the scope of the Safety Case: Environment and Organism. The Environment should include ranges of pH, temperature, and other factors such as exposure to light and specific substances. The Organism should include the species and strain of the organism(s) that the Safety Case applies to. Secondly, the general pattern moving down a Safety Case should be as follows: Goal, Strategy, Goal, . . . , Strategy, Goal, and finally a Solution/Future Solution. Finally, every child should be more specific than its parent and work towards a solution for its parent.
Modularity of Safety Cases for iGEM:
Our vision for the use and application of Safety Cases in iGEM competitions in the future hopes to address the growing concerns of the public surrounding the capabilities and safety of large-scale projects in synthetic biology. We believe the inclusion of Safety Cases in not only fully formed iGEM projects but also in basic and complex parts in the iGEM registry could help change the views of those still skeptical of the safety involved in synthetic biology. This includes an approach to modularity.
The modularity of Safety Cases can already be found in common practice in the aeronautics industry, but we think that iGEM calls for an even higher level of modularity. We hope that the use of Safety Cases will become common enough in iGEM that each part in the registry could come with its own Safety Case called a SafetyBrick. SafetyBricks will include specific precautions teams should take into consideration when using the BioBricks they are associated with and the Environment and Organisms the BioBrick has been proven to work safely in. Using these SafetyBricks, iGEM teams and other synthetic biologists could build complex system with a better understanding of how thoroughly the parts they use are characterized and how they might interact. In order for a team to use a BioBrick in their project, the Environment and Organism included in the part’s SafetyBrick must be fully included in their project’s Safety Case Environment and Organism to ensure predictability.
Safety Case Templates and Patterns:
Looking deeper into Safety Cases for a particular industry, one starts to notice a pattern between Safety Cases for similar projects. Using this, templates can start to be developed and perfected. In iGEM and synthetic biology, there exists a wide range of projects, but there are commonalities between some that can be used to help teams develop Safety Cases of their own. However, each project has its own distinct challenges to ensuring safety and this must be taken into account while developing a team’s own unique Safety Case. With more and more teams utilizing this method for ensuring the safety of their project, better investigations can be conducted into how these commonalities manifest themselves in the form of Safety Cases. While it was not in the scope of this project to construct multiple templates for iGEM teams to use, we are confident that after a more general acceptance and practice, templates could be developed and used in the future. UNebraska-Lincoln’s 2017 Safety Case’s base structure (Figure 4) could be seen as the first of these templates, although it is relatively specific and many teams would not find it valuable for their project.
Our Safety Case
Please visit the main Safety page to find this year's safety requirements & deadlines, and to learn about safe & responsible research in iGEM.
On this page of your wiki, you should write about how you are addressing any safety issues in your project. The wiki is a place where you can go beyond the questions on the safety forms, and write about whatever safety topics are most interesting in your project. (You do not need to copy your safety forms onto this wiki page.)
Safe Project Design
Does your project include any safety features? Have you made certain decisions about the design to reduce risks? Write about them here! For example:
- Choosing a non-pathogenic chassis
- Choosing parts that will not harm humans / animals / plants
- Substituting safer materials for dangerous materials in a proof-of-concept experiment
- Including an "induced lethality" or "kill-switch" device
Safe Lab Work
What safety procedures do you use every day in the lab? Did you perform any unusual experiments, or face any unusual safety issues? Write about them here!
Safe Shipment
Did you face any safety problems in sending your DNA parts to the Registry? How did you solve those problems?