What's the White Paper going to mean for Healthcare Information?

The need for better information is a theme at the core of the reforms announced in the health White Paper.

The preamble to the document states some of the principles on which the government is basing its approach. For instance, ‘patients will have access to the information they want, to make choices about their care. They will have increased control over their own care records.’ Empowering patients, a core value of the White Paper, will require far greater access to information than in the past.

Another view of the same principle appears in the declaration that ‘a culture of open information, active responsibility and challenge will ensure that patient safety is put above all else, and that failings such as those in Mid-Staffordshire cannot go undetected.’

Poor, much-maligned Mid-Staffs seems destined to be the icon for poor hospital performance for a while longer. This is the case even though it’s not obvious that it suffered from much more than resource starvation as a result of a headlong rush for Foundation Trust status. Indeed, it’s not even clear that it performed substantially less well than other Trusts: even Dr Foster whose figures precipitated the original scandal, classified it ninth in the country within the year, using broadly similar indicators.

Still, the point here is that we’re again talking about information openness with patient considerations at the centre. For our purposes, all we need to take out of the Mid-Staffs experience is the lesson that getting information right is at least as important as making it accessible.

We also read that ‘the NHS will be held to account against clinically credible and evidence-based outcome measures, not process targets.’ The focus on outcomes will be a major theme for anyone involved in healthcare information in the coming years.

All this needs to be set against the background of the increasing shift towards GP-led commissioning and the unravelling of the National Programme for IT.

It may be a little premature to assume that the Commissioning Consortia will get off the ground any time soon. It feels to me as though a lot more money will have to be found to cover management costs. The Tory Andrew Lansley is unlikely to like the idea that he’s following in the footsteps of Nye Bevan, Socialist founder of the NHS, but he may find himself having to deal with doctors as Bevan did, by ‘stuffing their mouths with gold.’

Two aspects are going to dominate a reformed commissioning process. The first is that GPs are going to be interested in buying packages of care – treat this diabetic, remove that cataract, manage this depression – rather than just elements of a package – carry out this test, administer that medication, provide this therapy . So it’s no good saying ‘we provided another outpatient attendance’ if the protocol for the condition doesn’t allow for another attendance: the consortium will challenge the need to pay for the additional care. An approach based on care packages means analysis of pathways, not events.

The second is that outcomes are going to be crucial. So pathways have to be taken to their conclusion, which means they can’t be limited to what happened before discharge from hospital.

It seems to me that this is going to mean moving beyond current measures – readmissions or in-hospital mortality – to look at outcome indicators that tell us far more: patient reported outcome measures, through questionnaires about health status after treatment, and mortality within beyond discharge, through linking patient records with Office of National Statistics data.

Only with these measures will it be possible to see if care is delivering real benefit and, therefore, real value for money.

What about the demise of the National Programme? It always struck me as odd that a drive for efficiency and cost control should have set out to create local monopolies for the supply of software. How could that maintain the kind of choice that we wanted to offer patients, and therefore exercise the downward pressure on price and upward pressure on quality that competition is supposed to generate?

There also seemed to be a fundamental misconception in the idea that it was crucial to get all your software from a single source. One aim, of course, was to ensure that all systems were fully integrated. But if we’re building pathways, we do it with data from different sources linked in some intelligent way. That can be done by imposing on a range of suppliers the obligation to produce the necessary data in the appropriate form. That doesn’t require monopoly but accreditation.

The end of the National Programme, at least as far as local software supply is concerned, has to be welcomed. But, taken with the new pressures for different kinds of data, it will lead to significant pressure on healthcare information professionals, above all to learn to link data across sources and even beyond the limits of a hospital.

A challenge. But, I would say, an exciting one.

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...

Caution: software development under way

Software development work has admirably high professional standards. Unfortunately, developers find it a lot easier to state them than to stick to them.

If your development team is one of those that lives up to the most exacting standards, this blog post isn’t for you. If, on the other hand, an IT department or software supplier near you is falling short of the levels of professionalism you expect, I hope his overview may give you some pointers as to why.

Estimates, guesstimates

One of the extraordinary characteristics of developers is their ability to estimate the likely duration of a job. It’s astonishing how they can listen for twenty minutes to your description of what you want a piece of software to do, and then tell you exactly how long it’ll take to develop.

Afterwards you may want to get an independent and possibly more reliable estimate, say by slaughtering a chicken and consulting its entrails.

At any rate, multiply the estimate by at least three. This is because the developer will have left a number of factors out of account.

• He – and it usually is a ‘he’ – already has three projects on the go. He’s told you he’s fiendishly busy, but that won’t stop him estimating for the new job as though he had nothing else on. Why? Because a new project is always more interesting than one that’s already under way.
• He’ll make no allowance for interruptions, though he knows that his last three releases were so bug-ridden that he’s spending half of every day dealing with support calls.
• He’ll make no allowance for anything going wrong. I suffered from this problem in spades. I remember very clearly the one project I worked on which came in less than 10% over schedule. It’s the only one I remember when I’m estimating. All the others, which came in horrendous overruns, are expunged from my mind.
• He only thinks of his own time. For instance, he hasn’t allowed for documentation. Developers are part of a superior breed that lives by mystical communication with each other. Writing things down is like preparing a pre-nuptial agreement: it destroys all the romance. As for QA, well, yes, of course there should be some, but only to confirm that the software is bug-free. A few days at the end of the project. You object that there may be some feedback, as QA finds errors that need to be fixed. Well, yes, add a few days for that too, but believe me, it really isn’t going to hold up the project.. The Red Queen in Lewis Carroll’s Through the Looking Glass claimed ‘sometimes I've believed as many as six impossible things before breakfast.’ If you want to emulate her, start with ‘you can get good software without extensive QA.’ 
• He hasn’t actually seen a specification yet. That one deserves a section to itself.

Specifications – who needs one?

Once you’ve told the developer what you need from the new system, he just wants to get on with it. He doesn’t want to waste time writing requirements down. He wants to get on with cutting code.

Perhaps I should have written ‘Code’, with a capital ‘C’, since it has the status of near-sacred text. For those who don’t know it, it’s made up of large blocks of completely opaque programming language. Some unorthodox developers believe in including the occasional line of natural English, so-called comment lines, with the aim of explaining to someone who might come along later just what the code was intended to do. To purists, these lines just interrupt the natural flow of the Code. The next guy will be another member of the sacred band and will work out what the Code was intended to do, just by reading it and applying his mystic intuition. Comment lines are just boring, like specifications.

It’s true that specifications can be deadly. I recently saw a 35-page text covering work that we actually carried out in less than five days. The spec contained at least one page marked ‘This page intentionally left blank.’ Whenever I see one of those I want to scribble across it ‘why wasn’t this blank page intentionally left out?’

That kind of thing gives specifications a bad name, but something tighter and more to the point can be really useful. It can at least ensure that we understand the same thing by the words we use.

Once I came across a system which assumed that ‘Non-Elective’ meant the same as ‘Emergency’. Terribly embarrassing when you have to explain to a Trust why its emergency work has shot up while its maternity work has fallen to zero along with the tertiary referrals it used to receive.

Of course, if you’re working with people who just never need anything like that made clear to them, you may well be able to get away without a proper spec. One word of warning though: it’s really difficult to see how you can test software to see if it’s behaving properly, if you haven’t previously defined what it should be doing in the first place.

It’s about the reporting, dummy.

www.CartoonStock.com

Ever since Neanderthal times man has been expressing himself by means of graphics. So why in the twenty-first century are IT professionals finding it so difficult to understand the need to do the same?

Most users of healthcare information think its aim should be to help take better decisions about care delivery. So they might want to see a range of indicators all included in a single dashboard-type report. They may want to be able to drill up and down, say from a whole functional area within a hospital down to individual clinical teams to groups of patients with similar diagnoses. They may want to see values for the whole year or for a single months or, indeed, for trends across several months. They may ultimately want to get down to the level of the individual patient records behind the general indicator values.

Now many IT people will simply yawn at all this. Have you ever come across the term ‘ETL’? It means extract, transfer and load. The most exciting for an IT person is ‘Extract’. This means he’s looking at someone else’s system. This is a challenge, because the probability is that the teams who built that system didn’t bother with any comment lines or documentation – they’re kindred spirits, in fact. So it’s a battle of wits. Our man is hunting among tables with names like ‘37A’ or ‘PAT4201’, trying to identify the different bits of information to build up the records he’s been asked to load. And it’s a long-term source of innocent fun: system suppliers are quite likely to change the structure of their databases without warning, so that our developer can go through the whole process again every few months.

Next comes Transfer. Well, that’s a bit less absorbing though it can still be amusing. Your tables, for instance, might hold dates of birth in the form ‘19630622’ for 22 June 1963. The system you’re reading from might hold them in the form ‘22061963’. You can fill some idle hours quite productively writing the transfer routines mapping one format to the other.

Finally, there’s Load. Well, OK. Yes, it has to be done, but it’s not half as exciting. Get the data in, make sure that it’s more or less error-free. A bit fiddly, but there you go. Once it’s finished, your work is done.

Have you noticed the omission? We’ve done E, T and L. There’s been no mention of ‘R’ – Retrieval. What matters for IT is getting the data in and storing it securely. Making it available for someone else to use? Come on, that’s child’s play once the data’s been loaded into a database. It’s someone else’s department altogether.

Sadly, that’s not a department that is always as well staffed as it might be. That’s why hospitals are awash with data but short on information. That’s why we’ve spent billions on information systems with so little to show for it. That’s why clinical departments that want to assess their work build their own separate systems, creating new silos of data.

Unfortunately, investment isn’t as easy any more, and we certainly can’t keep making it without the real promise of a return. It’s great to see developers having fun, of course, but wouldn’t be even more fun to deliver systems that really worked and that healthcare managers really wanted to use? Systems that genuinely delivered information for management?

Sound utopian? Maybe it is.

But since it’s pretty much the minimal demand any user should be making of an information system worthy of the name, maybe it’s time we started insisting on it a bit more forcefully.