NHS / Red Star · Fracture Liaison Service
Finding capacity within the service.
The interface was one part of the problem. The work also concerned how patients were found, how clinical staff reviewed them, and how a decision became a care plan.
Time was being lost before care could begin.
Fragility-fracture identification involved substantial manual work. Staff had to find possible patients, filter them into candidates for the service, and gather information from separate systems before assessing them.
That created a capacity problem as well as an information problem. A better screen would only help if the surrounding process also made it easier to identify, review and progress the right patients.
I mapped the existing service with clinical teams, investigated where time and capacity were being lost, and modelled alternative ways of working. That work informed the target operating model and the interfaces needed to support it.
From finding information to acting on it.
The redesigned process connected fracture identification, clinical review and the work that followed a decision.
The existing process
- Find possible patients
Manual identification included searching wards for potential candidates.
- Assemble a clinical picture
Staff gathered relevant information from multiple systems.
- Prepare the next action
Care planning and correspondence involved further manual work.
The redesigned process
- Bring candidates into a worklist
Relevant fractures from radiology feed structured identification and filtering.
- Support clinical review
Worklists and a curated patient view bring decision-relevant information together.
- Connect a decision to care
Workflow progression, care plans and generated letters support follow-through.
Three connected design decisions.
- Make the work visible.
A list of potential patients gave nurses a systematic starting point. Filters and priorities reflected clinical considerations such as fracture type, age, existing treatment and DEXA history.
I worked on the worklists and progression between stages so the interface supported the service’s sequence of decisions.
- Curate the patient view.
The patient profile brought together relevant reports, medications, laboratory information, previous scans and fracture history.
The design task was deciding what clinical staff needed to see to assess the patient. Bringing everything onto one screen would not, by itself, make that assessment easier.
- Follow the decision beyond the screen.
Care plans connected to correspondence for GPs and patients. I also redesigned that communication, aiming to make the next steps and the care being offered easier to understand.
That extended the design work from staff interactions into the experience of receiving care.
Service understanding into interaction detail.
My contribution moved between the overall process and the detail of reviewing patients, recording information, creating care plans and progressing work.
I developed and validated the operating model and supporting interfaces with clinical teams. Clinical decisions, data methods and software engineering were the work of the relevant specialists. The service depended on those contributions working together.
A pilot that became a live service.
Reported multidisciplinary results
- Case-processing time
- 55% lower
- Service capacity
- 92% higher
- Existing waiting list
- Eliminated
Red Star reports these results for the Fracture Liaison Service. They describe the combined service and technology change delivered with the NHS team.
The software and service change were subsequently procured in NHS Greater Glasgow & Clyde and NHS Lothian.
The value of the design work was in connecting the operating model, the information clinicians needed, and the interactions that helped them move care forward.
Sources and attribution
The design and deployment account is drawn from my project experience. The figures above are published by Red Star and describe the multidisciplinary work. The linked case study documents the GGC implementation.
The process illustration is a portfolio reconstruction. It uses no patient data and does not reproduce a historical project artefact.