Author Archives: admin

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.

Poor Quality Information costs money – and you can take that to the Bank

Leave a reply

via Keith Underdown comes this story hot off the press release engine in the UK’s Financial Services Authority.

Barclay’s Bank have been fined stg£2.45 million for “failing to provide accurate transaction reports to the FSA and for serious weaknesses in systems and controls in relation to transaction reporting”. The fine would have been higher (stg£3.5 million but for the fact that Barclay’s co-operated with the investigation and agreed to settle the matter quickly). According the the FSA press release

“Complete and accurate transaction reports are an essential component of the FSA’s market monitoring work. Barclays’ reporting failures could have a damaging impact on our ability to detect and investigate suspected market abuse.

“The penalty imposed on Barclays is significantly higher than previous penalties imposed for transaction reporting errors. This reflects the serious nature of Barclays’ breaches and is a warning to other firms that the FSA will not tolerate inadequate systems and controls.”

This is an interesting warning that serves as an indicator of how Regulatory systems and enforcement will be changing in a post-Recession world.

Of course, the true cost to Barclays is much greater than the cost of the fine. For one, there is the reputational damage that comes from being fined to this extent by the FSA. And then there is the cost of correcting errors and fixing the defective processes, which Barclays has done “including commissioning a review of its transaction reporting process and committing extensive resources to improve its processes and resolve the errors.”

Reviews and resources don’t grow on trees you know.

This is a clear example of an IQ Trainwreck.

A cautionary tale of GPS woes

2 Replies

From today’s Irish Times comes a story which shows the real significance and impact of a common Information/Data Quality problem, transposition of letters or numbers.

A Swedish couple holidaying in Italy were looking forward to their visit to the lovely sunny island of  Capri.

Unfortunately a “finger flub” on their GPS put them 650 kilometres north and inland of their intended destination in the lovely Italian industrial town of Carpi.

Oh dear.

Kid from 6th Sense works on Economic Stimulus – he stimulates dead people

3 Replies

The bad joke in the headline aside, this story (which comes to us via Initiate Systems on Twitter, who linked to it from WBALTV in Baltimore USA) reveals a common type of IQ Trainwreck – the “sending things to dead people” problem.

As we know, the US Government has been sending out Stimulus Cheques (or Checks, if you are in the US) to people to help stimulate consumer spending in the US economy. Kind of like a defibrillator for consumer confidence.

Initiate Systems picked up on the story of a cheque that was sent to Mrs Rose Hagner. Her son found it in the mail and was a bit surprised when he saw it. After all, he’s 83 years old and his mother has been dead for over 40 years. Social Security officials give the following explanation:

Of the about 52 million checks that have been mailed out, about 10,000 of those have been sent to people who are deceased.

The agency blames the error on the strict mid-June deadline of mailing out all of the checks, which didn’t leave officials much time to clean up all of their records.

Of course, one might ask why this was such a challenge when the issue raised its head in 2008 as well when a cheque was mailed to a man in Georgia which was made out to a Mr George Croker DECD (an abbreviation for deceased). The story, which was picked up by SmartPros.com at the time (and for the life of us we can’t see how it slipped under our radar), describes the situation as follows:

Richard Hicks, a Fulton County magistrate, says the $600 check arrived in Roswell this week and was made out to George A. Coker DECD, which, of course, stands for “deceased.”

Coker obviously won’t be able to do his bit to spur the consumer economy, which has Hicks puzzled and somewhat miffed.

“There’s a $9 trillion national debt and our government’s giving away money to dead people,” he told The Atlanta Journal-Constitution. “As a taxpayer, it offends the hell out of me.”

The Internal Revenue Service in Atlanta told the newspaper it didn’t know how many other DECD checks have been written nationwide since the 2007 returns are still being processed.

So, the issue has existed since at least 2008 and relates to data being used for a new purpose (sending cheques on a blanket basis). It would seem the solution that is being attempted is to inspect the errors out of the cheque batches before they are sent by the June dead-line. A better solution might be to:

  1. Apply some business rules to the process, for example “If recipient is older than 120 then verify – as the oldest person in the world is currently 115), or parse the name string to determine which social security records end with “DECD” or any other standard variant abbreviation for “deceased”.
  2. Embed these checks (not cheques) into the process for managing the master data set rather than applying them at ‘point of use’.

Building quality into a process, and into the information produced by and consumed by a process, reduces the risk of embarrassing information quality errors. Cleaning and correcting errors or exceptions as a bulk batch process is not as value-adding as actually improving your processes to prevent poor quality information being created or being acted on.

Why is this an IQ Trainwreck?

Well, the volumes of records affected and the actual cost are quite low so one could argue that the information is “close enough for government work”. However, government work tends to get political and a google search on this topic has thrown up a lot of negative political comment from opponents of the stimulus plan.

The volume and actual cost may be low, but the likely impact in terms of PR impact and time that might be required to explain the issue in the media highlights the often overlooked cost and impact of poor quality information – reputation and credibility.

Tax disc mailings… on the Double

Leave a reply

From our ever vigilant sources over at The Register comes this story of duplicated information resulting in confusion and costs to the UK Taxpayer.

It seems that the UK DVLA has issued duplicate tax discs to concientous motorists who renewed their motor tax on-line.

A DVLA spokesman told theRegister: “As a result of an error, a number of customers, who recently purchased tax discs on line or by phone, were issued with duplicate tax discs.

“Once the problem was identified, swift action was taken to rectify it. All customers affected are being sent a letter of apology and the erroneous discs have been cancelled.”

So. Let’s sum this one up…

  1. Poor quality information in a process resulted in the normal cost of the Motor tax process being higher than it should (because of duplicate postage and printing costs for the certificates sent in error).
  2. A further printing and postage expense will be incurred to apologise to motorists for the confusion
  3. Analysis will need to be done to identify all the affected motorists, which will require staff to be diverted from other duties or increased costs due to overtime or external IT contractor spend
  4. People might bin the wrong tax disc and find themselves technically in breach of the law.

This is a simple example of the costs to organizations of poor quality information. A classic IQTrainwreck scenario.

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.

I am who I am, except when I’m not.

Leave a reply

Steve Tuck, writing over at SmartDataCollective, shares a tale of an embarassing IQTrainwreck involving his brother. The root cause of Steve’s tale is ‘false positives’ in matching, but it goes to show how simple assumptions or errors in the management of the quality of information can lead to unforeseen and undesired consequences.

Steve’s brother had checked into a hotel for a trade conference. He went and had a shower and was quite surprised to come out of the bathroom to find another man standing in his room. It turned out that they both had the same name and were both attending the same event and the hotel had (despite all the other evidence to the contrary, like different companies and different credit card details) decided to merge the two reservations so two people wound up being booked into the same room.

The second Mr Tuck had to take his bags and go to a different hotel in the end, causing unnecessary aggravation for him (it is always nice to be staying in the hotel a conference is on in… the more relaxed pace over breakfast can help ease you into the day). Steve’s brother had the embarassment of being caught in little more than a towel.

For the embarassment factor and customer service impacts, this meets the criteria for an IQ Trainwreck. 

Thanks Steve.

This isn’t the first time we’ve covered this type of false positive IQ Trainwreck though. A scan of our archives brings up this story from 2007.

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

    TB or not TB (with apologies to Shakespeare)

    3 Replies

    The Irish Examiner newspaper today carried this story about an American lawyer who was let back into the US despite being red-flagged as a health risk.

    It would seem that he had acquired a particularly nasty drug-resistant form of Tuberculosis – a diagnosis which was confirmed in Europe where he was travelling. He was advised not to travel and to seek treatment. Being a sensible personal injury lawyer with an understanding of duty of care to others who might be harmed by his actions and causal chains in litigation, he jumped on the next flight out.

    Despite warnings from US health officials not to board another long flight, he flew home for treatment, fearing he would not survive if he did not reach the US, he said. He said he tried to sneak home by way of Canada instead of flying directly into the US.

    When he got to the US/Canadian border his passport swipe popped a big red flag that advised the Border guard to restrain him, to prevent him from entering the US and to don a protective mask when dealing with this lawyer. The border guard promptly waved him through, despite the medical advice to hold him and quarantine him, because…

    the infected man seemed perfectly healthy and that he thought the warning was merely “discretionary”.

    While the guard is not a doctor, their future career as a border guard may also be in question (they are currently on ‘administrative duties’). The union representing the guard in question has gone on record saying that “public health issues are not receiving adquate attention and training” within the Dept of Homeland Security.

    The right information was in the right place at the right time. It was accurate. However through a disregard for process the information was without value and the border security process didn’t work as expected. That disregard for process may have had a root cause in a failure of training to either cover the public health issue or a failure of the organisation to emphasise that the role of Homeland Security is to protect against threats – not just terrorist ones.

    Sometimes an IQ Trainwreck just gets you in the …

    Leave a reply

    Over on the website of Information Impact (Larry P. English’s consulting firm) a list of “Publicly exposed IQ Problems” is maintained. Occasionally we like to pop over and see what Larry’s people have spotted in the media that we might have missed.

    One that got the (male) administrator of this site right in the *ahem* was the story of a US Army veteran who had the wrong testicle removed in a Veterans Administration Hospital. It seems that a chain of small errors resulted in the surgeon confidently and competently removing the wrong gonad. Gonad… I’d goMad.

    The interesting thing on the USA Today blog site is that in the related stories they link to a Washington Post story that says that “wrong site surgery” (in other words accidentally cutting off perfectly functioning body parts or the right part off the wrong person) could be up to 20 times more common than previously thought. However they also link to a press release from the Agency for Healthcare Research and Quality (an American organisation) detailing a study that shows wrong site surgery to be less common than previously thought.

    This contradiction in statistics is itself an IQ Trainwreck – either there is a problem which should be addressed with expidition or there isn’t a problem. The fact that reliable information appears not to be available (perhaps through non-reporting of the issue in some cases) means that the ‘customers’ of healthcare services in the US don’t have information that meets, let alone exceeds, their expectations.

    At least the two reports agree that these errors are preventable.

    Of course wrong site surgery never happens outside the USA. Apart from:

    the Irish man who had his stomach removed in error due to a mix up in tissue samples (no, that is not the set up to a humorous punchline). In this case doctors went to the extent of sending the tissue samples to an outside laboratory to get the diagnosis confirmed before operating (a 21 year old man was diagnosed with advanced stomach cancer). However the defect in the process/information had occured so early in the chain of events that their ‘stop and check’ actions simply confirmed the incorrect diagnosis leading to an extreme result for the young man in question.