Identify full range of hazards to support derivation of system safety requirements.
Sub-topic/point |
Actions |
Identifying full range of hazards |
Establish Artefact A Stage 1 |
Healthcare clinical pathway systems are intrinsically socio-technical and are constructed of three core components, technology, healthcare professional (HCP) and information. Each component has a specialised role, as will be the case for any ML component. However, these core components must all come together to achieve an overarching goal of providing healthcare services safely.
AMLAS adheres to a well-established safety engineering concept of system safety, whereby safety of a system component is only meaningful if its contribution to safety is considered from a system-level within the intended context. For this reason, prior to applying the stages of AMLAS there is a pre-requisite for system safety requirements (Stage 1: Artefact A) to be established which should be derived by initially conducting system safety analyses that identify system-level hazards.
Considerations for identifying full range of hazards to establish system safety requirements
1. Technique selection: selecting analyses techniques that are fit for purpose will enhance the chances of identifying full range of hazards that are caused in healthcare by technology, human factors, or information flows. It is feasible, more than one technique may need to be utilised to identify the hazards. Table 1 offers existing analysis techniques to capture the hazards, although it is by no means exhaustive.
2. HCP Inclusion: prior to implementing AMLAS, identification of credible system level hazards and corresponding safety requirements is vital due to their cascading dependency in each AMLAS stage. This identification is unlikely to happen correctly, and in a timely manner, if only those who have an engineering or safety role are consulted. Therefore, explicit inclusion of HCPs should be considered. Their expertise, knowledge and skills obtained from being embedded in clinical pathways will enrich output.
3. Analyses scope: all analyses must be scoped within a boundary of responsibility to identify credible hazards (that is, potentially lead to patient harm) from which safety requirements may be derived. To this aim, a clear understanding of the clinical pathway is required to realise in context each component’s influence from a safety perspective. Graphical process flow charts can be one of many approaches to achieving this objective.
4. Establish requirements: functional safety requirements (requirements established to ensure a product operates correctly to maintain the overall safety2) are the obvious choice when establishing safety requirements for technology. However, full consideration must be given to the safety requirements associated with human factors, such as, situational awareness, automation bias and human-machine teaming, to mention a few3. Furthermore, ML has brought into scope attributes typically associated with humans from which now there is a need for safety requirements to be derived. A few of these attributes are, interpretability, explainability and fairness, which all fall under the umbrella term, transparency.
5. Safety requirements allocation to ML: once derivation of system safety requirements is complete, they will become Artefact A as labelled in AMLAS stage 1. Subsequent AMLAS activities will expect allocation of ML safety requirements derived from the system safety requirements, which the ML must then satisfy through the ML development lifecycle, as prescribed by AMLAS stages 2-6.