Safety cases timing

The objective of a safety case is to demonstrate to the regulatory authority that a company is fully aware of the hazards associated with its operations and that they are conducted in a safe manner, such that employees and the public are not exposed to undue risks. The regulatory authority must examine the safety case and communicate the results of its examination to the facility, usually within a reasonable period of time. ... 

The Accident Database is a compilation of safety case studies and accident reported compiled by the (UK) Institution of Chemical Engineers (IChemE). The database is a subscription product but a time-limited trial version is available. 

At the outset of developing the plan it should be recognised that projects change and mature during their lifecycle. As such, it can be wise to revisit and reissue the plan from time to time (although a radical update immediately before the safety case is validated against the plan may prove questionable). In particular one needs to take... 

Over time there is always the opportunity for scope CTeep. The intended purpose may change or grow as the product is developed and healthcare organisations find increasingly innovative ways of harnessing a system s functionality. It is therefore important to monitor the currently defined intended purpose against its live operation and the product roadmap. Where the intended purpose changes, it is likely that the safety case will need to be revisited and the clinical risk reassessed. 

Assumptions that are made at the time of carrying out a safety assessment may later be proven valid or invalid. It is therefore sensible (and indeed desirable) to revisit assumptions from time to time and either declare them as facts or revisit the safety case to investigate the effect of the assumption being invalid. 

On occasion one encounters a situation where information is simply not known and no practicable assumptions can be made. In this case we may have an opportunity to undertake a part-assessment perhaps until a time when the information becomes unavailable. This is a perfectly reasonable approach so long as this limitation is formally documented as a constraint on the analysis and the project generally. It may even be appropriate to document which areas of the analysis have potential to change once more information does become available. Clearly it is important to monitor the provision of the information on which the safety case is dependent and build this into the project plan. If one believes that the information may not be available or forthcoming then this should represent a risk to the project and be documented and escalated accordingly. 

The argument set out in the safety case requires there to be coherence of user stories, requirements, code, testing, controls, etc. When documentation is at a minimum safety case developers can find it time-consuming to construct a logical argu-... 

Training is generally a less effective control but that doesn t mean its delivery or otherwise can be ignored. Human factor controls can be difficult to evidence so when time and effort are put into a robust training progranune its features form useful material for the safety case. 

In Sect. 11.1 we discussed the importance of defining the system by ascertaining its intended purpose and boundaries. It is worth reiterating this in the safety case itself as by the time this is being constructed it is likely that one will have a better handle on the precise nature of the requironents, functionality and design. Similarly it can be helpful to restate the rationale for the assessment and its regulatory position. As a minimum the text should set out ... 

No safety case can be complete without the inclusion of the hazard register. Remember that as the hazard register is continually evolving during the life of the product its inclusion in the report can only represent a snapshot at a point in time. It can be useful to point this out in the report and to ensure that the date aud/or version number of the hazard register is indicated. 

Note that it can be particularly helpful to reissue the safety case shortly after go-live (Version 3 in this example). This provides the safety case developer with the opportunity to monitor immediate post-go-live issues, often a time when many functional and non-functional defects are recognised. The identification and resolution of these issues can be concisely wrapped up in a post-go-live report with any newly established hazards, causes or controls neatly highlighted. This version of the report will often carry the systan through live service perhaps requiring only minor updates as and when changes are implemented or when new information comes to light. 

Assessing a safety-related fault is similar to documenting an argument in the safety case - only this time the trigger for the hazard is real rather than hypothetical. Also at time of writing the analysis, information is likely to be incomplete and the risk incompletely (if at all) mitigated. There are many ways of documenting the issue but a sensible approach is to ... 

It is unfortunate that many a safety case is constructed before product launch only for it to be filed away in the annals of history after go-live. The safety case is a key document for the lifetime of the product but its content shouldn t be static. There is much to be learnt from operating a system in a live environment and the world changes in ways that could impact the validity of the arguments set out in the safety case. It is the nature of the software industry that products evolve, new functionality is introduced and old methods are deprecated. Clinical processes change too and in a short space of time there can be extensive divergence between the original safely case and the product as it stands today. 

This phase is aimed at obtaining the regulatory authority consent to the implementation of a specific part of the refurbishment, which is to be accomplished during a particular planned outage of the subject unit for refueling. Hence, it will be repeated as many times as is the number of outages necessary for the completion of the refurbishment at this unit. The safety case will again be a kind of an update of the previous phase safety case, i.e. either of the 3A phase or 3B phase safety case, and will in addition include ... 

The first safety cases prepared for the process industries were those developed for North Sea offshore oil and gas operations following the Piper Alpha disaster that occurred in the year 1988. The Cullen report (Cullen, 1990) that was written following that accident was highly critical of offshore operating practices and recommended that a safety case approach be implemented. The Seveso incident that occurred in Italy further prompted the increased use of safety cases. Since that time the use of safety cases has spread to other industries (such as mining and railway operations) and to other nations, primarily in Europe and Australasia. (It is notable that the safety case regime approach has not been taken up for offshore oil and gas operations in the Gulf of Mexico—instead a more prescriptive approach based on industry consensus standards is used.)... 

A safety case is a living document that describes the safety of an operation from the initial concept design, aU the way through normal operations, to the eventual termination and shut down of the facility. The Safety Case is modified and upgraded as needed in order to ensure that risk and safety are properly managed at all times. 

This issue has come under particularly close scrutiny following the Deepwater Horizon incident in the Gulf of Mexico. At the time of the incident, the safety regulation in place for the offshore oil and gas industry in the United States took the form of a prescriptive, standards-based regime. The report of the National Commission on the Deepwater Horizon Blowout includes a summary of the development of the safety case approach in the nuclear, chemicals, aviation, and offshore oil and gas industry (National Commission on the BP Deepwater Horizon Oil Spill and Offshore Drilling 2011b, 69) and points out that the fatality rate in the offshore oil and gas industry in the United States is at least four times the fatality rate in European jurisdictions that have operated for several decades under safety case... 

---