The Safety Case

A safety case approach along the lines of the Seveso63 requirements is another possible alternative for determining regulatory coverage. The safety case requires a detailed explanation of why a process is safe to operate. Again, objective criteria such as NAICS codes, thermodynamic properties, or some combination of those criteria previously discussed are used to establish coverage. 

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 safety case may be prescriptive or performance based Although this approach is comprehensive, if applied to reactive hazards, it requires that regulatory agencies have expertise to assess the adequacy of the analysis. 

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

Any risk-benefit analysis should be clearly set out in the safety case with the appropriate justification, rationale and supporting evidence. The complexity of the arguments involved warrant close cooperation between manufacturers, users and regulators. In most cases the inclusion of potential benefits in the safety case is simply not required in HIT CRM and, if anything, introduces subjective noise into an otherwise objective methodology. 

The role of incident reporting systems in HIT is still unclear from a practical perspective. Challenges remain in particular for ascertaining the precise role of technology in its contribution to an adverse incident, i.e. did it cause the event, fail to prevent it or simply remain a passive onlooker. Certainly the safety case should not be a replacement for sound incident reporting. But keeping a careful eye on local and national incident data will influence the hazards derived and the likelihood component of risk estimation. 

The reporting of adverse incidents should not be relied upon as a sole means of identifying and managing potential hazards. However, the real-world performance of systems is important in assessing the effectiveness of controls and the on-going validity of the safety case. 

Healthcare organisations need to have business continuity plans in place and hosting organisations need tried and tested disaster recovery strategies. The existence of these plans and policies can be used to support the safety case. 

Finally note that an SMS is not the same as a safety case. The SMS sets out the processes and methodologies that an organisation will harness in pursuit of building a safety case. In other words the safety case is one of the outputs of applying the SMS to a particular HIT solution or component. Whilst the SMS will define acceptability criteria it will say nothing about whether the risk profile for a specific system is tolerable. 

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. 

Where an organisation has a single product which is regularly subject to CRM activities, it is not unreasonable to discuss the CRM methodology exclusively in the safety case itself. In this way, each section of the report essentially reads as ... 

Where extension of use is conducted as part of a controlled roll out it should be subject to the usual change management procedures which will have been established in the in SMS. Essentially a set of safety activities will need to take place on the product to determine whether the new operating environment introduces any new hazards and the safety case updated accordingly. The analysis will need to be able to justify operating the system outside of the intended purpose and set out the evidence to support the claim that the risk remains acceptable. 

Systems can only go so far in preventing deliberate or inadvertently reckless acts and the safety case should reflect this real-world limitation. 

The Safety Case Report - setting out the argument and evidence to support the... 

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

At an early stage in the project planning it is necessary to carefully define the scope of the system or module under examination. Limiting and articulating the scope is necessary to define the boundaries that have been applied to the analysis. More importantly, this formalises those system entities which have not been subject to analysis. The safety case will therefore say nothing about the clinical risk associated with those components outside of that defined boundary. By instituting boundaries early on in a project one is able to more accurately size the target and define the resources and timescales necessary to complete the task. 

A key purpose of the safety case and the associated hazard log is to formally communicate those controls which other stakeholders are required to implement. In many cases, this translates into a natural boundary between the supplier of a HIT system and the healthcare organisation who implements it. Safety cases frequently demarcate the scope at this convenient level and also make it possible for the parties developing safety cases to mirror the commercial contract. 

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. 

A key danger in the retrospective approach is to fall into the trap of conveniently building the safety argument around selective evidence which happens to be at hand. To do so runs the risk of forcing the safety case to articulate an artificially rosy picture of the world. It can be easy to assume that a much-loved system that has been in operation for many years must be intrinsically safe. That is not to say that it is unsafe but one should actively question whether the data which happens to be available can truly and objectively substantiate the safety case s claims. In some circumstances it may be appropriate to undertake the hazard assessment in a virtual vacuum of operational knowledge perhaps involving personnel who are somewhat removed from its day-to-day business. In this way appropriate controls can be developed and more objectively be tested to determine whether they can be traly validated. 

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. 

---