So far I’ve mostly talked about avoiding the avoidable in hospital expense only at the start, the admission stage, of a hospital stay. But the problem arises at the other end too, when a patient has to stay on because the discharge process is delayed. 

There are two main reasons why this might happen.

OK, so why can’t I just go home?

The more obvious one is that the discharge has not been properly prepared. Tests need to be carried out to confirm that the patient is fit to go home, but the results haven’t been received – or perhaps the tests haven’t even been ordered. Possibly the patient needs to take medications home and the necessary prescription hasn’t been sent through to the hospital pharmacy. Or, even more simply, the discharge needs the approval of a doctor who simply isn’t available, called away to an urgent conference which perhaps, and entirely coincidentally, is taking place next door to a prestigious golf course.

This kind of problem occurs everywhere. Recently I read a 2014 study of two hospitals in Brazil. It found that in one of the hospitals, delayed discharged represented a 23% extra occupancy rate, a figure that climbed to 28% in the other. That means a massive proportion, around a quarter, of the beds in those hospitals were occupied at any one time by people who should already have left.

The other main reason for a delayed discharge is particularly familiar in a nation such as England. Patients can’t leave because there’s nowhere for them to go where they will receive the ongoing care they need. This is particularly acute for older people who may be living alone with no one available to act as carer. They can only be discharged once there is a social worker or community nurse available to help them, or perhaps a bed in a care home.

Delayed discharges generate two problems. First of all, it’s bad for the patients: people generally recover better in their own beds than in hospital and, in any case, simply by staying on patients are exposing themselves to unnecessary risk, if only of infection from other patients around them.

Secondly, the delayed discharge is bad news financially. Acute hospital care is the most expensive care and, even though costs will be lower towards the end of a stay by which time the patient requires less treatment, the mere fact of occupying a bed is expensive. That’s without taking account of the impact on other patients who might have benefited from being admitted to a bed blocked in this way.

A recent study (February 2016) for the NHS in England by a team headed by Lord Carter of Coles, Operational productivity and performance in English NHS acute hospitals: Unwarranted variations, put a figure on the impact of delaying discharges: “the cost of these delays to NHS providers could be around £900m per year.”

That’s close to 2% of the total expenditure on acute care.

How do we fix these problems?

Both require management action, naturally. For instance, my wife worked until two or three years ago in the Discharge Planning team of our local hospital. Here, nurses, social workers and hospital staff worked out of a single suite of offices, preparing the plan to discharge a patient from the moment he or she was admitted. That meant that the agencies involved in post-hospital care had the greatest possible notice that their services would be needed. They could, therefore, assign staff or find suitable accommodation, at least as far resources allowed, in the most favourable possible conditions, rather than in a rush at the end.

Equally, steps can be taken in plenty of time to ensure that all necessary processes are carried out, the appropriate tests or medications ordered, and the paperwork prepared for someone to sign who will be around at the right time.

Computer systems can help, of course. The kind of pathways management software I’ve been talking about in this series can be used by hospital staff as it can by people in primary care. It can issue alerts not just to physicians but to nurses and care assistants: “for this patient to be discharged tomorrow morning, you have to request this test today,” for instance.

When it comes to helping with groups like my wife’s former colleagues, what’s needed is ways to improve collaborative working between different systems. Social work management software needs to interwork with nurse management and general hospital systems. Fortunately, none of that is impossible and over the last few years, great strides have been taken towards making it happen.

What that means is that avoiding the avoidable can now be tackled at both ends of a hospital stay: discharge, with its own specific problems, as well as admission.

Supporting clinical decisions for physicians

Clinical decision support software can be invaluable in a triage service: it will remind staff of conditions that fit the symptoms a caller is describing and prompt them to ask the relevant questions to check on the possibilities, or propose sensible actions.

Isn’t that exactly what we want for doctors too? Shouldn’t they be prompted to consider all possible explanations of a patient’s condition? Might they not also need an occasional reminder?

Things, sadly, are not that simple. As long ago as 1999, the Journal of the American Medical Association carried an article on ‘Why don’t physicians follow clinical practice guidelines?’ They found a number of barriers to the use of guidelines (that’s guidelines in general, irrespective of whether they’re drawing on software support). They may not be aware of their existence. They may be put off by the sheer volume of guidelines out there. They may, quite simply, not have the time to consult them.

Systems should support delivery of patient care, not distract from it

That last objection is one I’ve heard from General Practitioners (family physicians) in Britain. On average, they have ten minutes for each patient consultation, which means the useful time is around seven and a half minutes. Pulling a book out to check on a guideline simply takes too high a proportion of the available time. “I would never consult a guideline,” one GP told me.

Most British GPs use a computerised system these days. Even then, though, they don’t want to have to call up their decision support system and work through it to see whether it has anything to suggest. “I don’t want to have to check my system to be told that a patient coughing blood needs to be checked for possible cancer. If I didn’t know that, I shouldn’t be in this job.”

They also don’t like it if their screen is full of popup alert windows. They need their screens to contain the information that’s useful to them. They don’t want it cluttered.

Despite all that, we all know that diagnoses are sometimes missed. Recently, it was announced that heart attacks are missed in one-third of British women who have had one. Why? Because it’s with men that physicians first think of heart attacks. With women patients, the first thought is much more likely to be cancer. That’s despite the fact that experts point out that women are as likely to suffer a heart attack as men are.

So what’s the answer for a clinical decision support supplier?

First of all, although there does have to be an alert to doctors concerning the presence of decision support information, it needs to be discreet – it mustn’t take up too much space on screen. It just has to be eye-catching enough for the physician, whether a GP or in a hospital, to realise that the system has something to suggest. He or she can then choose to consult it.

Secondly, once the physician has gone into the decision support system, it should not require him or her to select a specific pathway – say lung cancer rather than congestive obstructive pulmonary disease. Instead it should be assembling the symptoms and findings already recorded and, if they are compatible with either condition, propose further questions to ask, or tests to carry out, in order to eliminate one or other of the possibilities.

Thirdly, it has to be constructed to as to save the physician time, not cost more. So as well as supporting the clinical decision, it should also support the process itself. For example, for a GP, does a letter have to be produced for a referral to hospital care? Then the system should produce it. That way the physician doesn’t have to flick between systems and, if anything, the use of it will save time that can be used for the consultation itself, listening to the patient or providing advice.

What does that all mean? That there is indeed a vital role for a clinical decision support system to play in supporting physicians. But it needs to be highly intelligent in design, to ensure that while it benefits patients it does not do so by distracting physicians from their main purpose: helping in every way possible to alleviate suffering and reduce ill health.

That’s one of the most exciting and satisfying challenges that healthcare information work provides today.

Supporting clinical decisions for better triage

Most of us understand the need to keep healthcare costs low. On the other hand, when we become patients, we’re not keen to see savings made at the price of increased risk. When it comes to avoiding the avoidable in healthcare, we like to think that costs are unavoidable if they ’re incurred ensuring our safety.

The Netherlands have an out-of-hours service patients can call when their GP practice is shut. The aim is to reduce visits to emergency departments in lieu of family practitioners. Nurses take callers through guidelines, asking a series of questions to establish what care the patient needs and with what urgency.

An out-of-hours call centre at work

A 2007 study set out to find out how well the service was performing. The results were disturbing. In 19% of cases, nurses underestimated the urgency of the patient’s condition. The study’s authors conclude that the service was “possibly not safe,” which feels like an understatement.

Denmark’s out-of-hours service gives evidence of the opposite effect: excessive caution by nurses. The Danish service is principally staffed by GPs, but there’s pressure to use nurses as an economy measure. However, a 2013 investigation found that nurses might be too inclined to refer a case for a GP to see instead of taking a decision themselves. The result? On top of the cost of employing the extra nurses needed, the service, far from reducing calls on GP time, might increase them. Costs could rise instead of falling.

What’s the answer? How can we reduce expenditure by having nurses or, even better, non-medical staff, take responsibility for triage, without either increasing risk to patients or incurring higher costs?

The 2007 Dutch study came up with one answer: it found that the more training nurses had received in the use of the call centre guidelines, the less frequently severity was underestimated. Certainly, telephone triage isn’t simply another application of already acquired skills. It’s a legitimate healthcare service in its own right, needing its own knowledge and expertise.

There is, however, another way in to  improve services. That’s the field in which I’m currently spending much of my time: clinical decision support.

What we’re talking about here is software that helps nurses or non-clinical call handlers work their way through guidelines. At the most trivial level, such software can ensure that nothing’s forgotten. A question might be mandatory, so the handler simply can’t move on until it’s asked. That would ensure essential information isn’t missed. Even with optional questions, their mere appearance on a screen would at least prompt the handler to ask them and might trigger a new line of enquiry.

That, however, is far from enough. There has been research (not enough, yet, but what there has been is telling) into the impact of clinical decision software. A revealing article showed that a call handler might be pushed down the wrong line by the software itself. It cites the example of a handler, a nurse, who had begun to explore what the software offered on the subject of nausea, while the caller had moved on to talk about back pain. With one line of questions already under way, the call handler failed to pick up the second symptom, however important it may have been.

Again, on some occasions, the lack of an appropriate response to certain questions led to a distorting effect: the patient was saying that she felt sick each time she ate, but the software hadn’t allowed for that reply, imposing instead quantitative entries – once a day, three times a day, and so on.

That’s what makes the search for effective software design such an interesting challenge. It’s not enough just to list all possible questions, in a fixed order. It’s vital to take all the information concerning any particular patient into account, without deciding too soon that one item has overriding importance or letting the software itself drive the direction of the investigation. In fact, the system has to:

1. take into account all the information about the patient, entered in whatever order. In other words, as in a real, face-to-face medical consultation, the patient should be able to describe all his or her symptoms without making a judgement about which is the most important 
2. suggest questions to the call handler based on all the symptoms, not just one of them 
3. drop irrelevant questions but propose all the others 
4. handle unquantified information, such as “I feel sick each time I eat”

That would be the kind of clinical decision support software that can really make a difference, because it emulates what happens in a medical consultation: the patient describes symptoms as they come to mind, not in an orderly or pre-filtered way. Alongside the kind of comprehensive training we’ve already seen is needed, such support software could bring us closer to the goal we seek: a triage service that delivers a reduction in costs without an increase in risk.

In fact, it would be valuable for far more than triage. It can make a major contribution to managing medical pathways in general. But that’s the subject of my next post.

A tale of two stroke patients

It’s been a while since I last put up a blog here. My only excuse is that I’ve been so heavily involved in doing healthcare information that I’ve not had enough time to talk about it.

In particular I’ve been working on what remains as much as ever my hobby horse, pathways. So I thought it might be interesting to give an example of one. Or rather two. 

Two women, one aged 61 and the other 62, both had emergency hospital admissions for strokes. The first woman’s hospital stay only lasted a night, which meant it incurred just a short stay emergency charge of about £1400, but the second stayed four nights and cost £4400.


So the obvious issue is – why was there such difference between them?

The first place to look is among the secondary diagnoses recorded for both women.

The short-stay case, primary and secondary diagnoses

Code	Diagnosis
I639	Cerebral infarction, unspecified
I251	Atherosclerotic heart disease
I248	Other forms of acute ischaemic heart disease
G409	Epilepsy, unspecified
Z867	Personal history of diseases of the circulatory system

Diagnoses for the four-day case

Code	Diagnosis
I639	Cerebral infarction, unspecified
I678	Other specified cerebrovascular diseases
F329	Depressive episode, unspecified
Z870	Personal history of diseases of the respiratory system

To a non-clinician like me at least, nothing springs out from this to explain the differences between the two cases. And that’s the problem with focusing exclusively on a single event in this way, in this case on the hospital spell: it gives much too limited a view of the patients’ real experience.

The picture changes fundamentally if we take a longer view. We don’t have information about the GP care of these two women, but we do know about all their treatment in acute hospitals, in community hospitals, in community health services, even in social care. So let’s take a look at what happened to them both in the period leading up to their strokes.

For the patient who was in for a day after the stroke, the only care we know about over the previous eighteen months were two outpatient attendances in Cardiology. It seems that she must have shown symptoms of a developing heart problem, but nothing serious enough to justify further hospital treatment. Ten months after the second outpatient clinic, she attended A&E followed her stroke and was admitted for emergency treatment.

With the other patient, on the other hand, the picture could hardly be more different. Below is the pathway of just six months before her stroke (drawn to the scale of the lengths of each event):

The poor woman has been through a real catalogue of misfortunes:

1. She was admitted for an acute myocardial infarction five months before the stroke
2. A month later she was in for a pulmonary embolism
3. She had a great deal of care in the community, including physio, occupational health as well as district nursing
4. She was taken into residential care
5. Despite the care she was receiving, she had four more emergency admissions for respiratory or suspected cardiac symptoms over a period of about a month some three months before the stroke.
6. She then had her stroke

All we need is to move away from our focus on a single acute event and look instead at the whole pathway of her care, to understand that we are talking about two profoundly different cases. This woman is simply far more ill, in a state similar to what is referred to as ‘frailty’ in older patients: any problem, even a small one, can lead to a string of others, some far more serious.

So there’s absolutely nothing surprising about the fact that she needed a longer stay in hospital after the stroke. In fact, it’s now clear that while the stroke was a major event in the history of the other woman, for this one it was just the latest in a series of severe problems. If we wanted to take a look at ways of making her care more effective, or more cost-effective, it might not even be with the stroke event that we’d start (after all, she was in hospital for 25 days after the myocardial infarction).

All it takes to get this much richer and, I’m sure you’ll agree, much more valuable view of the patient’s healthcare is to take a pathway view. And all that needs is to get hold of the data and string it together...

Showing the pathway forward

When it comes to building pathways out of healthcare event data, it’s crucial not to be put off by the apparent scale of the task. In fact, it's important to realise that a great deal can be done even with relatively limited data. Equally, we have to bear in mind that a key to achieving success is making sure that the results are well presented, so that users can understand them and get real benefit from them. 

Since that means good reporting, and therefore a breach with the practice I described in my last piece, this post is going to be rich in illustrations. They were most kindly supplied by Ardentia Ltd (and in the interests of transparency, let me say that I worked at the company myself for four years). The examples I've included are details of screenshots from Ardentia's Pathway Analytics application, based on sample data from a real hospital. At the time, the hospital wasn't yet in a position to link in departmental data, for areas such as laboratory, radiology and pharmacy, so the examples are based on Patient Administration System (PAS) data only. My point is that even working with so apparently little can provide some strikingly useful results.  

The screenshots are concerned with Caesarean sections for women aged 19 or over. The hospital has defined a protocol specifying that cases should be managed through an ante-partum examination during an outpatient visit, followed by a single inpatient stay. Drawing on Map of Medicine guidelines, it suggests that a Caesarean should only be carried out for patients who have one of the following conditions: 

• Gestational diabetes
• Complications from high blood pressure
• An exceptionally large baby
• Baby in breech presentation
• Placenta praevia

The protocol can be shown diagrammatically as two linked boxes with details of the associated conditions or procedures. For example, the second box in the diagram shows the single live birth associated with the section, and then five conditions one of which should be present to justify the procedure. 

Detail of an Ardentia Pathway Analytics screen with a protocol for Caesarean Sections

Next we compare real pathways to the protocol. At top level, we look only at the PAS events (OPA is an outpatient attendance and APC is an inpatient stay):

Part of the screen comparing actual pathways to the protocol (the full screen contains several more lines).
Note the low-lighted line, second from the top, that corresponds to the protocol shape.

The first striking feature of the comparison is that only a minority (14%) of the cases corresponds to the protocol at all. 65% of the cases have a single admitted patient care event without an outpatient attendance. This should lead to a discussion of whether the protocol is appropriate and whether this kind of case could be legitimately handled with a single inpatient stay and no prior outpatient attendance (perhaps as a an alternative protocol structure).

Another feature is the number of cases involving a second or subsequent inpatient stay. Now there’s a health warning to be issued here: these screens are from a prototype product and the analysis is based on episodes, not spells, so we can’t be certain the second admitted patient care event is an actual second stay – it might be a second episode in the same stay. If, however, an enhanced version of the product showed there really were subsequent stays, we’d have to ask whether what we are seeing here are readmissions. In which case, is something failing during the first stay?

We can drill further into the information behind these first views. For instance, we could look more closely at the eight cases which apparently involved an outpatient attendance followed by two inpatient stays:

Three pathway shapes or types followed by cases that apparently
involved an additional inpatient stay

 The first two lines show instances where the delivery took place in the first inpatient stay (the box for the first stay is associated with a circile containing the value '1', corresponding to the entry in the protocol for a single live birth). In seven of these cases, the patient needed further inpatient treatment after the Caesarean. The last line shows something rather different: the patient was admitted but not delivered and then apparently had to be brought back in for the delivery.

Note that the middle line shows that just two cases out of the total of eight are associated with a diagnosis specified by the protocol as a justification for a Caesarean: they are linked with condition 5, breech presentation. The fact that no such information is recorded for the other six suggests either that Caesarean sections have been carried out for cases not justified by the protocol, or that key data is not being recorded. Either way, further investigation seems necessary.

We can also look in more detail still at individual cases.

Clinical details for a specific event

The example shows a case that has followed the protocol: an ante-partum examination was carried out on 5 May and the patient was admitted on the same day, with the Caesarean section taking place on 8 May. The ticked box in the greyed-out diagram shows that a condition justifying the caesarean has been recorded (placenta praevia). This is confirmed by the highlighted box of detailed information (note that the consultant's code has been removed for confidentiality reasons).



The simple examples here show that pathway analysis provides a real narrative of what happens during the delivery of healthcare to a patient. On the one hand, it can answer certain questions, such as why a Caesarean was carried out at all, and on the other it can suggest further questions that need investigation: what went wrong with this case? why was the procedure carried out in the first place? was there a significant deviation from the protocol?



If we can do that much with nothing more than simple PAS data, imagine how powerful we could make this kind of analysis if we included information from other sources too...