Safety Case information

The scale of such social issues is pnqwrtional to the length of time during which safety case information may need to be retrieved the "limitation period" inhoent in the Consuma Protection Act 1987 indicates that a safety case needs to be retained until at least 10 years after the supply of the last system using that case. 

The study of case histories provides valuable information to chemical engineers involved with safety. This information is used to improve procedures to prevent similar accidents in the future. 

The third and fourth disks include Occupational Health and Safety (OHS) information. These disks contain data bases on Resource Organizations, Resource People, Case Law, Jurisprudence, Fatalities, Mining Incidents, and ADISCAN. Furthermore, information on Noise Levels, National Institute for Occupational Safety and Health (NIOSHTEC) Non-Ionizing Radiation Levels, and a Document Information Directory System is readily retrievable. These CD-ROM materials are available from the Canadian Center for Occupational Health and Safety, 250 Main Street East, Hamilton, Ontario L8N 1H6. 

Any alarm system used must communicate clearly the nature of the emergency event and its severity. In a Level One Emergency some people may have to be evacuated in order to ensure their safety, but by and large the emergency can be contained within the unit. In that case, information usually may be given to unaffected employees through normal telephone communications. 

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

In addition, all case report forms containing potentially unblinding information and MRI images must be kept sequestered from the remaining study documentation, except if required for patient safety. This information enters the database only immediately before unblinding of the trial. 

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

Note that the approach does not preclude compliance with any specific regulatory or standard requirements. Rather the SMS should ensure that compliance is achieved in the course of safety case development. Essentially, the safety case represents an information superset and knowledge base potentially facilitating compliance with any number of relevant safety standards. 

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. 

If at the end of the analysis when go-live is nearing the constraints are still in place, the safety case is essentially incomplete and the situation needs careful management. A view should be taken on whether the missing information represents a... 

Note that in defining the system one should be careful not to use overly commercial language. The safety case is not the place to extol the virtues of efficiency gains, improved productivity, return on investment, etc. These are all important facets of product management, the business case and marketing but in the safety case these factors could be perceived as being an ill-informed means of justifying the clinical risk. Any text which is reused from other materials should have subjective elements removed so that a plain and factual system description is articulated. 

In some cases, especially where an organisation is managing a small and single product, it may be more efficient to set out the entire CRM process within the safety case itself rather than maintain this information separately. This has the advantage that the safety case becomes a self-contained justification without requiring the reader to consult extraneous material. 

The risk analysis and evaluation will form the heart of the safety case. It is here where the argument and evidence is set out to justify the report s safety claims. This information is inextricably linked to the detail in the hazard register but in the safety case one has the opportunity for further explanation and elaboration. The hazard register typically has a formal structure to support cohesion and consistency between hazards. The fiee-form text of the safety case facilitates articulation and openness enabling us to support our argument with direct and indirect evidence. Essentially the text provides the necessary inference between the hazards, causes, controls and evidence that is needed to justify the argument. 

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

Faults provide a rich schane of knowledge and the learnings may reveal new information which needs to be incorporated into the safety case and the risk re-evaluated. 

The safety case of this phase is based on the information generated by the conceptual design of the refurbishment. The following topics are addressed in the documentation submitted to SUJB for assessment ... 

The safety case should contain sufficient information about the facility to verily that the design and operating philosophy is consistent with the SMS and with the assumptions and outputs of the formal risk analysis. Using an offshore platform as an example, the safety case will generally contain the following minimum information. 

The safety case need not contain detailed procedures, calculations, drawings, or plans, but should contain sufficient information to allow the regulator to assess whether the systems and conclusions presented in the safety case are reasonable. General documentary evidence that supports the conclusions reached in the safety case should be referenced, and the regulator given access to the relevant documentation where necessary. 

For more information on how the System Safety Assessment came about (and a comparison with Safety Case), see Kritzinger, D.E, 2005. Aircraft System Safety Military and Civil Aeronautical Applications. Woodhead Publishing Ltd, Cambridge, CBl 6AH. 

Dislocation includes the failure of mislayering different information, e.g. information can conceal other safety-relevant information. Mistiming of displayed information can make safety-relevant action by the user too early or too late. Formatting failures, for example low contrast and tiny fonts, increase the risk of the user overlooking the information. Content anomahes refer to the failures that the information itself is corrupt or erroneous. This is also the case with wrong units for example, if speed is displayed without units it can be interpreted in km/h or mph. 

Gary Lang and Rhiatmon Hardy, UK HSE, paper submitted to the committee, April 2012. More information on HSE and safety cases is available at http //www.hse.gov.uk/offshore/safetycases. htm. 

NASA was an early user and developer of system safety methods for its complex systems. Most people recognize that space exploration is a risky business. The agency has introduced some concepts that are worth noting. One is risk-informed safety case, intended to determine if something is adequately safe. Another concept addresses the problem of what is adequately safe. NASA uses the term as safe as reasonably practicable. The NASA System Safety Handbook explains the concepts further (note 5). 

Risk-Informed Safety Case (RISC) NASA describes RISC as ... 

The safety work was given high visibility in the project, through the use of a hazard log which was accessible to all project team members and which managed safety-related tasks through to completion. The wealth of information captured within the tool considerably simplified the task of writing the safety case. 

---