Bug in MetaVision ICU system potentially catastrophic - American bad health IT goes Down Under

I have often written in this blog about healthcare IT defects and the lack of quality control regulation and safety testing.   I have indicated that patients have become guinea pigs for software development and testing, and healthcare facilities a software beta testing "proving ground" and defects remediation site.

This should all be occurring in the lab, not on live patients who've never given their consent to the use of these experimental cybernetic "command and control" systems that, in fact, regulate and govern their care in many ways.

Now there's this from Down Under in the journal Pulse*IT:

http://www.pulseitmagazine.com.au/index.php?option=com_content&view=article&id=2127:bug-in-metavision-icu-system-potentially-catastrophic 

Bug in MetaVision ICU system potentially catastrophic
Written by Kate McDonald on 27 October 2014.

A bug in the MetaVision intensive care software package being rolled out in several Brisbane hospitals has been identified as having the potential to seriously harm or even kill patients, several media outlets are reporting.

Fairfax's The Brisbane Times reported that a risk assessment by the Metro North Hospital and Health Service - which covers Brisbane's Prince Charles and Royal Brisbane and Women's (RBWH) hospitals - had found potentially catastrophic problems with prescription errors caused by the system that had a 60 to 90 per cent likelihood of causing a patient death.

MetaVision, from US vendor iMDsoft, is one of the few specialist critical care software packages on the market. It is able to capture information from medical devices and contains a full medical record specific to ICU patients.

This is U.S. software being foisted onto the very sick ICU patients of another country, Australia.

I should note that the author of the article, Kate McDonald, did an article about me in July 2012 and about my - at the time - upcoming presentation to the Health Informatics Society of Australia in health IT trust (article at http://issuu.com/pulseitmagazine/docs/pulseit_july2012/56, writeup of my presentation and link to slides at http://hcrenewal.blogspot.com/2012/08/my-presentation-to-health-informatics.html).

A 60 to 90 percent likelihood of causing a patient death is of great concern, especially in an ICU.  The likelihood of injury is probably in the same ballpark.

Who detected the problems?  The true experts - those with clinical expertise:

... It also contains medications management and decision support, and is able to interface with the complex IV infusion pumps used to administer medications to patients in intensive care.

The ABC [Australian Broadcasting Company] reported that according to the risk assessment report, “monitoring of patient records by pharmacists has revealed several potentially serious prescription errors specifically caused by the system”.

"Large volume prescriptions and high acuity of patients overlayed [sic] with functional risks of the system increases the likelihood of a SAC 1 (serious harm or death) event.

(Where have I seen computer-caused prescription errors with harm potential caused by bad health IT before?  Here, for one:   "Lifespan (Rhode Island): Yet another health IT "glitch" affecting thousands", http://hcrenewal.blogspot.com/2011/11/lifespan-rhode-island-yet-another.html.)

According to the ABC, the testing of this software was about par for the course in this unregulated health IT industry:

"There is no record of robust regression or functional testing at vendor, Queensland Health corporate or facility level."

Yet the software has been, and is, being rolled out by eager beavers seemingly just jolly at subjecting non-consenting ICU patients to an American experiment:

MetaVision has been rolled out in the ICUs at the Canberra and Calvary hospitals in the ACT, and at the Gold Coast, Prince Charles, Townsville, Rockhampton, Cairns and Logan hospitals in Queensland, where it has been installed for over a year.

It went live at Brisbane's Royal Children's in June, RBWH in September and at Princess Alexandra Hospital (PAH) just last week.

It is live at the Sydney Adventist Hospital and has also been chosen for a statewide roll-out in all ICUs in NSW.

The software company responds:

MDsoft issued a statement late on Monday saying that the problem was unique to the version implemented at Queensland Heath and does not affect any other installations in Australia.

"Late last week, certain clinicians from Queensland Heath highlighted potential risks as a result of prescribing with the MetaVision clinical information system," iMDsoft's director of marketing, Anne Belkin, said.

"iMDsoft is aware of this issue, and has already provided a solution to Queensland Heath. The software fix has been in testing at the site for several weeks and will be implemented in the near future.

First, one wonders why software being rolled out at hospitals in the Australian state of Queensland would be uniquely affected by such a severe bug, while at other sites it has not.  I question if some "new" features are being alpha- or beta-tested there - using Queensland Health ICU patients as unwitting laboratory rats.

Unless that "fix in testing" is being tested completely offline, this suggests patients are being used as literal software debugging test subjects regarding a flaw that could kill them.  The very best interpretation is that clinicians are asked to work around a potentially fatal "bug" in an ICU setting with the very sickest patients while the "fix" for a bug that should not exist in the first place is being remediated.   

"The risks highlighted by the report were originally identified during testing and, with close cooperation between iMDsoft and the clinicians at the Hospital and Health Service sites, a mitigation plan was immediately put into effect.  ... [The Brisbane Times] said the system has been manually over-ridden with medical charts [presumably the electronic charts - ed.] being reviewed daily by ICU specialists.

This suggests workarounds, which can be dangerous themselves ("one should not have to work around that which is not in their way", as I've written.)

A better and more ethical solution, in my opinion, to a potentially fatal bug's "mitigation plan" would be to turn the system off in the interim and revert to paper - as if the system had crashed - until the "bug" is fixed.

The company is then quoted as making this statement:

"The underlying risk is unique to the version implemented at Queensland Heath, and does not exist in any prior or subsequent releases for Australia. MetaVision is used at more than three hundred sites worldwide and is regulated by stringent international standards to ensure patient safety."

"Three hundred sites worldwide" is a very small number.  This suggests this is a very recent - or perhaps unpopular - offering.

The company site offers this:

iMDsoft is audited on a regular basis by international agencies. Our core products have been granted FDA marketing clearance and other accreditations. Our quality management system is certified under ISO 13485, which ensures that every working process is controlled and continuously improved to meet market and customer requirements.

iMDsoft is audited on a regular basis by international agencies. Our core products have been granted FDA marketing clearance and other accreditations. Our quality management system is certified under ISO 13485, which ensures that every working process is controlled and continuously improved to meet market and customer requirements. - See more at: http://www.imd-soft.us/about-us#sthash.RZMu32FN.dpuf

iMDsoft is audited on a regular basis by international agencies. Our core products have been granted FDA marketing clearance and other accreditations. Our quality management system is certified under ISO 13485, which ensures that every working process is controlled and continuously improved to meet market and customer requirements. - See more at: http://www.imd-soft.us/about-us#sthash.RZMu32FN.dpuf

It would be interesting to know what "stringent international standards" are being followed to "ensure patient safety" (ISO 13485, http://www.iso.org/iso/catalogue_detail?csnumber=36786 for medical devices is likely the one being cited), and what testing the FDA performed specifically.

I don't know of such standards for ICU health IT in the U.S., the country of origin of this software, where regulation of health IT is in the discussion stages by the government and FDA, and very unsatisfactorily I might add (see "FDA on health IT risk:  "We don't know the magnitude of the risk, and what we do know is the tip of the iceberg, but health IT is of 'sufficiently low risk' that we don't need to regulate it" (http://hcrenewal.blogspot.com/2014/04/fda-on-health-it-risk-reckless-or.html).

Nor do I know of rigorous ICU clinical EHR software evaluation and testing regulations and procedures anywhere else, for that matter, although would be glad to be informed of some that could be adopted in the U.S.

The expected excuses also appear:

Brent Richards, director of intensive care at the Gold Coast Hospital and then chairman of Queensland's Statewide Intensive Care Clinical Network, told Pulse+IT last year that the system delivered improvements in workflow and safety.

“ICU is incredibly complex and can be quite hard to computerise, because we have a lot of data flow,” Dr Richards said. “You want to capture all of that data including the data from the equipment interfaces, which is transferred minutely in MetaVision.

“Giving drugs is a lot more complex because ICU patients frequently have numerous infusions, and there is frequent real-time management of infusions – titrating medication infusions is normal in ICU – and the system has got to be able to capture it.”

In response, I penned this letter to Kate McDonald.  It speaks for itself:

From: Silverstein,Scot
Sent: Friday, November 07, 2014 9:58 AM
To: Kate McDonald
Subject: Re: Bug in MetaVision ICU system potentially catastrophic

Re:  http://www.pulseitmagazine.com.au/index.php?option=com_content&view=article&id=2127:bug-in-metavision-icu-system-potentially-catastrophic

Dear Kate,

I hope you are well.  My Australian colleagues alerted me to your article on the Metavision ICU flaws.

The excuse that:

... “ICU is incredibly complex and can be quite hard to computerise, because we have a lot of data flow,” Dr Richards said.

rings incredibly hollow.

If an ICU is so complex, the most stringent IT testing is indicated BEFORE go-live on actual patients.  If this were an aircraft or nuclear energy facility, one might now have a smoldering ruin or a Chernobyl (or Three Mile Island in the U.S., http://en.wikipedia.org/wiki/Three_Mile_Island_accident) radiation cloud.

Live patient environments, especially with the sickest in an ICU, are not proper software beta testing and debugging environments.

This is why in the U.S. I call for mandatory and strict quality and safety regulation of healthcare IT that will be employed on patients, much as software is regulated in other mission-critical and life-critical industries.

The health IT industry has for decades been given an extraordinary regulatory accommodation - that is, little to no regulation - and this can, and has, harmed and killed patients.

Please consider this letter suitable for publication.  I addressed some of these issues in my keynote at HISA 2012 in Sydney.

Sincerely,

Scot Silverstein

I, for one, certainly do not want buggy software deployed in ICU's anywhere near my residence.  Hospitals have a legal and ethical obligation to maintain safe environments for care.

Australian as well as American hospital management seem to have been cavalier about that when it comes to healthcare information technology.

-- SS

9:15 AM

Yet another health IT "glitch", that warm, fuzzy euphemism for life-threatening malfunctions: Internet outage left doctors without records for hours

Up to 112,000, in fact.

Nobody seemed to be listening when I and other "Health IT iconoclasts" warned years ago of issues like this regarding the blind-faith abandonment of paper and lack of truly robust local computing redundancy. When you're a patient, especially one in extremis, you do NOT want this to happen:

Internet outage left doctors without records for hours
Huffington Post
8/19/2014

http://www.huffingtonpost.com/2014/08/19/internet-outage-doctors-records_n_5689260.html

For several hours last week, doctors at PIM Associates, a primary care practice in Philadelphia, couldn’t see patients' lab results or what medications they were taking.

Those digital records are stored in the cloud by a company called Practice Fusion, which makes software to help doctors track patients.

But Practice Fusion's service was disrupted over two days last week because its data center provider suffered an outage. That prevented many of the 112,000 health care providers who rely on the company's software from accessing patient records.

“If you’re in an office that's completely electronic and the system goes down, you're flying blind,” Kelly Gallagher, a medical assistant at PIM Associates, told HuffPost. “It could be potentially dangerous.”

Potentially?  I'd say dangerous, period.

The episode offered an example of the potential drawbacks of electronic health records. It also highlighted how technology glitches can have serious human consequences. In this case, some out-of-date Internet equipment created confusion for many doctors.

Injured or dead patients really don't care.   They just want their records available.  Paper seems not to suffer mass outages...

... the ability to view electronic health records online depends on the reliability of technology companies -- which can experience glitches and outages. Last August, an electronic health record system made by Epic Systems went dark for a day, preventing nurses and staff at clinics in Northern California from accessing patient information. Last March, an outage involving a digital health record system in Boulder, Colorado, made by Meditech prevented some people from scheduling surgeries, getting test results or making appointments, according to the Boulder Daily Camera.

I covered those stories on this blog, and many others accessible under the query link http://hcrenewal.blogspot.com/search/label/glitch.

Health care providers face similar risks as other industries that store data in the cloud, but the stakes for doctors are often higher. One New York doctor who uses Practice Fusion's software said the outage could have been "a disaster if you’re dealing with life and death situations."

 I think the stakes are the highest for the patients.

The doctor requested that his name not be used because he said he worried that Practice Fusion might further disrupt his service. “My whole practice is in their hands,” he added.

Physicians are now beholden to and supplicated to IT companies.   That is not a pleasant thought.

Practice Fusion said the outage affected about one-third of its users, but didn't compromise data security. The outage "was out of our and our data center partner’s control," a company spokesperson told HuffPost.

"We worked closely with our partner to minimize the outage’s impact to our broader user base,” the spokesperson said. “We are monitoring the situation closely with our data center partner to address any other issues that may arise.”

I urge anyone reading this, if they know of injuries that resulted, to contact me.  I will pass the information along to plaintiff trial lawyers.

Practice Fusion attributed the outage to what experts are calling a rare Internet "brownout." Internet traffic is carried by a series of routers and switches, but the Web is now becoming too big and complicated for some of the old equipment. Last week, for the first time, the number of pathways for carrying Internet traffic crossed the critical threshold of 512,000. Many old Internet routers and switches can’t remember that many pathways, creating disruptions or outages across some parts of the Internet where that equipment needs to be replaced.

Again, injured and dead patients don't care, some of whom were in extremis when these outages occurred.  In medicine, there is no room for miscalculation and excuses.  My message to IT companies is if you can't provide reliable service, for whatever reason, then get the hell out of the medical clinic.

... Jim Cowie, chief scientist at Dyn, a company that tracks network management, said such disruptions will only continue in the coming months as the Internet keeps growing and its aging equipment is not replaced.

“We’re going to see more of these small, localized outages wherever there are vulnerable pieces of equipment,” Cowie said.

Well, then, perhaps paper is needed.

... In a blog post, the company recommended that affected customers print out any patient records they need. 

They agree.

For doctors, some of whom have complained about converting to electronic records, the Internet outage last week gave them justification for still keeping old-fashioned paper records.

“Sobering not to have had access to my practice for the last two days. Thank god for paper charts,” Meenakshi Budhraja, a gastroenterologist in Little Rock, Arkansas, tweeted.

Health IT extremists who believe in the abolishment of paper need to heed case examples like this.

But they won't, and that's almost guaranteed, at least until a cybernetic Libby Zion case occurs.

-- SS

5:38 PM

Bad Health IT -Yet Another Health IT 'Glitch' - Potential Image Loss in GE Centricity PACS; ECRI Again Reports Health IT a Top Ten Hospital Risk

From my definition of bad health IT (BHIT) at this link:

Bad Health IT ("BHIT") is defined as IT that is ill-suited to purpose, hard to use, unreliable, loses data or provides incorrect data, causes cognitive overload, slows rather than facilitates users, lacks appropriate alerts, creates the need for hypervigilance (i.e., towards avoiding IT-related mishaps) that increases stress, is lacking in security, compromises patient privacy or otherwise demonstrates suboptimal design and/or implementation.  

Considering the problem of lost data (lost x-rays) that affects not one, but two versions ("versions 3.x and 4.x and higher") of a common GE PACS (radiology image management) system, as in the attached memo to hospital radiology and IT executives, one might ask:

• How long has this been going on before this 'glitch' was discovered? 

• What validation and safety testing does GE use before releasing its health IT to production? 

• Why was it discovered in several successive versions of PACS systems being used on live patients, instead of in laboratory testing?

• How many delayed diagnoses, injuries and/or deaths might have occurred as a result of this "disappearing image" bug?

• What is the likelihood this "workaround" will be uniformly adopted in short order?  

• What levels of hypervigilance, stress and increased likelihood of error will this temporary "workaround" engender?

• When will it be fixed in all implementations worldwide?

 Beware disappearing x-rays.  Make sure every system user performs this workaround, too (click to enlarge).

Page 2 (click to enlarge)

It's not as if missing x-rays are a trivial matter.  One routine x-ray lost to followup resulted in the needless and rather horrible death of an infant, and a $1.5 million settlement, as at the June 2011 link "Babies' deaths spotlight safety risks linked to computerized systems" (case #2).

Patient safety is being compromised.

Lack of regulation of health IT, and lack of reporting and accountability, needless to say, are major contributors to the prevalence of BHIT.

I also note for several years running, including in the latest report of 2013, the ECRI Institute (an independent tester of healthcare technology) reports health IT-related problems as among the top ten technology problems in hospitals (link to report):

...Five of the top 10 hazards explained in ECRI Institute’s [2013] report are:

    1.  Alarm hazards
    2.  Medication administration errors using infusion pumps
    3.  Unnecessary radiation exposures and radiation burns during diagnostic radiology
         procedures
    4.  Patient/data mismatches in EHRs and other health IT (HIT) systems
    5.  Interoperability failures with medical devices and health IT systems

Three of the ten topics on the 2013 list are directly associated with the still-maturing [i.e., experimental - ed.] health IT field where the interplay between complexity and effectiveness and potential harm is most evident; several of the other topics are peripherally related to HIT issues.

“The inherent complexity of HIT-related medical technologies, their potential to introduce new failure modes, and the possibility that such failures will affect many patients before being noticed—combined with federal incentives to meet Meaningful Use requirements—leads us to encourage healthcare facilities to pay particular attention to health IT when prioritizing their safety initiatives for 2013,” says James P. Keller, Jr., vice president, health technology evaluation and safety, ECRI Institute.

The hazards included in the 2013 list, published in the November 2012 issue of ECRI Institute’s Health Devices journal, met one or all of the following criteria: it has resulted in injury or death; it has occurred frequently; it can affect a large number of individuals; it is difficult to recognize; it’s had high-profile, widespread news coverage.

-- SS

3:43 PM

At my Dec. 2011 post "IT Malpractice? Yet Another "Glitch" Affecting Thousands of Patients. Of Course, As Always, Patient Care Was "Not Compromised" and others, I noted:

UK: Another Example of IT Malpractice With Bad Health IT (BHIT) Affecting Thousands of Patients, But, As Always, Patient Care Was "Not Compromised"

At my Dec. 2011 post "IT Malpractice? Yet Another "Glitch" Affecting Thousands of Patients. Of Course, As Always, Patient Care Was "Not Compromised" and others, I noted:

... claims [in stories regarding health IT failure] that "no patients were harmed" ... are both misleading and irrelevant:

Such claims of 'massive EHR outage benevolence' are misleading, in that medical errors due to electronic outages might not appear for days or weeks after the outage ... Claims of 'massive EHR outage benevolence' are also irrelevant in that, even if there was no catastrophe directly coincident with the outage, their was greatly elevated risk. Sooner or later, such outages will maim and kill.

Here is a prime example of why I've opined at my Sept. 2012 post "Good Health IT (GHIT) v. Bad Health IT (BHIT): Paper is Better Than The Latter" that a good or even average paper-based medical record keeping system can facilitate safer and better provision of care than a system based on bad health IT (BHIT).

Try this with paper:

NHS 'cover-up' over lost cancer patient records

Thousands awaiting treatment were kept in the dark for five months when data disappeared

Sanchez Manning
The Independent
Sunday 30 September 2012

Britain's largest NHS trust took five months to tell patients it had mislaid medical records for thousands of people waiting for cancer tests and other urgent treatments. Imperial College Healthcare NHS Trust discovered in January that a serious computer problem and staff mistakes had played havoc with patient waiting lists.

It's quite likely the "serious computer problem" far outweighed the impact of "staff mistakes", as disappearing computer data does so in a "silent" manner.  One does not realize it's missing as there's not generally a trail of evidence that it's gone.

About 2,500 patients were forced to wait longer on the waiting lists than the NHS's targets, and the trust had no idea whether another 3,000 suspected cancer patients on the waiting list had been given potentially life-saving tests. Despite the fact that the trust discovered discrepancies in January and was forced to launch an internal review into the mess, including 74 cases where patients died, it did not tell GPs about the lost records until May.

That is, quite frankly, outrageous if true and (at least in the U.S.) might be considered criminally negligent (failure to use reasonable care to avoid consequences that threaten or harm the safety of the public and that are the foreseeable outcome of acting in a particular manner).

Revelations about the delay prompted a furious response yesterday from GPs, local authorities and patients' groups. Dr Tony Grewal, one of the GPs who had made referrals to Imperial, said doctors should have been told sooner to allow them to trace patients whose records were missing. "The trust should have contacted us as soon as it was recognised that patients with potentially serious illnesses had been failed by a system," he said. "GPs hold the ultimate responsibility for their patient care."

That is axiomatic.

The chief executive of the Patients Association, Katherine Murphy, added: "This is unacceptable for any patient who has had any investigation, but especially patients awaiting cancer results, where every day counts. The trust has a duty to contact GPs who referred the patients. It's unfair on the patients to have this stress and worry, and the trust should not have tried to hide the fact that they had lost these records. They should have let the GPs know at the outset."

Unfair to the patients is an understatement,  However, if one's attitude is that computers have more rights than patients, as many on the health IT sector seem to with their ignoring of patient rights such as informed consent, lack of safety regulation, and lack of accountability, then it's quite acceptable.

The trust defended the delay in alerting GPs, arguing that it needed to check accurately how much data it had lost before making the matter public. It said a clinical review had now concluded that no one died as a result of patients waiting longer for tests or care.

That would be perhaps OK if the subjects whose "data had been lost" through IT malpractice were lab rats.

Despite this, three London councils – Westminster, Kensington and Chelsea, and Hammersmith and Fulham – are deeply critical of the way the trust handled the data loss. Sarah Richardson, a Westminster councillor who heads the council's health scrutiny committee, said that trust bosses had attempted to "cover up" the extent of the debacle. "Yes, they've done what they can but, in doing so, [they] put the reputation of the trust first," she said. "Rather than share it with the GPs, patients and us, they thought how can we manage this information internally. They chose to consider their reputation over patient care."

As at my Oct. 2011 post "Cybernetik Über Alles: Computers Have More Rights Than Patients?", to be more specific, they may have put the reputation of the Trust's computers first. 

Last week, it was revealed that Imperial has been fined £1m by NHS North West London for the failures that led to patient data going missing. On Wednesday, an external review into the lost records said a "serious management failure" was to blame for the blunder.

Management of what, one might ask?

Imperial's chief financial officer, Bill Shields, admitted at a meeting with the councils that the letter could have been produced more quickly. He said that, at the time, the trust had operated with "antiquated computer systems" and had a "light-touch regime" on elective waiting times.

Version 2.0A will, as again is a typical refrain, fix all the problems.

Terry Hanafin, the leading management consultant who wrote the report, said the data problems went back to 2008 and had built up over almost four years until mid-2011. Mr Hanafin said the priorities of senior managers at that time were the casualty department and finance.

Clinical computing is not business computing, I state for the thousandth time.  When medical data is discovered "lost", the only response should be ... find it, or inform patients and clinicians - immediately.

He further concluded that while the delays in care turned out to be non-life threatening, they had the potential to cause pain, distress and, in the case of cancer patients, "more serious consequences" ... The trust said it had found no evidence of clinical harm and stressed that new systems have now been implemented to record patient data. It denied trying to cover up its mistakes or put its reputation before concerns for patients. "Patient safety is always our top priority," said a spokesman.

"More serious consequences" is a euphemism for horrible metastatic cancer and death, I might add.  The leaders simply cannot claim they "found no evidence of clinical harm" regarding delays in cancer diagnosis and treatment until time has passed, and followup studies performed on this group of patients.

This refrain is evidence these folks are either lying, CYA-style, or have no understanding of clinical medicine whatsoever - in which case their responsibilities over the clinic need to be ended in my opinion.

I, for one, would like to know the exact nature of the "computer problem", who was responsible, and if it was a software bug, how such software was validated and how it got into production.

-- SS

Oct. 1, 2012 Addendum:

What was behind the problems, according to another source?   

Bad Health IT (BHIT):

Poor IT behind Imperial cancer problems
e-Health Insider
28 September 2012
Rebecca Todd

An independent review of data quality issues affecting cancer patient referrals to Imperial College Healthcare NHS Trust has identified “poor computer systems” as a key cause of the problem.

The review’s report highlights the trust’s use of up to 17 different IT systems as causing problems for patient tracking.

However, it says the trust should be aware of the risks of [replacing the BHIT and] moving to a single system, Cerner Millennium, because of reported problems in providing performance data after similar moves at other London trusts.

In January 2012, the report says the NHS Intensive Support Team was reviewing the way reports on cancer waiting times were created from Imperial’s cancer IT system, Excelicare.

The team discovered that almost 3,000 patients were still on open pathways who should have been seen within two weeks. In May, letters were sent to GPs to try and ascertain the clinical status of around 1,000 patients.

BHIT must be forbidden from real-world deployments, and fixed rapidly or dismantled (as Imperial College Healthcare NHS Trust appears to be doing), although the "solution" might be just as bad, or worse, than the disease.

-- SS

5:47 AM

Clinicians: How to Document the EHR Screens You Encounter That Cause Concern

Healthcare IT "glitches" as reported on this blog should make any clinician - and patient - wary of the technology in its present state.

In the past, when camera film was the only image recording medium, it was often difficult to get high quality photographs of TV screens.  No longer.

Clinicians, here's a hint: it's now easy to photograph computer screens, either old CRT-based or newer flat panels, with a cellphone or other digital camera.

When you see something you are concerned about...you have the tools to document and share as necessary with the appropriate authorities, and to protect yourself.

Further, hospitals often claim they cannot show data as clinicians see it on-screen because of "print page" restrictions or due to the "oppressive burden" of someone having to do multiple screen dumps to a printer.

That excuse is no longer valid:

A screen shot of the very screen used to create this post, taken with an old 2 megapixel cellphone, default settings, no flash, ambient (dim) light, unremarkable flat screen monitor.  The same can be done for EHR, CPOE, etc.  Click to enlarge.

This example blows that Discovery-impairing excuse out of the water.

"Glitches" should be reported, and in a manner as I wrote at this post, reproduced below:

(Disclaimer:  The IT sellers and hospital corporate officials are likely to invoke IP rights regarding EHR screens and HIPAA regulations in the attempt to limit transparency about problems, for which I take no responsibility.  Use this technique with appropriate precautions with regard to information sharing.)

... When a physician or other clinician observes health IT problems, defects, malfunctions, mission hostility (e.g., poor user interfaces), significant downtimes, lost data, erroneous data, misidentified data, and so forth ... and most certainly, patient 'close calls' or actual injuries ... they should (anonymously if necessary if in a hostile management setting):

• Inform their facility's senior management, if deemed safe and not likely to result in retaliation such as being slandered as a "disruptive physician" and/or or being subjected to sham peer review (link).

• Inform their personal and organizational insurance carriers, in writing. Insurance carriers do not enjoy paying out for preventable IT-related medical mistakes. They have begun to become aware of HIT risks. See, for example, the essay on Norcal Mutual Insurance Company's newsletter on HIT risks at this link. (Note - many medical malpractice insurance policies can be interpreted as requiring this reporting, observed occasional guest blogger Dr. Scott Monteith in a comment to me about this post.)

• Inform the Joint Commission (or similar national accreditor of hospital safety if not in the U.S.) via their complaint site at http://www.jointcommission.org/report_a_complaint.aspx . Also consider writing the JC senior officers (link to officer's list), whose awareness of HIT issues I can personally attest to via our correspondences.

• Inform the FDA (or similar healthcare regulator if not in the U.S.) via the FDA Medwatch Form 3500 reporting site at https://www.accessdata.fda.gov/scripts/medwatch/medwatch-online.htm. An example of such an adverse event report I filed myself (when the involved hospital refused) is at this link in the FDA MAUDE (Manufacturer and User Facility Device Experience) database.

• Inform the State Medical Society and local Medical Society of your locale.

• Inform the appropriate Board of Health for your locale.

• If applicable (and it often is), inform the Medicare Quality Improvement Organization (QIO) of your state or region. Example: in Pennsylvania, the QIO is "Quality Insights of PA."

• Inform a personal attorney.

• Inform local, state and national representatives such as congressional representatives. Sen. Grassley of Iowa is aware of these issues, for example.

• As clinicians are often forced to use health IT, at their own risk even when "certified" (link), if a healthcare organization or HIT seller is sluggish or resistant in taking corrective actions, consider taking another risk (perhaps this is for the very daring or those near the end of their clinical career). Present your organization's management with a statement for them to sign to the effect of:

"We, the undersigned, do hereby acknowledge the concerns of [Dr. Jones] about care quality issues at [Mount St. Elsewhere Hospital] regarding EHR difficulties that were reported, namely [event A, event B, event C ... etc.]

We hereby indemnify [Dr. Jones] for malpractice liability regarding patient care errors that occur due to EHR issues beyond his/her control, but within the control of hospital management, including but not limited to: [system downtimes, lost orders, missing or erroneous data, etc.] that are known to pose risk to patients. We assume responsibility for any such malpractice.

With regard to health IT and its potential negative effects on care, Dr. Jones has provided us with the Joint Commission Sentinel Events Alert on Health IT at http://www.jointcommission.org/assets/1/18/SEA_42.PDF, the IOM report on HIT safety at http://www.modernhealthcare.com/Assets/pdf/CH76254118.PDF, and the FDA Internal Memorandum on H-IT Safety Issues at http://www.scribd.com/huffpostfund/d/33754943-Internal-FDA-Report-on-Adverse-Events-Involving-Health-Information-Technology.

CMO __________ (date, time)
CIO ___________ (date, time)
CMIO _________ (date, time)
General Counsel ___________ (date, time)
etc."

• If the hospital or organizational management refuses to sign such a waiver (and they likely will!), note the refusal, with date and time of refusal, and file away with your attorney. It could come in handy if EHR-related med mal does occur.

As EHRs remain experimental, I note that indemnifications such as the above probably belong in medical staff contracts and bylaws when EHR use is coerced.

Physicians can create health IT transparency; waiting for the industry or HHS to do so is, in my view, futile and not a patient advocacy stance.

-- SS

Aug. 31, 2012 Addendum:

I tried this method on a 20 year old, cathode ray tube-based Fisher 13" (appx.) color TV set.  Of course, this TV set is limited to a few hundred lines of resolution, and is interlaced (unlike most computer monitors after the early 1990's). Here's what I got.  Note that the picture was moving:

Old TV, old 2 MP cellphone, default settings.  Click to enlarge.

Again, old 2 MP cellphone, ambient background, default settings.  I tried several shots, and all were of similar quality.

-- SS

7:47 AM

From the University of Chicago EHR Helpdesk Call Line

I was alerted this morning (Aug. 23rd) to this message currently in the telephone message of the CBIS [Chicago Biomedicine Information Services] Service Desk at University of Chicago Medical Center:

"Thanks for calling the CBIS Service Desk.  Your call is very important to us. We are currently experiencing troubles with our Citrix logon.  It may log you on under a different profile.  Please check before you go any further when you're logging in to Citrix."

Citrix is a computer program that allows remote access to information systems.

I imagine the meaning of "log you on under a different profile" means "logging you on as a different user."

The chances of a security breach (ability of unauthorized user to peer into patient's charts they have no business seeing), unauthorized history/order manipulation, or even misidentification error (e.g., a clinician inadvertently acting upon a patient of some other clinician who has a similar name to their own patient) and other distracting work disruptions due to the inconveniences this "trouble" creates are worrisome.

One wonders how every user is being informed of this problem, as not everyone makes it a habit to call the service desk before logging in to clinical systems...

But, alas, this is just a "glitch" (the euphemism used by technophiles for malignant software defects), and, of course, patient safety is never compromised by "glitches."

Patient Safety Will Not Be Compromised, We Predict ... So Say Us All.

-- SS

8/29/12 Addendum:

Apparently the problem was finally solved between 5:30 PM and 9 PM CST on August 27.   I first became aware of it at around 8 AM EST August 23.  Brings to life the line "either you are in control of your information systems, or they are in control of you."

Also, see the comment thread to this post here, specifically the comments starting at August 28, 2012 12:16:00 PM EDT, to see yet another demonstration of the illogic, unserious attitudes and feelings of entitlement towards patient risk and transparency characteristic of the health IT industry.  The anonymous commenter also alleges to have firsthand knowledge of the problem, suggesting they are from U. Chicago, but this cannot be confirmed.

-- SS

6:17 AM

Massive Health IT Outage: But, Of Course, Patient Safety Was Not Compromised

Having been 'Down Under' in Sydney addressing the Health Informatics Society of Australia on the need to slow down their national health IT program - and on the need to think critically about HIT seller public relations exaggerations and hubris - and being very busy, I missed this quite stunning story of a major health IT outage.

Just a typical "glitch":

Some lessons from a major outage
Posted on July 31, 2012
By Tony Collins

Last week Cerner had a major outage across the US. Its international customers might also have been affected.

InformationWeek Healthcare reported that Cerner’s remote hosting service went down for about six hours on Monday, 23 July. It hit “hospital and physician practice clients all over the country”. Information Week said the unusual outage “reportedly took down the vendor’s entire network” and raised “new questions about the reliability of cloud-based hosting services”.

A Cerner spokesperson Kelli Christman told Information Week,

“Cerner’s remote-hosted clients experienced unscheduled downtime this week. Our clients all have downtime procedures in place to ensure patient safety.  [Meaning, for the most part, blank paper - ed.] The issue has been resolved and clients are back up and running. A human error caused the outage.  [I don't think they mean human error as in poor disaster recovery and business continuity engineering - ed.]  As a result, we are reviewing our training protocol and documented work instructions for any improvements that can be made.”

Christman did not respond to a question about how many Cerner clients were affected. HIStalk, a popular health IT blog, reported that hospital staff resorted to paper [if that was true, that paper was OK in an unplanned workflow disruption of major proportions, then why do we need to spend billions on health IT, one might ask? - ed.] but it is unclear whether they would have had access to the most recent information on patients.

One Tweet by @UhVeeNesh said “Thank you Cerner for being down all day. Just how I like to start my week…with the computer system crashing for all of NorCal [Northern California].”

Tony Collins is a commentator for ComputerWorldUK.com.  He's quoted me, as I wrote in my May 2011 post Key lesson from the NPfIT - The Tony Collins Blog.

This incident brings to life longstanding concerns about hospitals outsourcing their crucial functions to IT companies.  

Quite simply, I think it's insane, at least in the foreseeable future, as this example shows.

It also brings to mind the concerns that health IT, as an unregulated technology, causes dangers in hospitals with inadequate internal disaster and business continuity functions aside from fresh sheets of paper.  Such capabilities would likely be mandatory if health IT were meaningfully regulated.

The Joint Commission, for example, likely issued its stamp of approval for the affected hospitals, hospitals who had outsourced their crucial medical records functions to an outside party that sometimes went mute.  If someone was injured or died due to this outage, they would not care very much about the supposed advantages.

There's this in the article:

... “Issue appears to have something to do with DNS entries being deleted across RHO network and possible Active Directory corruption. Outage was across all North America clients as well as some international clients.”

Of course, patient safety was not compromised.

Finally:

Imagine being a patient, perhaps with a complex history, in extremis at the time of this outage.  

I, for one, do not want my own medical care nor that of my relatives and friends subject to cybernetic recordkeeping unreliability and incompetence like this, and the risk it creates.

-- SS

Aug. 8, 2012 addendum:

The Los Angeles Times covered this outage in a story aptly entitled "Patient data outage exposes risks of electronic medical records."

They write:

Dozens of hospitals across the country lost access to crucial electronic medical records for about five hours during a major computer outage last week, raising fresh concerns about whether poorly designed technology can compromise patient care.

My only comment is that the answer to this question is rather axiomatic.

They also quote Jacob Reider, acting chief medical officer at the federal Office of the National Coordinator for Health Information Technology, who said:

"These types of outages are quite rare and there's no way to completely eliminate human error"

This is precisely the type of political spin and misdirection I cautioned the Australian health authorities to evaluate critically.

Paper, unless there is a mass outbreak of use of disappearing ink, or locally hosted clinical IT, do not go blank en masse across multiple states and countries for any length of time, raising risk across multiple hospitals greatly, acutely and simultaneously.  (Locally hosted IT outages only cause "local" mayhem; see my further thoughts on this issue here).

-- SS

11:08 PM