Safety cases references

For more on Safety Case, refer Chapter 9 in Kritzinger (2006). 

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. 

The previous chapter concerning safety cases referred to the importance of formal safety assessments (FSAs). An FSA is a technical assessment carried out to determine the likelihood and impact of high-consequence events and to help develop corrective actions. Most FSA work is done during the design of an offshore facility because that is the time when major changes to equipment design and layout can be made without having to carry out expensive retrofit work. 

However, the resolution of hazards is never satisfied. The Safety Case (refer Ch. 9) continually monitors the design and operational safety risks through a continuous process of hazard identification, and trend monitoring throughout the system s life-cycle. 

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. ... 

The use of the terms upper bound and worst-case refer to the expectations that this approach is likely to be highly conservative and will not underestimate potential risk. These terms are not meant to connote that statistical analysis to estimate error bounds would be performed, or that additional safety factors (traditional for extrapolation to acceptable daily intake values for non-carcinogens) would be incorporated into the extrapolation. 

Note that in discussing availability and performance one needs to make reference to the stakeholders responsible for hosting the system. In practice this could be the healthcare organisation, software manufacturer or a third party. The principles of fault tolerance and resilience remain the same irrespective of which party takes commercial responsibility. However the stakeholder responsible for implementing controls will vary as will the information available to safety case developers. In this... 

The CRM Plan should state or reference the agreed intended purpose and in this way contribute to the boundary setting of the CRM analysis and safety case. As a minimum a HIT system s intended purpose should include ... 

Most HIT safety cases would not typically stand up to the intense rigour of the scientific method. The safety case is not a mathematical proof. Rather it should present the rationale for a reasonably educated reader, through the careful appUcation of logic, to draw justifiable conclusions from the evidence presented. The technique is sometimes referred to as inductive reasoning and is the basis of many scientific theories. 

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. 

At the design stage a manufacturer may have identified the need to collaborate with users more closely. Perhaps they choose to convene a group of expert users to guide screen design, workflows and operational rules. The convening of these important consultations are likely to reduce risk and a summary of the sessions should be set out in the safety case preferably with reference to formal minutes. 

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. 

In practice, all actual safety management programs combine a mix of prescriptive and nonprescrip-tive approaches. For example, many offshore Safety Cases make reference to the API s Recommended Practice 14C, a prescriptive standard. On the other hand, judgment will always be required when prescriptive standards are being applied—no rule or standard can cover every possible situation. It would be invidious to state that one approach is better than the other. 

Key operating procedures and equipment identified in the Safety Case are referred to as Operating Rules and Safety Mechanisms. 

The third category is the PPB (Parts Per Billion) level safety that refers to the field incidents of Li-ion cells that were subjected to normal recommended operating conditions. This category is the most concerning one and corresponds to the cells not categorized in bulk safety and the failure mode in most cases is a thermal runaway during normal operating conditions. 

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 ... 

This chapter details all standards which have to be addressed, failure rate targets, allocated safety integrity levels, a description of requirements handed over from other safety cases and emerging from the hazard analysis and a reference forward to where each requirement is addressed. It also includes operational safety requirements. 

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. 

All the Assumptions on which the Safety Case depends, including the high-level Assumptions mentioned above, should be presented directly, and/or by reference. Assumptions usually relate to matters outside of the direct control of the organisation responsible for the Safety Case but which are essential to the completeness and/or correctness of the Safety Case. Each Assumption must be shown to be valid or at least reasonable according to the... 

For the doctrine of precedent to operate there must be reliable law reporting. Important judgements are published in the Weekly Law Reports (WLR), some of which are selected for the Law Reports. Another important series is the All England Reports (All ER). Important Scottish cases are reported in Sessions Cases (SC) and Scots Law Times (SLT). In N. Ireland the two main series of law reports are the Northern Ireland Law Reports (Nl) and the Northern Ireland Judgements Bulletin (N.I.J.B.), sometimes called the Bluebook. There are various specialist law reports, to which reference may be made when considering safety cases. A list of their abbreviations is published in the January edition of Current Law which also summarises current developments and current accident awards. 

Intrinsic variation exists whenever there is more than one argumentation style to support the safety claims of a particular product-line instance. Extrinsic variation, in contrast, is more peculiar to product-line safety cases. The source of this type of variation is not the product-line safety case itself but rather the reusable assets referenced in the safety case from product-line models such as the feature and reference architectural models. This is because many of these assets are expected to vary in how they are developed, configured and composed. This variation may change the contribution of these assets to safety and therefore may change the way in which the safety of the system is justified in the safety case. To this end, it is important that extrinsic... 

The new arrangements for health and safety which accompanied privatization were referred to by those in the industry as a safety cascade . This describes a system which greatly extends previous notions of self-regulation, by making the infrastructure controllers responsible for overseeing the safety of the operational network under the supervision of HSE . These controllers thus have responsibihties for their own activities under the HSW Act and for the entire operational network under the 1993 Railways Act. The key to this system is the Railway Safety Case (RSC). 

The reader is referred to appropriate books on preparing a safety case. See for example DISK (2000) in Further Reading at the end of this chapter. 

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. 

Petroleum Institute (API) developed their Recommended Practice 75 (RP 75), which recommended that offshore facilities develop a Safety and Environmental Management Program (SEMP). Like a safety case, RP 75 is mostly nonprescrip-tive. However, it makes extensive reference to industry standards (mostly from the American Petroleum Institute), and so it is perceived as being considerably more prescriptive then the safety case approach. Nor does RP 75 require that a formal assessment of acceptable risk (ALARP) be determined. 

---