At "FDA on Health IT Adverse Consequences: 44 Reported Injuries And 6 Deaths In Two Years, Probably Just Tip of Iceberg" I wrote about a meeting of the HIT Policy Committee, Adoption/Certification Workgroup on February 25, 2010. The topic was "HIT safety." The agenda, presenters and presentations are available at this link.

At this meeting FDA testimony was given by Jeffrey Shuren, Director of FDA’s Center for Devices and Radiological Health. Dr. Shuren noted several categories of health IT-induced adverse consequences known by FDA. This information was striking.

He wrote:

... In the past two years, we have received 260 reports of HIT-related malfunctions with the potential for patient harm – including 44 reported injuries and 6 reported deaths. Because these reports are purely voluntary, they may represent only the tip of the iceberg in terms of the HIT-related problems that exist.

Well, there's absolutely nothing to worry about, according to the Office of the National Coordinator and Dr. David Blumenthal. Nothing to see here. Move on.

Blumenthal has just reportedly stated that:

http://www.massdevice.com/news/blumenthal-evidence-adverse-events-with-emrs-anecdotal-and-fragmented

... [Blumenthal's] department is confident that its mission remains unchanged in trying to push all healthcare establishments to adopt EMRs as a standard practice. "The [ONC] committee [investigating FDA reports of HIT endangement] said that nothing it had found would give them any pause that a policy of introducing EMR's could impede patient safety," he said.

I ask a simple question:

• Are these the words to be reasonably expected from an academic physician/scientist?

Perhaps I'm a bit behind these postmodern times, but I once believed the perhaps now old-fashioned and obsolete view that a scientist would not base a conclusion of medical safety in national dissemination of drug, device, or whatever on some analysis of anecdotal data, whether 'preliminary' or final.

Due to reasons such as the lack of knowledge of FDA as a place to report HIT problems, as well as fear by clinicians in reporting HIT problems at all, the cited FDA data (260 HIT-related adverse events over two years, including 44 reported injuries and six deaths) is most certainly anecdotal and incomplete, and potentially (per FDA's Jeff Shuren, MD, JD) the "tip of the iceberg."

I would not take the FDA data to be anything but a possible red flag, not a source of truth, one way or the other.

For example, the scant reports of health IT bugs and defects -- many of which admittedly could cause medical error -- in another database, MAUDE, voluntarily submitted by just a tiny fraction of the HIT vendors, should give a scientist pause. They are a sentinel. (See my Oct. 2009 post "Our Policy Is To Always Have Unabashed Faith In The Computer ... Except When It Screws Up, And Then It's The Doctor's Fault" for several MAUDE database examples).

Obviously, the unreported, unrecognized (and therefore uncorrected) bugs and defects have the same potential. Those MAUDE reports alone should provide an impetus to call for full, rigorous, scientific, uncensored investigations on HIT safety, not make pronouncements on safety to a national audience.

Proof by lack of evidence is not what I was taught in medical school.

Blumenthal appears to be speaking not as a scientist, but as a marketer and (of course) politician.

This is quite disappointing.

However, as the man said, nothing to see here, move along.

By the way, I am assuming the "analysis" will be open to public scrutiny.

At an interview of Barry Chaiken, MD, MPH, FHIMSS, former Chairman of the Board of health IT trade group HIMSS and chief medical officer of Imprivata, a company specializing in healthcare IT security, Chaiken pleads for the following special accommodations for Health IT relative to other medical sectors:

... We’re still learning, in healthcare, about that user interface. We’re still learning about how to put the applications together in a clinical workflow that’s going to be valuable to the patients and to the people who are providing care. Let’s be patient. Let’s give them a chance to figure out the right way to do this. Let’s give the application providers an opportunity to make this better.

[Why are the health IT applications bad to begin with, I ask? - ed.]

I note the following.

• If 'we're' still learning (and I don't include people with genuine clinical computing expertise in that subgroup, but it does include the plethora of amateurs in the commercial health IT industry), then the technology is experimental.
• Worse, it's unregulated - a major special accommodation in and of itself.
  
• These sentiments about "being patient" would be appropriate - if the subjects of this experimental technology that vendors need to be "given a chance" to make better were experimental lab rats.

Instead, the subjects of the experimental technology are unwitting, unconsenting human beings, who are being used as experimental test subjects for software development, and being put at risk, injured and indeed killed by the disruptions these experimental technologies cause.

Under these realities, the position presented by Chaiken is, in my opinion, ethically perverse.

That such sentiments come from someone who holds the MD degree and who I assume took the Hippocratic oath in some form is stunning.

In the health IT industry, "Primum non nocere" seems to have been replaced with "Kybernetik über alle."

Further, the commercial health IT vendors have had the good part of five decades to "get it right." How long is long enough?

Their software is unavailable for detailed evaluation and open critique of the user experience by impartial experts, unlike open source EHR's like VistA CPRS, demo version available at this link where anyone can:

• Download the latest version of CPRS today and get access to new features including graphing functionality
• Use the software as if you were a provider by entering orders, entering documentation, retrieving reports (and graphs) and viewing alerts and notifications that help with decision support
• Learn first hand how VA’s electronic health record system works

Personally, I've had to use stealth simply to obtain and post graphical representations of some simply inexcusable commercial HIT interface sins (link). Why should a secretive industry be given additional special accommodation?

Dr. Chaiken goes on to state:

Let’s hold them accountable if they don’t [make the applications better]. Absolutely, hold them accountable if they don’t; and the marketplace, I hope, will be able to make those choices and hold them accountable when they don’t. But, we’re still learning.

Again, I'm not sure who the "we're" refers to, but "holding companies accountable" will not really help victims of the experiments who are seriously injured or killed.

A better solution, as I have written on this blog (such as at my Nov. 2008 post "Should The U.S. Call A Moratorium On Ambitious National Electronic Health Records Plans?" and at other sites as well:

Protect patients. Constrain the health IT experiment temporally and geographically, and apply the laws, customs and regulations of medical experimentation until this industry "has learned" whatever lessons Chaiken thinks they need to learn, e.g., from decades of Medical Informatics, Social Informatics, Computer Science, HCI and other research. None of these fields - last time I looked - are classified or protected intellectual property. Share information on patient adverse outcomes and near misses, instead of concealing them and contractually gagging users from openly speaking about problems.

That would be the ethical approach.

Further, how many more decades should we wait for the health IT industry to figure out how to look for better leaders beyond the "school of hard knocks" bias that's existed for at least the past decade? How many substandard health IT leaders were placed in hospitals the past few decades as a result of outrageous attitudes like these below from the major recrutiers, centered on spreading the wealth?

I don't think a degree gets you anything," says healthcare recruiter Lion Goodman, president of the Goodman Group in San Rafael, California about CIO's and other healthcare MIS staffers. Healthcare MIS recruiter Betsy Hersher of Hersher Associates, Northbrook, Illinois, agreed, stating "There's nothing like the school of hard knocks." In seeking out CIO talent, recruiter Lion Goodman "doesn't think clinical experience yields [hospital] IT people who have broad enough perspective. Physicians in particular make poor choices for CIOs. They don't think of the business issues at hand because they're consumed with patient care issues," according to Goodman. Healthcare Informatics, "Who's Growing CIO's."

[No, that line about 'being consumed with patient care issues' as a strike against health IT leadership didn't come from a Scott Adams business-idiot parody cartoon - ed.]

As in clinical medicine itself, if you're going to be anywhere near patient care and making decisions affecting its delivery, a degree damn well "gets you something."

At about the same time the above appeared in Healthcare Informatics, a generalist IT recruiter wrote me this:

... What is happening to MDs trying to change careers is providing a window into broader issues about professionals in society today - narrow training, pigeonholing in the marketplace, difficulty making lateral and cross-industry transition, what a handicap it is to be creative, entrepreneurial, or cross-disciplinary in the current marketplace, and the wasted intellectual capital represented by the high caliber of individuals who can't find ways to fruitfully plug themselves into the marketplace.

I continue to be amazed at this general phenomenon...the remarkable quality of a number of candidates I've met, and the lack of recruiters' ability to get them in the door of good companies. The interesting part of the story is that when I am able to get access to high level execs in some of these companies (not just IT, but devices, pharmaceuticals, etc. also) they are dismayed at the quality of those that they hire. They know that something is wrong in how the recruitment process is working. (eg, one of the major device cos. just devoted the time of 1 FTE in Human Resources to 'finding innovative ways of identifying and recruiting good talent into the company.')

Whose fault were the outrageous, deleterious hiring practices prevalent in this industry that contributed materially to its production of substandard products, hiring practices that persist to this day? (See example here.)

Why should we be "patient", and "give them [yet more chances] to figure out the right way to do this", and why should patients permit themselves to continue to be guinea pigs to such a sloppy, cavalier industry?

I note that Chaiken's credentials appear to fit the template, as colleague Roy Poses describes at various posts including here, of an "executive isolated from the real world of health care" and member of the superclass. From the interview linked above:

... According to your LinkedIn profile, you’re CMO for Imprivata, CMIO for Symphony Corporation, and CMO of DocsNetwork. You’re on a couple of advisory boards, you own a vineyard, and you just finished your term as chair of the HIMSS board.

Perhaps that helps explain the mantra of "computers [and profit] first, patients second."

Finally, in answer to my own question above "Why are the health IT applications bad to begin with", I suggest complacency, incompetence, willful ignorance, and negligence (including criminal negligence) as possible answers.

-- SS

Addendum:

The following in today's WSJ caught my eye ("What we've learned from the Gulf spill", Michio Kaku, July 20, 2010):

The nagging question is: Why did it take so long? Why couldn't they have capped the leak months ago? For three agonizing months, BP's engineers and executives were essentially making things up as they went along, conducting a billion dollar science project with the American people as guinea pigs. The basic science of stopping oil leaks at 5,000 feet below sea level should have been done years ago.

Concepts are similar. With just a few edits, we have this:

The nagging question is: Why is it taking so long? Why couldn't they have learned to create useful health IT decades ago? For at least thirty agonizing years, Health IT vendors' engineers and executives were essentially making things up as they went along, conducting a multibillion dollar science project with the American people as guinea pigs. The basic science of producing safe, effective, usable health IT should have been done years ago.

I present another health IT problem case from the FDA's voluntary MAUDE (Manufacturer and User Facility Device Experience) database below.

From FDA's description of MAUDE:

• MAUDE data represents reports of adverse events involving medical devices. The data consists of voluntary reports since June 1993, user facility reports since 1991, distributor reports since 1993, and manufacturer reports since August 1996. MAUDE may not include reports made according to exemptions, variances, or alternative reporting requirements granted under 21 CFR 803.19.
• The on-line search allows you to search CDRH database information on medical devices which may have malfunctioned or caused a death or serious injury. MAUDE is scheduled to be updated monthly and the search page reflects the date of the most recent update. FDA seeks to include all reports received prior to the update. However, the inclusion of some reports may be delayed by technical or clerical difficulties.
• MAUDE data is not intended to be used either to evaluate rates of adverse events or to compare adverse event occurrence rates across devices. Please be aware that reports regarding device trade names may have been submitted under different manufacturer names. Searches only retrieve records that contain the search term(s) provided by the requester.

I somehow missed the following case when I wrote the Oct. 2009 post 'Our Policy Is To Always Have Unabashed Faith In The Computer ... Except When It Screws Up, And Then It's The Doctor's Fault' but I have added it there as well:

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1656460
CERNER MILLENIUM POWERCHART CPOE
Event Date 11/19/2006
Event Type: Death
Patient Outcome: Death

The medication review screen of the subject device does not specify the exact dose in milligrams of combination medications. For example, narcotics are combined with tylenol in at least two strengths. Liquid narcotic tylenol-oxycodone combination is reported in ml, not mg. The exact dose of tylenol is not specified and requires knowledge of the combination medication dose in the volume specified.

Certain fields of the grid do not specify the volume, but rather state "date/time" requiring another click or pop up screen. The immediate knowledge of tylenol dosage in mg is directly related to understanding and preventing excessive doses. In the subject, 10 ml of acetaminophen-oxycodone is indicated as having been given 3 times over 4 hours. That means that 1950 mg of tylenol was administered in 4 hours while the patient was in a state of starvation and receiving other medication that increase the effects of tylenol.

This dose would equate to 11,700 mg of tylenol over 24 hours, nearly 3 times the maximum daily dose in otherwise health people. In the ensuing days, the patient developed acute renal failure, presumably acute tubular necrosis, and died. In the absence of other etiology, the excess tylenol was the culprit. This was not considered as etiology ante-mortem. The counterintuitive screen impaired the professionals. The pharmacist did not recognize and stop the medication, the nurses administered it, and the excessive dose, clinically meaninglessly listed as a volume of 10 ml -given 3 times in 4 hours- of acetaminophen-oxycodone, was missed by the physicians. Adverse events have been ascribed to "user error" by vendors.

The device offers a potent propensity to life endangering oversights. There are other screens on this device which present information that interfere with clinically useful visualization of data. [Who designed these screens, I ask? Clinicians, or business IT personnel used to designing inventory systems for widget control? - ed.] The data does not flow to the professionals. It is not represented in a meaningfully useful manner.

The professionals need to hunt for it. As such, the user unfriendly screens [see this link on mission hostile HIT - ed.] impair safe medical care consistent with the impediment to expedient professional understanding of what, exactly, is the dose of medication and how much was administered to the patient. This sentinel case of death is directly attributed to user unfriendly screens on this device.

How many cases like this, as well as "near misses" related to health IT go unreported, nationwide and worldwide?

As in my paper "Remediating an Unintended Consequence of Healthcare IT: A Dearth of Data on Unintended Consequences of Healthcare IT", nobody really knows; these devices are unregulated with no requirements for reporting.

However, let's roll it out nationally anyway, because HIT will deterministically "revolutionize" medicine. Just ignore those spoil-the-party, man-behind-the-curtain prattle from writers like these.

We can safely ignore all contrarian research and literature, of course, as we all know HIT will revolutionize medicine from the definitive certainty of HHS in "The 'Meaningful Use' Regulation for Electronic Health Records", NEJM, Blumenthal and Tavenner (10.1056/NEJMp1006114, July 13, 2010):

The widespread use of electronic health records (EHRs) in the United States is inevitable. EHRs will improve caregivers’ decisions and patients’ outcomes. Once patients experience the benefits of this technology, they will demand nothing less from their providers. Hundreds of thousands of physicians have already seen these benefits in their clinical practice.

[Except for those who haven't - ed.]

And our government's called BP Energy Company cavalier?

I offer no additional comments.

AI recently had the chance to observe my mother's care in a small community hospital.

This was a hospital that, in her last several days there before going back to a nursing home for rehab, went live with a major vendor CPOE. The CPOE was brought in from a parent large hospital where the CPOE had been in use several years.

Just by passing the nursing station/doctor's charting room on my mother's floor and opening my eyes and ears, I saw doctors and nurses struggling to take care of patients while "getting the bugs out of the system."

They had had received some classroom "training" in a static environment, but it was clear they were learning about a lot of "gotcha's" and unanticipated glitches in vivo.

The fact of problems were predictable. In fact, I predicted unexpected difficulties to several of my mother's clinicians before go-live.

There was some skepticism (maybe in my nearly being in tears about my mother, I came off as a bit melodramatic). However, several later told me they "now knew what I was talking about" upon my mother's discharge, just several days into the go-live.

One story I overheard during go-live especially sticks out in my mind.

A newly-admitted patient who needed urgent heparinization did not receive the medication promptly. The patient's physician could not order it, and could not enter the required weight needed to order it, due to some type of 'glitch' or system malfunction. Physicians found no way to override, despite calls to the help desk, attempts by on site IT people and users from the parent hospital, etc.

In the end, the pharmacist simply provided the med using a weight estimate despite no "official" order having been entered into CPOE. I heard that the delay was on the order of "several hours."

Clearly, both technology and people issues were involved ... but I assure the reader, injured or dead patients really don't care exactly how their injury occurred, after the fact (other than in litigation, which doesn't fix the damage or remediate the suffering).

Here, then, is my question:

Where does the moral authority come from to subject live, unsuspecting, uninformed patients to the type of risks the patient whose heparin was delayed was subject to?

What right did the hospital have to NOT inform this patient before admission that a new critical CPOE system was going "live" that day, and that the patient could consider going to another hospital a few miles down the road instead that had no such potential problems?

From the Belmont Report (also see http://ohsr.od.nih.gov/guidelines/belmont.html ), the six fundamental ethical principles for using any human subjects for research are:

• (1) Respect for persons: protecting the autonomy of all people and treating them with courtesy and respect and allowing for informed consent;
• (2) Beneficence: maximizing benefits for the research project while minimizing risks to the research subjects; and
• (3) Justice: ensuring reasonable, non-exploitative, and well-considered procedures are administered fairly (the fair distribution of costs and benefits to potential research participants.)
• (4) Fidelity: fairness and equality.
• (5) Non-maleficence: Do no harm.
• (6) Veracity: Be truthful, no deception.

I would like a straight, unspun answer to this simple question:

On the basis of Belmont Report and other medical ethics regulations, where does the moral authority come from for hospitals to put patients through such risks without informing them ahead of time and offering them an opt-out, even if only the continued use of paper in their care?

I have passed this question on to major American Medical Informatics Association mailing lists and await replies.

The National Institute of Standards and Technology (NIST) has begun to address deficient clinical IT usability. A PDF with presentations on the topic from the recent NIST conference on HIT usability is here (warning: very large, 26 MB).

There is a critical "meta-issue" that's being ignored regarding usability, though, yet it is the elephant in the living room.

First, I will detail the elephant, then ask the simple, logical question that arises (the "inconvenient" question that nobody seems to be able to give a straight, non-marketing-spin answer to).

Here are the details of the elephant.

First, poor usability ---> increased risk to patients.

This is a first principle; it is not open to debate.

Now:

If NIST is just now getting involved in "improving HIT usability" (the improvement of which should have occurred at least two decades ago);

While HIMSS's former Chairman of the Board admits the technology remains experimental:

... We’re still learning, in healthcare, about that user interface. We’re still learning about how to put the applications together in a clinical workflow that’s going to be valuable to the patients and to the people who are providing care. Let’s be patient. Let’s give them a chance to figure out the right way to do this. Let’s give the application providers an opportunity to make this better;

While HIMSS itself admits in this 2009 PDF that

"Electronic medical record (EMR)!adoption rates have been slower than expected in the United States, especially in comparison to other industry sectors and other developed countries. A key reason, aside from initial costs and lost productivity during EMR implementation, is lack of efficiency and usability of EMRs currently available";

While the National Research Council (the highest scientific authority in the U.S.) last year reported that :

"Current Approaches to U.S. Health Care Information Technology are Insufficient" and that the technology "does not support clinicians' cognitive needs." The study was chaired by Medical Informatics pioneers Octo Barnett (Harvard/MGH) and William Stead (Vanderbilt);

While it's not just the user experience that's the problem, either...

Insurers are starting to recognize this, e.g., "NORCAL Mutual Insurance Company: "Electronic Health Records: Recognizing and Managing the Risks" ;

While hospitals and vendors cannot yet manage the technology reliably - how many medical mistakes have/will occur as a result of screw ups like this one, now confirmed to have occurred at a religious-denomination hospital chain headquartered in the Great Lakes region of the U.S.?

This patient won't get a second chance, either.

The above issues are the elephant in the living room. Or, shall I say, in the Boardrooms and meeting rooms where health IT is planned and discussed?

Health IT is great stuff, guys; it might actually work well one day!

Let's roll it out nationally and penalize those Luddite doctors

who refuse to "use it meaningfully" because it's not very usable.

Oh, just ignore that strange creature over there in the corner ...

Considering the size and weight of the elephant, here is my question:

Why are we rolling out this technology nationally under penalty of Medicare garnishment?

I cannot get a straight, unspun answer to that question.

Perhaps we need Bill O'Reilly to ask these questions of health IT officials on his FOX News program, The O'Reilly Factor, where spin is attacked relentlessly (the "No Spin Zone.")

From the aforementioned Huffington Post Investigative Fund article "FDA, Obama Digital Medical Records Team at Odds over Safety Oversight" and timeline of industry resistance to government oversight of health IT (link), one document stands out in my mind.

The internal FDA memorandum of Feb. 23, 2010 ("not intended for public use") to Jeffrey Shuren on HIT risks. which I have now re-hosted at this link (PDF) is quite fascinating.



Internal FDA Memo ("not intended for public use") on potential dangers of health IT. Download the PDF here.



The memo begins:

This report serves to characterize medical device reports (MDRs) in the Manufacturer and User Facility Experience (MAUDE) database, inclusive of MedSun reports, pertaining to Health Information Technology (H-IT) safety issues as requested by the Office of the Center Director, Center for Devices and Radiological Health (CDRH), in contrast to the previously submitted MedSun and Office of Compliance information.

(I've mentioned MAUDE here and here, including a report of an HIT-related patient death at the latter link.)

To those "anecdotalists" in the healthcare information technology community who believe reports of HIT-related harm are "anecdotal, and anecdotes don't make data" (as opposed to the "Markopolists"):

When an internal FDA review of their own data concludes the following, I invite you to think about the point of view that maintains that reports of HIT-related patient injury and death are so 'fragmentary' as to not merit (actually, demand) significant resources be diverted to rigorously addressing the issue of HIT risk:

In summary, the results of this data review suggest significant clinical implications and public safety issues surrounding Health Information Technology. The most commonly reported H-IT safety issues included wrong patient/wrong data, medication administration issues, clinical data loss/miscalculation, and unforeseen software design issues; all of which have varying impact on the patient’s clinical care and outcome, which included 6 death and 43 injuries. The absence of mandatory reporting enforcement of H-IT safety issues limits the number of relevant MDRs and impedes a more comprehensive understanding of the actual problems and implications.

This is especially true considering the FDA's own noted limitations of their information sources:

Limitations of the MAUDE search and final subset of MDRs include the following:

1. Not all H-IT safety issue MDRs can be captured due to limitations of reporting practices including

... (a) Vast number of H-IT systems that interface with multiple medical devices currently assigned to multiple procodes making it difficult to identify specific procodes for H-IT safety issues;
... (b) Procode assignments are also affected by the ability of the reporter/contractor to correctly identify the event as a H-IT safety issue;
... (c) Correct identification by the reporter of the suspect device brand name is challenged by difficulties discerning the actual H-IT system versus the device it supports.
2. Due to incomplete information in the MDRs, it is difficult to unduplicate similar reports, potentially resulting in a higher number of reports than actual events.
3. Reported death and injury events may only be associated with the reported device but not necessarily attributed to the device.
Memo: H-IT Safety Issues
4 Correct identification by the reporter of the manufacturer name is convoluted by the inability to discern the manufacturer of the actual H-IT system versus the device it supports.
5 The volume of MDR reporting to MAUDE may be impacted by a lack of understanding the reportability of H-IT safety issues and enforcement of such reporting.

If HIT were VIOXX or Phen-Fen, the class action lawsuits would likely be starting already.

(Note: for more on why there is a scarcity of data on HIT related adverse events, see my paper "Remediating an Unintended Consequence of Healthcare IT: A Dearth of Data on Unintended Consequences of Healthcare IT" at this Scribd link. This paper was not accepted on first draft by the medical informatics peer review process. I received anonymous review comments such as one that paradoxically stated that the paper "did not contain anything that could not be read in any big city newspaper", an odd comment indeed considering the topic. On that basis I decided not to attempt a revision but to post the paper publicly. -- SS)

One has to ask why this internal FDA report has not been made public until the Huffington Post article, nor been acted upon vigorously. The term of art is "double standard" compared to pharmaceuticals and other medical devices.

When the NEJM starts publishing unreferenced statements of absolute certainty like this from ONC Chair Blumenthal:

The widespread use of electronic health records (EHRs) in the United States is inevitable. EHRs will improve caregivers’ decisions and patients’ outcomes. Once patients experience the benefits of this technology, they will demand nothing less from their providers. Hundreds of thousands of physicians have already seen these benefits in their clinical practice.

and the HuffPo Investigative Fund quotes him as follows:

“We know that every study and every professional consensus process has concluded that electronic health systems strongly and materially improve patient safety. And we believe that in spreading electronic health records we are going to avoid many types of errors that currently plague the healthcare system,” Blumenthal said when unveiling new regulations in Washington on July 13.

... a statement easily demonstrable to be without merit, in fact, then one has to wonder where science has gone.



One also has to wonder if someone is short-circuiting the FDA's role in regulating this technology.

Could Blumenthal (in essence a family doctor), Sibelius (a trial lawyer), DeParle, or others, or the White House itself be telling FDA how to conduct its business? Are they impeding FDA's regulatory role in the irrationally exuberant multi-billion $$$ race to HIT utopia?

Finally, it is my belief that numerous health IT/medical informatics academics and talking heads who've steadfastly avoided the issue of health IT-related patient harm, or scoffed at it in legally-discoverable forums, might find themselves as defendants in upcoming plaintiff lawsuits. "Knew, or should have known" is the phrase that might apply.

As I learned from my pre-informatics Transit Authority medical management experience, juries will likely not take kindly to academic and marketing arguments akin to Scott Adam's sarcastic example of the logical fallacy of "ignoring all anecdotal evidence":

"I always get hives immediately after eating strawberries. But without a scientifically controlled experiment, it's not reliable data. So I continue to eat strawberries every day, since I can't tell if they cause hives."

The UK's NHS has not had the best of success to date implementing national health IT, as indicated by reports here and here, for example.

However, they have appeared to have learned from their mistakes and in fact are on the way to being far ahead of the U.S. in terms of understanding what it truly takes for HIT to be efficacious - and perhaps even more importantly, as safe as possible.

From an informatics colleague who informed me of these developments:

The UK has recently adopted the ISO draft standards for the development and deployment of HIT. They don't go as far as premarket approval, but do require vendors to develop and deliver to healthcare organizations a formal hazard assessment for their products, require both to continually update their risk assessments, and require care delivery organizations to have an explicit process for identifying & mitigating risks, and formally accepting (or not) the residual risks that remain. The thinking is these standards will be adopted across the EU once the ISO approval process is completed.

"Health informatics — Guidance on the management of clinical risk relating to the deployment and use of health software"Formerly ISO/TR 29322:2008(E)

DSCN18/2009

and


"Health Informatics — Application of clinical risk management to the manufacture of health software"
Formerly ISO/TS 29321:2008(E)
DSCN14/2009

From the first of these, the overall intro:

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

Then on to matters at hand:

Introduction

The threat to patient safety

There is mounting concern around the world about the substantial number of avoidable clinical incidents which have an adverse effect on patients, of which a significant proportion result in avoidable death or serious disability, see references [1], [2], [3], [4], [5] and [6]. A number of such avoidable incidents involved poor or "wrong" diagnoses or other decisions. A contributing factor is often missing or incomplete information, or simply ignorance, e.g. of clinical options in difficult circumstances or of the cross-reaction of treatments (a substantial percentage of clinical incidents are related to missing or incomplete information).

It is increasingly claimed that information systems such as decision support, protocols, guidelines and pathways could markedly reduce such adverse effects.

[As I have written in many places such as here and here, this may or may not be true regarding today's commercial healthcare IT as it is currently designed and deployed. Evidence supporting the assertion, especially robust studies such as randomized controlled clinical trials, is scarce, and evidence contradicting it is growing. The technology remains experimental - ed.]

If for no other reason – and there are others – this is leading to increasing deployment and use of increasingly complex health software systems, such as for decision support and disease management. It can also be anticipated that, due to pressures on time and to medico-legal aspects, clinicians will increasingly rely on such systems, with less questioning of their "output", as a "foreground" part of care delivery rather than as a "background" adjunct to it. Indeed, as such systems become integrated with medical care, any failure by clinicians to use standard support facilities may be criticised on legal grounds.

Increased use of such systems is not only in clinical treatment but also in areas just as important to patient safety, such as referral decision-making. Failure to make a "correct" referral, or to make one "in time", can have serious consequences.

Economic pressures are also leading to more decision support systems. The area of generic and/or economic prescribing is the most obvious, but achieving economy in the number and costs of clinical investigative tests is another.

Thus the use of health software and medical devices in increasingly integrated systems, e.g. networks, can bring substantial benefit to patients. However unless they are proven to be safe and fit for purpose they may also present potential for harm or at least deter clinical and other health delivery staff from making use of them, to the ultimate detriment of patients. Annex A provides some examples of the potential for harm.

Harm can of course result from unquestioning and/or non-professional use, although the manufacturers of health software products, and those in health organizations deploying and using such products within systems, can mitigate such circumstances through, for example, instructions for use, training and on-screen presentation techniques, guidance, warnings or instructions.

Some of these system deficiencies are insidious, may be invisible to the end user [an obviously perilous situation - ed.] and are typically out of the sole control of either the manufacturer or the deploying health organization.

The reports note the obvious, something that the health IT vendors' contractual gag clauses and secrecy in the health IT industry make difficult to rigorously evaluate:

A necessary pre-cursor for determining and implementing controls to minimize risks to patients, from a health software systems that is manufactured and then deployed and used within a health organization, is a clear understanding of the risks which the deployed system might present to patients if malfunction or an unintended event were to occur, and the likelihood of such a malfunction or event causing harm to the patient.

These risks cannot be properly evaluated in an industry where the flows of information are dominated by the vendors.

Some examples of potential for harm, from annex (appendix) A, will likely sound quite familiar to readers of Healthcare Renewal:

• Patient (mis)identification
• Inadvertent accidental prescribing of dangerous drugs (such as methotrexate)
• Incorrect patient details retrieved from radiology information system
• CT and MRI images could not be seen after being moved to PACS
• Drug mapping error
• Pre-natal screening risk computation errors
• Radiotherapy errors
• Slack security

I especially note the following in the first document (on deployment):

5.3 Competencies of personnel

Persons performing risk management tasks will need to have the knowledge, experience and competencies appropriate to the tasks assigned to them. This will need to include, where appropriate, knowledge and experience of the particular health software systems (or similar health software products) and applications, the technologies involved and risk management techniques. This should include appropriate registered clinical input throughout the process. Appropriate competency and experience records will need to be maintained.

Clinical risk management tasks can, and should, be performed by a project team that contains representatives of each of the functions that are involved in deploying and subsequently using the health software systems or system, with each contributing their specialist knowledge to build both awareness and consensus. Of particular importance will be clinical input from clinicians who are familiar with the practical realities of the environments within which the software system will be used and the clinical processes to which the software system is directed.

Emphasis on the last sentence is mine. At a time when U.S. CIOs and health IT "talking heads" still find the need to write touchy-feely "Master of the Obvious" articles extolling the virtues of permitting clinicians 'input' into health IT projects, usually under the aegis of unempowered "Directors of Informatics" or "Chief Medical Information Officers" (a.k.a. Directors of Nothing and Chiefs of Nothing, with no true executive presence or authority), the latter direct, definitive sentence is refreshing.

Miracle of miracles, even postmarketing surveillance is covered (the pharma and medical device industries have been mandated by regulators to conduct such studies on their products for decades):

11 Post-deployment monitoring

Both manufacturers and organizations deploying and using health software and other products within systems, have a business need to establish, document and maintain a process to collect and review information about the clinical safety performance of the products and system in the post-deployment phase, at least to help manage their liabilities but also to enable them to optimize their products and systems.

There is much more in these documents.

Download and read the PDF's. I will have more to say in future posts, but thank god someone is considering the risks to patients of this technology, touted as universally beneficent by health IT exceptionalists, in a serious manner.

Now if only we can import this thinking into the United States.

-- SS

In the Battle of Britain in WW2, the Royal Air Force (RAF) heroically repelled a foreign invasion of the UK.

The Supermarine Spitfire, key defense tool in the Battle of Britain. (Worked without major glitches.)

Now, the invasion is American, and the battlefield is healthcare...

I have often said health IT remains an experimental technology. However, the technology is being inexplicably force-fed with a vengeance to hospitals by IT companies and governments, force-fed with respect to the actual evidence of benefit.

In the case of the NPfIT in the UK, we have items such as those below from a 2009 government report "The National Programme for IT in the NHS: Progress since 2006 - Public Accounts Committee." Emphases in italics mine:

The termination of Fujitsu's contract has caused uncertainty among Trusts in the South and new deployments have stopped. One option being considered for new deployments is for Trusts to have a choice of either Lorenzo provided through CSC or the [Cerner, an American company - ed.] Millennium system provided through BT. There are, however, considerable problems with existing deployments of Millennium and serious concerns about the prospects for future deployments of Lorenzo. Before the new arrangements for the South are finalised, the Department should assess whether it would be wise for Trusts in the South to adopt these systems. Should either of the Local Service Providers take on additional commitments relating to the South, the Department should take particular care to assess the implications of the extra workload for the quality of services to Trusts in the Local Service Providers' existing areas of responsibility.

The Programme is not providing value for money at present because there have been few successful deployments of the [Cerner] Millennium system and none of Lorenzo in any Acute Trust. Trusts cannot be expected to take on the burden of deploying care records systems that do not work effectively. Unless the position on care records system deployments improves appreciably in the very near future (i.e. within the next six months), the Department should assess the financial case for allowing Trusts to put forward applications for central funding for alternative systems compatible with the objectives of the Programme.

In 2010 Londoners continue to be used as cannon fodder for the health IT experiment, which continues to rain IT bombs down upon them. The result?

Mayhem:

St George’s suffers Cerner teething pain
E-Health Insider
Jon Hoeksma
26 Aug 2010

St George’s Healthcare NHS Trust is facing teething problems with its installation of a Cerner Millennium hospital information system.

"Teething" problems? As if to imply problems with health IT are as minor as an infant's dental discomfort? That's some spin:

Health IT problems? Just baby issues; nothing a good cry can't solve ...

(The health IT baby must have serious endocrinological problems. Even after decades, it never seems to grow up, and is forever teething.)

The spin and excuses surrounding the health IT industry are simply nauseating, considering it's people's lives that are being screwed with.

Let's translate to everyday language: the project has been a disaster.

... The trust went live with the Millennium in March, under a new local delivery model from local service provider BT.

Five months later, the trust, which is one of the largest in London, has had to second additional senior management expertise into the project team and institute an additional programme of workflow changes and training.

The trust says the new system is creating difficulties in tracking patient notes in some areas and in managing outpatient appointments; creating backlogs of work that have required extra staff to deal with.

Health IT is touted as improving clinician-clinician communication. Allow me to translate "difficulties in tracking patient notes." In King's English (as opposed to health IT political-ese and other mumbo-jumbo), this translates to "patient notes are getting lost."

That means that health IT is obstructing patient care. I'm sure the patients didn't consent to the use of unproven technology that could get them killed.

Health IT is also the supposed cure to healthcare's financial and staffing woes:

They have also had a knock-on effect on the trust’s ability to meet and report on activity. Sources familiar with the implementation say the trust was fortunate that the coalition government dropped the national requirement to meet 18-week referral to treatment time targets in the revised NHS operating framework.

The problems are understood to mainly relate to staff finding it difficult to adjust to new processes and to using the unfamiliar Cerner system.

...“Since the programme deployed some staff have found it challenging to follow the new workflows. Therefore, where appropriate, we are simplifying processes by modifying workflows and administrative procedures.”

Translation: staff are finding it difficult to perform clinical-related work according to the capricious diktats of non-clinician health IT developers. In other words, they have difficulty being coerced to work for the computer, instead of the computer working for them.

The south London trust told E-Health Insider this week that the implementation was just the beginning of a major change programme; a project it calls iCLIP.

Only the beginning? God save the King....

“Although we successfully avoided some of the major pitfalls of other deployments, the new systems have presented some challenges to staff, particularly in relation to outpatient clinics and the tracking of case notes,” said chief operating officer Patrick Mitchell in a statement.

How major could those "major pitfalls" have been? Perhaps he means, the software actually runs and no longer crashes?

He added: “We have allocated additional temporary support while the new system and processes fully embed in these areas. A further programme of training and workflow changes are also underway as we continue to support staff and prepare for the next stages of the programme.”

"Temporary?" We'll see about that. Per the recent article "Electronic Medical Records, Nurse Staffing, and Nurse-Sensitive Patient Outcomes: Evidence from California Hospitals, 1998–2007" (Health Services Research, 9 APR 2010, DOI: 10.1111/j.1475-6773.2010.01110.x), on a longitudinal analysis of 326 short-term, general acute care hospitals in California:

... Our results suggest that advanced EMR applications may increase hospital costs and nurse staffing levels, as well as increase complications and decrease mortality for some conditions. Contrary to expectation [I'm not sure whose expectation, and on what basis - ed.], we found no support for the proposition that EMR reduced length of stay or decreased the demand for nurses.

On to the issues of skills:

Julia Crawshaw, the general manager for maternity services, has now been seconded into the project team “to lead on the work looking at optimisation of workflows, operational procedures and further training.”

Will this GM for maternity be looking at workflows in, for example, neurosurgery?

The problems now being addressed occurred despite 1,600 staff being comprehensively trained prior to go-live.

"Comprehensively?" What does that mean, exactly? The results seem to belie that assertion. Or are these systems and their user experience so ill conceived, tedious, cryptic and complex that no amount of "training" is adequate? (I believe the latter.)

However, Mitchell stressed that thanks to the hard work of staff, the new information system is delivering benefits, including “real-time reporting in the A&E department and more complete monitoring of bed occupancy.”

How many millions of pounds and person-years were spent to achieve these startling results, I wonder?

Mitchell said: “Reporting in real-time requires that staff report more promptly and accurately so additional training needs are also being identified to help individual staff become more comfortable with the system.”

Perhaps the system - and its designers - should be "trained" to be more comfortable with the users?

A spokesperson for BT told EHI: “Obviously these are operational issues the trust is dealing with. It is not for BT to comment. But you would expect that on a major deployment programme of this scale there would be issues.”

This is a classic appeal to common practice. Such "issues" might be tolerable for inventory systems of widgets (perhaps Cadbury Schweppes products?), but no, in mission critical areas I would not "expect" problems such as lost clinical notes.

In the most recent trust newsletter, the chief executive said: “I do fully appreciate that iCLIP has been far from smooth sailing. However, all major projects have their ups and downs and I know that many colleagues are focused on the long-term success of this important project.”

More spin and appeal to common practice.

This voyage was smooth sailing, until a little glitch was encountered...

"Far from smooth sailing?" Why does the HMS Titanic come to mind?

... The next trust due to go live with Millennium in London is meant to be Imperial, scheduled to take the system in 2011, under Cerner’s Method M delivery model.

"Method M delivery model"? How many "models" does it take to implement information systems in mission critical healthcare environments?

In summary, the NPfIT, already by the government's admission a multi-billion pound debacle, continues to drag on. Patients and hospital workers are the fodder for this experiment, spearheaded this time by an American invasion.

The Blitz is on.

Unfortunately, this time there's no RAF in sight to repel the foreign invasion.

The upside down world of commercial health IT. Is healthcare in St. George's Trust being incernerated?

In an article simply entitled "Danger", Health Data Management author Elizabeth Gardner spells out some "inconvenient truths" about health IT.

Many of the contributors have opined on the risks associated with health IT; several are newly contrite about this issue:

Danger
By Elizabeth Gardner
Health Data Management Magazine, 08/01/2010

Even to Ross Koppel, electronic health records are better than paper ones, "or cuneiform tablets, smoke signals, or carrier pigeons," he adds. He prefers to use hospitals and doctors that have EHRs.

But the University of Pennsylvania sociologist specializes in analyzing interactions between medical computer systems and the people who use them, and he's found enough problems to turn him into an industry gadfly on the potential dangers of EHRs.

"A resident will get an alert at 50 [milligrams of a certain drug] at one hospital, 60 at a second hospital, and no alert at a third hospital because they turned it off," Koppel says. "So he thinks the 70 milligrams he's ordered there are safe. The residents don't know whether the alerts are on or off. They're not familiar with many medications and they start a new rotation every thirty days. They use these alerts as safety bumpers and that's not safe."

... Koppel has found plenty of other glitches, from outright programming errors to user interfaces that make life difficult for clinicians. Numerical values appear in an order that makes sense to the computer but looks random to a human; positive test results aren't always flagged for review; weights aren't consistently labeled as pounds or kilograms (which can lead to babies, for example, being given twice, or half, the medication they need).

"Everyone focuses on why physicians are resistant to computers, but I would rather focus on how difficult the systems are to use," Koppel says. "Most physicians are the smartest guys in the room. Their resistance to technology as such is zero, but they resist software that has a clunky structure."

Dr. Koppel, a sociologist, is a well recognized name in health IT critical thinking circles. He will not win any favors from the health IT vendors and CIO's for that comment about physicians and smartness, but he is quite correct. Physicians are not Luddites. They readily adapt new technology proven as good for patients.

In fact, in my observations IT personnel are the true Luddites, clinging to inappropriate, rigid business-IT views on the healthcare IT development and implementation process (vs. more appropriate and modern agile methodologies), holding unshakable, stereotypical views about physicians, and remaining unreasonably obstinate on clinician complaints about "clunky" health IT user experiences.

Every year the ECRI Institute, Plymouth Meeting, Pa., a not-for-profit organization that evaluates health technology, issues a top 10 list of technology hazards in medical care. "Problems with computerized equipment and systems" ranked seventh this year, right behind "needlesticks and other sharps injuries" and ahead of "surgical stapler hazards." Most of the incidents reported to ECRI by its 5,000 members (hospitals, health systems, payers, and other interested parties) were due to convergence of computers and medical devices in areas like medication management and the routing of device alarms to clinicians' cell phones and pagers. (ECRI Institute points out that such problems are "most certainly underreported.")

Under-reporting of health IT hazards is a familiar theme to this author, as in a 2009 paper entitled "Remediating an Unintended Consequence of Healthcare IT: A Dearth of Data on Unintended Consequences of Healthcare IT" that was not published due to first-round reviews. Some of those reviews were legitimate and constructive regarding revision, but others appeared to suggest the topic was verboten (for example, "nothing is in this paper that could not be read in any big city newspaper", rather the oxymoron considering the paper's topic). I did not bother with a revision, simply making the paper public and bypassing the peer review censorship I saw coming.

But EHRs can easily cause errors, too. Plenty of experts believe that too many systems are being installed too fast into environments too complex to be easily computerized. In the frenzy to be eligible for federal EHR meaningful use incentive payments, and avoid reimbursement penalties starting in 2015, institutions may be setting themselves up for disastrous computer-induced medical errors.

The theme of "too fast" has been present in my writings for awhile now; see for example my 2008 posts "Should The U.S. Call A Moratorium On Ambitious National Electronic Health Records Plans?" and "Open Letter to President Barack Obama on Healthcare Information Technology".

"I'm one of the biggest believers [in EHRs], but there's tremendous pressure to implement these systems so fast," says medical informaticist Dean Sittig, associate professor at the University of Texas Health Science Center at Houston and a leading researcher on successes and failures of EHR implementations. "It worries me that people won't have adequate time to come to grips with what they're doing and test their systems properly."

Dr. Sittig did write some excellent, pioneering articles on the indispensibility of the CMIO role ("information architect" - PDF) back in the mid-1990's that I use in my teaching. However, a few years ago he told a former student of mine (he was unaware of that relationship) who listed me as a reference on her CV to not do so, as I was not a "real medical informaticist" or words to that effect. Seems at the time he may have taken issue with my realist views on the problems with health IT.

The medical environment is more complex than other fields like aircraft navigation, which is already hard enough to computerize, notes Nancy Leveson, professor of aeronautics and astronautics at the Massachusetts Institute of Technology. She's a pioneer in software safety ... "We're talking about a professional environment of doctors, and changing the way they do business," Leveson says. "Most other kinds of automation aren't doing that.

This issue is critical and at the root of health IT dysfunction. No other profession is being asked to use IT in the manner in which clinicians have been asked. No other profession may have an information model as complex that they're asked to record in painstaking, granular detail, either.

Because software engineers aren't taught about usability and the impact of their systems on the world, they think they'll just automate it the way they want and make people do it their way. There's a lot of stuff out there [in health care] that's very difficult to use. The industry is naive about introducing software and the change it requires and the potential hazards it introduces, and they think it's going to be all right."

I would replace the word "naive" with "willfully ignorant, complacent and negligent." There are simply no acceptable excuses for a field that has been in existence for decades to be as toddlers on the impact of their work.

... Clinicians who already have extensive experience with EHRs are under no illusions that everything works smoothly. "It's inevitable that some new errors will be introduced [with EHRs]," says David Bates, M.D., chief of general medicine at Brigham and Women's Hospital, Boston, a patient safety expert, and a member of the information technology executive committee of Partners HealthCare, Brigham's parent.

Considering the ice-cold reception by most of those clinician experts (e.g., in the medical informatics community) to my writings on HIT problems that began in 1999 and now reside at my Drexel site here, and to the similar writings of others, I disagree with Bates' assessment. I think the experts have now painted themselves into a corner and have been forced by reality and their own willful blindness into admitting the truth about this experimental technology. (A PubMed search on "Bates DW" is not generally revealing of papers on health IT risks until relatively recently.)

"The key thing is to devote enough resources and attention to fixing them [errors] after they happen. Your EHR may prevent 10 errors for every new one it causes [not sure where these figures come from or if they're generalizable at all - ed.], but you have to have an approach for dealing with the new ones."

Again, I would differ. The key thing is to prevent them from happening as much as possible. The pharma and medical device industries do this through RCT's, post market studies, and strong regulatory requirements for their products' manufacture and use.

Bates is not an advocate of regulation of health IT. As in my post "JAMA letter: Health Care Information Technology, Hospital Responsibilities, and Joint Commission Standards", in 2009 Bates signed on to an unpublished letter to JAMA (archived here) in response to Koppel and Kreda's article on "hold harmless" clauses that stated "... the belief that the best approach to increase the safety and effectiveness of EHR systems is by legal regulation of system vendors is misplaced." (Incidentally, the letter that JAMA did publish was mine.)

... Partners has been developing its own in-house EHR for several decades, and still encounters things that need fixing. For example, when physician order entry was introduced, the system made it possible to order fatally large doses of intravenous potassium, because the initial order choices hadn't been properly vetted by the internal team responsible. The nurses who executed the orders knew enough to catch the error before it harmed a patient, but Bates says it took a year and a half to get the screen corrected in the order entry system.

I can add that taking a year and a half to correct a potential fatality-causing screen in a home-built clinical IT application is not just a technological issue, but also an organizational, political and leadership issue.

... "Emergency care is by definition nonlinear and unpredictable, and information technology tends to enforce a certain amount of linearity: you can't do step 5 until you've done steps 1 through 4," says Wears. Emergency room personnel often care for multiple patients simultaneously and have to do things "out of order" so they can be more efficient. If an EHR enforces a linear pattern, it will just get in their way, and they'll compensate by running a parallel system on paper and putting information into the EHR later. "That subverts one of the fundamental things you wanted the system to do-give you real-time feedback on good and bad ideas," Wears says.

The realities of the ED cannot be neatly dealt with as if a calm, solitary office environment .

There's plenty of blame to go around. Koppel and Leveson say software design, or lack of it, is a common culprit, and they take vendors to task for not focusing on usability.

Again, there is no reasonable excuse for IT intractability in a mission critical sector.

Leveson says part of the problem is a lack of regulatory standards. "The FDA doesn't want to oversee anything and that's a mistake," she says. "So it's become this free-for-all in the industry."

I've used that same language. In my 2009 post E-Health Hazards: Provider Liability and Electronic Health Record Systems I wrote "the unregulated free-for-all that has been the health IT marketplace, with dangerous and even outrageous practices I noted starting a decade ago, must come to an end as the market matures and as diffusion of this technology massively increases per the government mandates now in effect."

Though experts say EHRs clearly fall under the category of medical devices, the FDA has steered clear of directly regulating them. Its ill-starred policy of requiring pre-market approval for blood-bank software, begun back in the 1990s, resulted in major vendors pulling out of the market altogether and stifling innovation ... "That kind of regulation provides a huge economic disincentive and there hasn't been any substantial improvement in blood bank software in 10 years," says Geisinger's Walker. "If the FDA required it for EHRs, it would harm patients more than help."

I disagree with Walker and especially disagree with the latter statement, based on one anecdotal case of IT regulation (ironically, it's HIT proponents who most often claim that 'anecdotes' of patient harm don't make data).

Further, the FDA was called in initially because of IT dangers in existing blood banking software. Also, the "innovation" referred to could more accurately be referred to as "lifecycle adaptation and enhancement", not true innovation. In other words, there was not enough profit to be made in maintaining mature software under regulation. The effect might be to push the quick-buck profiteers out of the industry, and thus improve quality and innovation.

The Swedish Medical Products Agency is leading the way for consideration of HIT in the EU as a medical device to be regulated as in my post "Improving Patient Safety In The EU: HIT Should Be Classified As Medical Devices". Yet, that didn't seem to impact Swedish innovation; in the UK, Wrightington, Wigan and Leigh NHS Foundation Trust has recently awarded its hospital information system contract to Swedish healthcare systems provider, Cambio (link).

Albeit in another anecdote, FDA's regulation did not harm pharma IT as far as I could tell, while a Group Director in Merck Research Labs' Research Information Systems Division.

Truth is, there is no good data one way or the other regarding regulation, but after thirty or more years of an unfettered HIT industry, I believe it reasonable to say that the presence of harmful HIT speaks more for regulation than for a continued industry "free-for-all."

The Agency for Healthcare Research and Quality is currently working with the FDA, VA and other federal agencies to develop a common format for reporting I.T.-related patient safety events and unsafe conditions.

"What took so long" is my question.

Read the whole article. The myth of health IT beneficence continues to be eroded. One can only hope the tens of billions earmarked for the technology in the recent economic "recovery" legislation will become similarly eroded in years to come, to allow the technology to be safely improved - that is, in vitro, not in vivo.

In my July 2010 post "Meaningful Use Final Rule" I pointed out the cart-before-the-horse problem of creating "meaningful use" rules for health IT before usability issues were resolved:

From the HIMSS EHR Usability Task Force, June 2009:

Electronic medical record (EMR) adoption rates have been slower than expected in the United States, especially in comparison to other industry sectors and other developed countries. A key reason, aside from initial costs and lost productivity during EMR implementation, is lack of efficiency and usability of EMRs currently available. Achieving the healthcare reform goals of broad EMR adoption and “meaningful use” will require that efficiency and usability be effectively addressed at a fundamental level.

These "usability" problems require long term solutions. There are no quick fix, plug and play solutions. Years of research are needed, and years of system migrations as well for existing installations.

Yet we now have an HHS Final Rule on "meaningful use" regarding experimental, unregulated medical devices the industry itself admits have major usability problems, along with a growing body of literature on the risks entailed.

For crying out loud, talk about putting the cart before the horse...

Something's very wrong here...

Here we go again.

"Ready ... fire ... aim" seems the postmodern approach to healthcare IT:

Institute to study HIT patient safety for ONC
Mary Mosquera

Government Health IT, Thursday, September 30, 2010

The Institute of Medicine (IOM) announced it will conduct a year-long study for the Office of the National Coordinator for Health IT to identify best policies and practices for improving healthcare safety when using electronic health records.

The IOM, an arm of the National Academy of Sciences, will examine prevention of health IT-related errors, rapid reporting of patient safety concerns [To whom? The vendor, as now, so they can sit on the problems until it suits them to fix it? In the face of contractual gag clauses, I'm not sure where else such reports can go - ed.] and methods to promote safety-enhancing features of electronic health records (EHRs), said Dr. David Blumenthal, the national health IT coordinator.

The IOM will also make recommendations about the potential effects of government policies and private sector efforts to make the most of patient safety and avoid medical errors through health IT.

[In reading the hype right up to the ONC Director Blumenthal and the POTUS, one would get the impression that medical error-prevention was an inherent, deterministic characteristic of this 100% beneficent technology, so much so that simply putting it in will revolutionize medicine. Now, we all of a sudden need to study its safety? - ed].

... “This study will draw on IOM’s depth of knowledge in this area to help all of us ensure that HIT reaches the goals we are seeking for patient safety improvement,” Blumenthal said.

Earlier this year, the Health IT Policy Committee, a federal advisory group, conducted hearings about patient safety and EHRs. It recommended creating a national database to which healthcare providers can report patient data errors and unsafe conditions they encounter using EHRs.

[To reiterate, there is a major problem with this proposal: "providers" cannot do this with contractual gag clauses in effect. It also seems such databases belong at the state level, since the control of medicine traditionally resides in the states, but these days the Federal government seems to know no bounds - ed.]

The committee also urged the establishment of a patient safety organization to analyze the reports and share information from the database to make healthcare a learning system.

So, in the midst of a National Program for Health IT in the United States (NPfIT in the U.S.), with tens of billions of dollars earmarked for health IT already (money we don't really have, but it can be printed quickly, or borrowed from China) the IOM is going to study health IT safety, prevention of health IT-related errors, etc. ... only now?

Perhaps these studies should have been initiated, say, ten years ago, or at least before the beneficence of health IT and its capacity to revolutionize medicine was openly promoted by the past and current Administrations (the current one going so far as to institutionalize penalties for non adopters)?

A move like this suggests someone's blown the whistle on the purveyors of the NPfIT in the U.S. They are now attempting to cover their tracks regarding this glaring deficiency (unknown risk) in an already-initiated, extremely expensive national program based on equivocal studies and literature, an increasing amount of which is now refuting the grandiose claims made about health IT. The purveyors would seem to have a figurative gun at their heads causing them to ask the IOM for assistance at this rather late date in the scheme of things (could that gun be named Grassley?)

A tidbit of common sense regarding IT, all too lacking in today's national leadership:

• You should not need year-long IOM studies to study the safety of supposedly safe devices already slated for national rollout.

Finally, the sudden interest in health IT safety suggests the HITECH act on health IT with its timelines and penalties, smuggled in under the auspices of the ARRA, is premature and should be repealed - or its timelines delayed until this technology is truly understood.

-- SS

10/2/10 addendum:

I recall that we already have the 2009 National Research Council HIT study. It reported that HIT in its present form does not support physician cognitive needs and that our approaches to HIT are "insufficient" to achieve stated goals...

The U.S. National Research Council’s "Current Approaches to U.S. Health Care Information Technology are Insufficient" is here. A full report on an investigation of healthcare IT lack of progress is here (PDF).

From the NRC/NAS/IOM sites:

"The National Research Council (NRC) functions under the auspices of the National Academy of Sciences (NAS), the National Academy of Engineering (NAE), and the Institute of Medicine (IOM)." ... "The IOM is the health arm of the NAS."

The National Research Council report on HIT was basically buried. HITECH happened anyway.

ONC seems to now be going back to the same source(s), presumably for either a glowing report, or a report that it can safely ignore.

Finally:

That HIT effectiveness issues, safety issues, admittedly poor usability but "meaningful use" criteria crafted anyway, lack of clinician cognitive support requiring years of multidisciplinary research to correct, etc. - have had no inhibitory effect on grandiose, autocratic and highly expensive plans for national HIT also suggest political agendas far beyond "improving patient care.