Risk Factor

As I wrote about in my previous post, world-wide efforts are underway to replace the paper-based medical record with electronic medical records (EHRs). For information on the US effort, you can visit the White House website to get some background information of the US effort, as well as the US Department of Health & Human Services (HHS) website to see current status information.

Something that has gone surprisingly unnoticed is that this month marks the hundredth anniversary of the modern paper medical record. This innovation, which we all take for granted, can trace its origins to Dr. Henry Plummer, a partner at the Mayo Clinic, in the year 1907. Plummer recognized that each patientâ''s medical history needed to be recorded, stored and retrieved in a different manner than was the current practice if the quality of patient care were to improve.

For example, when a patient first visited the clinic, a Mayo doctor would write up his medical notes in the currently active patient ledger book. On a patientâ''s later visit, the treating physician would need to unearth the correct ledger book where the patientâ''s first visit notes were entered, next find where in the ledger book the notes were written, and then append new information underneath the first entry. If there wasnâ''t sufficient room, the doctor wrote his notes in the margins of the page. Adding to the problem was that different medical departments had their own ledger books to record their interactions with the patient. Naturally, creating and especially retrieving a medical record was an awkward process that kept a doctor from having a complete understanding of a patientâ''s medical history.

Plummer, along with his assistant Mabel Root, developed and then began implementation on 1 July 1907 a â''patient dossierâ'' system to address these issues. Now, instead of a ledger, each Mayo doctor would record all aspects of a Mayo patientâ''s visit in a single, comprehensive file that was forever linked to the patient through a unique registration number. Whenever a patient left the clinic, the patientâ''s file was stored in a central file repository until the patient returned when it would be retrieved, possibly years later. This provided a means for maintaining continuity of patient care.

To increase efficiently further, Plummer, who I call properly the first true Chief Information Officer (CIO) as well as IS&T architect, devised an â''information networkâ'' consisting of conveyors and pneumatic tubes to more quickly retrieve patient information from the central repository. The mechanical network transported patient and other administrative information throughout the Mayo Clinicâ''s various offices and medical departments. Plummer later devised a medical search indexing method so that the information contained within a patientâ''s file, with permission, could be used to assist in advancing diagnostic research.

The benefits of his system were so evident that it did not take long for Plummerâ''s medical records systemâ''s approach to become a world-wide standard. His innovations worked very well in large hospital settings and small doctorâ''s offices alike, and provided family doctors almost a complete longitudinal record of a patientâ''s medical history for the next forty years.

So the next time you are at a doctorâ''s office, think about Dr. Plummer, and give him a nod of thanks.

There was a great commentary piece in the Wall Street Journal (subscription required) yesterday titled, â''Where are the Innovators in Health Care?â'' written by Regina Herzlinger, a professor at Harvard Business School, a senior fellow at the Manhattan Institute and the author of the book "Who Killed Health Care?"

Herzlinger describes the perverse disincentives to innovation in the health care industry, something that I wrote about last year for IEEE Spectrum and the various electronic health record initiatives being implemented by governments around the world. Basically, she argues, if a health care provider finds innovative ways to reduce the cost of treatment, the health care provider cannot share in the savings.

She gives an example of Duke University Medical Center, and its innovative program for people with congestive heart failure. Their innovative treatment,

â''â'¿ so substantially improved patients' health that hospital visits and usage plummeted, the perverse nature of the payment system meant Duke couldn't benefit from saving its patients' money -- nearly $8,000 per person. In only one year, the program had reduced costs by 40%, yielding the kind of do-good returns that would normally earn kudos from Wall Street and Main Street. But, because the third parties pay providers only for treating sick people, they penalize innovators who make people healthy.â''

Herzlinger goes on to write,

â''Non-market based payment is but one of many barriers to innovation that plague the health-care industry. Insurance entrepreneurs who confront mandated benefits and "community pricing" can neither design nor price their innovations. Technology entrepreneurs must clear massive hurdles before securing the â''codingâ'' and â''coverageâ'' decisions that open the door to reimbursement. And health-service entrepreneurs must comply with tens of thousands of pages of regulations.â''

The same thing happens in the defense industry as well, where innovations to reduce costs often are not embraced, because to do so would reduce a contractorâ''s net revenue. The government sometimes allows a portion of the cost savings to accrue back to the defense contractor if they are clever at reducing contract costs, but since these amounts are usually capped, the incentive for contractors to innovate are reduced.

Herzlinger calls for consumer-driven health care as a way to break what she calls, â''the entrepreneur-suppressing status quo.â'' She believes that if consumers can purchase health care in a market, with transparency of pricing and information on effectiveness of treatments, we would end up with better health care at a lower cost.

I think Herzlinger is correct in theory, although in practice it assumes a medically-literate population. Unless both education and consumerism are brought together simultaneously, the gains that might be had could also be canceled out.

Another interesting story from the UK from ComputerWeekly.com. It seems that HM Revenue and Customs is having trouble matching pay and tax details to individual taxpayers - about 13 million of them or 32% of taxpayers.

To make matters more "interesting," Revenue and Customs is about to transfer taxpayer files from one computer system to another, before all the taxpayer discrepancies are resolved. A Revenue spokesperson said that at least 75% of taxpayers had paid the right amount of tax (gee, only a 1 out of 4 chance that you paid too much or too little) and that the "good news" was that the back log of open cases would be reduced to 10.5 million having discrepancies by April 2008. I hate to know what bad news means to Revenue and Customs.

The US Internal Revenue Service has had long-term problems itself in trying to achieve modernization, but I don't recall it ever having reached this level of poor data quality. Those of us in the US may complain about the IRS, but I think our friends in the UK should have our profound sympathy.

It appears that the Security and Exchange Commission (SEC) is going to look, at least informally for now, at the blogs of John Mackey, CEO of Whole Foods. It appears that he posted rather unflattering opinions using a pseudonym of a major competitor, Wild Oats, which his company is now trying to buy.

While CEO's blogging and bad mouthing competitors is not unheard of, what is getting SEC attentions is that Mackey's musings might be interpreted as a means to drive down Wild Oats stock before an acquisition bid. Mackey also appeared to disclose company sensitive financial information in his blog. The question is whether there was "intent" to damage Wild Oats or "intent" to disclose information that could be interpreted as inside information.

Corporate lawyers are divided about whether SEC law was broken (no surprise there), the Wall Street Journal is saying (subscription required) that the whole thing is a tempest in the teapot, and others are claiming that Mackey was just exercising his free speech rights (also no surprise).

My own view, be it as it may, is that the SEC will likely warn Mackey not to make statements about his company under a pseudonym; Whole Foods will suffer a bit in its reputation and stock price for a short while because of the flap; Mackey will be warned by his board to shut up in the future; and the next CEO who does something similar is going to find the SEC hanging him or her out to dry. The free speech angle will need a court to decide.

The point is, that IS&T continues to create new situations and new risks that are hard to predict a priori. If Mackey had done what he had done using old paper and pen, I don't think there would be an argument over his intent - the idea of what blogging actually is about clouds intent. Is blogging just a person's "musings" or "opinions" that legally mean very little, if anything?

This area is very gray, and is getting legally tested all the time in regard to blogs and libel, for example. The law has always lagged technology. This case is no different. All we can do is sit back, watch the fun and blog about it.

After a relatively quiet period, IS&T glitches popped up in several places.

In Japan, sales of some mobile phones made by Sony Ericsson were continued again after they had been stopped on 4 July because of software problems that could erase stored telephone numbers among other items.

A Target department store in San Diego, California saw its point-of-sales system fail for a few hours, which likely cost it tens of thousands of dollars.

A computer problem created headaches for motorists trying to renew their car registrations at the Bureau of Motor Vehicles across Indiana. It had to happen, of course, the day when many registrations expire.

A software error in cable boxes in Burbank, California shut down a cable television system for six hours which affected 35,000 customers.

A lawsuit was filed in West Virgina against telecommunication company FiberNet alleging "breach of contract, fraud and negligence, and seeks class-action status and unspecified punitive and compensatory damages." Seems that a computer problem stopped service for two days to about half of its 24,000 customers, which included hospitals, police, businesses, etc.

And my favorite, five hundred and eighty-seven patients at Northern Cochise Community Hospital in Wilcox, Arizona received inaccurate hospital bills. The new billing software decided to keep adding the bill of the previous patient onto to the next patient's bill. Someone received a bill for $49 million.

Hope that last one didn't put the person back into the hospital.

This week two non-IT news items on what happens when you don't manage risk well appeared. The first was on the National Transportation Safety Board (NTSB) report of the collapse of the ceiling panels in Boston's Big Dig Tunnels that killed a woman. It seems that the epoxy glue holding the bolts that held up the concrete panels was of the wrong type.

The second was a report commissioned by the US Army Corps of Engineers on the decision making that led up to the failure of the levees in New Orleans. It seems that because of budget constraints and opposition of local leaders and environmental groups, that a great many decisions were made over time that incrementally increased the risks of the levees collapsing in a hurricane.

In both cases, warning signs were ignored. In 1999, bolts slipped, but the reason why they slipped was not thoroughly investigated. The Corps also knew that the existing flood walls were inadequate years before Katrina, but it found hundreds of rationalizations as why not to act.

Both of these reports should serve to remind the IT community of the importance of paying attention to the details, and the potential consequences of not forthrightly dealing with the problems when they make themselves known. They should also remind members of the IEEE of their first responsibility under the IEEE Code of Ethics:

To accept responsibility in making decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment.

We tend to forget about this until after the event.

A small story was published over at Government Executive magazine on the possibility that the wireless network used to support the Secure Border Initiative Network (SBINet) might be susceptible to hacking, and that the prime contractor Boeing is looking for ways to increase its security.

I wish Boeing luck. As my friend Peter Neumann wrote a long time ago, it is awfully hard to build security into a system after the fact.

In another software burp reported last week, some Scotiabank customers in Vancouver, Canada were surprised to find that their pre-authorized payments had been withdrawn twice from their bank accounts.

I personally know the fun that can cause. Many years back, I tried to withdraw $50 at my local bank's ATM. I was informed that this wasn't possible, since my account was overdrawn by roughly $1.4 million. That was news to me. Since I discovered this on a Friday night, I had to stew on it until Monday morning.

A "small software problem" (the bank's terminology) caused my overdraft which in turn meant my pre-authorized payments (like my mortgage) weren't paid on time. It took a good long while to get this mess straightened out, especially with the credit scoring companies who saw that I had missed a whole bunch of payments. Try telling them that it was just a computer error. I stopped using pre-authorized payments after that little episode, as well as changed banks.

Anyway, what caught my eye in the article were some quotes allegedly made from a person at a local university who said that he "wasn't surprised to hear of a technical error with banking systems." Me either - been there.

He went on to say, "I'd say that you have to expect some things like this.You can't expect things to be perfect even if they're run by technology." Yup - I agree.

"Personally, I don't blame the bank. I'd blame them if they didn't get right on it."

Huh? He didn't blame the bank - it was just a technology error? The bigger problem was if the bank's response wasn't effective?

I vehemently disagree - I do blame the bank, and it better make its customers' whole again and quickly.

When are we going to quit giving companies (and government organizations) free passes on software foul-ups?

The only way that I would not blame the bank is if it could reasonably explain to me why the error checking routine in its application software to ensure that double payments could not be made failed - and could not be traced to any decisions they made or actions they took. It is not like the possibility of an erroneousness double payment is some novel event that had never occurred in any previous banking systems.

I would also like the bank to explain to me why it thought its current business, systems and software engineering practices used to create its banking application should be seen as posing "acceptable" risk, especially in relation to this event occurring.

This stuff happens all the time - as the person quoted above mentions - but until the bank proves why it should be held blameless, this is an unacceptable failure that I, at least, do totally blame as being the bank's fault. I think its customers should too.

Some 20,000 ex-Enron workers who finally received their first payment for some of their lost retirement funds were told that they were over-underpaid (12,800 total) or maybe worse over-paid (7,700 total) because of a computer burp. Those over-paid are probably going to have to pay the money back.

Of course, the company involved could just reprogram the software to account for the over-payment/under-payment in the next payment due, but ...

A couple of years back, I wrote a story for IEEE Spectrum on Why Software Fails. I opened with the story that has been floating around the software business for the past twenty years about the disappearing warehouse. Well, yesterday I read a story in the Wall Street Journal about another "disappearing" warehouse - this time to help hide accounting fraud.

The story (subscription required) concerned the electronics company International Rectifier which recently admitted in filings with the US Security and Exchange Commission (SEC) that its Audit Committee had found some "material weaknesses in internal control," one being that a "foreign subsidiary where from time to time certain unsubstantiated orders were entered. These orders resulted in the shipment of products and the recording of sales with no obligation by customers to receive and pay for the products. The practice included routing certain product shipments to warehouses not on the Company's logistical systems."

An, the phantom warehouse trick, as Maxwell Smart used to say! Not quite a disappearing warehouse, but hey, close enough.

For those interested in the history of phantom inventories and how computing systems are great for helping along the practice, I suggest you start with a nice overview posted at the American Institute of Certified Public Accountants (AICPA). You'll find several tracks to follow from there.