KevinMD: How algorithm driven medicine can affect (make more dangerous, actually) patient care

Reposted from KevinMD blog on another aspect of the health IT mission hostile user experience. Emphases and comments in [red italics] are mine:

How algorithm driven medicine can affect patient care
by Jeffrey Parks, MD

Whenever someone is scheduled for an operation, the assigned nurse is required to fill out a “pre-op checklist” to ensure that all safety and quality metrics are being adhered to. Before the patient is allowed to be wheeled into the OR we make sure the surgical site is marked, the consents are signed, all necessary equipment is available, etc. One of the most important metrics involves the peri-operative administration of IV antibiotics. SCIP guidelines mandate that the prophylactic antibiotic is given within an hour of incision time to optimize outcomes. This has been drilled into the heads of physicians, health care providers, and ancillary staff to such an extent that it occasionally causes total brain shutdown.

Let me explain. For most elective surgeries I give a single dose of antibiotics just before I cut. For elective colon surgery, the antibiotics are continued for 24 hours post-op. This is accepted standard of care. You don’t want to give antibiotics inappropriately or continue them indefinitely.

But what about a patient with gangrenous cholecystitis or acute appendicitis? What if, in my clinical judgment, I want to start the patient on antibiotics right away (i.e. several hours before anticipated incision time) and then continue them for greater than 24 hours post-op, depending on what the clinical status warrants? I should be able to do that right? [No - wrong - the idiots who designed your CPOE/Pharmacy IT system forgot that robotic medicine is bad medicine - ed.]

Well, you’d be surprised. [No, actually, I'm not. I'd have been more surprised to see a system not impeding critical medical decisions tailored to the individual patient - ed.]

You see, at two different, unaffiliated hospitals I cover, the surgeons have seen that decision-making capability removed from their power. If a young patient comes in with acute appendicitis and I feel that it would be prudent to continue the Zosyn an extra couple of days, an automatic stop order is triggered [presumably cybernetically - ed.] in the department of pharmacy and the antibiotic is stopped after 24 hours, no matter what. Unless the surgeon specifically writes “please do not stop this antibiotic after 24 hours; it is being administered for therapeutic purposes, not prophylaxis [that sounds a bit like begging - ed.] ,” the antibiotic will not be sent to the patient’s floor for administration. As a result, patients end up being treated sub-optimally, and potentially harmed, due to an over-emphasis on “protocol” and “quality care metrics.”

Similarly, the 60-minute timeline for pre-operative antibiotic administration can be problematic. I have had patients come into the ER with appendicitis or cholecystitis and, in my pre-op orders, write for Zosyn or whatever, to be started ASAP, no matter what time the operation is scheduled. Not too long ago, I admitted a gallbladder over the phone at 2am. I gave the nurse admitting orders which included one for a broad spectrum antibiotic.

When I saw the patient in the morning, I added her on to the OR schedule. By the time a room opened up, it was about 10:30am. The OR nurse asked me if I wanted to give an antibiotic for the case. I told her that the patient was already on antibiotics as part of her admit orders for treatment. The nurse shook her hand. It had never been given; the floor nurse held it so that it wasn’t administered until 60 minutes before the scheduled OR time, just like the algorithm dictates — despite the fact it had been ordered nearly 8 hours prior to the case, not for peri-op prophylaxis, but for treatment of an established pathology. [This is how EHR-induced malpractice occurs, readers. Guess who bears liability? - ed.]

And there it was, the cefotetan, hanging on her IV stand. Now nothing bad happened [this time, due to luck - ed.], but here you have a situation where health care providers are so terrified of violating Quality Assurance Protocol that they end up withholding necessary treatment. It’s just astounding. [It's astounding the surgeons don't simply use a scalpel on the computer terminal network and power cables to protect their patients - ed.]

As surgeons, we have bitched and moaned. You would think that these issues would be quickly rectified. But no. It is the responsibility of the surgeon to write qualifying statements [a workaround to a 'feature' that turns medical judgment on its head - ed.] for therapeutic antibiotics because the default mode is to override a licensed physician’s clinical judgment. [Not mentioned is who is overriding that judgment through cybernetic proxy - ed.]

This is what I’m talking about when I say that blind allegiance to a top-down, systems analysis-driven algorithm can turn everyone involved in health care into a bunch of mindless drones.

Jeffrey Parks is a general surgeon who blogs at Buckeye Surgeon.

I will simply add that these issues sound like poor IT/protocol design and implementation, getting in a physician's way regarding tailoring of care to the individual patient.

An inviolable rule in health IT is - or needs to be -

"You should not have to work around something that is not in the way."

There is nothing to debate or discuss on this issue.

-- SS

Feb. 3, 2012 addendum:

Some IT person (anonymously, of course) tried to argue and debate anyway; however, they did not even do basic homework. See their comments in the comments box.

Feb. 5, 2012 addendum:

More in the comments section by someone saying they made the aforementioned comments, stating they are a hospitalist, and still trying to advance the same arguments in favor of physicians adapting to mission-hostile HIT and/or protocols rather than 'protesting too much.'

BUY IT NOW!

EHR Workstation Designed by Amateurs

Below is an actual workstation, in an ICU of a major regional hospital, to permit interaction with an already mission-hostile EHR system:

How many things are wrong here? (Click to enlarge)

I can charitably say this workstation, in this recent picture, was designed by amateurs. Less charitably, I would use the words 'glaring incompetents.'

How many things are wrong here? For starters (commenters are welcome to suggest additions to the list):

• Small square (4x3) monitor, when large 16x9 monitors are available quite cheaply, even at retail let alone in bulk;

• Monitor in front of window so on sunny days, glare causes eye strain;

• Monitor forces user to look away from the patient, with their back facing the patient behind them;

• Standard keyboard and mouse to help spread infection, not medical-specialty devices such as membrane-based or membrane-covered keyboards and easily cleanable trackpads;

• Very slow, small, toy-ish nettop computer, to facilitate responsiveness delays;

• Height of ledge with keyboard/mouse and of elevated monitor on ledge does not facilitate comfortable ergonomics when sitting, note chair in background (or standing as is intended, either, although I don't recall ever making entries in the permanent paper chart on my feet). It seems nobody ever heard of an appropriate moveable workstation desk;

• Tangle of wires behind setup, without any protective sheath or shield, facilitates "accidents."

There are probably a few more "issues" I'm missing.

There is nothing to argue here and nothing to debate. Combined with the mission hostile virtual user interfaces presented by health IT software itself, this is inexcusable.

Apart from designers, any physicians (and nurses) who would accept such poor choices - and the cause of this workstation's problems were, in fact, deliberate choices - are either weak-kneed victims of "physician's learned helplessness" themselves, or enjoy EHR-induced medical errors and lawsuits.

The workstations are poorly designed like this all throughout this hospital, including the ED.

This is not the first time I've observed this type of amateurism in hospitals. I observed similar issues in another ICU - over a decade ago.

Hospitals are truly an IT backwater.

-- SS

BUY IT NOW!

NIST on the EHR Mission Hostile User Experience: Blame the User? Nyet...

I have often had to respond to those who claim that EHR's don't cause medical errors, users do. That subset of the health IT irrationally exuberant seem common in the health IT industry and pundit channels.

NIST (The U.S. National Institute of Standards and Technology) has recently issued a draft report "NISTIR 7804: Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records." It is available at http://www.nist.gov/healthcare/usability/upload/Draft_EUP_09_28_11.pdf (PDF).

The report is quite negative concerning the low usability of today's commercial health IT, and recommends significant improvements that have been standard practice in other mission- and life-critical IT sectors for decades.

I will have more to write about this report, but I found a passage and footnote early in the report striking.

Of note, from the new NIST draft report:

This passage, from page 10:

The EUP (EHR usability protocol) emphasis should be on ensuring that necessary and sufficient usability validation and remediation has been conducted so that use error [3] is minimized.

[3] “Use error” is a term used very specifically to refer to user interface designs that will engender users to make errors of commission or omission. It is true that users do make errors, but many errors are due not to user error per se but due to designs that are flawed, e.g., poorly written messaging [or lack of messaging, e.g., no warnings of potentially dangerous actions - ed.], misuse of color-coding conventions, omission of information, etc.

This passage describes what I have termed a mission hostile user experience.

"Blame the user" as the default, reflex reply to clinical IT-related medical errors, and the "hold vendor harmless for defects" clauses that facilitate this excuse are now heading to the junkpile - in the clinic, hospital, and courtroom.

It is my hope that the the Wild West, free-for-all, cavalier, get out of jail free days of the health IT industry are coming to a close.

Hint to health IT industry: you may actually need to invest in people who know what they're doing, instead of hiring the cheapest labor possible. (See, for example, my Aug. 2010 post
"EPIC's outrageous recommendations on healthcare IT project staffing" for more on that issue.)

-- SS

Oct. 25, 2011 Addendum:

This comment (#5, October 25th, 2011 at 12:38 pm) by "a practicing front-end designer and application developer" over at HIStalk is quite interesting. The writer points out the differences between designers and developers, and opines that:

If you’re going to improve vendor design, it has to begin with an internal commitment to value designers and what they contribute to the product development process. They can not be an afterthought. There are very few companies with this mindset. Almost all HIT companies are developer-driven, so the first thought, and one that is promoted in this report, is to turn developers into designers. This will not work! A developer and a designer require two fundamentally different skill sets that are not easily transposed. Developers are trained to think rationally and analytically; design requires empathy for the user.

In health IT, empathy for the patient as well, I might add.

-- SS

BUY IT NOW!

Australia and Health IT: Will Government Officials Ever Learn?

Perhaps New Zealand professor Shaun Goldfinch's article "Pessimism, Computer Failure, and Information Systems Development in the Public Sector" should be required reading in their neighboring continent due northwest:

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

Here's what's about to "go down" (no pun intended) Down Under, this time in the Australian state of Queensland:

Queensland Health eyes software system despite red flags
Koren Helbig
From: The Courier-Mail
September 21, 2011 12:00AM

QUEENSLAND Health is poised to sign a multimillion-dollar contract for computer software similar to that labelled "defective" by an IT expert who audited its use in southern hospitals.

University of Sydney's Professor Jon Patrick said electronic medical records systems built by Cerner Corporation for the NSW Government crashed frequently and risked patient safety.

A similar Cerner system installed by the Victorian health department also has been plagued by glitches and is five years behind schedule.

Dr. Jon Patrick's detailed forensic analysis of a Cerner ED system is at this link and has been a subject of numerous posts on this blog.

"I don't think there's any reason for optimism that they can be improved," Prof Patrick said.

Leaked internal documents have surfaced detailing problems already looming within Queensland, as bureaucrats negotiate with US-based Cerner to build a $243 million electronic medical records system in Queensland hospitals.

Technical information for the proposed Cerner system and existing IT platforms that it must work with was "often incomplete, not-comprehensive, inaccurate and out-of-date", a leaked position paper found.

Another email addressed to chief information officer Ray Brown, released to the State Opposition under Right to Information laws, warned of the increasing need to document potential risks "even if we can't find the resources to remove them" in case of disaster and patient death.

I guess dead patients can't complain about that, unless provided with underground megaphones.

"The no-surprises rule may be applicable and would help in a Coroner's Court," the clinical adviser wrote.

But, in a written statement, Mr Brown last night backed Cerner, which he said had successfully operated systems at the Royal Brisbane and Women's and Princess Alexandra hospitals for more than a decade.

A few anecdotes of success, let's ignore those pesky anecdotes of problems, and - WHAM! - let's spend billions and roll this out statewide/nationwide.

The problem with this (il)logic was well-explained by another physician Down Under who chooses to remain anonymous. See my August 2011 post "From a Senior Clinician Down Under: Anecdotes and Medicine, We are Actually Talking About Two Different Things" at this link. Read it carefully....

Mr Brown said Queensland had learnt from interstate problems and would implement an "end-to-end solution", rather than trying to marry different systems across hospitals.

Independent experts had verified the rollout and more than 4000 staff had been consulted, indicating their support for Cerner software, he said.

The debate came after The Courier-Mail yesterday detailed Opposition claims that Queensland Health bureaucrats deliberately changed an independent report to favour Cerner when hunting for software suppliers in 2009, which QH vehemently denied.

Prof Patrick, chair of Language Technology at the university's School of IT, said problems with Cerner's NSW and Victorian systems were well documented in 2009.

He said Queensland bureaucrats likely knew of the faults, which should have served as "red flags".

Cerner did not respond to a call for comment.

May I suggest that "red flags" often get ignored when the color green is present, at least in the U.S. (I don't know the colors of Australian currency.)

Who cares about "Red flags" when you can have wads of these?

-- SS

Addendum:

Dr. Patrick notes this at his aforementioned university page:

3.13 Statement on 22nd August 2011. I attended the HIC conference in Brisbane in the beginning of August and at a dinner hosted by IBM on the 2nd August I met Mr Greg Wells, the CIO of HSS, and the person responsible for the FirstNet roll out in NSW. He stated that Cerner had provided new software that would solve all of the User Interface problems and it was being rolled at the present time in the Northern Area Health Service region. He said all installations across the state would have this solution by Christmas this year. We shall watch with interest.

I guess solving problems like these simply takes a lot of pizzas and Coca-Cola.

-- SS

BUY IT NOW!

EHR ED's in New South Wales. Will the Problems Magically "Disappear?"

It occurs that one could look at Prof. Jon Patrick's recent health IT forensic analysis as a kind of "indictment" of the industry.

He can be seen as suggesting the industry needs to be "put on trial" (figuratively) regarding "crimes" (again, figuratively speaking) they've committed with regard to IT robustness and reliability. The latter translate directly to patient safety.

In a lawsuit such as a medical malpractice trial, obvious as well as potential evidence is put under "legal hold." For instance, if an EHR defect is suspected, metadata, audit trails, and patient data are asked (or should be asked) to be frozen or archived in the state they were in at the time of the alleged accident.

It can take a page or three (or more) of specifications simply to define what information, exactly, needs to be put on legal hold. My former staff were frequently required to place myriad materials on legal hold at Merck Research Labs, for example, baed on the lawsuit du jour.

Once frozen, discovery and forensic analysis of these now-static data can then proceed. In fact, cases can be lost on the basis of evidence of an archiving omissions, destruction or tampering when information holds are requested.

It occurs to me that Prof. Patrick has given the industry a detailed look into factors they could start to remediate, without publicity and without telling anyone. While this would be a net plus for patients, it might result in less of a learning experience to the industy than that industry needs, to motivate the industry to avoid future product engineering and quality issues and put quality (not simply margin) as priority #1.

I therefore would believe a "hold" put on the present state of these ED EMR systems, or a "snapshot" of their current state (i.e., an evaluation environment mirrored from the present operational one) would allow a careful evaluation of the impact of the issues noted in the study.

Such an evaluation would be far more difficult with a cybernetic moving target.

The "snapshot" idea would allow evaluation of system risk levels, intermittent "glitches", interference with workflows, etc. in a controlled testing environment, using mock data or data drawn from actual cases.

The "snapshot" approach would also allow incremental remediation of the "live" system that comes out of safe, controlled testing, rather than sticking with what exists now until the studies could be completed on the as-is system, and then applying all the fixes as one or more large "upgrades."

I, for one, would be interested in studying this "built by software professionals" system and comparing it to health IT systems we "academic nerds" were authoring, say, 10-15 years ago.

-- SS

BUY IT NOW!

On an EMR Forensic Evaluation by Professor Jon Patrick from Down Under: More Thoughts.

Note: the reports to which this post refers are available as a set of PDF's from the University of Sydney, NSW, Australia at this link (12 Mb, .zip folder), or at "A study of an Enterprise Health information System" at http://sydney.edu.au/engineering/it/~hitru/index.php?option=com_content&task=view&id=91&Itemid=146.

March 6, 2011 addendum. Also see my new post "What to do about the state of the ED EHR in NSW?"

Over ten years ago now, 1999 in fact, I started my healthcare IT difficulties website.

That site, "Contemporary Issues in Medical Informatics: Common Examples of Healthcare Information Technology Difficulties" now resides on a Drexel University server in Philadelphia, Pennsylvania USA at this link, and used as a teaching resource.

I started the site after observing, for lack of a better description, "crazy stuff" in the commercial healthcare information technology sector.

Crazy stuff such as EMR systems for ICU's that crashed regularly and spread pathogens around, EMR's for invasive cardiology cath labs that were an informational jumble and abyss and that also issued regular General Protection Faults and died, lack of Medical Informatics expertise (and actual disdain for it) in healthcare IT projects, grossly incompetent IT leaders, and hospitals uncritically and enthusiastically buying these products as if they were a plug and play, proven technology.

To make matters worse, I also observed executives expressing a hostile indifference to glaring deficiencies.

My observations about health IT and about responses to my counsel brought to mind the biblical passage:

"Give not that which is holy unto the dogs, neither cast ye your pearls before swine, lest they trample them under their feet, and turn again and rend you." - Matthew 7:6

I was never afforded the opportunity to perform a forensic analysis of the internals of these systems, being that I was not allowed to obtain the software or "schematics" of the data structures. In fact, to make the cardiology system usable, I ordered the IT staff to simply discard the internal data dictionary, relational data structures, input screens, and analytic routines, and rebuild them - from scratch - using a proper Medical Informatics-based, cardiology domain expert-driven, iterative and incremental (agile) approach.

The result was a resounding success, and was described in a written report as "exceptional" by national specialty association reviewers invited to evaluate the effort.

(A success for which, I might add, I and my enlightened executive sponsor were paradoxically demonized by the IT department and hospital executives; cf. Matthew 7:6.)

Now, an Australian researcher of considerable computer and database expertise, Professor Jon Patrick at the University of Sydney, has put considerable ink to a forensic evaluation of the internals and external reactions to an EMR system "built in America", Cerner Firstnet.

Professor Patrick holds a Ph.D. from Monash University. He came to the University of Sydney from Massey University, New Zealand, where he held the foundation Chair of Information Systems. Professor Patrick won Australia's national Eureka science prize in 2005 for developing a natural language processing system that detected financial scams in web pages at the behest of the Australian Government.

FirstNet is an ED EHR that government officials decided must be installed in ED's of public hospitals throughout the Australian state of New South Wales. Promo material below, click to enlarge:

FirstNet promo material, page 1. Click to enlarge. (Hmm ... Is there a subliminal message in the picture of the doctor and nurse?)

FirstNet Promo material, page 2. Click to enlarge.

The initiative's been underway for several years, and the result is a group of apparently very unhappy Wal-Mart shoppers. (I guess the correct line would be "unhappy Big W shoppers" for those Down Under.)

Prof. Patrick had written a preliminary essay on the issue entitled, in rhetorical question-style, "The Story of the Deployment of an ED Clinical Information System: Systemic Failure or Bad Luck?" back in 2009. He apparently found himself in considerable hot water for doing so due to 'pushback' as I described at "Academic Freedom and ED EHR's Down Under: An Update". However, his university stood by him in defense of academic freedom (and of the sanctity of those in the healing arts, I might add).

He's spent the intervening time expanding the analysis of the ED clinical system and its deployment considerably, right down to the fine nuances of relational database design in complex domains (such as biomedicine).

As I wrote in an initial post "A Study of an Enterprise Health information System - Finally, an Informatics Scientist Does A Rigorous Review of a Commercial EHR System, by Cerner", the TOC of his new analysis are these (the files are available as a .zip archive at this link):

3.0 Part 0 - Executive Summary
3.1 Part 1 - A Critical Essay on the Deployment of an ED Clinical Information System ‐ Systemic Failure or Bad Luck? First published here in Oct 2009, revised Dec 2009.
3.2 Part 2 - Discussions with ED Directors: Are we on the right track?
3.3 Part 3 - Discussions with Software Performance Experts.
3.4 Part 4 - Conceptual Data Modelling.
3.5 Part 5 - Database Relational Schema and Data Tables.
3.6 Part 6 - Coalescing the Analyses of the ER Diagrams, Relational Schemata and Data Tables.
3.7 Part 7 - The Integrated Assessment.
3.8 Part 8 - Future HIT Regulation Proposals.
3.9 Part 9 - Ockham's Razor of Design. Published at the IHI conference, Nov 2010 Washington.

I have been reading these sections, and have found the technical sections (parts 4-6) highly informative about a major suspicion I've held for many years.

I suspected chaos in the health care IT software engineering process, with inadequate attention to quality, rigor, fine detail, resilience engineering, talent management and other practices essential in development of mission critical products of any type.

Prof. Patrick's forensic analysis, while not proof of my concerns, certainly supports them. If Boeing produced aircraft with malfunctioning engines, broken seats, defective flaps, tires that blew on landing, and rust right out of the factory (like the Chevy Vega of old?), one might suspect the development and manufacturing environment could be substantially problematic.

The theme of apparent violations of fundamental precepts of relational database design run consistently through his analysis of the FirstNet product.

Without getting too technical (which I can, having written successful relational database-based clinical information systems of considerable complexity for challenging environments, with novel user interaction design besides), I see evidence of developmental chaos.

Examples: primary key-foreign key inconsistencies and problematic usages ("keys" are flags used to link sets of information about some object or entity, such as a patient to their diagnoses or meds), internal field nomenclature faux pas (there are best practices on how to do this to enhance software quality and maintenance), cryptic documentation , "stale bits" (old code and data) from past iterations remaining to create "glitches", unreliabilities and new problems, and other technical sins apparently abound.

These can be read about in sections 4-6 of Prof. Patrick's analysis. The issues can be summarized as he did in the part 6 Abstract:

Consistent weaknesses in sections of the Millenium clinical information System (CIS) are revealed in the combined study of the ERD (entity-relationship diagram), logical schema and the data tables. PK (primary key, i.e., unique identifier) values are not always defined unambiguously at the design level and data tables reveal inconsistencies in declarations and data validation. There is evidence that keys are managed by software within the application rather than by the in-built functions available in the database management system leading to less confidence in data integrity.

He goes on to relate:

The [technical design] weaknesses in terms of clinical work practices, that have been identified are only likely to show up in occasional circumstances with a combination of processing and data values separated in time. [In other words, the resulting errors are unpredictable, and depend on variable factors about the patient's data and user's attempted actions that cannot be predicted ahead of time - ed.] Staff are not likely to associate one instance of missing or mis-processed data with another. This spasmodic nature tends to lull staff into a false sense of security that the mis-processing is either inconsequential or an accident of their own making. We recommend that each and every mis-processing experience be recorded as accurately as possible so that appropriate computational forensic analysis can correctly identify if weaknesses in the underlying technology have been the source.

These are dead-serious matters, literally. One's well being in an ED should not depend on random chance. If you are the "lucky patient" who Wins the Lottery or Hits the Jackpot on health IT mis-processing, or whose clinicians are distracted by user experience flaws, "workarounds", demoralization or other issues, you might end up maimed - or in the grave.

The ED EHR Slot Machine. Click to enlarge. You've hit the ED EHR mis-processing jackpot! Perhaps today is a good day to die...

I do not believe mission critical software for, say, avionics, or for implantable medical devices, suffers such sloppiness. (In part due to regulation, which health IT lacks entirely in the U.S.).

The UK, having their own HIT issues (see my Aug. 2010 "Battle of Britain" post at this link), apparently learned something, as evidenced in:

Health informatics — Guidance on the management of clinical risk relating to the deployment and use of health software. UK National Health Service, DSCN18 (2009), formerly ISO/TR 29322:2008(E).

and

Health Informatics — Application of clinical risk management to the manufacture of health software. UK National Health Service, DSCN14 (2009), formerly ISO/TS 29321:2008(E).

That said, I will now comment in more detail on a part of the analysis readily understandable by 'database laypeople': part 2, "Discussions with ED Directors: Are we on the right track?" (again, probably a rhetorical question).

In this section, candid discussions were held with the Directors of seven Emergency Departments in New South Wales public hospitals assessing the impact of the introduction of the FirstNet information system into their ED's. The effort has been ongoing for approximately the last 5 years.

Numerous themes remind me of my own observations as in my aforementioned Drexel health IT difficulties site:

The implementation processes of the HSS [governmental Health IT support, a.k.a. Health Support Services - ed.] were criticised for refusing to acknowledge the validity of complaints, failing to fulfil promises, creating an ineffective change process, refusing to consult clinicians, using strategies to disenfranchise participation by clinical staff, and introducing a technology that doesnʼt fit their needs.

All of these themes are familiar to me, and are representative of the phenomena of non-clinician, IT-centric arrogant ignorance, paternalism, leadership-pyramid inversion (i.e., the facilitators thinking and acting as if they are the enablers of healthcare), playing nasty politics with clinicians to avoid work, and minimizing job and results-evaluation discomfort for those lucky enough to secure cushy IT jobs in health IT support.

In determining the clinical documentation needs of staff, the Directors claim that the HSS ignores the needs of staff. Directors report over-supply of irrelevant information and under-supply of needed information in the clinical interfaces. ["Legible gibberish" - ed.] The environment consists of counter-intuitive interfaces where data is entered by one person in one part of the system so that it is not discoverable by another person.

The interfaces have inappropriate sizing of objects, confusing functions, redundant steps, unused functions and cluttered interfaces. These difficulties have resulted in increased time usage on the system resulting in decreased time with patients for no gain in administrative or clinical outcomes. Staff minimise their use of the system to as little as possible with work arounds being constantly developed and improved. Staff morale has been clearly degraded with accompanying loss of respect for the HSS and more generally NSWHealth’s authority.

These concepts are described and illustrated in my multi-part essay on the healthcare IT mission hostile user experience at this link. They represent major deviations from good information science, information presentation and human-computer interaction (HCI) precepts.

... Workarounds in using the system are the most obvious tangible response of staff to the functions of the system they consider unsatisfactory. The key aspect of workarounds is that they constitute a subversion of the policy processes created by the software that the staff are not prepared to collaborate with. Some of these strategies may even compromise the legal status of the records in the system: such as not signing documents, unrecorded alterations to documents, and test results not attached to patient records.

... Another form of staff protest workaround is the strategy by staff to avoid using the system by either having other people [presumably underlings - ed.] do the work on the system, inserting minimal amounts of information thereby reducing the value of the information and passing information to other staff verbally.

Workarounds to IT obstacle courses and booby traps, as noted by Koppel, Wetterneck, Telles & Karsh in "Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes and Threats to Patient Safety", J Am Med Inform Assoc. 2008 Jul-Aug;15(4):408-23, increase, not reduce, the risk of EHR-mediated medical errors. I wrote about their findings at "Business v. clinical computing: Workarounds to Barcode Medication Administration Systems" at this link.

It should be kept in mind that these are mission-critical systems for use in a fast-paced ED, not tracking systems for widgets - or for lab rats.

The lack of appropriate reporting functionality of the system has had a serious impact on the critical work of the Directors on process improvement ... It was evident in talking to the Directors that they have antennae highly tuned to the processes happening in their departments and the public health issues that emerge from their patients.

On a daily, weekly and monthly basis they review single cases, collections of common cases, and variations in established disease profiles to understand the success of their work and to detect emerging new trends or potential new disease outbreaks. At an administrative level they are asked to review cases either because of the return of new test results or due to complaints or reviews from other bodies.

The FirstNet installation has removed all the reporting functionality the directors had in their previous system EDIS while destroying their information sources for process improvement, and their mechanisms for creating and collaborating in research projects. This, in turn, has led to a loss of motivation to enter data further degrading the value of the data held within the system.

Reducing the value of a tool to people, and decreasing their ability to perform their jobs (especially when they take great professional responsibility and pride in those jobs) predictably leads to demoralization, demotivation and a cascading path down a whirlpool of failure.

The disadvantages of the system for day to day operations is well demonstrated by the issues around the ordering system. It is stated to be overly complex and requires a large deal of repetitive information to be input for multiple orders on one sample, plus specialist data entry knowledge that requires every joint order to have exactly the same timestamp. Ordering was the first accession where staff recognised that information is sometimes sent to the wrong staff, both arriving where it shouldn’t and not arriving where it should.

... Further mis-processing is seen with the cancellation of orders when a patient is transferred to a hospital ward from the ED. The results of orders, particularly radiology, often need to be checked by senior staff, but the system has no functionality to enable efficient processing of orders that have normal results, and thereby require no further attention.

I do recall another EHR system, by the same vendor I believe, where an "upgrade" in the recent past led to orders ending up in the wrong places (link):

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

Not to pick on this vendor; these "glitches" seem to be occurring in many HIT vendor's products.

All this, dear readers, is simply madness.

... Patient record retrieval is an important aspect of the staff work with patients, therefore its efficiency and accuracy is of vital importance to the activities of the ED. Staff were particularly pointed about the deterioration of this functionality in FirstNet compared to the previous system EDIS. [ED information system - ed.] There were cases where records could not be found, confusion about where data was stored in the patient record with different staff writing the same information into different parts of the record, and the [manual] rewriting of records [requiring a large amount of additional labor and time, not exactly a commodity in an ED -ed.] due to insertion of content into the wrong record.

These are critical issues. If you can't get information out of a computer in a timely fashion, what you have is a very expensive doorstop. I also note that a document imaging system that images hand written charts would not have these problems...

Prof. Patrick addresses the oft-heard canard that such complaints are the complaints of "Luddite doctors", old dogs who simply don't want to learn new tricks:

The staff in the ED are now generally experienced at using some form of clinical information system, many for over 10 years. This experience gives them a keen sense of what is possible with technology as well as the deficiencies in the existing systems. Combining this experience and knowledge with a sense of professional responsibility for process improvement enables them to judge quite acutely when a system is well designed or not. Hence their observations about elements of systems that are not parsimonious enough for optimal clinical efficiency deserve to be respected.

That it even needs to be written that the opinions of experienced medical professionals on the tools they are coerced to use by non-medical outsiders "deserve to be respected" gives testimony to my observation of a cross-disciplinary invasion of healthcare by the IT profession (among others).

Workflow and dataflow and the continuity of these processes are vital to the smooth running of a complex socio-technical process. ED staff have shaped these flows over a period of years and socialised all staff into the streaming. The directors have found that with the workflow of staff needing to use both clinical and nursing notes at the same time, their separation in FirstNet is deleterious. One department considered that the many nursing and medical notes accumulated over a day had to be kept in a single continuous sequence in the clinical record. Their workaround was to keep the one note page open for 24 hours to maintain the needed continuity in the patient record and avoid staff using a significant amount of time at the computer searching for needed information.

Nemeth and Cook explain how an ED EHR can be developed and marketed that interferes with, not supports, the workflows common in ED"s worldwide, in "Hiding in plain sight: What Koppel et al. tell us about healthcare IT", J Biomed Inform. 2005 Aug;38(4):262-3:

... On the surface, healthcare work seems to flow smoothly. That is because the clinicians who provide healthcare service make it so. Just beneath the apparently smooth-running operations is a complex, poorly bounded, conflicted, highly variable, uncertain, and high-tempo work domain. The technical work that clinicians perform resolves these complex and conflicting elements into a productive work domain. Occasional visitors to this setting [i.e., IT personnel, non-medical bureaucrats, etc. - ed.] see the smooth surface that clinicians have created and remain unaware of the conflicts that lie beneath it.

The technical work that clinicians perform is hiding in plain sight. [Hiding from the uninformed, that is - ed.] Those who know how to do research in this domain can see through the smooth surface and understand its complex and challenging reality. Occasional visitors cannot fathom this demanding work, much less create IT systems to support it. Progress in healthcare IT systems relies on scientific data on the actual, not the perceived, nature of day-today operations.

It increasingly seems the only place the faux-expert, healthcare-facilitor, cybernetic snake oil salespeople are going ot learn this simple lesson is in the courtroom...

A recent article in the press has presented evidence that access block times in EDs across the state of NSW are worsening.

As regards causality, it perhaps takes being an IS dept. director in a hospital - or holding elected office - to be unable to recognize the nose at the front of one's face.

Prof. Patrick wraps up this section of his forensic analysis as follows:

A number of conclusions can be drawn from the study:

1. Staff are entirely dissatisfied with the SBB and they feel that the deliverables have significantly failed to match the promises.

2. The Directors see that the HSS have failed in their support of the frontline of emergency care across the Sydney basin and their practices are decidedly lacking in proper engagement with the user community which should be their primary concern.

3. Some of the consequences of the HSS decision not to provide the reports needed by the Directors have lead to them being seriously hampered in being able to monitor the quality of their own department’s practices and wider changes and trends in community health.

4. The inefficiencies introduced by this technology have lead to a litany of complaints about its behaviour that have gone unheeded over the past three years.

5. It has lead to major strategies to work around the system by staff at all levels, to the point of complete avoidance by some staff.

The major consequences of these failings in the eyes of the ED directors are:

• Lost productivity and inefficiencies,
• Increased risks to patients,
• Disillusionment of staff and loss of morale.

Considering my own relative's injuries originating in an ED EHR mishap, I think I can safely add to Prof. Patrick's final tally an additional item:

• Patients have been harmed.
  

This is not a pretty picture.

I'm confident the Australian legal system abhors negligence as much as our own here in the U.S. If patients are injured and/or die as a result, considering that the Programme leadership and IT vendors knew - or should have known - of these deficits, it would not surprise me if criminal negligence charges begin to appear.

These issues are not exactly rocket science, and an expanding literature base has been appearing in recent years. See, for example, my recent post "An Updated Reading List on Health IT" at this link.

I can only add that my own relative was nearly killed as a result of a number of the phenomena described in Prof. Patrick's analysis.

More on other sections of his report at another time.

-- SS

March 6, 2011 addendum:

Also see my new post "What to do about the state of the ED EHR in NSW?"

-- SS

Mar. 8, 2011 addendum:

Prof. Patrick has added a new section to his report, entitled "The Future Pathways for e-Health in NSW." It is available at this link (PDF).

It inoculates against most of the 'Ten Plagues' that bedevil health IT projects (such as the IT-clinical leadership inversion, magical thinking about the technology, and lack of accountability):

More on the Pathways at my post here.

The de facto "National Program for IT in the HHS" here in the United States needs a similar inoculation.

--SS

BUY IT NOW!

IOM Committee on Patient Safety and Health IT, Meeting Two: Institute of Medicine, or of Mediocrity?

In my Jan. 2011 post "Institute of Medicine Committee on Patient Safety and Health Information Technology, and Thoughts on Social Aspects of Health IT Evaluation" I wrote that:

The U.S. National Research Council of the National Academy of Sciences issued a report in early 2009 on the state of health IT. That study's report, led in part by pioneers in Medical Informatics G. Octo Barnett and William Stead, was entitled "Computational Technology for Effective Health Care: Immediate Steps and Strategic Directions" (pre-publication PDF available free at this link). The report was announced under the following header:

CURRENT APPROACHES TO U.S. HEALTH CARE INFORMATION TECHNOLOGY ARE INSUFFICIENT

The insufficiencies were largely in the areas of difficulties with data sharing and integration, deployment of new IT capabilities, large-scale data management, and lack of cognitive support by health IT for busy clinicians.

One might reasonably conclude such deficits could affect patient safety.

Recently the Institute of Medicine (the health arm of the National Academy of Sciences) formed a Committee to study health IT safety. It held its first meeting on Dec. 14, 2010 (quite a few years late in my opinion, and only after tens of billions of dollars have been earmarked for health IT, but better late than never):

The Institute of Medicine Committee on Patient Safety and Health Information Technology is holding its first meeting on December 14-15, 2010. The first day, December 14, 2010 beginning at 10:30 am, is open to the public to observe the committee proceedings. The committee will hear presentations by the Office of the National Coordinator and other invited guests. There will also be an opportunity for members of the public and representatives of interested organizations to make a brief statement before the committee. Prior registration is requested for attendees and required for those wishing to make a statement.

Here are links to the PPT presentations from Meeting 2 of the Committee on Patient Safety and Health IT that took place Feb. 24, 2011:

http://www.iom.edu/~/media/Files/Activity%20Files/Quality/Patient%20Safety%20and%20HIT/Meeting%202/Dwork.pdf

http://www.iom.edu/~/media/Files/Activity%20Files/Quality/Patient%20Safety%20and%20HIT/Meeting%202/WoodsNormanFeb2011.pdf

http://www.iom.edu/~/media/Files/Activity%20Files/Quality/Patient%20Safety%20and%20HIT/Meeting%202/Harper%20IOM%20HIT%20Patient%20Safety.pdf

http://www.iom.edu/~/media/Files/Activity%20Files/Quality/Patient%20Safety%20and%20HIT/Meeting%202/Chrisman-.pdf

http://www.iom.edu/~/media/Files/Activity%20Files/Quality/Patient%20Safety%20and%20HIT/Meeting%202/Palmer.pdf

The PPT's can be downloaded directly from these links.

I note several observations:

• The overall quality of these presentations appears mediocre;

• Issues of healthcare IT risks - as they exist on the ground in 2011 - are addressed poorly if at all;
  

• Proposed "solutions" are really nothing novel or new compared to existing literature or recommendations made in earlier studies, including that of the US NRC;

• That these presentations come from the highest scientific body in the United States is, in my opinion, a disappointment and, indeed, an embarrassment.

The IOM's rules of engagement, according to the Study Director, preclude my testifying, as a Medical Informatics specialist and former CMIO, about a relative's nearly being killed by poorly designed and implemented health IT. Instead, the linked presentations above are presented.

Here's an example of what I consider a somewhat rigorous and critical thinking-based presentation on health IT risks:

http://www.ischool.drexel.edu/faculty/ssilverstein/Clinical_IT_benefits_risks.ppt

I think the IOM should be able to do better than a mere small-university medical informatics adjunct professor.

-- SS

BUY IT NOW!

MAUDE and HIT Risks: What in God's Name is Going on Here?

As I wrote at my last post "Healthcare IT Delirium":

The field of health IT has become delirious.

On top of an irrational exuberance (see this blog query) largely unsupported by the literature (e.g. here), the technology is experimental, its rollout is a grand national experiment in social re-engineering of medicine, there is no patient informed consent, nobody is in control, and nobody is taking responsibility for regulating the domain despite known risks. The results will very likely reflect the Wild West free-for-all that is now extant.

It's worse.

Some time ago I posted on a number of cases of health IT malfunction from the FDA's MAUDE (Manufacturer and User Facility Device Experience) database of medical device risks. See posts on MAUDE here and here.

Center for Public Integrity Investigative reporter Fred Schulte had also written on the MAUDE reports and other "glitches" at a Nov. 2009 report "Switch to electronic records getting mixed reviews at hospitals and clinics."

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.

Either I missed a Titanic boatload of cases, or MAUDE has been appended since my posts, because MAUDE links such as this , this and this are now returning a Mother Lode of cases, at least from one vendor where these events are reported (other vendors' products suffer similar problems).

Examples just from light browsing cause the hair to stand up on my head (there are many, many more at the MAUDE links above):

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1584195
CERNER MILLENIUM CPOE, POWER CHART
Event Type Injury Patient Outcome Life Threatening;
Event Description

The cpoe system serves and documents all transactions of communication pertaining to the patient's care. Orders are entered and delivered to an anticipated recipient and the action ordered is executed. The device-recipient interface has been unreliable with specific etiologies for failure not yet resolved or understood. Examples include orders to transfer patient from icu to a non-icu bed. Patient is moved to another bed but recipient care team does not receive communication and was not aware patient was under their charge. Patient had seizures on floor for hours throughout the night. Other patients had orders for lab tests, chemical tests on body fluids, cytological analysis of body fluids, cultures on body fluids, pathology on or specimen, and others that are not executed by the recipient, leaving the patient undiagnosed after having taken risks for a procedure. Such interface failures have been known by the vendor for years as reported by its own support team.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1581240
CERNER MILLENIUM CPOE, POWERCHART Back to Search Results
Event Type Injury Patient Outcome Life Threatening; Hospitalization Disability
Event Description

The displays, formats, layouts, and interfaces of the cpoe tools at this institution contain elevated degrees of user unfriendliness. This toxic effect on the user is manifested by, to mention a few, more than 20 electronic silos in which orders are stored and extensive wordiness using descriptors that are highly irrelevant to the task of the care of pts with critical illness. This manifests itself in several ways, one of which is the ordering of duplicate medications and treatments, some of which get to the pt. These should be reported to pharmacopoeia data bases but often are not. This pt was being infused both total parenteral nutrition and a concentrated dextrose solution, the combined rate of which and cumulative dose caused pulmonary edema.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1577753
CERNER MILLENIUM CPOE Back to Search Results
Event Type Injury Patient Outcome Life Threatening; Hospitalization Disability
Event Description

Stress test orders are ambiguous. An example of the order states "stress test adenosine/dobutamine w/imaging nm -stress test adenosine nm-". Order displays on 4 lines on the screen. The type of test that the doctor intended to be performed is unclear, resulting the risk of incorrect pharmacological modalities being used. This caused life threatening acute asthma attack in patient with background asthma who incorrectly received an infusion of adenosine. All patients ordered pharmacological stress tests become subject to said risk.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1578421
CERNER MILLENIUM CPOE Back to Search Results
Event Type Injury Patient Outcome Life Threatening; Other
Event Description

When a pt having been in the hospital preoperatively, begins its post-operative course in the recovery room or intensive care unit, post op orders are electronically entered by deleting the unneeded orders that have been active, leaving the orders that are still needed, and adding new ones. There can be upwards of 300 lines of "active" orders on a complicated pt. Precise and safe post-operative ordering requires a time consuming line by line review of each order, counter-intuitively canceling those that are not needed. This does not always occur for any number of reasons, not the least of which is that the task is time consuming and user-unfriendly. The incidence of commingling the pre and post op orders in a hospital with cpoe instruments of care is unk, but not uncommon. At least one pt was placed at risk when the clean post operative abdomen was irrigated based on the pre-op order.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1574909
CERNER MILLENIUM CPOE Back to Search Results
Event Type Injury Patient Outcome Life Threatening;
Event Description

This cpoe product allows doses to be ordered that are not a multiple-s- of the pill size. A representative example is 20mg atenolol po daily. Pill size is 25mg. This feature facilitates dosing errors and enables dangerously absurd dosing without warning. When the reports such dose having been given, the clinician is left to wonder, what dose was given, actually.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1570802
CERNER MILLENIUM CPOE, POWER CHART Back to Search Results
Event Date 07/11/2006
Event Type Injury Patient Outcome Life Threatening; Hospitalization Required Intervention
Event Description

Hospital wide breakdown of system of electric charts and electric order gadgets resulted in confusion, neglect, failed communications and delayed treatments in the days immediately following the surgery, leaving patient with permanent musculoskeletal disability and mental anguish. Breakdowns of this magnitude endanger hundreds of patients simultaneously.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1665473
CERNER MILLENIUM CPOE, POWER CHART Back to Search Results
Event Date 10/09/2006
Event Type Malfunction Patient Outcome Other;
Event Description

It has been discovered that the medication review screen consisting of a list of the medications on the left most column and a grid indicating the number of doses administered in each time period. The defect manifests itself in the representation of exactly what medication was administered. For pts who are taking two or more forms of the same pharmacological agent, eg nitroglycerin in the paste form, sub lingual form, and pill form, the name of the medication is represented as "nitroglycerin" on the list. The number of times it was administered is confusingly listed as a number in parentheses without clarity on which form of the medication was administered, creating confusion in the clinician and risk to the pt.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1726923
CERNER MILLENIUM CPOE, POWER CHART
Event Date 04/03/2010
Event Type Injury Patient Outcome Life Threatening; Other
Event Description

The computerized physician order entry instruments were deployed. Pleural fluid specimen were obtained. Chemical and cytological analysis was ordered on the specimen using the cpoe instruments. The specimen was not analyzed as ordered. Cytology results did not become available. Similar dysfunction appeared in more than 6 patients. The hospital has resorted to paper forms to clarify the dysfunction of this cpoe instrument. The patients may have cancer causing the fluid build up. This will not be known until time passes. There may be resultant delay in diagnosis of chest organ cancer.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1766892
CERNER MILLENIUM CPOE
Event Date 07/08/2010
Event Type Injury Patient Outcome Life Threatening;
Event Description

The active and active prn medication list had 7 potassium doses and routes, 2 tylenol doses and routes, 3 magnesium doses, 3 narcotic medications and doses, and 6 sodium chloride and sodium phosphate orders. The defects in the device and human factors at the interface enabled duplicate, triplicate, and more medications, enabling the nurse to potentially decide the treatment for this pt. The exact incidence of medication duplication from (b)(4) systems is unk, but common.

Some examples of mere "malfunctions", again just from random browsing of the MAUDE data:

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=358222
Model Number RELEASE 500
Event Date 10/03/2001
Event Type Malfunction Patient Outcome Other;
Event Description

Please see initial report.

Event Description

A user entered an order during the order entry process, with a frequency of every 8 hours and then used the ad hoc scheduling feature to modify the defaulted administration times for that frequency. After this was done, the user changed the frequency of the order to a 12-hour frequency without modifying the ad hoc administrations times. The software did not clear the previously entered ad hoc administration times to adjust to the default times for the new frequency. This resulted in a patient receiving a medications 3 times a day as opposed to 2 times a day. The drug was carbamazepene. This incorrect order frequency was repeated for 3 days, ultimately resulting in the patient receiving of total of 3 extra doses over a 3-day period (1 extra dose per day). On the fourth day, the nurse caring for the patient noticed the inconsistency in the order and conducted a further investigation with the pharmacist. The patient was discharged on time; no extended stay was necessary as a result of the overmedication. The patient's carbamazepene levels were checked during a follow-up visit that occurred 5 days after discharge, and were noted as normal at that time.http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1365512
Model Number 2007.01 - 2007.17
Event Date 12/30/2008
Event Type Malfunction Patient Outcome Other;
Event Description

The issue involves cerner millennium powerchart message center inox. When the results folder is filtered by event set and the event set display and event set name are different, result filtering may not function correctly. If the result filter is in message center and is an inclusive filter, results may be filtered out incorrectly. The impact associated with this issue is that patient care may be delayed or missed as follow-up may not occur. Cerner has not received communication on any adverse patient events as a result of this issue.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1247673
Model Number 2007
Event Date 10/30/2008
Event Type Malfunction
Manufacturer Narrative

Cerner distributed a priority review flash notification on nov 13, 2008 to all potentially impacted client sites. The software notification includes a description of the issue and an interim workflow adjustment to prevent the malfunction. A software modification is being developed to address the issue for all sites that could be potentially impacted. Cerner corporation will provide a follow-up report when the software correction is available.

Event Description

This issue involves the overview with reminder functionality on powerchart and affects sites that use cerner millennium powerchart (powerchart. Exe). If a currently open pt chart is replaced with another pt chart, and reminders are subsequently viewed in the detail pane of this visit, the incorrect patient's reminder may de displayed. Pt care could be adversely affected, as clinical decisions could be based on the wrong pt info. Cerner has not received communication of any adverse pt events as a result of this issue.


http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1097561
Model Number 2007.13
Event Date 06/30/2008
Event Type Malfunction
Event Description

The issue involves the task list functionality in carenet, and affects users that utilize the task list to view and document pt activities. When encounter security is turned on and the user documents an activity in task list, utilizing the previous or next arrows to select another pt chart, the single pt task list displays tasks for incorrect pt. Clinicians may view and document a pt's activity in another pt's record. Pt care may be affected as clinical decisions could be based on incomplete, invalid, or inappropriate info. Cerner has not received communication of an adverse pt event as a result of this issue.

Cerner has distributed a priority review flash notification july 30, 2008, to all potentially impacted client sites. The software notification includes a description of the issue and an interim workflow adjustment to prevent the malfunction. A software modification is being developed to address the issue for all sites that could be potentially impacted. Cerner corporation will provide a follow-up report when the modification is available. Additional model #: 2007. 16.

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1051313
Model Number 2001 THROUGH 2007
Event Date 04/23/2008
Event Type Malfunction
Manufacturer Narrative

Cerner has distributed a priority review flash notification may 23, 2008 to all potentially impacted clients sites. The notification includes a description of the issue and an interim workflow adjustment to prevent the malfunction. User documentation is being updated to address the issue for all sites that could be potentially impacted. Cerner corporation will provide a follow-up report when the documentation is available.

Event Description

The issue involves the order entry formats in powerorders and affects sites that use powerorders and medication profile. When creating the volume dose detail in the order entry formats (oef), the strength order formats require the volume dose to have an "=" sign as a prefix label. Failure to adhere to this build can result in an inpatient prescription order converted to produce an outpatient prescription that may be misleading. This only occurs when the inpatient order used is verified with a pharmacy product and the formulation used does not exactly match the dose. A formulation factor of more or less than one is used to achieve the volume and the order is then converted to a prescription. For example, 500 mg = 1 tab or 250 mg times 2 tabs = 500 mg. Patient care could be adversely affected, as a patient could receive either more or less of a medication therapy than intended. Cerner has received communication of order discrepancies discovered during a chart review as a result of this issue.

Again, there are many, many more examples like these in MAUDE, and I haven't even looked for data from other mfg's yet.
My relative was nearly killed last year by this technology due to issues like these, the risks of which I've been writing about for more than ten years now.

Alert to Sarah Palin: "Death panels?" Who needs death panels when technology like this is mediating our care and is planned for "urgent" national rollout with "meaningful use" rules and Medicare-penalty extortion - er, gentle coercion - directed towards healthcare organizations and clinicians?

I repeat, from the title of this post:

What in God's Name is Going on Here?

and:

U.S. government, regulatory agencies and consumer watchdogs: where are you?

-- SS

Jan. 21, 2011 addendum:

One wonders if the EHRevent site I wrote about at "EHRevent.org: Web Site to Collect EHR Safety Reports" and at "EHRevent: survey amateurism, bias, or something else?" will be as frank as MAUDE.

BUY IT NOW!

Medical center has more than 6000 "issues" with Cerner CPOE system in four months - has patient harm resulted?

As I have written at Healthcare Renewal before, computerized physician order entry systems (CPOE's) are known to present risks to patients through induction of medical errors.

This technology is held out to be ready for national diffusion, right up to the POTUS. Per ONC director Blumenthal in the July 13, 2010 NEJM:

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.

Vendors deny major problems with their CPOE and other health IT products.

The true story is a bit more complex.

Fortunately, there are some medical centers who are open and honest about HIT problems. These medical centers seem a rarity. However, those that do share are actually conducting themselves in an honorable and mission-true manner, per Joint Commission Safety Standards, the ethics of the medical profession, and the expectations of the public. They should be commended.

One such example is Munson Medical Center in Michigan.

From the October 2010 "News for Physicians affiliated with Munson Medical Center" newsletter, a large medical center in Northern Michigan, about more than six thousand "issues" with their Cerner CPOE:

POE Program Continues to be Improved, Enhanced

The Provider Order Entry (POE) program continues to be improved. Since implementation in June [four months ago - ed.], more than 6,000 issues have been reported. Issues are defined as an aspect of the program not working as intended [does that include medication and treatment errors and 'near-misses'? - ed.], process issues [can these 'issues' kill? - ed.], education needs, or PowerPlan [Cerner - ed.] change requests.

About 600 of these remain open. Issues are prioritized by the POE Team and addressed according to existing standards.

One wonders how many of those 6,000, and how many of the 600 remaining "issues" fall into categories of "likely to cause patient harm in short term if uncorrected" or "may cause in patient harm in medium or long term."

I note that Cerner CPOE is not a new product, nor are similar products from other vendors also afflicted with long lists of "issues." That there could be more than 6,000 "issues" at a new site suggests deep rooted, severe problems with CPOE specifically and health IT design and implementation processes in general.

Did patient harm result here or at other CPOE sites (using products of any vendor, not just this one) that had hundreds or thousands of "issues"? We may never know.

That national rollout is mandated as if this technology were proven, safe, and plug and play is a scandal of UK NPfIT-like proportions.

-- SS

BUY IT NOW!