PSIRF
PSIRF Software Buyer's Guide 2026: What to look for
Written by: Romano Rabie
Most incident platforms weren't built for PSIRF. Here's what a genuine PSIRF-aligned system looks like — and the six capabilities to test every vendor against.
Two years into the Patient Safety Incident Response Framework, an uncomfortable pattern has emerged across NHS trusts and independent healthcare providers: they're willing to apply PSIRF properly, but most of their tools don't make it easy.
HSSIB's October 2025 review of PSIRF investigations found that staff using the recommended systems-based methods often default to treating SEIPS, the framework's primary investigation tool, as a set of buckets to categorise incidents, rather than as a model for linking system factors. The training gap is part of it. But the software gap is the other half. Most incident management platforms still treat patient safety as a queue of individual events to be logged, assigned, and closed, which is precisely the model PSIRF was designed to move beyond.
If you're evaluating PSIRF software, whether you're an NHS trust under the Standard Contract or an independent provider stepping into NHS-funded care, the question isn't whether a vendor mentions PSIRF in their marketing. It's whether their platform actually supports the work PSIRF asks providers to do.
Here's what to look for.
PSIRF requirements: what the framework actually demands
PSIRF replaced the Serious Incident Framework in August 2022 and became a contractual requirement under the NHS Standard Contract in 2023/24. It applies to all NHS-funded secondary care: acute, mental health, ambulance, community, and maternity services. Primary care is being phased in from September 2024 under the Primary Care Patient Safety Strategy. Independent providers delivering NHS-funded care are in scope. Independent providers chasing NHS contracts are increasingly being asked to show PSIRF alignment as a procurement gate.
The shift PSIRF demands is hard to overstate. The old model — Root Cause Analysis applied to incidents classified as "serious" — produced individual reports about individual failings. The new model treats safety as an emergent property of the system. A nurse misses a dose. A swab is missing from a pack. A patient's pregnancy disclosure isn't actioned in time. PSIRF asks what about the system made the failure likely.
NHS England sets out four aims:
Compassionate engagement and involvement of those affected by patient safety incidents
A range of system-based approaches to learning from incidents
Considered and proportionate responses to incidents
Supportive oversight focused on improvement, not compliance theatre
Oversight under PSIRF is explicit on the last point. NHS England states that providers must "demonstrate improvement rather than compliance with prescriptive, centrally mandated measures." That is a process change, a reporting change, a data model change, and in most cases a software change.
The grouped incident model — and why most platforms can't do it
The most visible operational shift in PSIRF is the move from investigating every incident individually to investigating clusters of related incidents as a group.
Moderate-harm and above incidents still get their own investigation. That hasn't changed. What has changed is how no-harm and low-harm incidents are treated. Rather than running ten separate investigations on ten broadly similar near-miss events, PSIRF asks you to group them by theme and run one investigation that captures the system-level learning.
The themes are organisation-specific, and that's the point. For an acute trust, common themes look like falls (no harm), delayed theatre starts, cancelled surgeries, low-acuity self-harm, GDPR breaches. For a digital healthcare provider like Manual, one of our customers voluntarily aligning to PSIRF as it expands, themes look different: patients disclosing pregnancy mid-treatment while on weight-loss medication, missing items from pharmacy dispensations, side effects like low mood on finasteride, delayed deliveries. The mechanic holds across organisations.
To support this in software, the platform needs to do three things most incident systems weren't built for:
Allow incidents to be grouped under a named theme by an admin or quality lead, with the flexibility to spin up a new theme when one emerges. Your theme list will evolve — the system has to assume that, not resist it.
Hold the group open for a defined window — typically 30 days — so additional incidents can join, and pause the individual KPI clock on each incident while it's in the group. Otherwise every incident inside the group fails its 10-day investigation SLA and your dashboard lies to you.
Run the investigation against the group as a unit, while preserving the link back to every individual incident inside it. Learnings, actions, and findings need to attach to the group and propagate back to each constituent incident.
This sounds operational. It is. But it's the part that exposes whether a platform was designed for PSIRF or had PSIRF terminology bolted on later. Most legacy incident systems still treat investigations as 1:1 with incidents. If a vendor can't show you how the system handles 1:many, the rest of the PSIRF conversation is theatre.
SEIPS, properly
SEIPS, the Systems Engineering Initiative for Patient Safety is the systems-based investigation framework NHS England has standardised on. It originated in human factors and aviation safety work, and it's the headline tool in NHS England's PSIRF learning response toolkit. For the majority of patient safety investigations, SEIPS has replaced Root Cause Analysis.
SEIPS has six elements:
Person — who is involved (staff, patients, families)
Tasks — what they're trying to do
Tools and technology — what systems or equipment are involved
Physical environment — where the work happens
Organisation — the policies, culture, and workflows surrounding the work
External environment — what's happening outside the organisation that shapes the work
Most "PSIRF-aligned" platforms now offer a SEIPS template. You fill in the six fields. You save the report. Job done.
SEIPS is more than that. The analytical work is linking the buckets, not filling them.
HSSIB's October 2025 review names this directly: investigators new to SEIPS, without proper training or tooling, tend to categorise into isolated elements of a work system. They fill the buckets and stop. The actual analytical work of SEIPS is linking the buckets — showing that the cold draft from a pharmacy door (physical environment) is dislodging paperwork (tasks) used by a staff member rushing to a delivery slot (person) under a workflow designed without winter weather in mind (organisation). The system fix isn't retraining the pharmacist. The system fix is an air curtain on the door, or rescheduling the delivery slot.
This is the kind of example PSIRF practitioners now use to teach systems thinking — and it's the example that drove how we designed Safe Workplace's PSIRF investigation flow. The mechanic that matters is the ability to draw the links. Six lists in parallel won't get you there. The platform has to make linking system factors a first-class action in the workflow.
Three practical tests when evaluating PSIRF software:
Can the investigator visually link factors across the six SEIPS elements, not just populate them in parallel?
Can the linked factors be summarised in a way that surfaces the causative system pattern, rather than a generic list of contributors?
When the analysis is complete, does the resulting action plan tie back to the linked system factors — or does it default to "retrain the staff member"?
If a platform fails the third test, it isn't a PSIRF system. It's an incident log with a SEIPS skin.
Six capabilities to look for in PSIRF software
Pulling the above together, here's the checklist worth running every vendor through.
1. Thematic grouping of incidents. Admin-controlled grouping, with the flexibility to create new themes as they emerge. Bonus points if the platform suggests themes intelligently — but the human override has to remain the source of truth.
2. KPI clock pause on grouped incidents. When an incident enters a group, its individual investigation clock stops. Otherwise, the reporting layer punishes you for doing PSIRF properly.
3. SEIPS workflow embedded in the investigation flow. Not a downloadable template. Not a tab. A guided, step-by-step workflow that walks the investigator through the SEIPS elements as part of the platform's investigation process.
4. Visual linking between SEIPS factors. The investigator should be able to draw connections between elements, not just populate them in parallel. This is the single biggest predictor of whether a platform was designed by people who have actually run a SEIPS-based investigation.
5. Learning and actions tied to causative system factors. When an action is created, it should be attached to the specific system factor it addresses not orphaned in a generic action list. This is what makes the resulting improvement plan defensible to the CQC and to an ICB lead.
6. Reporting that demonstrates improvement, not just activity. PSIRF oversight standards explicitly require organisations to show improvement over time. The platform's reporting layer needs to surface trends in causative factors, action completion against those factors, and reduction in incident clusters not just incident counts.
Across all six, the underlying question is the same: was this platform designed for PSIRF, or was PSIRF terminology added to a platform designed for the SIF era of incident management? The answer usually becomes obvious within the first five minutes of a demo.
PSIRF software vs traditional incident management
The shift between the two is structural, not cosmetic. A platform built for SIF-era incident management and a platform built for PSIRF differ on every axis that matters at evaluation.
Aspect | Traditional incident management | PSIRF software |
Investigation unit | Single incident (1:1) | Grouped incidents by theme (1:many) |
Primary method | Root Cause Analysis on "serious" incidents | SEIPS-based system analysis on themed clusters |
Action attribution | Generic action list | Actions tied to causative system factors |
Reporting focus | Incident volume and closure rate | Trends in causative factors, action completion, and cluster reduction |
KPI clock behaviour | Single clock per incident | Group clock with individual incident clocks paused while grouped |
Oversight model | Compliance with mandated measures | Demonstrated improvement over time |
Workflow assumption | Investigate, log, close | Group, analyse, link, learn, improve |
A platform that excels in the left column is not automatically a PSIRF system. The questions in the buyer's checklist above are designed to reveal which side a vendor's platform actually sits on.
PSIRF as a commercial lever, not just a compliance burden
For independent providers, there are two reasons to take PSIRF seriously beyond regulatory alignment.
The first is contract eligibility. NHS contracts increasingly gate on PSIRF alignment. Independent providers — digital health platforms, private care groups, specialist clinics — entering NHS-funded care are being asked to demonstrate PSIRF maturity at procurement. A platform that can produce a Patient Safety Incident Response Policy, a Patient Safety Incident Response Plan, and a body of demonstrated improvement work moves the provider through that gate faster.
The second is the CQC signal. PSIRF maturity is increasingly read as a marker of safety culture under the Single Assessment Framework. Providers who can demonstrate genuine system-based learning, not just incident logging, score better against the "safe" and "well-led" key questions. That feeds into ratings, which feed into occupancy, referrals, and exit multiples.
There's a third reason, and it surfaced clearly in our build work with Manual: at scale, the per-incident RCA model becomes operationally unsustainable. At a healthy 1% incident reporting rate across a growing patient base, the volume of investigations under the old model would overwhelm the quality team. PSIRF, applied properly, reduces admin burden and improves the quality of learning. It's a rare regulatory shift that's also a productivity gain.
The right PSIRF software turns compliance into an asset. Most still make it harder.
Book a PSIRF readiness review
Safe Workplace is building its PSIRF investigation workflow alongside Manual, an independent digital healthcare provider voluntarily aligning to PSIRF as it expands into NHS-adjacent care. If you're evaluating PSIRF software and want to understand how a system-based investigation platform should actually work, we'd be happy to walk you through what we've built and what we're shipping next.
