Tag Archives: data quality

Information Quality – Every Little Helps

Leave a reply

[Thanks to Tony O’Brien for sending this one in to us recently. For those of you not familiar with Tesco and their marketing slogans, this is their corporate website.]

ManagementToday.com has a great story (from 25th November) of how six bicycles purchased by Tesco from a supplier came with an apparent£1million (US$1.62 million) price tag.

Some red faces at Tesco HQ this morning, after news emerged that Britain’s biggest supermarket accidentally paid one of its suppliers almost £1m for six bikes.

The unit cost for each bicycle turns out to be a whopping £164000 instead of the usual £164.

While the majority of the money was repaid, the trouble for Tesco is that they are engaged in a dispute with the supplier in relation to other matters so the supplier has held on to 12% of the money. So Tesco have called in their lawyers. Which means that the total cost of failure will inevitably be much higher by the time the whole mess is sorted out.

Of course, simple consistency checks on data entry could have trapped that error and saved Tesco money and embarrassment.

It seems that with Information Quality, as with Retail Grocery, every little helps.

An Airtravel trainwreck near-miss

Leave a reply

From today’s Irish Independent comes a story which clearly shows the impact that poor quality information can have on a process or an outcome. The tale serves to highlight the fact that information entered as part of a process can feed into other processes and result in a less than desirable outcome.

On 20th March 2009, poor quality information nearly resulted in the worst air traffic disaster in Australian history as an Airbus A340-500 narrowly avoided crashing on take off into a residential area of Melbourne. The aircraft sustained damage to its tail and also caused damage to various lights and other systems on the runway of the airport at Melbourne.

The provisional report of the Australian Air Crash investigation found that the root cause for the incident was the inputting of an incorrect calculation for the weight of the aircraft of 262 tonnes, where as the plane was actually 362 tonnes in weight. This affected the calculations for airspeed required for take-off and the necessary thrust required to reach that speed.

The end  result was that the plane failed to take off correctly and gain height as required, resulting in the tail of the plane impacting on the runway and then proceeding to plough through a lighting array and airport instruments at the end of the runway.

It is interesting, from an Information Quality perspective, to read the areas that the Accident Investigation team are looking at for further investigation (I’ve put the ones of most interest in Bold text, and the full report is available here):

  • human performance and organisational risk controls, including:
    • data entry
    • a review of similar accidents and incidents
    • organisational risk controls
    • systems and processes relating to performance calculations
  • computer-based flight performance planning, including:
    • the effectiveness of the human interface of computer based planning tools.
  • reduced power takeoffs, including:
    • the risks associated with reduced power takeoffs and how they are  managed
    • crew ability to reconcile aircraft performance with required takeoff performance, and the associated decision making of the flight crew
    • preventative methods, especially technological advancements.

The Report by the Australian authorities also contains reference to some of the migitations that the aircraft operator was considering to help prevent a recurrence of this risk:

  • • human factors – including review of current pre-departure, runway performance calculation and cross-check procedures; to determine if additional enhancement is feasible and desirable, with particular regard to error tolerance and human factors issues.
  • training – including review of the initial and recurrent training in relation to mixed fleet flying and human factors.
  • fleet technical and procedures – including introduction of a performance calculation and verification system which will protect against single data source entry error by allowing at least two independent calculations.
  • hardware and software technology – including liaising with technology providers regarding systems for detecting abnormal take-off performance.

For those of us familiar with Information Quality practices, this is an impressive haul of information quality management improvement actions focussed on ensuring that this type of near-miss never happens again. It is doubly interesting that causes of poor quality information feature in the items that are subject to further investigation (e.g. “human factors”, risk controls etc.) and common approaches to resolution or prevention of information quality problems form 75% of the action plan put forward by the operator (process enhancement, improved checking of accuracy/validity, assuring consistency with other facts or measures etc).

Apple App Store IQ Trainwreck

Leave a reply

It appears that Apple iPhone App developers are having difficulty getting paid at the moment, according to this story from The Register. (Gizmodo.com carries the story here, Techcrunch.com has it here,

According to The Register:

A backlog in Apple’s payment processing system has left some iPhone developers still waiting for February’s payments, leaving some at risk of bankruptcy and considering legal action against the lads in Cupertino.

Desperate developers have been told to stop e-mailing the iTunes finance system and to wait patiently for their money – in some cases tens of thousands of dollars – while Apple sorts things out.

It would appear from comments and coverage elsewhere that this problem has been occurring for some developers for longer (since late 2008 according to the TechCrunch article and this article from eequalsmcsquare.com (an iphone community site))

The article goes on to explain that:

According to postings on the iPhone developer community Apple has been blaming bank errors and processing problems for the delays. Complainants are being told that payments have been made, that bank errors have caused rejections[.]

One commenter on the story on The Register, commenting anonymously, attempts to shed some light on this with an explanation that, from an Information Quality point of view, sounds plausible.

  • Two American banks merged (was it Washington Mutual and Chase?) and the SWIFT code for the customers of one had to change. The bank didn’t tell the customers and Apple had the payments refused. Apple seem to be manually changing the codes in the payment system, but that’s separate from the web interface where devs enter their bank details.
  • A lot of American banks don’t have SWIFT codes at all. Royalties from e.g. EU sales are sent from Apple (Luxembourg) S.A.. The chances of this money arriving at Bank Of Smalltown seem slim at best.

This what we have here is a failure to manage master data correctly it seems, and also a glaring case of potentially incomplete data which would impact the ability for funds to flow freely from the App Store to the Developers.

The Anonymous commenter’s explanation would seem to hold water because Apple are claiming that “bank errors have caused rejections”. Having had some experience with electronic funds transfer processes, one of the reasons a funds transfer would fail would be if the data used was incorrect, inconsistent or inaccurate. This would happen if the SWIFT codes of Bank A had to change (or if Bank A and Bank B had to have new codes issued).

However, some commenters based in the EU have reported that they have given Apple updated bank details and are still awaiting payment, which suggests there may be yet another potential root cause at play here that may yet come to light.

Apple still owes me more than $7,500 since September 2008 for US and World regions. I supplied them with a new SWIFT code and a intermediary bank they could use last month, but still nothing. Sent them tons of emails but I never got to know what is really wrong/faulty so I just tried to give them another SWIFT code that DNB (Biggest bank in Norway) uses. All other region payments have been OK.” (quote from comment featured on this article)

So, for the potential impact on iPhone Apps developers cash flow, and the PR impact on one of Apple’s flagship services, and the fact that management of the accuracy, completeness and consistency of key master data for a process, this counts as an IQ Trainwreck.

The Retail Data Nightmare

Leave a reply

Over at SmartDataCollective, Daniel Gent has shared an excellent example of a very common scenario in organizations across the globe… the troubling matter of the duplicated, fragmented and inconsistent customer details.

He shares a story with his readers about a recent trip to a retail store which used his telephone number as the search string to find his customer profile. The search returned no fewer than 7 distinct customer records, all of them variations on a theme. Daniel enumerates the records thusly:

1) One past owner of the phone from over 15 years ago;
2) Three versions of my name;
3) Two versions of my wife’s name; and,
4) One record that was a joint name account.

The implications that Daniel identifies for this are direct and immediate costs to the business:

  • Multiple duplicate direct mailings per year offering services
  • Multiple call centre contacts offering yet more services
  • Potential problems with calling on his warranty for the goods he bought because the store can’t find which of his customer records the warranty details are associated to.

Of course, this is just the tip of the ice-berg.

Daniel’s experience is all too common. And it is a Retail Data Nightmare that can quickly turn into an Information Quality trainwreck if left unchecked.

Google Health – Dead on Arrival due to duff data quality?

7 Replies

It would seem that poor quality information has caused some definitely embarassing and potentially risky outcomes in Google’s new on-line Patient Health Record service. The story has featured (amongst other places) :

  • Here (Boston.com, the website of the Boston Globe)
  • Here  (InformationWeek.com’s Global CIO Blog)

‘Patient Zero’ for this story was this blog post by “e-patient Dave” over at e-patient.net. In this blog post “e-Patient Dave” shared his experiences migrating his personal health records over to Google Health. To say that the quality of the information that was transferred was poor is an understatement. Amongst other things:

Yes, ladies and germs, it transmitted everything I’ve ever had. With almost no dates attached.

So, to someone looking at e-Patient Dave’s medical records in Google Health it would appear that his middle name might be Lucky as he had every ailment he’s ever had… at the same time.

Not only that, for the item where dates did come across on the migration, there were factual errors in the data. For example, the date given for e-Patient Dave’s cancer diagnosis was out by four months. To cap things off, e-patient Dave tells us that:

The really fun stuff, though, is that some of the conditions transmitted are things I’ve never had: aortic aneurysm and mets to the brain or spine.

The root cause that e-Patient Dave uncovered by talking to some doctors was that the migration process transferred billing code data rather than actual diagnostic data to Google Health. As readers of Larry English’s Improving Data Warehouse and Business Information Quality will know, the quality of that data isn’t always *ahem* good enough. As English tells us:

An insurance company discovered from its data warehouse, newly loaded with claims data, that 80% of the claims from one region were paid for a claim with a medical diagnosis code of  “broken leg”. Was that region a rough neighborhood? No, claims processors were measured on how fast they paid claims, rather than for accurate claim information. Only needing a “valid diagnosis code” to pay a claim, they frequently allowed the system to default to a value of “broken leg”.

(Historical note: while this example features in Larry’s book, it originally featured in an article he wrote for DM-Review (now Information-Management.com) back in 1996.)

“e-patient Dave” adds another wrinkle to this story..

[i]f a doc needs to bill insurance for something and the list of billing codes doesn’t happen to include exactly what your condition is, they cram it into something else so the stupid system will accept it.) (And, btw, everyone in the business is apparently accustomed to the system being stupid, so it’s no surprise that nobody can tell whether things are making any sense: nobody counts on the data to be meaningful in the first place.)

To cap it all off, a lot of the key data that e-Patient Dave expected to see transferred wasn’t there, and of what was transferred the information was either inaccurate or horridly incomplete:

  • what they transmitted for diagnoses was actually billing codes
  • the one item of medication data they sent was correct, but it was only my current BP med. (Which, btw, Google Health said had an urgent conflict with my two-years-ago potassium condition, which had been sent without a date). It sent no medication history, not even the fact that I’d had four weeks of high dosage Interleukin-2, which just MIGHT be useful to have in my personal health record, eh?
  • the allergies data did NOT include the one thing I must not ever, ever violate: no steroids ever again (e.g. cortisone) (they suppress the immune system), because it’ll interfere with the immune treatment that saved my life and is still active within me. (I am well, but my type of cancer normally recurs.)

    • So, it would seem that information quality problems that have been documented in the information quality literature for over a decade are at the root of an embarassing information quality trainwreck that could (potentially) have an affect on how a patient might be treated at a new hospital – considering they have all these ailments at once but appear asypmtomatic. To cap it all off, failures in the mapping of critical data resulted in an electronic patient record that was dangerously inaccurate and incomplete.

    Hugh Laurie as Dr. Gregory House

    Hugh Laurie as Dr. Gregory House

    What would Dr. Gregory House make of e-Patient Dave’s notes?

    e-Patient Dave’s blog post makes interesting reading (and at 2800 words + covers a lot of ground). He details a number of other reasons why quality problems exist in electronic patient records and why :

    • nobody’s in the habit of actually fixing errors. (he cites an x-ray record that shows him to be a female)
    • processes for data integrity in healthcare are largely absent, by ordinary business standards. I suspect there are few, if any, processes in place to prevent wrong data from entering the system, or tracking down the cause when things do go awry.
    • Data doesn’t seem to get transferred consistently from paper forms to electronic records (specficially e-Patient Dave’s requirement not to have steriods).
    • Lack of sufficient edit controls and governance over data and patient records, including audit trails.

    e-Patient Dave is at pains to make it clear that the problem isn’t with Google Health. The problem is with the data that was migrated across to Google Health from his existing electronic patient record.

    Google Health – DOA after an IQ Trainwreck.?

    Dead girl given truancy warning

    Leave a reply

    Courtesy of #dataquality twitterers Steve Tuck and Stephen Bonner comes this story from the BBC about a school in Cheshsire whose parents received a truancy notice about their daughter which threatened to ban her from her end of year prom for being over 30% below the target attendance rate for students.

    The young girl, Megan, had possibly the best excuse ever for playing hookey from school however. According to her mother:

    “Megan doesn’t go to that school any more. She’s been dead for two months now so it’s not surprising her attendance is low.”

    It appears that inconsistencies between two computer systems in the school resulted in the school’s left hand not knowing what the right hand was doing with regard to student information.

    Megan’s name had been taken off the school roll when she died, and removed from the main school database,” the spokeswoman said.

    “However, unknown to the school, her details had remained in a different part of the computer system and were called up when the school did a mail merge letter to the parents of all Year 11 students about their prom”.

    Reading the comments from the software providers in the BBC story, it would also appear that the software lacks a “dead student” flag to enable them to exclude deceased students from administrative mailings.

    This is a classic IQTrainwreck because it resulted in distress and upset to Megan’s parents, landed on the BBC News website (with video no less) , has been flashed across Twitter, and has now wound up here.

    Also, this failure of the computer systems to allow the left hand of the school (the student register systems) to know what the right hand (the Capita system) was doing is not dissimilar to the circumstances of the recent court case of Ferguson v British Gas where the defences put forward by British Gas that erroneous debt collection letters were ‘computer generated’ and so they couldn’t have been harassing the plaintiff were dismissed by the Court of Appeal in England and Wales.

    So we can add a potential legal risk to the list of reasons why this is an IQTrainwreck.