Topic 1.6 — Clinical Safety & Risk Management

In one sentence: Clinical safety is the disciplined, evidenced practice of finding the ways your digital technology could harm a patient and controlling those hazards before they reach anyone — safety designed in from the first sketch, not bolted on before go-live.

Why this matters in health and care#

In most sectors a software defect is an inconvenience: a page fails to load, an order is duplicated, a report is late. In health and care the same class of defect can kill. A medication field that truncates a decimal point, a results screen that shows the wrong patient, a triage algorithm that quietly stops flagging a symptom, an integration that silently drops allergy records — each is a software bug, and each is also a clinical hazard capable of causing severe harm or death. This is why clinical safety is not a quality nicety layered on top of good engineering; it is a distinct, regulated discipline with its own standards, roles, and evidence.

The stakes are asymmetric and often invisible. When a digital system works, no one sees the harm it prevented; when it fails, the harm can be catastrophic, delayed, and distributed across thousands of patients before anyone notices a pattern. That combination — high consequence, low visibility, wide blast radius — means you cannot rely on users to catch problems or on incidents to teach you everything. You have to reason about harm proactively, before deployment, and keep reasoning about it while the system is live. In the United Kingdom this proactive reasoning is not optional: NHS organizations and their suppliers are contractually and professionally expected to apply national clinical risk management standards, and to be able to show their working. Getting this right is inseparable from evidence (see Topic 1.3 — Evidence-Driven Decisions), from information governance and cyber security (see Topic 1.7 — Information Governance, Data Protection & Cyber Security), and from how you run services once they are live (see Topic 3.8 — Service Management & Live Operations).

Core concepts#

Patient safety and risk management. Patient safety is the prevention, reduction, reporting, and analysis of harm to patients from care. Clinical risk management applies the general discipline of risk management — identifying, evaluating, prioritizing, and controlling risks — to the specific question of how a health IT system could contribute to patient harm. The two national standards that govern this in England are DCB0129 and DCB0160 (DCB stands for Data Coordination Board; these are Standardization Committee for Care Information Standards / SCCI standards mandated under the Health and Social Care Act 2012). DCB0129 places obligations on the manufacturer or supplier of a health IT system; DCB0160 places obligations on the health organization deploying and using it. They are complementary: a supplier's clean safety case does not discharge a deploying trust's duty to assess the hazards introduced by its own configuration, workflow, and context.

The Clinical Safety Officer (CSO). Both standards require a named, suitably qualified and experienced Clinical Safety Officer — a registered, currently practicing clinician who has completed recognized clinical safety training — to own the clinical risk management activity and to personally approve the safety case. The CSO role is a competence requirement, not a job title you can assign to whoever is free. The CSO signs off that hazards have been identified and controlled to an acceptable level; it is a professional judgment carrying professional accountability.

The clinical risk management artifacts. Three documents anchor the discipline. The clinical risk management file is the container for all safety evidence for a system. The hazard log is the living register of every identified hazard, its causes, consequences, risk rating, controls, and residual risk. The clinical safety case is the structured argument, supported by evidence, that the system is acceptably safe for its intended use in its intended context — accompanied by a safety case report that summarizes the argument for approval. These are not paperwork for its own sake; they are how safety reasoning is made explicit, reviewable, and durable.

Hazard analysis: identification, analysis, evaluation, control. The core loop is: hazard identification (systematically imagining how the system could contribute to harm — through workshops, clinical walkthroughs, failure-mode analysis), risk analysis (estimating the severity of harm and the likelihood of it occurring), risk evaluation (comparing the estimated risk against acceptability criteria), and risk control (introducing measures — design changes, alerts, training, procedures — to reduce unacceptable risk, then re-evaluating the residual risk). Risk is reduced as low as reasonably practicable (ALARP): you keep controlling until further reduction would be grossly disproportionate to the benefit gained.

Medical device regulation, the MHRA, and Software as a Medical Device (SaMD). Some digital health technology is a regulated medical device. Software that has a medical purpose — diagnosing, preventing, monitoring, predicting, treating — can itself be a medical device: Software as a Medical Device (SaMD). In the UK the Medicines and Healthcare products Regulatory Agency (MHRA) regulates medical devices, including SaMD, and the software lifecycle standard IEC 62304 governs how such software must be developed. Deciding whether your technology is a regulated device is a threshold question with large consequences, and it is separate from — though it sits alongside — DCB0129/0160 clinical risk management.

The Digital Technology Assessment Criteria (DTAC). DTAC is the national baseline that NHS and social care organizations use to assess digital products before procurement, covering clinical safety (evidence of DCB0129 compliance), data protection, technical security, interoperability, and usability. It does not replace clinical risk management; it checks that a supplier has done it.

Human factors and safety culture. Human factors (ergonomics) is the scientific study of how people interact with systems under real conditions — fatigue, interruption, cognitive load, alarm fatigue. Most digital harm arises not from code that is "wrong" but from designs that make the safe action hard and the unsafe action easy. Safety culture is the organizational commitment to surfacing, reporting, and learning from risk without blame — the difference between a team that hides near-misses and one that mines them for improvement.

Incident reporting and learning. In England, Learn from Patient Safety Events (LFPSE) is the national service for recording patient safety events, and the Patient Safety Incident Response Framework (PSIRF) sets out how NHS organizations respond to and learn from incidents — emphasizing proportionate, systems-based root-cause analysis over blame. Live systems generate new hazards, so clinical safety continues after go-live through incident feedback into the hazard log.

Best practices#

1. Appoint a competent Clinical Safety Officer and give them real authority. Name a registered, practicing clinician with recognized clinical safety training as CSO for every system in scope, and ensure their sign-off is a genuine gate, not a rubber stamp reached the day before launch. The CSO must be able to say "not yet" and be heard — which means protecting their time, their independence, and their standing with the program board. A CSO who is overruled by delivery pressure is a governance fiction.

2. Do hazard identification early, with clinicians in the room. Start hazard workshops in discovery and design, not before go-live, because the cheapest and most effective controls are design changes made before anything is built (see Topic 3.5 — Delivery Lifecycles). Bring frontline clinicians, not just analysts, because they know how the work really happens — the interruptions, the workarounds, the way a screen is read at 3am. Walk through realistic clinical scenarios and ask relentlessly: "how could this system contribute to a patient being harmed?"

3. Keep a living hazard log, not a launch-day document. Treat the hazard log as a persistent register that opens at discovery and never closes while the system is live. Every hazard records its causes, potential harm, initial risk rating, the controls applied, and the residual risk after controls. When an incident, a change, or a near-miss reveals a new hazard, it enters the log and is worked through the same loop — the log is the memory of your safety reasoning.

4. Make the deploying organization own DCB0160, even with a compliant supplier. A supplier's DCB0129 safety case covers the product as built; it cannot cover how you configure it, which workflows you wrap around it, or which of your populations use it. Run your own DCB0160 assessment for local hazards — integration with your other systems, your data quality, your clinical pathways — and hold your own hazard log. Assuming the supplier's assurance covers your context is a common and dangerous shortcut.

5. Make risk control proportionate and prefer design over warnings. Rank controls by strength: designing the hazard out (constraints, defaults, forcing functions) beats an on-screen alert, which beats a line in a training manual. Reserve the heaviest assurance for the highest-consequence hazards and apply lighter, faster process to genuinely low-risk changes — proportionality is what lets safety keep pace with delivery. Reduce risk to ALARP and record why the residual risk is acceptable.

6. Design for human factors, and respect alarm fatigue. Assume users are busy, interrupted, and pattern-matching, and design so the safe action is the easy, default action. Guard against alert overload: an alert that fires too often is ignored, so every additional warning must earn its place or it degrades the ones that matter. Usability testing under realistic conditions is a clinical-safety activity, not just a design nicety.

7. Determine your regulatory status deliberately. Ask early whether your software meets the definition of a medical device or SaMD, and if so, engage MHRA requirements and IEC 62304 from the outset rather than discovering the obligation late. Getting classification wrong is expensive in both directions — an unregistered device is a legal and safety failure, while over-classifying a simple tool wastes scarce assurance capacity. When in doubt, seek regulatory advice and document the reasoning.

8. Use DTAC as a floor, not a finish line. Treat the Digital Technology Assessment Criteria as the minimum entry check for any procured digital product, confirming that clinical safety, data protection, security, interoperability, and usability have been addressed. Passing DTAC means a supplier has done the work; it does not mean the product is safe in your context, so pair it with your own DCB0160 assessment and live monitoring.

9. Close the loop from live incidents into the hazard log. Wire your incident reporting — LFPSE submissions, PSIRF investigations, local near-miss reports — back into clinical risk management so that real-world harm and near-misses update your hazards and controls. A safety case that is never revisited after go-live rots, because live systems, integrations, and clinical practice all drift (see Topic 3.8 — Service Management & Live Operations). Learning is systems-based and blame-aware, not a search for someone to punish.

10. Build a just, reporting safety culture. Make it safe and expected to report near-misses and to challenge a launch on safety grounds, because hazards you never hear about are hazards you cannot control. Leaders set this tone by responding to bad news with curiosity and improvement rather than blame, and by treating the CSO's caution as valuable rather than obstructive. Culture is the substrate on which every other practice here depends.

Questions to discuss with your team#

1. Where in our current portfolio are we relying on a supplier's safety assurance to cover risks that are actually ours to own? This question probes the DCB0129/DCB0160 split, which teams routinely blur. A supplier's DCB0129 safety case addresses the product as manufactured, but the moment you configure it, connect it to your other systems, wrap local workflows around it, and point it at your specific patient population, you introduce hazards the supplier never assessed and could not have. The honest tension is that running your own DCB0160 assessment costs scarce clinical and analytical time, and it is tempting to treat a supplier's clean assurance and a DTAC pass as sufficient. Work through a live or imminent deployment and ask concretely: who is our named CSO for it, do we have our own hazard log, and which hazards arise purely from our local context rather than the product itself? A good answer names specific systems where local assessment is thin, distinguishes product hazards from deployment hazards, and commits to owning the latter rather than assuming they are covered.

2. How proportionate is our clinical safety process — are we burying low-risk changes in paperwork while high-consequence changes slip through on momentum? The topic argues that assurance should scale with clinical risk: heaviest scrutiny for the highest-consequence hazards, lighter and faster process where risk is genuinely low. This question tests whether your organization actually calibrates, or applies one blunt setting. Both failure directions are real and costly — a uniformly heavy process trains teams to see clinical safety as a bureaucratic tax and to route around it, while a uniformly light process lets a change to a medication-dosing calculation pass with the same effort as a change to a help page. The subtler danger is that momentum, not risk, decides scrutiny: a flagship program with executive attention can acquire an aura of inevitability that discourages the CSO from saying "not yet." Examine two or three recent changes of clearly different risk and ask whether the effort spent matched the potential for harm, and whether anyone felt able to slow the high-profile one. An honest answer admits where the process is mis-calibrated in either direction and treats proportionality as a defensible, explicit judgment rather than a reflex.

3. When something nearly went wrong with one of our digital systems, what actually happened next — and would a frontline clinician say it was safe to raise it? This question examines safety culture and the incident-learning loop, which is where stated commitments meet reality. Clinical safety depends on hearing about near-misses, but people only report when reporting feels safe and worthwhile, and when they see it lead to change rather than blame. The tension is that under delivery and reputational pressure the instinct is to explain away a near-miss, close it quickly, and move on — especially if surfacing it fully would delay a launch or embarrass a senior sponsor. PSIRF's systems-based, blame-aware approach exists precisely because searching for an individual to fault suppresses the reporting you need and misses the real, systemic causes. Ground the discussion in a specific recent near-miss or incident: was it logged, did it reach the hazard log, was a proportionate investigation done, and did anything actually change? A good answer is candid about whether reporting felt safe, distinguishes genuine learning from paperwork closure, and names concrete behaviors leaders will adopt so the next person who spots a hazard speaks up.

4. Have we honestly determined which of our products are regulated medical devices — and who is accountable for that decision? Regulatory status is a threshold question with outsized consequences, and it is easy to leave unanswered because answering it can be inconvenient. Software that diagnoses, predicts, monitors, or treats may itself be Software as a Medical Device, pulling in MHRA obligations and the IEC 62304 lifecycle standard — separate from, and additional to, DCB0129/0160 clinical risk management. The tension runs both ways: under-classifying leaves you shipping an unregistered device, a legal and safety failure that can surface catastrophically at scale, while over-classifying a simple administrative tool burns scarce assurance capacity you needed elsewhere. The danger is that classification falls between roles — clinicians assume the engineers decided, engineers assume the regulatory or commercial team decided, and no one has actually written down the reasoning. Look concretely at the products in your portfolio that sit closest to the line — anything with a triage rule, a risk score, an alerting algorithm — and ask who made the device determination, on what basis, and whether it is documented and revisited as features change. An honest answer names the borderline products, points to a recorded and defensible rationale for each, and is candid where the decision was never really made.

5. Are we designing hazards out, or are we quietly accumulating alerts and warnings our clinicians have already learned to ignore? The topic ranks controls by strength — designing the hazard out beats an on-screen alert, which beats a line in a training manual — yet alerts are the path of least resistance, because adding a warning is fast and feels responsible while redesigning a workflow is slow and contested. Over time this bias accretes into alarm fatigue: so many warnings fire that clinicians pattern-match past all of them, including the one that matters, so each new alert can actually reduce safety. The real tension is that every unnecessary alert has a sponsor who added it in good faith after some incident, which makes warnings politically hard to remove even when they are degrading the system. Human factors is the discipline here — designing so the safe action is the easy, default action for a busy, interrupted user reading a screen at 3am — and usability testing under realistic conditions is a clinical-safety activity, not a design nicety. Examine a system your teams actually use and ask how many alerts a clinician meets in a typical task, which of those genuinely change behavior, and where a forcing function or a better default could have replaced a warning entirely. A good answer resists the reflex to add another alert, treats alert load as a measurable hazard in its own right, and is willing to remove warnings that no longer earn their place.

6. As our live systems, integrations, and clinical pathways drift over time, how do we know our safety case still holds? Clinical safety does not end at go-live; live systems generate new hazards, and the world around a system keeps moving — an upstream integration changes its data, a clinical pathway is redesigned, a supplier ships an update, a new patient cohort starts using the tool. A safety case approved two years ago describes a system and a context that may no longer exist, so the question is whether your hazard log is a living register or a document that was signed once and left to rot (see Topic 3.8 — Service Management & Live Operations). The tension is that maintaining safety reasoning after launch competes with new delivery for the same scarce CSO and clinical time, and drift is gradual and invisible in a way that rarely commands attention until something fails. Concrete angles include change control that re-triggers hazard assessment when configuration or integrations change, periodic review of the highest-consequence hazards, and monitoring that would actually detect a control silently degrading. Pick a system that has been live for a year or more and ask when its hazards were last reviewed, what has changed underneath it since approval, and who would notice if a key control stopped working. An honest answer distinguishes systems with genuine ongoing safety management from those coasting on a stale safety case, and commits to a proportionate cadence of review tied to real change rather than the calendar alone.

In practice: a health & care example#

An integrated care system (ICS) is deploying a shared e-referral tool that lets GPs refer patients directly into community services, with a built-in triage rule set that routes urgent cases to a faster queue. A delivery-driven approach would take the supplier's DCB0129 safety case, pass DTAC, and go live to hit a board-promised date.

Instead, the program appoints a practicing GP with clinical safety training as Clinical Safety Officer and opens a clinical risk management file and hazard log at the start of design. Early hazard workshops with GPs, community nurses, and administrators surface several hazards the supplier's product-level case never touched — all arising from local deployment. The worst: the triage rules were configured against the ICS's own service definitions, and a mapping error could route an urgent skin-cancer referral into a routine dermatology queue with a multi-week wait. That hazard is rated high severity, plausible likelihood.

Working the risk-control loop, the team prefers design over warnings. They add a forcing function so an urgent clinical flag cannot be overridden silently by the routing logic, a reconciliation report that a clinician reviews daily, and — lowest in the hierarchy — a training note. Residual risk is re-rated and judged acceptable and ALARP; the CSO records why. Because the tool only routes and does not itself diagnose, the team assesses it as not meeting the SaMD threshold, documents that reasoning, and files it. Human-factors testing catches a separate problem: an over-eager "duplicate referral" alert fires so often that GPs are already ignoring it, so it is redesigned to trigger only on genuine duplicates.

At go-live the DCB0160 safety case is approved by the CSO, not the program director. Three weeks in, an LFPSE report and a near-miss flagged by a receptionist reveal a new hazard — a free-text field being used to smuggle in urgent information the routing never sees. Under PSIRF, a proportionate, systems-based review runs, the hazard enters the log, a design change is scheduled, and an interim control is briefed the same week. The safety case is a living argument, and the record shows exactly how each hazard was reasoned about — which is what an inspector, a coroner, or a new CSO in two years' time will need.

Sector lenses#

Everyone owes the same duty to control clinical risk, but the machinery, incentives, and pressures differ sharply by organization.

Startup#

A digital-health startup often meets clinical safety as a procurement gate: an NHS buyer asks for DTAC and a DCB0129 safety case, and there is a scramble. The winning move is to build clinical risk management in from the first sprint — a hazard log alongside the backlog, an accessible Clinical Safety Officer (often contracted rather than employed, but genuinely competent and empowered) — because retrofitting a safety case onto a finished product is slow, expensive, and unconvincing. Founders must also confront the SaMD question honestly and early, since discovering mid-scale that the product is an unregistered medical device is an existential legal and safety risk. Done well, mature clinical safety artifacts become a commercial asset that shortens NHS sales cycles.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a domiciliary-care agency, a single-site clinic, or a small health-tech supplier past the pre-revenue stage — carries the same DCB0160 duty as a large trust when it deploys and configures digital systems, but with none of the spare capacity to discharge it. There is rarely a dedicated CSO or safety analyst on the payroll, so the practical route is to buy in a competent, practicing clinician on a contracted basis and to keep a lean but genuine hazard log rather than pretend the duty does not apply. The sharpest local hazards are usually configuration and workflow ones — how the shared record is set up, how urgent flags are handled, how one part-time administrator's workaround becomes a routing risk — precisely the hazards a supplier's DCB0129 case never covers. Proportionality is the small provider's friend here: concentrate the little assurance time you have on the highest-consequence hazards, use DTAC and the supplier's safety case as a floor when choosing products, and lean on shared resources such as ICS clinical-safety support rather than trying to build the whole apparatus alone.

Enterprise#

An NHS trust or ICS carries dual accountability: it deploys others' systems under DCB0160 and often builds or heavily configures its own under DCB0129. The characteristic failure is institutional — a flagship electronic patient record program whose go-live date has political weight, so the CSO's caution is quietly treated as an obstacle. The corrective is structural: give the CSO independence and a real veto, keep a live hazard log across the estate rather than a shelf of launch-day documents, and wire LFPSE and PSIRF learning back into clinical risk management as a standing process. At enterprise scale the biggest hazards are integration and configuration hazards, which no supplier assurance covers, so local ownership is non-negotiable.

Government#

A national body — NHS England, the MHRA, DHSC, NICE — sets the standards others must meet, so its ways of working shape the whole system: DCB0129/0160, DTAC, and SaMD regulation are instruments of population-scale safety. Decisions here attract regulatory, parliamentary, and public scrutiny, and a nationally mandated system that carries a latent hazard distributes that harm across millions before anyone sees the pattern. The obligations are proportionality made explicit in published standards, transparency about residual risk, and keeping the regulatory framework current as technology — especially AI — outpaces it (see Topic 8.4 — AI & Emerging Technology Governance). The distinctive risk at this scale is systemic: mandating a technology across the estate on thin safety evidence entrenches a hazard everywhere at once.

Common failure modes#

• Safety bolted on at the end. Producing a safety case the week before go-live to satisfy a gate. Antidote: open the hazard log at discovery; design the biggest hazards out.
• Supplier assurance mistaken for local safety. Treating a DCB0129 case and a DTAC pass as covering your deployment. Antidote: own your DCB0160 assessment and local hazard log.
• CSO as rubber stamp. A Clinical Safety Officer with no time, independence, or authority to say "not yet." Antidote: protect the role and make sign-off a genuine gate.
• Dead hazard log. A document written once and never revisited after launch. Antidote: keep it living; feed incidents and changes into it.
• Alert overload. So many warnings that clinicians ignore all of them, including the vital ones. Antidote: human-factors design; every alert must earn its place.
• Blame culture. Punishing individuals for near-misses, so reporting dries up. Antidote: a just, systems-based culture aligned with PSIRF.
• Missed regulatory threshold. Shipping SaMD without recognizing it as a regulated device. Antidote: assess and document medical-device status early.

Maturity model#

Checklist#

• A competent, practicing, trained Clinical Safety Officer is named for each system, with time and authority to say "not yet".
• A clinical risk management file, living hazard log, and clinical safety case exist for each system in scope.
• Hazard identification began in discovery, with frontline clinicians in the room.
• The deploying organization has run its own DCB0160 assessment, not just accepted the supplier's DCB0129 case.
• Risk controls prefer design-out over alerts over training, with residual risk reduced to ALARP and justified.
• Medical-device / SaMD status has been assessed and documented, and MHRA / IEC 62304 obligations engaged where relevant.
• DTAC has been completed as a floor, paired with local clinical risk management.
• Human-factors and usability testing under realistic conditions has been done; alert load is controlled.
• Live incidents (LFPSE) and PSIRF learning feed back into the hazard log as a standing process.
• Reporting near-misses and challenging a launch on safety grounds is visibly safe and expected.

Key sources#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training and clinical risk management guidance.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — Software and Artificial Intelligence (AI) as a Medical Device guidance.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — Learn from Patient Safety Events (LFPSE) service.
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• World Health Organization — Global Patient Safety Action Plan 2021–2030.

References#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan