Hazard analysis description

Preliminary Hazard Analysis Description. The incorporation of this information into a PHA entry is shown as Table II. This entry describes the proposed actions needed to eliminate or control the hazard (column 6), the risk assessment code assigned after controls (column 7), and the identification of applicable codes and standards (column 8). 

The handbook additionally provides an extensive overview and comparison of commercially available computer systems and software for chemical emergency planning. This section provides technical guidance for hazard analysis and identification implementing regulatory requirements and descriptions of computer applications and systems applicable under SARA Title III. 

Included in OSH As JHA Booklet, 3071, is a good description of a process hazard analysis (PHA) [1]. This is being used in the Process Safety Management (PSM) program (29 CER 1910.119) to understand how hazards exist. There are some good methods listed in the manual that can be used to conduct a JHA. As you review each method you can determine which one may be useful for your operation. The typical method chosen is the checklist. 

The term operability study should more properly be used for this type of study, though it is usually referred to as a hazard and operability study, or HAZOP study. This can cause confusion with the term hazard analysis , which is a technique for the quantitative assessment of a hazard, after it has been identified by an operability study, or similar technique. Numerous books have been written illustrating the use of HAZOP. Those by Hyatt (2003), AIChemE (2000), Taylor (2000) and Kletz (1999a) give comprehensive descriptions of the technique, with examples. 

A worksheet (data base spreadsheet) form is used to collect and collate the process hazard analysis review data. A computer software generated spreadsheet is typically used. For a complete description of commercially available HAZOP or What-If software, the user should refer to the manufacturer s HAZOP or What- If software User Instructions. Although pre-printed forms may be used, they are highly inefficient and should be maintained only as a backup in case of computer hardware or software failures. 

In the United States, the OSHA standard 29 CFR 1910.119 Process Safety Management of Highly Hazardous Chemicals requires that a hazard analysis must be carried out for any process involving certain listed chemicals (see Appendix A of the standard) or involving more than 10,0001b (4535.9 kg) of flammable gas or liquid. Employers must involve employees in the hazard analysis, and it must be made available to employees and updated at least every 5 years. Employees and contractors must be trained in safe work practices associated with the identified process hazards. Eull details of these and other legal requirements as well as descriptions of the information that must be included in the analysis can be found in the standard. The most recent version of this standard and all other OSHA regulations are available at www.osha.gov. 

The workflow should be broken down to manageable chunks each of which become a target for a round of hazard analysis and perhaps our what-if questions. It is at this stage that detailed hazards, causes and controls can be established which will form the bulk of the hazard register. The system business processes themselves may be derived from a number of different sources depending on the material available. Some systems may have detailed use cases with primary and exception flows carefully documented. For others the processes may need to be ascertained from training material, product descriptions or test cases. 

The scribe will enter the node description into the hazards analysis software. The start and stop points for the node should all be identified, as discussed above. Operations and maintenance experts will then provide some history and operating experience about it. Any relevant documentation to do with that node, such as equipment data sheets or MSDSs, should be put before the team at this time. 

Minimalist writing does not mean that a large number of words cannot be used where needed. If a hazards analysis team has uncovered a very serious issue that is also difficult to quickly understand, then a lengthy description should be provided in the report. Nevertheless, the writer of the report should still make every word tell. ... 

Details of statistical analyses for potential toxicities that should be explicitly considered for all products and AEs of special interest Aiialyses for these events will in general be more comprehensive than for standard safety parameters. These analyses may include subject-year adjusted rates, Cox proportional hazards analysis of time to first event, and Kaplan-Meier curves. Detailed descriptions of the models would typically be provided. For example, if Cox proportional hazards analysis is specified, a detailed description of the model(s) that will be used should be provided. This would generally include study as a stratification factor, covariates, and model selection techniques. More advanced methods, such as multiple events models or competing risk analyses, should be described if used (as appropriate). It is recommended that graphical methods also be employed, for example, forest plot and risk-over-time plot (Xia et al., 2011). 

Integral part of the risk analysis of a critical system is identification and assessment of hazards that significantly contribute to risk (Rausand Hoyland 2004). The hazard analysis generates data required in the next stage of analysis, which lead to description of risk scenarios, definition of safety functions, evaluation of actual risk levels and required risk reduction. Then the technical specification of safety-related functions to be realized by the system architectures considered to select most justified one. 

The subsystem hazard analysis report contains a description of the subsystem and a narrative summary of key findings that specifically address the adequacy of the controls placed on any high hazards associated with the end products, the level of residual risks that remain after controls have been applied, and recommendations for further analysis or testing. The report should also describe the techniques and methodology used in performing the analysis, including risk assessment and risk acceptance criteria. The report should also contain the hazard report worksheets used in the study. 

Analytical trees can be used in a variety of ways in the system safety effort. The most common application of analytical trees in current system safety programs is probably the use of fault trees for fault tree analysis (FTA). However, analytical trees can also be used as planning tools, project description documents, status charts, and feeder documents for several hazard analysis techniques (including fault tree analysis). Analytical trees can be multipurpose, life cycle documents and represent one of the most useful tools available to managers, engineers, and safety professionals. 

First, collect the input documents and reference resources. The primary input documents include an analytical tree and/or block diagram, drawings, and narrative descriptions of the system. The most important resources are a data base, lessons learned file, historical data, and/or other source(s) of failure rates or other reliability statistics. The preliminary hazard list (PHL), preliminary hazard analysis (PHA) and any other hazard analyses should also be available. 

For more detailed information, see the project description brochure (PDB) and the preliminary hazard analysis (PHA). 

This example will develop a hardware FMEA for a proposed system that is well into the design phase of the product life cycle. For informational purposes, it is assumed that a preliminary hazard analysis was previously performed during the early stages of the design phase of this system. The information from the PHA will be used to assist in the development of the hardware FMEA. It should also be noted that the nature of a FMEA requires evaluation of subsystems, subassemblies, and/or components. For this reason, more detailed and specific descriptive information is provided here than that supplied for previous examples discussed in this text. 

Software Preliminary Hazard Analysis This type of analysis is used to identify software program routines that are considered to be safety-critical, and thus is conducted prior to software program coding. To perform the analysis, the analyst should make reference to any available system specifications, interface documentation, functional flow diagrams, software flowcharts, storage and file allocation specifications, and any other program descriptive information. 

Recommend documenting the following information (1) comprehensive hazard description, (2) date listed, (3) reason listed, (4) applicable hazard analysis information, (5) controls used to reduce risk, (6) PPE issued to employees, and (7) training or education provided to deal with a hazard. 

Contemporary risk management follows a maturing path to the establishment, acceptance and management of a level of risk that is deemed tolerable and as low as reasonably practicable (ALARP). The recent issue of military standards [MoD 2004] describes six processes for risk management hazard identification, hazard analysis, risk estimation, risk and ALARP evaluation, risk reduction and risk acceptance. Whilst these are not the universal descriptions of the processes involved, the underlying principles are consistent with other procedures and handbooks, for example lEC 61 SOS, JSP 4S4 and Mil Stan 882D. 

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. 

DESCRIPTIONS OF HAZARDS ANALYSIS AND RISK ASSESSMENT TECHNIQUES... 

---