Tag Archives: legal issues in iq

Police Untelligence

From The Register comes this wonderful example of the problems that can arise where data is used for unintended purposes, resulting in poor quality outcomes for all involved.

The NYPD have been regularly raiding the home of an elderly Brooklyn couple. They’ve been hit 50 times over the past 4 years, which might mark them out as leading crime kingpins but for the fact that their address has wound up included in police data used to test notification systems. The Reg tags this as “a glitch in one of the department’s computers”, but Information Quality trainwreck observers will immediately recognise that the problem isn’t with the technology but with the Information.

The trainwreck is compounded by two facts which emerge in the article:

  1. NYPD believed that they had removed the couple’s address from the system back in 2007, but it appears to have not been the case (or perhaps it was restored from a backup)
  2. The solution the NYPD have now implemented is to put a flag on the couple’s address advising officers NOT to respond to calls to that address.

The latter “solution” echoes many of the pitfalls information quality professionals encounter on a daily basis where a “quick fix” is put in to address a specific symptom which then triggers (as el Reg puts it) “the law of unintended consequences”.  To cut through implication and suggestion, let’s pose the question – what happens if there is an actual incident at this couple’s home which requires a police response?

What might the alternative approaches or solutions be to this?

(And are the NYPD in discussions with the Slovak Border police about the perils of using live data or live subjects for testing?)

You can’t make an omlette with out breaking a few Eggs

A correspondent in the field, Nic Jefferis has sent in this story about how a “database glitch” has affected customers of the Egg on-line bank who have been trying to pay their bills using their NatWest debit cards.

The BBC describes the problem very succintly:

“The problem is that the Egg website does not recognise Natwest Visa Debit cards as being legitimate cards.”

The root cause seems to stem from the fact that key base data used by Egg’s on-line bank, the valid set of Bank Identification Numbers, appears to to not include NatWest Visa debit cards as they are only being rolled out at the moment to replace the existing Maestro Debit card facility currently in use at NatWest.

And at this point the second common component of IQTrainwrecks raises its head – who is responsible for the data.

Egg get their data from Experian. As soon as the problem arose, Egg contacted Experian to get a solution.  Natwest state that they were “aware of this problem and raised it with Egg at the outset” and were waiting for Egg to sort out the problem in their systems.

Somewhere in the process for maintaining BIN master data something has gone awry which has affected the ability of NatWest customers to pay bills using their new Visa debit cards. As the problem appears to be in the underlying base data, it is possible that there are impacts wider afield than just Egg’s payment systems.

As a source quoted in the BBC report says, this should be a straightforward process and an error like this would be highly unusual. But as we know here at IQTrainwrecks, it is often the simple errors that can have the biggest knock on impacts in downstream systems and processes resulting in loss, damage, injury, or frustration.

The terror of the Terrorist Watch list

A source who wishes to remain anoynymous sent us this link to a story on Wired.com about the state of the US Government’s Terrorist watch list.

The many and varied problems with the watch list have been covered on this blog before.

However, the reason that this most recent story constitutes an IQTrainwreck is that it seems that, despite undertakings to improve quality, the exact opposite has actually happened given:

  • The growth in the number of entries on the list
  • The failures on the part of the FBI to properly maintain and update information in a timely manner.

According to the report 15% of active terrorism suspects under investigation were not added to the Watch list. 72% of people cleared in closed investigations were not removed.

The report from the US Inspector General said that they “believe that the FBI’s failure to consistently nominate subjects of international and domestic terrorism investigations to the terrorist watchlist could pose a risk to national security.”

That quote sums up why this is an IQTrainwreck.

Continue reading

Double Debits – directly. (Another banking IQTrainwreck)

Courtesy of our Irish colleagues over on Tuppenceworth.ie comes yet another tale of poor quality information in financial services. Although this time it is at the lower end of the scale, at least on a per customer basis. However, the impacts on a customer are still irksome and problematic. And the solution the bank has put in place is a classic example of why inspecting defects out of a process is never an exact or value adding science.

It seems that Bank of Ireland has recently introduced some new software. Unfortunately, a bug in the software has resulted in certain transactions (deductions) being posted multiple times to accounts, resulting in cash-strapped Irish people being more strapped for cash than they’d expected.

Simon McGarr, (one of the authors over at Tuppenceworth) sums up the story and the reason why this is an IQTrainwreck:

I spotted a double charge on my account, for a pretty significant sum of money (is there any other kind?).

When I rang up to query it, I was told Bank of Ireland have changed their computer systems recently (Two weeks or so).

As a result, some transactions are being applied to accounts twice if they were processed through Laser [a debit card system in Ireland — ed.], or if they were a Pass machine [what the Irish call ATMs –ed.] withdrawal.

They say that if you spot the double charge, and ring them up to complain, they’ll send an email to their programmers to reverse the second charge.

I suggested to the polite customer services person that the bank might want to warn their clients to be alert for these double charges, as they could suffer additional charges (from appearing to breach their overdraft limits, for example) unless they spotted the bank’s mistake.

(Emphasis is added by this author)

Simon goes on to add (in a comment) that he has been without the benefit of his hard earned cash for 10 days (and counting).

Continue reading

Apple App Store IQ Trainwreck

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

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?

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

    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.