Getting the job done

It is 4pm in the afternoon of a normal working day of Dr Shah, junior doctor in a district general hospital.

He sits in front of a computer terminal and checks the blood results of Mr Smith, which were done earlier in the day. Mr Smith, a 70 year old retired shopkeeper was looking slightly pale and short of breath.

Dr Shah was concerned that Mr Smith was bleeding, so he ordered a blood test to check. The computer informs Dr Shah that Mr Smith’s blood count is 10g/dl. Dr Shah then carries out the following steps:

1. He checks the previous day’s blood test results. Then, Mr Smith’s blood count was 14g/dl. The difference indicates that Mr Smith has lost approximately 30% of his blood volume.

2. He decides that Mr Smith needs a blood transfusion. He needs to check if a blood sample has gone to the transfusion lab to perform tests to make sure that the right blood is given to Mr Smith.

He logs into the transfusion system, searches for the appropriate tests and date. He finds a test, but cannot remember exactly how recent a blood sample needs to be to be valid, so he rings the transfusion lab.

3. He decides that Mr Smith will need another blood test later in the day. He switches to the ordering system and puts in the tests that he wants ordered.

4. He decides to check Mr Smith’s latest blood pressure and heart rate to see if there are any clinical signs of continued bleeding. He logs in to the patient observation (vital signs) system to see if there has been any change since this morning.

5. Dr Shah wants to make sure that Mr Smith is not on any medications that might have caused the bleeding or that could make it worse. He logs on to the electronic prescribing system, notices Mr Smith is on Aspirin (Aspirin thins the blood) and discontinues it.

6. He then consults his boss, Professor Brown, about the situation. He copies and pastes all the relevant results and findings, across all the systems, into a secure NHS.net email and follows it up with a phone call.

What is the job of a blood results system?

In this scenario, the ‘job’ of a blood test is to inform clinical decisions. In other words, it is not simply to produce a result. Before ordering any tests, all doctors are taught to ask themselves: ‘How is this test going to change the management of my patient?’

Following on from this, the job of a blood test results system should be to facilitate management decisions. This is not purely a matter of operational efficiency; it has a direct impact on patient outcomes.

In this example, not remembering to stop Aspirin could have been the difference between life and death for Mr Smith.

The good news is that many of the actions that arise from a particular pattern of blood results can be predicted and appropriate rule-based functionality can be built-in.

For example, after detecting a fall in the blood count from 14 g/dl to 10 g/dl, the system could automatically tell a doctor whether a valid blood transfusion sample is available and if not, suggest that one should be ordered.

Some argue that this should be the ‘job’ of the doctor and not a computer system. Without devaluing the responsibility of the doctor, we need to recognise that humans are fallible and systems should be in place to minimise these errors; as the US Institute of Medicine argued more than a decade ago, in its seminal report ‘To Err is Human’.

An opportunity for software developers

If you are thinking of developing a piece of software to support healthcare, I encourage you to truly understand the ‘job to be done.’

This is a theory championed by Professor Clay Christensen at Harvard Business School; the author of the bestsellers ‘The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail’ and ‘The Innovator’s Prescription: A Disruptive Solution for Health Care’.

Broadly, it says that customers don’t really buy products, they ‘hire’ them to do a job. So instead of asking what products a customer wants, you need to uncover what fundamental problems they hope to address.

Applying this theory to the healthcare system should go a long way to unravelling the IT productivity paradox – or why large investment in health It has not delivered productivity increases – since it is generally accepted that a good part of this can be put down to the way solutions are implemented.

Practically, it means don’t sit around around a table with your clients ruminating on endless specifications without understanding the manner in which these changes will influence clinical management.

Go and see

A key principle of the famous and widely adopted Toyota Production system is Genchi Gembutsu, roughly translated into ‘go and see.’ I urge you to ‘go and see’ how healthcare is delivered armed with an open mind and a creative spirit.

Asking healthcare professionals what they want is not enough. As Henry Ford said, famously, if he had asked customers what they wanted before he invented the mass market car, they would have said a faster horse that ate less.

Healthcare professionals themselves have often not truly reflected on the ‘job to be done’. However, we are very good at complaining when it doesn’t help us or, indeed, gets in the way when we are trying to ‘get the job done’.

Taking your time to seek these answers may just be your competitive advantage. The journey will not only be fun but, along the way, you may even help save a few lives and alleviate suffering for many more.

About the author: Dr Wai Keong Wong is a physician specialising in haematology and a national leadership and management fellow. He is on secondment to Bupa as part of the NHS Medical Director Leadership and Management Scheme.

In addition to this, he is chair of the project board of the joint BCS, The Chartered Institute for IT and Department of Health project to create user guidance for safe keeping of their electronic health and social care records. He is also the chair of the CCIO Leaders Network advisory board, where he is the representative for doctors in training.

He tweets as @wai2k