Healthcare

Enterprise Product

Under NDA

Digitising the surgical implant supply chain

A hospital was running its implant supply chain on phone calls and memory. This is the system that replaced it: five roles, one status model, and a check at the operating table before anything is opened.

Role

Senior Product Designer

Disciplines

Product Design, UX, UI, Research and Design Systems

Client

Orthopaedic hospital group

Platform

Web, Tablet & Mobile

The desktop case list, every surgical case carrying the colour of its request type, beside the vendor rep's phone with the cases waiting to be acknowledged and the orders still to submit.

Overview

An orthopaedic hospital was running its implant supply chain without software. Cases were scheduled in the hospital’s record system; everything after that was phone calls, printed lists and technicians who had learned the catalogue by heart.

I designed the system that replaced it. One application, five roles, one status model underneath all of them, carrying a case from scheduling through vendor confirmation, picking, quality checking, transfer to theatre, the last check before anything is opened, and closing out afterwards.

I was the only designer on the engagement. The engagement manager and I ran the interviews and the stakeholder sessions together.

Challenge

There was nothing to improve. No product to redesign, no competitor solving the same problem, no screens to argue with. When we asked when the problem had started, the answer was that the process had always been manual.

A manual process that works is held together by people who remember things. Training a technician meant months of memorising which implant fits which system, which brands the hospital stocks, and which sizes have to be in the room in case the first choice doesn’t fit. The cost arrived as phone calls: a surgeon’s team ringing the technician room during preparation, and sometimes during surgery.

Two things made it worse, and he wrote both down himself at the time: an implant dropped on the floor has no backup plan, because the stock a technician can reach is not on any screen; and loaners, the implants borrowed in for a single case, take a long time to handle. The loaner follows the order the whole way, and it has to be found again in the bin at the end.

Diagram. Before: phone calls during preparation and sometimes during surgery, printed lists, months of memorising which implant fits which system, and stock a technician can reach that is on no screen, all converging on one implant technician. After: one status model under five roles, where the case is defined, the order confirmed, the implants picked and checked, checked again in theatre, and closed and returned, every transition naming the role allowed to make it.

This ends in an operating theatre, with gloved hands, a sterile field and a patient on the table, where an implant that doesn’t fit costs a second operation.

Process

We interviewed the people who would use it: surgeons and their PAs, implant technicians, theatre nurses, the vendor reps who deliver the stock, and the supply chain administrators. Five personas came out of those conversations: the administrator, the implant technician, the vendor rep, the surgeon and the nurse. They are the five roles the product is built around.

Five persona cards, one per role: the administrator, the implant technician, the vendor rep, the surgeon and the theatre nurse, each with the goal and the frustration that shaped the product.

I drew the process as it ran, then as it would have to run, in three phases. The as-is diagram did most of the arguing: it showed how much of the sequence lived in somebody’s head.

The implant lifecycle as a swimlane across five roles: the case is scheduled in Epic, the app creates it, the vendor confirms receipt and the order, the implant technician picks and checks it, the theatre nurse scans it at the table, and it comes back to the technician to be closed.

Then the status model. Every implant order moves through a set of states, and I wrote down which role is allowed to make each transition, including the one that looks like a state and isn’t. The screens were drawn from that.

The implant order status model: twelve states from Order Missing to Case Closed, every transition annotated with the role allowed to make it, and Case Acknowledged drawn in a dashed box because it is not a status.

Decisions

Compatibility resolved when the case is defined

The Tension

If surgeons prepare a case in advance, the calls to the technician room collapse. A surgeon who requests the wrong component still generates the call, so an advance request that is wrong buys nothing.

What I chose

The product resolves compatibility at the moment the case is defined. Choose a system and it brings in the implants that connect to it, in the brands the hospital actually stocks.

What it cost

States that nobody had to manage before. Something has to happen when a request is incomplete or when stock contradicts it, so the product grew validation stages and a colour vocabulary for request type and status, so a technician can read a queue at a glance. The team now runs states that used to be a phone call.

Two desktop screens from setting up a case: the implants attached to it, and the picker that brings in compatible implants filtered by component, design and size.

One product at three sizes, and one screen that isn’t

The Tension

The phone, the tablet and the desktop are the same product at three sizes, with different people in front of each: the vendor rep on the phone, the implant technician on the tablet, the surgeon and the administrator on the desktop. Treating the theatre screen as a fourth size would have been consistent, and consistency is usually the right answer.

What I chose

The theatre screen stopped being one of the sizes. Nobody touches it, because the field is sterile, and nobody stands close to it, so it left the touch rules behind and took its own type scale and density. The implant is scanned and read against the case there, from across the room.

What it cost

An exception, in a system whose whole value is not having them. Every shared pattern now has to be checked twice: once across the three sizes, and once on the screen that plays by different rules.

The same kind of case list on three surfaces: dense cards on a phone, an eight-row table on the desktop, and four large rows with a colour status rail on the in-theatre screen.

I argued for one quality check and lost

The Tension

The hospital wanted the quality check run twice, by two people. I argued for one. Two people running the same steps against the same data give you a second person rather than a second check: whatever the procedure misses, it misses twice. A check that catches something different has to be built differently, and this one was the same check again.

What I chose

They kept two, so I designed the handoff to cost as little as it can. The first pass closes on a screen that states what is done and that somebody else finishes it, and the second person opens on that state rather than reading the case again from the start.

What it cost

Time in preparation, where time is expensive, and it does not buy what the hospital believes it buys. Their position is that an implant deserves a second pair of eyes. Mine is that it deserves a second method. The design holds their position, because the risk is theirs to carry.

The tablet at the end of the first quality pass, reading QA1 Complete and saying another user will finish the quality checking, beside the completed scan list.

Solution

The sitemap organised by role: the vendor rep, surgeon and surgeon PA share one path, while the implant technician, the administrator and the theatre nurse each have their own.

A case arrives from scheduling and becomes a request with everything attached to it: the system, the compatible implants, the brands, and the sizes to have in the room.

The technician works a queue instead of a phone. Picking is scanned rather than ticked, and the items still outstanding stay visible while the work is happening.

Quality checking is a stage with its own owner. The handoff between the two people who do it happens on screen.

In theatre the implant is scanned and checked against the case on a screen on the wall, item by item, before anything is opened. Surgeons and nurses both read it, and neither has to touch it.

Vendor reps confirm orders from a phone, which is where they are.

Validation

HOW IT WAS REVIEWED

Interviews and review sessions with surgeons, surgeon PAs, implant technicians, theatre nurses and supply chain administrators, run by the engagement manager and me. The design was then reviewed against the built application: I went through the implementation screen by screen and annotated what had drifted.

WHAT SHIPPED

Research, design system and mockups built with the implementation team: validation sessions with the developers, QA, and review of what was built against the design. Live, all three phases.

Outcome

The client reported that implant swap errors fell from 25% to 3%. That is their figure, not one I measured.

The 3% is worth naming. Those are the cases that still arrive by phone and never reach the app.

Technicians answer more requests than they used to, because the queue is on a screen where the work used to arrive by phone. There is more work than before, and it is organised.

All three delivery phases were built.

implant swap errors, down from 25%

roles, from the vendor rep to the theatre nurse

surfaces, one of which nobody is allowed to touch

Reflection

Every error the product removed was an error that passed through it. The 3% that remains is the requests that go around the system, and no screen reaches those; it is a question of who is allowed to ask for an implant and how. I would put that inside the brief next time instead of treating it as the part outside the scope.

The number on this page is the client’s. I would instrument one flow myself before handover, even a small one, so that something here is mine.

Previous project

Global medical devices

A System That Cares

Next Project

North American industrial rental

Modernising field operations for a complex rental business

All case studies

Healthcare

Enterprise Product

Under NDA

Digitising the surgical implant supply chain

Role

Senior Product Designer

Disciplines

Product Design, UX, UI, Research and Design Systems

Client

Orthopaedic hospital group

Platform

Web, Tablet & Mobile

Overview

I was the only designer on the engagement. The engagement manager and I ran the interviews and the stakeholder sessions together.

Challenge

This ends in an operating theatre, with gloved hands, a sterile field and a patient on the table, where an implant that doesn’t fit costs a second operation.

Process

I drew the process as it ran, then as it would have to run, in three phases. The as-is diagram did most of the arguing: it showed how much of the sequence lived in somebody’s head.

Decisions

Compatibility resolved when the case is defined

The Tension

What I chose

The product resolves compatibility at the moment the case is defined. Choose a system and it brings in the implants that connect to it, in the brands the hospital actually stocks.

What it cost

One product at three sizes, and one screen that isn’t

The Tension

What I chose

What it cost

An exception, in a system whose whole value is not having them. Every shared pattern now has to be checked twice: once across the three sizes, and once on the screen that plays by different rules.

I argued for one quality check and lost

The Tension

What I chose

What it cost

Solution

A case arrives from scheduling and becomes a request with everything attached to it: the system, the compatible implants, the brands, and the sizes to have in the room.

The technician works a queue instead of a phone. Picking is scanned rather than ticked, and the items still outstanding stay visible while the work is happening.

Quality checking is a stage with its own owner. The handoff between the two people who do it happens on screen.

In theatre the implant is scanned and checked against the case on a screen on the wall, item by item, before anything is opened. Surgeons and nurses both read it, and neither has to touch it.

Vendor reps confirm orders from a phone, which is where they are.

Validation

HOW IT WAS REVIEWED

WHAT SHIPPED

Research, design system and mockups built with the implementation team: validation sessions with the developers, QA, and review of what was built against the design. Live, all three phases.

Outcome

The client reported that implant swap errors fell from 25% to 3%. That is their figure, not one I measured.

The 3% is worth naming. Those are the cases that still arrive by phone and never reach the app.

Technicians answer more requests than they used to, because the queue is on a screen where the work used to arrive by phone. There is more work than before, and it is organised.

All three delivery phases were built.

implant swap errors, down from 25%

roles, from the vendor rep to the theatre nurse

surfaces, one of which nobody is allowed to touch

Reflection

The number on this page is the client’s. I would instrument one flow myself before handover, even a small one, so that something here is mine.

Previous project

Global medical devices

A System That Cares

Next Project

North American industrial rental

Modernising field operations for a complex rental business

All case studies