Reference documents, Safety Case

FMEA is focused on safety consequences of component failures. Identified failure modes of a component are analyzed case by case. The analysis process results in an explicit and documented decisions that take into account the risk associated with a given failure mode. The decision can be just the acceptance (supported by a convincing justification) of the consequences of the failure or it can suggest necessary design changes to remove (or mitigate) the consequences or causes of the failures. Documentation is an important output of FMEA. This documentation can be then referred to by a safety case for the considered system. 

It is rarely possible to completely mitigate a risk other than by somehow taking action to avoid the associated hazard in the first place. Instead, risks need to be reduced so that they become As Low As Reasonably Practical (ALARP). Remedial project actions should be specifically documented — this is sometimes referred to as the Safety Case. Remedial actions may employ hazard avoidance strategies, introduce hazard tolerant design feamres, or apply specihc project management controls, or a combination. Further information on risk management for medical devices can be found in ISO 14971. ... 

Careful thought needs to be put in to how key safety messages are communicated in training material. Often instruction manuals focus on the practical aspects of system functionality rather than the finer points of safe operation. This is especially the case when the only documentation available is that belonging to a manufacturer who undertakes little or no safety assurance. Sometimes the only reference to safety in the user guide is a disclaimer waiving the manufacturer s responsibilities. 

In terms of evidence, the safety case should set out (for those key hazards where human factors are important mitigations) a clear chain of logic from the control to a workable and effective policy. At the most basic level this should consist of a formal reference to the document or traceability from a series of controls to several relevant policies. By supplementing this with a description of how the above policy characteristics were achieved, further confidence can be built to show that appropriate diligence and governance has been applied. 

Note that where hazard registers are large it might be easier in the safety case to refer out to a dedicated document, appendix, annex or electronic report. Whatever format is chosen, it should be complete, intuitively structured aud be readily accessible to the intended stakeholders. 

A safety case is a comprehensive and structured set of safety documentation which is aimed to ensure that the safety of a specific vessel or equipment can be demonstrated by reference to ... 

A major issue regarding the document is the structural clarity. As a safety case needs a lot of supporting documentation usually a lot of references are made. Care has to be taken by the author, that there are not too many references of references as it can get itiqsossible to have a corrqrlete view and in addition to avoid circular references. 

The safety case evidence report is the final deliverable of the assurance process. Since the safety argument should be designed to be abstract, it is possible for a single version of a safety argument to cover multiple software installations, or multiple deliveries of a phased-delivery project. However, the safety case evidence report will need to address a specific software version and a specific installation. The safety case evidence report will identify the unique set of relevant evidence for the safety case. It will need to refer to the baseline of the software (which may be addressed by standard documentation such as a release note) and it will need to relate this to the appropriate set of safety evidence, including system level evidence. Each installation may have unique evidence specific site constraints a unique history of field experience perhaps using previous versions of the software, and different experiences of commissioning. 

Although a Safety Case is fundamentally nonprescriptive and performance-based, this does not mean that it will not call out industrial standards and codes—many of which are quite detailed. Not only will API standards be referred to, particularly those in the Recommended Practices 14 group, but documents from other professional bodies such as the American Society of Mechanical Engineers (ASME) and the Institute of Electrical and Electronics Engineers (IEEE) are also likely to be cited. 

Although a Safety Case will generally be large and comprehensive, not aU the information it uses will be included in the document itself. Reference documents can be stored separately. These references will generally be of three types ... 

Related Safety Documents This section should contain references to all other related safety documents used in support of the development of the safety case. 

According to EN50129 [1] the safety management has to describe the relationship to the subordinate safety cases, which is normally in the document Related Safety Cases , part 5 of the safety case. In this document the safety management confirms the process of SAC compliance with references to verification and validation reports. Also it has to be judged if all SACs of subordinate items have been fulfilled and proved or forwarded to a further level. SACs that could not be fulfilled within the scope of the own development project, but that are directed to the superior application level (compare with Fig. 2 and Fig. 3) must be passed on. Part 5 of the safety case contains a list of these SACs. 

If the above point is not possible, a direct argumentative reason and, if required, a reference to safety analysis, to test results or to other documents is possible. A testable SAC must, however, be covered with a test case at all means. 

The claim that all applicable hazards have been complied with [sic] is set in the context of whatever is determined as an applicable standard. Cl. .. refers to the set of standards identified as applicable (e.g. pointing to the document or file location / section where applicability is discussed and defined). The second example shows an argument. .. (SI). .. over. .. all hazards.. .. SI is only truly defined when the basis over which it is stated is made clear. C2 refers to where the identified hazards are discussed and defined within the supporting safety case documentation. The [third] example. .. shows context being used to communicate the basis on which a piece of evidence (solution) is being put forward.. .. C3 makes clear that the fault tree evidence referred to by Snl depends upon... 

Our discussion of documenting interdependencies within a safety case refers to two different forms of traceability. Firstly, we refer to the ability to relate safety argument fragments to system design components as component traceability (through a safety argument). Secondly, we refer to evidence across system s artefacts as evidence traceability. 

Holloway s example states that hazard HI is eliminated by formal verification, and that the probabihties of hazards H2 and H3 are estabUshed by FTA. The formalized top-level safety case simply makes reference to the documentation for these, but we can imagine that they could themselves be partially or fully formalized and automated. For example, infinite bounded model checking on a detailed... 

Each safety case is held as a Macintosh document, which appears as a document icon in the Finder. The complete safety case may be held in the document file, or (in an experimental variant) the file may hold a reference to an object-oriented database on a networked server. SAM normally presents the document content to the user as a mixed text and graphics presentation in a number of windows. It is possible to ask for a linear text version of the document to be created, displayed in a separate, single window and printed. 

A safety case is a written submission prepared by the operation of an offshore installation. It is a standalone document which can be evaluated on its own but has cross-references to other supporting studies and calculations. The amount of detail contained in the document is a matter of agreement between the operator and the regulating authority. In general, the following elements of an offshore installation are common for many safety cases ... 

Once the FDA receive the initial submission, an IND reference number is assigned. The application is then passed on to the appropriate review centre either the Center for Drug Evaluation and Research (CDER), or the Center for Biologies Evaluation and Research (CBER). Various experts will then review the submitted documents, the purpose being to ensure that the safety of subjects is not compromised and, in the case of Phase II and III studies, that the quality of study design is scientifically adequate. The FDA are allowed 30 days to complete the initial review, after which the study can commence, provided that it has been approved by an Institutional Review Board (IRB). 

In most cases these materials will be stored in the archives of the testing facility, and the report will so indicate. In the case of contract safety testing, however, a sponsor will sometimes ask that raw data, documentation, and specimens be sent to the sponsor for storage in the sponsor s archives. In other cases a laboratory may store some or part of the archival material at an off-site location. In either case the final report should reference the actual storage site(s). 

---