Showing posts with label IT failure. Show all posts
Showing posts with label IT failure. Show all posts

Monday, October 28, 2013

Over At The Health Care Blog, Aneesh Chopra Distorts IT Failure Reality

I feel sorry for President Obama.  I really do.  He's been deceived by IT hyperenthusiasts who, in addition to their hyperenthusiasm, probably heaped him a big helping of plain old lies.

I warned of this in my Feb. 18, 2009 Letter to the Editor published in the Wall Street Journal (at http://online.wsj.com/news/articles/SB123492035330205101, third letter):

Dear Wall Street Journal:

You observe that the true political goal is socialized medicine facilitated by health care information technology. You note that the public is being deceived, as the rules behind this takeover were stealthily inserted in the stimulus bill.

I have a different view on who is deceiving whom. In fact, it is the government that has been deceived by the HIT industry and its pundits. Stated directly, the administration is deluded about the true difficulty of making large-scale health IT work. The beneficiaries will largely be the IT industry and IT management consultants.

For £12.7 billion the U.K., which already has socialized medicine, still does not have a working national HIT system, but instead has a major IT quagmire, some of it caused by U.S. HIT vendors. [That project, the National Programme for IT in the NHS or NPfIT, was since abandoned - ed.]

HIT (with a few exceptions) is largely a disaster. I'm far more concerned about a mega-expensive IT misadventure than an IT-empowered takeover of medicine.

The stimulus bill, to its credit, recognizes the need for research on improving HIT. However this is a tool to facilitate clinical care, not a cybernetic miracle to revolutionize medicine. The government has bought the IT magic bullet exuberance hook, line and sinker.

I can only hope patients get something worthwhile for the $20 billion.

Now, more spin and misinformation by Aneesh Chopra, senior fellow at the Center for American Progress, and the former U.S. chief technology officer in the Obama Administration over at the Health Care Blog at a piece "What's Next For Healthcare.gov?" (http://thehealthcareblog.com/blog/2013/10/25/whats-next-for-healthcare-gov/).

Like a cybernetic Rasputin, Chopra writes:

The launch of HealthCare.gov certainly didn’t go as planned. Due to technical errors, millions of Americans were sent to the functional equivalent of a waiting room before they could enter the shopping portion of the site.

Historically, projects of such complexity and demand have encountered early problems yet still often achieve great success. While much of the commentary has focused on coding problems, the site still has the potential to spur innovation — be it public or private —  that will result in quality improvement and lower costs.

(Note the definitive "will", without evidence.  Mr. Obama's probably been hearing a lot of non-evidence-based wishful thinking about health IT in recent years.)

The statement about future success is belied, for example, by the National Programme for IT in the NHS (NPfIT) failing and going "pfffft" as just one example (http://hcrenewal.blogspot.com/2011/09/npfit-programme-going-pffft.html and other links).

More generally, there's this article by Shaun Goldfinch, formerly at the U. Otago in New Zealand:

"Pessimism, Computer Failure, and Information Systems Development in the Public Sector."  (Public Administration Review 67;5:917-929, Sept/Oct. 2007, Shaun Goldfinch, University of Otago, New Zealand). 

Unfortunately it's not freely available, but a free first-page preview is at http://www.jstor.org/discover/10.2307/4624644?uid=3739864&uid=2129&uid=2&uid=70&uid=4&uid=3739256&sid=21102828298677:

Summary:

The majority of information systems developments are unsuccessful. The larger the development, the more likely it will be unsuccessful. Despite the persistence of this problem for decades and the expenditure of vast sums of money, computer failure has received surprisingly little attention in the public administration literature. This article outlines the problems of enthusiasm and the problems of control, as well as the overwhelming complexity, that make the failure of large developments almost inevitable. Rather than the positive view found in much of the public administration literature, the author suggests a pessimism when it comes to information systems development. Aims for information technology should be modest ones, and in many cases, the risks, uncertainties, and probability of failure mean that new investments in technology are not justified. The author argues for a public official as a recalcitrant, suspicious, and skeptical adopter of IT.

Article start:

The majority of information systems (IS) developments are unsuccessfu1. The larger the development, the more likely it will be unsuccessful.

Though the exact numbers are uncertain and depend to some extent on how success is measured, something like 20 percent to 30 percent of all developments are total failures in which projects are abandoned. Around 30 percent to 60 percent are partial failures in which there are time and cost overruns or other problems. The minority are those counted as successes (Collins and Bicknell 1997; Corner and Hinton 2002; Georgiadou 2003; Heeks and Bhatnagar 1999; Heeks 2002, 2004 ; Iacovou 1999; James 1997; Korac-Boisvert and Kouzmin 1995 ; Standish Group 2001, 2004).

A U.S. survey of IS projects conducted by the Standish Group in 2001 found that success rates varied from 59 percent in the retail sector to 32 percent in the financial sector, 27 percent in manufacturing, and 18 percent in government. Overall, the success rate was 26 percent. In all, 46 percent of projects had problems, including being over budget and behind schedule or being delivered with fewer functions and features than originally specified. Another 28 percent failed altogether or were cancelled. Cost overruns averaged nearly 200 percent. Th is success rate varied dramatically by total project budget: For projects under US$750,000 the success rate was 55 percent; for those with budgets over US$10 million, no projects were successful (SIMPL/NZIER 2000).

More recent Standish Group (2004) estimates saw a success rate of 29 percent, but 53 percent of projects had problems and 18 percent failed. A New Zealand government study judged 38 percent of government projects a success, while 59 percent involved problems and 3 percent were a complete failure or were cancelled. Government success rates, at 31 percent, were slightly higher than private sector success rates. Above the NZ$10 million mark, however, the success rate for both was zero (SIMPL/ NZIER 2000). One study of hundreds of corporate software developments found that five out of six projects were considered unsuccessful, with one-third cancelled outright. Of the two-thirds that were not cancelled, price and completion times were almost twice what had originally been planned (Georgiadou 2003). The Royal Academy of Engineering and the British Computer Society (2004) found that 84 percent of public sector projects resulted in failure of some sort.

The sums involved in such projects can be staggering.  A study of IS developments in the British public sector estimated that 20 percent of expenditures were wasted, and a further 30 percent to 40 percent led to no perceivable benefits (Wilcocks 1994). In 1994, the U.S. General Accounting Office reported that spending of more than US$200 billion in the previous 12 years had led to few meaningful returns.

The article is extensively referenced, and nothing has changed since it was published.  While the article's cost from the jstor.org site is $25 (US I think), it is well worth reading for anyone involved in large public sector IT projects.

Especially, the President of the United States and his staff.

It is my belief the same actors who've misled him about health IT and the supposed ease of building a national insurance portal for 300 million+ people are going to mislead him about remediation of the latter, resulting in yet more embarrassment, and perhaps eventually patient harm and death when someone, somewhere, is denied care or has delayed care due to insurance loss.

Finally, I note this in Chopra's bio at the Health Care Blog Piece:

Aneesh Chopra is a senior advisor at The Advisory Board Company

The Advisory Board Company (http://www.advisory.com/About-Us) is:

... a performance improvement partner for 165,000+ leaders in 4,100+ organizations across health care and higher education.

The Advisory Board Company has been an advisor on hospital management and technology for decades.

Perhaps they're another piece in the puzzle as to why hospital executives are implementing bad health IT (http://cci.drexel.edu/faculty/ssilverstein/cases/) technology in droves, such as in the ED where many underprivileged people get primary and emergency care.  (See "Quality and Safety Implications of Emergency Department Information Systems: ED EHR Systems Pose Serious Concerns, Report Says" at http://hcrenewal.blogspot.com/2013/10/quality-and-safety-implications-of.html, for example.)

After all, with senior advisors to a major healthcare organization consultant in denialist roles, if the IT's bad now, it will be just great in ver. 2.0.

(See "The Denialists' Deck of Cards: An Illustrated Taxonomy of Rhetoric Used to Frustrate Consumer Protection Efforts" by Chris Jay Hoofnagle, available at http://papers.ssrn.com/sol3/papers.cfm?abstract_id=962462.)

The same Denialist Deck of Cards is being played, I fear, to frustrate taxpayer attempts at hemming in waste ... and to frustrate the President of the United States' efforts to leave a good legacy.

-- SS

Tuesday, December 20, 2011

David Pogue: "The Year of C.E.O. Failures Explained" and Why IT is so Bad

David Pogue is a prolific writer on IT, having written some of the most popular books on MacIntosh, e.g., the Mac Secrets series.

In an article in the Dec. 15, 2011 New York Times on "CEO's idiotic blunders" as he calls them, he reveals why IT generally, HIT included, may be so poorly done:

The Latest in Technology from David Pogue
The Year of CEO Failures Explained
New York Times
Dec. 15, 2011

... But it doesn’t seem like you’d need a business degree to appreciate that these [decisions by CEO's on making major changes to businesses] would be bad decisions. Whenever I see a company shooting itself in the foot like that, I always wonder: how could anyone be so stupid? When do people become so stupid?

Last spring, I taught a class at the Columbia Business School called “What Makes a Hit a Hit—and a Flop a Flop.” I focused on consumer-tech success stories and disasters.

I distinctly remember the day I focused on products that were rushed to market when they were full of bugs — and the company knew it (can you say “BlackBerry Storm?”). I sagely told my class full of twentysomethings that I was proud to talk to them now, when they were young and impressionable — that I hoped I could instill some sense of Doing What’s Right before they became corrupted by the corporate world.

But it was too late.

To my astonishment, hands shot up all over the room. These budding chief executives wound up telling me, politely, that I was wrong. That there’s a solid business case for shipping half-finished software. “You get the revenue flowing,” one young lady told me. “You don’t want to let your investors down, right? You can always fix the software later.”

You can always fix the software later. Wow.

That’s right. Use your customers as beta testers. Don’t worry about burning them. Don’t worry about souring them on your company name forever. There will always be more customers where those came from, right?

In health IT, beta-testing unregulated, experimental software medical devices on patients is commonplace. And patients do get burned. Literally.

That “ignore the customer” approach hasn’t worked out so well for Hewlett-Packard, Netflix and Cisco. All three suffered enormous public black eyes. All three looked like they had no idea what they were doing.

Maybe all of those M.B.A.’s pouring into the workplace know something we don’t. Maybe there’s actually a shrewd master plan that the common folk can’t even fathom.

Actually, no. If anything, IMO the MBA's suffer the Dunning-Kruger effect.

But maybe, too, there’s a solid business case to be made for factoring public reaction and the customer’s interest into big business decisions. And maybe, just maybe, that idea will become other C.E.O.s’ 2012 New Year’s resolution.

I doubt it.

In healthcare IT, it will take a few more years - and much more litigation - before the frankly immoral and nihilistic attitude of "we can fix the software later" becomes taboo.

It may also take some of those sage MBA's realizing that their loved ones have no "reset button" when they've been "burned" by faulty health IT, and that their loved ones - unlike software - cannot be "fixed later."

-- SS

Thursday, October 13, 2011

"24", This Computer Project Was Not

A fascinating case study of IT failure in another life-critical domain has come to my attention.

I think if the words "FBI" were replaced with "hospitals" and "healthcare IT", this could be a study of IT failure in the latter organizations. Many of the familiar issues are there:

The Failure of Virtual Case File and the FBI

Background

The FBI first sought to embrace technology in the 1980s during the onset of computer availability and hoped to have a paperless office where agents could quickly pull up case files, information, and photographs at the comfort of their desks without having to sift and sort through numerous paper files. The infrastructure in that time was limited to text based search engines and there were no provisions for photo storage or the ability to scan written reports. As a result, the FBI found its agents decided not to rely on the existing technology and were reverting back to paper.

After the attacks on September 11, 2001, the FBI was placed under scrutiny for being ineffective and inefficient in its operations due to the time it would take to share information with other law enforcement agencies, locate reports, and transmit them from one location to another (usually done via fax or by mailed CDs). To combat this, the FBI developed a plan known as Trilogy, which aimed for three primary goals: A new computer network, personal computers for most agents, and an online criminal database that would be titled Virtual Case File (VCF). An external contractor by the name of Science Applications International Corp. (SAIC) was contracted in June 2001 to begin the project with an estimated schedule of three years for completion and a first year budget of $14 million. The project continued until early 2005 (7 months over schedule), at which time the project scope had expanded by 80% with costs of $170 million and was riddled with issues. Ultimately, in early 2005, the project was cancelled but not after escalation and persistence on the part of the FBI.


The Problems and Failure of VCF

The FBI wanted SAIC to create the database from scratch instead of using off-the shelf Oracle programs that could have been customized. A study by the National Research Council (NRC) after the planned 3-year period in late 2004 was conducted to gauge the success of the program, and while the first two goals had been achieved (personal computers for most agents and the creation of a new network), VCF was found to be problematic and incomplete. The project plan was incomplete and there were no monitoring controls regarding finances or the schedule. The FBI threw quality out the window by wanting to bypass testing and release the product upon its ready date.

However, VCF failed the most basic functionality tests under the NRC and had not included network management, security, and storage systems, or basic sorting capabilities. The study also found that most of the FBI's skilled managers had left for the private sector and there were little to no individuals who had the IT experience or knowledge to interact effectively with contractors to achieve what was needed. The definition and scope of operations and processes were ultimately entrusted to SAIC who were outsiders.

In an attempt to salvage the project, the FBI immediately hired a federally funded R&D firm (Aerospace Corp.) costing $2 million to conduct an assessment of the project who concluded that the project needed to be scrapped and shut down due to the severity of the software issues. Upon investigation by Congress, there was a lack of financial controls and safeguards on the part of the FBI, enabling SAIC to continue to develop a program which was lacklustre and failed to meet objectives.

200 programmers from SAIC were used on the project when only a dozen were required and SAIC was not being properly monitored by the FBI. They felt as long as money was being funnelled to them by the government on the project, they did not need to be responsible for the effectiveness or viability of the program [was there a "hold harmless" clause as in health IT? - ed.] they were building and fired staff who expressed concerns over the direction of the program. [They must have been Luddites and IT skeptics who just refused to change the way they do things - ed.]

Further, the FBI took a trial by error approach to the project without truly understanding their end goal and without setting benchmarks for evaluating the progress of the project and took a nearly hands off approach by entrusting SAIC entirely. SAIC claimed the FBI were indecisive in what they wanted and there had been 19 government personnel changes over the project tenure which brought on scope creep and the focus of the project in a state of flux, in addition to a clear lack of leadership. A further $17 million was then spent by the FBI to perform more rigorous testing to try to salvage the project once more, which was another missed opportunity to cancel the project. It was only in early 2005 that the decision was made by Congress to terminate the project.

Source: Eggen, Dan; Witte, Griff. 'The FBI Upgrade that wasn't'. August 8, 2006. Website: http://www.washingtonpost.com/wp-dyn/content/article/2006/08/17/AR2006081701485.html (accessed on November 7, 2009).


"24" this was not.


Chloe O'Brian, where were you?

In the FBI's case, the failure exposes us to potential crime. In a hospital's case, the stakes are even more personal.

Even worse, at least here Congress intervened; health IT is a virtually unregulated industry and nobody is minding the store.

The UK's National Programme for IT (NPfIT) in the NHS paid the price of failure through problems such as above.

Will the "NPfIT in the HHS" meet a similar fate?

-- SS

Oct. 13, 2011 Addendum: where have we seen SAIC before?

How about here?

Case 3: Bedlam

Meanwhile, Science Applications International Corporation disclosed that computer backup tapes containing medical data for 4.9 million military patients [that number also amounts to almost 2% of the total U.S. population - ed.] had been stolen from an employee’s car in San Antonio. The data included Social Security numbers, clinical notes, laboratory test results and prescriptions.

-- SS

Friday, January 14, 2011

ONC Workgroup Document Misindentification - Just the Type of Computer "Glitch" That Can Kill People

A provocative title indeed.

The Office of the National Coordinator's Health IT Standards Committee Implementation Workgroup recently had a meeting, Jan. 10-11, 2010.

They've posted the testimony and supporting documents here: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1482&&PageID=17128&mode=2 .

I've copied & pasted these document links directly from the site, at 12:45 PM EST 1/14/2011:


The problem is, some of the URL's are simply wrong, including several of the ones I've bolded.

For instance, I tried to download Dr. Willa Drummond's documents:


The links for "Collection of Problem Scenarios from Professional List Serve" and "Ten Commandments for Computerized Healthcare Information Systems" are simply wrong.

They lead to the incorrect documents as of this writing.

By experimentation (borne of experience!), I found I could locate the correct documents by manually altering a number in the URL.

For example, to locate the "Problem Scenarios" document whose URL is linked as:

http://healthit.hhs.gov/portal/server.pt/document/949972/drumexsum-imwg-11011_pdf

I had to alter the number 949972 to 949973, like this:

http://healthit.hhs.gov/portal/server.pt/document/949973/drumexsum-imwg-11011_pdf

I further had to experiment to find the "Ten Commandments" document, also erroneously listed as at this URL ...

http://healthit.hhs.gov/portal/server.pt/document/949972/drumexsum-imwg-11011_pdf

... but actually here at 949971:

http://healthit.hhs.gov/portal/server.pt/document/949971/drumexsum-imwg-11011_pdf

Presumably these erroneous indices will be fixed at some point. Are they due to computer and/or software error, or human error -- as in medicine, due to busy schedules, cognitive overload from a suboptimal IT user experience, and other factors?

I do not consider these errors "minor" or at all humorous. Leadership by example - through fine attention to detail - in a supposed "HITECH" paperless-medicine promoting government organization - is what I expect.

Similar "misidentification" errors in EHR systems can and do cause medications to be missed or given to the wrong patient - such as in the example at the Trinity Healthcare System as mentioned in my post "Huffington Post Investigative Fund: FDA, Obama Digital Medical Records Team at Odds over Safety Oversight" where an EHR "upgrade" caused considerable risk:

... Computers at a major Midwest hospital chain went awry on June 29, posting some doctors’ orders to the wrong medical charts in a few cases and possibly putting patients in harm’s way.

The digital records system “would switch to another patient record without the user directing it to do so,” said Stephen Shivinsky, vice-president for corporate communications at Trinity Health System. Trinity operates 46 hospitals, most in Michigan, Iowa and Ohio.

[In other words, data entered by clinicians was going into the wrong charts. How many charts were involved? Does the hospital system even know, I wonder? - ed.]


Less than two weeks later, an unrelated glitch caused Trinity to shut down its $400 million system for four hours at 10 hospitals in the network because electronic pharmacy orders weren’t being delivered to nurses for dispensing to patients, he said.

See the many questions I raised about this episode at the followup post "More on Huffington Post Investigative Fund: "FDA, Obama Digital Medical Records Team at Odds over Safety Oversight." (I understand that the initial "fix" to the problem of "orders going to the wrong chart" was to prevent clinicians from opening more than one chart at a time, thus further interfering with clinicians' work.)

"Glitches" cause sometimes crucial data to be lost, and even patients to be harmed or killed (e.g., see the gray banner at top of my site on HIT failure, and my recent post "EHR Problems? No, They're Merely Anecodotal; the Truth Must Be That I Attract Bad Electrons and Stale Bits" on this blog).

Ironically, the First Commandment in the mislinked Ten Commandments document above is:

"The Computer shall find and collate all data generated by other computers."

Perhaps it should read:

"The Computer shall find and correctly collate all data generated by other computers."

-- SS

1/14 addendum:

I looked specifically for those documents as my first retrievals on the HHS site due to past correspondence with Dr. Drummond. The pinball machine then tilted.

Perhaps it is simply those bad electrons and stale bits that follow me around once more.

Monday, January 18, 2010

Electronic Medical Records and Going For Broke: Jackson Health System's Financial Future Appears Grim

I have written on numerous occasions that health IT in its present form, often poorly designed and implemented under current IT leadership structures, is often a waste of precious healthcare resources. The resources might be better spent on essentials such as patient care for the poor or improved human staffing, until this experimental technology is perfected.

As at my site on health IT difficulties and mismanagement I observed:

Healthcare information technology (HIT) holds great promise towards improving healthcare quality, safety and costs. As we enter the second decade of the 21st century, however, this potential has been largely unrealized. A significant factor impeding HIT achievement has been mismanagement of the technology. Mismanagement of HIT is largely due to false assumptions and naïveté concerning the challenges presented by this still-experimental technology, and underestimations of the expertise essential to achieve the potential benefits of HIT. This results in mission-hostile HIT design, and HIT leaders and stakeholders operating outside (often far outside) the boundaries of their professional competencies. Until these issues are acknowledged and corrected, HIT efforts will waste precious healthcare resources, will not achieve claimed benefits for many years to come, and may actually cause harm. Numerous reports in the 2009 articles link corroborate this view, including those from the U.S. Joint Commission and National Research Council.

The following may bring my observations to life.

This from 2007:

RedOrbit.com/News
Jackson Memorial Hospital Uses State-of-the-Art Technology to Drive Improved Patient Outcomes for South Florida Families

Posted on: Thursday, 6 September 2007, 09:11 EDT

Jackson Memorial Hospital (JMH), part of Jackson Memorial Health System, South Florida's leading/largest healthcare provider, recently implemented 11 Cerner Millennium® solutions.

[Including EMR, nursing, pharmacy, radiology, HIM, Eligibility Management, Master Person Index, Registration Management, Scheduling Management, Emergency Department, etc. - ed.]

This marks the hospital's first step in a multi-stage healthcare information technology implementation. With Cerner Millennium® solutions, JMH clinicians now have access to real-time resources to better manage patient care with improved access to cross-department information, evidence-based clinical decision support and streamlined hospitals operations.

"Cerner is pleased to partner with Jackson Memorial Hospital, an institution continually ranked as one of the best hospitals in America," said Trace Devanny, Cerner -- president. "JMH's decision to implement a solution-oriented information technology system reinforces its vision to improve healthcare communitywide. Cerner worked together with JMH to implement multiple Cerner Millennium solutions specifically designed for various roles, venues and conditions that will ultimately improve the patient experience."


These implementations, a mere "first step" towards "streamlining operations," and their maintenance, modification, remediation, and staffing were undoubtedly multimillion-dollar expenses and are likely still ongoing. (See other examples of mass hospital IT expenditures here and here.)

Now, fast forward to 2010. This is stunning:

Jackson Health System's financial future appears grim

Miami Herald
BY JOHN DORSCHNER
Posted on Wednesday, 01.13.10

Looking forward and back, Jackson Health System's grim financial picture just keeps getting worse.

Members of the Public Health Trust, the system's governing board, are being told:

Patient volume has dropped by 6.5 percent recently, meaning that with all the cost cutting and new revenue plans, Jackson is facing an $88 million loss this fiscal year, and this estimate is likely to get worse.

The government system may have lost much more money last year than the $56 million it reported in unaudited statements. That loss could conceivably go as high as $150 million.

Cash on hand to pay bills -- the measure of how the three-hospital system is doing at this moment -- continues to be awful. ``Perhaps a cash hemorrhage,'' PHT member Marcos Lapciuc called it.

The bad news came at PHT committee hearings late Tuesday afternoon. ``Very drastic measures need to happen'' to stem the growing losses, said Chief Executive Eneida Roldan. She said the losses were likely to increase, because considerable funding for poor patients comes from Tallahassee, and the Legislature is expected to cut back on healthcare funding programs as it deals with its own budget crisis.

``We're making very drastic decisions that no hospital wants to do,'' Roldan told the board, including ending contracts for 175 unfunded patients to receive dialysis at out-patient centers.

Ending contracts for unfunded patients to receive dialysis after spending tens of millions of dollars on IT to "streamline operations?" Could this be an example of "Blood for Computers?"

Board members were upset in particular about how the institution, with 12,000 employees and $1.9 billion in revenue, could be so uncertain about its financial performance last year.

The central issue appears to be the proper amount of accounts receivable -- money that the system expects to collect from insurers -- as contrasted with bad debts that are unlikely to be collected. As of Nov. 30, Jackson was listing its accounts receivable at $431.8 million.

``It just doesn't tie in,'' said board member Martin Zilber. ``We talk about $400 million or $500 million like it's buying lunch.''

Ernst & Young, Jackson's auditors, are expected to present the official audited returns within the next month. ``We know there's going to be a sizable adjustment,'' Chief Financial Officer Frank Barrett told the board. But he's uncertain how much.

Uncertain how much money will be "adjusted" in accounts receivable? Apparently all this computerization has not realized a ROI on basic financial management.

Could problems with the IT (e.g., mismanaged design, mission hostile user experience, bugs, etc.) and/or mismanagement of its implementation actually be responsible for the chaos, I ask?

... Perplexed board members heard several explanations. One is that the system has switched computer systems, and the old financial software may have been calculating bills as accounts receivable from years ago, when those items should be listed as uncollectable bad debts.

If that was the case (and I note the "may have", implying the organization is not even certain of this explanation), why was this discrepancy not noted before or during the transition? Who, exactly, was managing this project? This would be a stunning example of IT mismanagement making what happened at Yale some years ago look like a cakewalk, and on par with the mismanagement at another Miami hospital, Mt. Sinai, as I posted here.

... On Monday, the board was shown a presentation on bill collecting with a complex grid of flow charts and time lines. Still, some board members expressed concern about why Jackson's financial people didn't have a better handle on key measures of the system's condition.

A question arises regarding whether the massive IT implementations are causing data irregularities, confusion, or are not functioning properly in other ways affecting financial management.

``I don't totally understand the reasons,'' said [board member] Ernsto de la Fé.

...
The fiscal 2009-2010 budget had calculated a loss of $6.5 million. Of that, $107 million was the baseline loss, reduced by $59.8 million in new revenue building ventures and $41.5 million in cost-cutting.

"Cost cutting" usually is synonymous with "layoffs." How many millions were spent on computing instead of jobs, I wonder?

Additional information on these financial difficulties are available at the Miami Herald:


While IT is not a definite cause or contributor to these problems, I sense familiar patterns. Perhaps forensics related to hospital computing, the decisions to spend so many millions on the technology, and the actual impact of the implementations might shed additional light on the reasons for this apparent financial debacle.

Perhaps the hospital system would have better spent that money on buttressing its financial stability, and hiring smart people to have kept better track of its finances.

An analysis of these issues might likely provide a cautionary tale for hospital executives planning on massive new HIT expenditures to "streamline operations."

Addendum:

This is a good time to once again call attention to this paper by a perspicacious author from Down Under:

Pessimism, Computer Failure, and Information Systems Development in the Public Sector. (Public Administration Review 67;5:917-929, Sept/Oct. 2007, Shaun Goldfinch, University of Otago, New Zealand). Cautionary article on IT that should be read by every healthcare executive documenting the widespread nature of IT difficulties and failure, the lack of attention to the issues responsible, and recommending much more critical attitudes towards IT. link to pdf

Feb. 11, 2010 Addendum:

CFO at Miami health system resigns

MIAMI – Frank Barrett, chief financial officer and executive vice president at Miami's Jackson Health System, has resigned after five years in the position. The health system's board of directors criticized Barrett strongly last week after he reported miscalculated financial losses. Barrett had revealed to the board that Jackson Health lost $203.8 million in fiscal 2009, although he had originally reported a $46.8 million loss. The projected loss for fiscal 2010 rose $87 million to $229 million.


-- SS