ONC on healthcare IT and patient rights: These systems "have to be rolled out to know where the problems lie"

An anonymous commenter to my blog post about the USA Today article on bad health IT (http://hcrenewal.blogspot.com/2015/02/former-onc-director-david-blumenthal.html) noted this, that I myself missed:

Anonymous said...

Gettinger's comment is stunning, especially coming from a director of safety and quality for HHS' Office of the National Commissioner for Health Information Technology:

 "You don't just plunk down EHRs and everyone's happy. You use an incremental kind of approach (and) that takes time, that takes energy and that takes effort," he says, adding that they have to be rolled out to know where the problems lie.

February 1, 2015 at 9:17:00 PM EST

(Writing of ONC's Acting Director Andrew Gettinger MD, Office of Clinical Quality and Safety, http://www.healthit.gov/newsroom/andrew-gettinger-md.)

If quoted accurately, that's likely the end of the line for me regarding ONC and any concerns about patients' rights.  Patients are to be used as live subjects to debug software.

That is advocating human subjects experimentation without informed consent with a technology known to cause increased risk, harm and death, and there's nothing to debate there.  This statement would be perhaps appropriate for someone writing about animal experimentation. 

My own mother's dead, in fact, from that type of attitude.

Gettinger's statement will serve as the cover slide to my upcoming legal presentations to American Association for Justice state chapters and at the AAJ national meeting later this year, as well as to the Association of Health Care Journalists (AHCJ), to which I've been invited to speak.

-- SS

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

Yet another EHR "glitch" - insulin decreased per protocol, oops, I meant heparin

Yet another EHR "glitch" (http://hcrenewal.blogspot.com/search/label/glitch):

http://www.labornotes.org/2013/07/electronic-medical-records-friend-or-foe

An emergency room nurse described her frustrating experience trying to accurately document a dose of heparin, a blood thinner for patients with chest pain. “The doctor stated he wanted 4000 units bolus [all at once] and then a 1000 unit per hour infusion,” she wrote. “The order in Paragon stated 5000 units of heparin. I was given the option to decrease the dose, which I manually changed.

“However, I had to pick a reason why I decreased the dose. There was a drop-down box, and the only option was ‘Insulin decreased per protocol.’”

In the unregulated world of health IT, there's no pre-market evaluation or QC process to find little "glitches" like this that make it onto floors of live patients. 

The drug was heparin, not insulin. What was she supposed to do? “I contacted the pharmacy and spoke to three different people, and the final response was, ‘snapshot the screen and give it to your manager.’ This was a nine-minute conversation.”

That's really not very helpful to the patient needing heparin urgently.

The manager finally advised her to select the given option for insulin, then separately document that heparin, not insulin, was given.

No future mistakes are possible due to this little glitch "workaround", right?

That’s nine extra minutes away from the bedside, just to document one medication—and to document it inaccurately, to boot. Multiply that times the many different tasks and patients a nurse juggles every day, and you start to see the problem.

I point out that this order would have taken exactly ten seconds with a pen and paper.

I hear stories like this - odd "glitches" and "gotchas" - from medical colleagues at least weekly, and sometimes daily.

-- SS

Cerner: "It’s in the DNA of our company to have the vision and passion to fix what’s broken in health care." Maybe they should fix their software first?

I point out this hyper-exuberant piece on health IT in the St. Louis Post-Dispatch.

Clearly someone at Cerner thinks they're going to cure the world with "population health" and their computer software:

With its Healthy Nevada initiative, Cerner Corp. cultivates a culture of health
St. Louis Post-Dispatch
Diane Stafford,  Kansas City Star
May 11, 2014

http://www.stltoday.com/news/special-reports/mohealth/updates/with-its-healthy-nevada-initiative-cerner-corp-cultivates-a-culture/article_8cc3168f-fd9f-5e7e-ba80-cc05dd6a35f9.html

Cerner Corp. employees started visiting Nevada, Mo., in 2011, looking to adopt a community as a testing ground for theories to control skyrocketing medical costs.

At the outset, “our discussions were marked by a lot of confusion,” recalled City Manager John David Kehrman. “We thought of Cerner as a data company. We didn’t understand what they wanted.”

The North Kansas City-based company, grown to global prominence by selling health care information technology to hospitals and doctors, aimed to reach a broader audience with a message: You have to take more responsibility for your own health.

... the company’s bigger evolution is that it’s investing millions in its next-generation software, dubbed Healthe Intent, which tracks individual and group health and treatment results. It re-imagines jobs in the health care industry and eventually will reach into patients’ homes.

If the initiatives blossom, Cerner executives believe they will boost the company’s revenue by billions of dollars a year ... “Cerner’s founders never saw themselves being a health care IT company,” Swindells asserted. “They saw themselves fixing health care.”

Wow.  That's a neat trick for a health IT company.

(As I asked of health IT company CEOs making similar statements back at a 1997-or-so Microsoft Healthcare Users Group meeting, "How are you going to revolutionize healthcare when you and nearly everyone at this meeting has no actual healthcare experience?"  They had no rational answer.  See "Broken Chord", Healthcare Informatics, Feb. 1999, archived at this link.)

I won't comment further on the content of the St. Louis Post-Dispatch piece, which is marketing agitprop.  It's their right to produce such material, after all.  Read it for yourself and learn of our glorious Cerner-driven health utopia.

I will comment, however, on one line in the piece, namely:

... “It’s in the DNA of our company to have the vision and passion to fix what’s broken in health care,” said Matthew Swindells, Cerner’s head of population health and global strategy.

Considering the broken health IT this company introduces into the market upon unsuspecting physicians, nurses and patients [e.g., see notes 1-6], perhaps they should consider fixing what's broken in health IT before releasing to market, and certainly before attempting to tackle the infinitely harder task of "fixing what's broken in health care."

-- SS

Notes:

[1]  November 17, 2013. "Another 'Survey' on EHRs - Affinity Medical Center Nurses Warn That Serious Patient Complications 'Only a Matter of Time' in Open Letter", http://hcrenewal.blogspot.com/2013/11/another-survey-on-ehrs-affinity-medical.html
  
[2] January 19, 2012. "[British MP] Bacon calls for halt on [Cerner] Millennium", http://www.ehi.co.uk/news/acute-care/7471/bacon-calls-for-halt-on-millennium

[3]  January 21, 2011.  "MAUDE and HIT Risks: What in God's Name is Going on Here? [Cerner health IT defects reports]", http://hcrenewal.blogspot.com/2011/01/maude-and-hit-risk-mother-mary-what-in.html

[4]  March 4, 2011. "A study of an Enterprise Health information System [Cerner Firstnet]", Prof. Jon Patrick, Univ. of Sydney, http://sydney.edu.au/engineering/it/~hitru/index.php?option=com_content&task=view&id=91&Itemid=146

[5] Oct. 20, 2010.  "Medical center has more than 6000 "issues" with Cerner CPOE system in four months", http://hcrenewal.blogspot.com/2010/10/medical-center-has-more-than-6000.html

[6] 2009.  "The National Programme for IT in the NHS: Progress since 2006 - Public Accounts Committee" [on Lorenzo and Cerner Millenium], UK National Programme for Health IT in the NHS (now defunct), http://www.publications.parliament.uk/pa/cm200809/cmselect/cmpubacc/153/15304.htm

EHR recall: Use of this affected product may cause serious adverse health consequences, including death

Here is another example of a grossly defective health IT product, this from last year but only posted by FDA publicly on 3/14/2014 at http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm389356.htm:

"There was an occurrence where the patient case data did not match the patient data when the case was recalled in the Anesthesia Care Record (ACR) in that it included data from another case. Use of this affected product may cause serious adverse health consequences, including death."

One wonders why problems like this are found in the field when real patients are involved, not in the testing lab...could it have to do with lack of regulatory oversight?

Other examples of recalled bad health IT that I know of, including FDA-initiated recalls, are here:  http://hcrenewal.blogspot.com/2012/07/health-it-fda-recall-philips-xcelera.html, http://hcrenewal.blogspot.com/2011/12/fda-recalls-health-it-software-because.html , http://hcrenewal.blogspot.com/2013/08/a-good-way-to-cynernetically-harm-or.html.

Also note the FDA advisory:  Health care professionals and consumers may report adverse reactions or quality problems they experienced using these products to MedWatch: The FDA Safety Information and Adverse Event Reporting Program either online, by regular mail or by FAX:

http://www.fda.gov/MedicalDevices/Safety/ListofRecalls/ucm389328.htm 

McKesson Technologies, McKesson Anesthesia Care – Patient Case Data May Not Match Patient Data

Recall Class: Class I 

Date Recall Initiated: March 15, 2013 

Product: McKesson Anesthesia Care 

Use: The device is a computer-based system which collects, processes, and records data both through manual entry and from monitors which are attached to patients, such as in an operating room environment. The system provides clinical decision support by communicating potential adverse drug event alerts proactively during the pre-anesthesia evaluation and at the point-of-care. The system is generally indicated in the anesthetizing environment when the anesthesia provider decides to perform a patient assessment, to generate a paper and/or electronic record of the administration of anesthesia to a patient, and to document care. 

Recalling Firm:
McKesson Technologies, Inc.
5995 Windward Parkway
Alpharetta, Georgia 30005 

Reason for Recall: There was an occurrence where the patient case data did not match the patient data when the case was recalled in the Anesthesia Care Record (ACR) in that it included data from another case. Use of this affected product may cause serious adverse health consequences, including death.

Public Contact: Customers with questions may contact McKesson Customer Support at 1-800-442-6767 (option 3). For questions regarding this recall, call 404-338-3556. 

FDA District: Atlanta District Office 

FDA Comments:
On March 15, 2013, the firm initiated a Clinical Alert which was distributed to potentially affected customers. Phone calls were placed to each customer, followed up by an email. The firm provided their customers with written copies of the communication and Clinical Alert; and obtained acknowledgement that they read and understood the issue and preventive action to take.

Customers with questions were instructed to contact McKesson Customer Support at 1-800-442-6767 (option 3). For questions regarding this recall, call 404-338-3556.

Class I recalls are the most serious type of recall and involve situations in which there is a reasonable probability that use of these products will cause serious adverse health consequences or death. 

Health care professionals and consumers may report adverse reactions or quality problems they experienced using these products to MedWatch: The FDA Safety Information and Adverse Event Reporting Program either online, by regular mail or by FAX.

I encourage clinicians to take advantage of MedWatch with regard to bad health IT, anonymously if necessary to avoid internal repercussions or retaliation from executives who've spent hundreds of millions of dollars on the IT, and whose bonuses and promotions might be tied into its "success."

-- SS

An Idiotically-Designed EHR Medication Discontinuation "Feature"

Over at The Healthcare Blog, Michael Chen, MD, a family physician and EHR designer in Portland, Oregon wrote a piece entitled "Why EHR Design Matters" (http://thehealthcareblog.com/blog/2013/12/18/why-ehr-design-matters/).  I am cited.

Dr. Chen reports on a major commercial EHR with the following "feature":

... In this well known EHR, you are presented a medication list for a patient. As a physician, you assume that this list is a current medication list and is up to date.  However, the reality is that this EHR system automatically removes a medication from the list when it is determined to be expired even if it should be appearing on the current medication list.

When a physician prescribes a medication from this system, it calculates the duration of usage of the medication based on the instructions, quantity of medication prescribed, and the number of refills. Once the duration exceeds the number of days that has elapsed since the prescription was made, the medication is taken off the current list automatically by the EHR.  

In other words, the EHR drops the medication from the meds list when the time elapsed exceeds the amount of time the total # of doses written for would be consumed.   As any medical student would say, "that's just brilliant."

Now, taken at face value, this sounds like the logical approach to manage a medication list and utilizes the computing power that an EHR will gladly show off as a benefit to physicians.

Misuses, actually, and at the Warp-10 speeds of today's machines, that's a lot of misuse...

Unfortunately, the EHR programmers failed to understand that medications are not taken regularly by all patients all the time. In fact, no physician assumes that at all. So why should an EHR make that assumption? Furthermore, there are plenty of treatments that are to be taken only as needed so how can an EHR account for that? Absolutely, impossible.

Perhaps the designers and programmers, simply brimming with medical degrees and expertise, thought they knew everything about medicine.  After all, you go to see a doctor, the doctor taps on you and squeezes here and there, puts a stethoscope on you, then pulls out a prescription pad and scribbles a few lines.  How hard can medicine be compared to, say, programming?

Here's how this "feature" worked out in the real world:

So I recently treated a patient that reportedly has asthma. I happened to look at a previous note and find out that the patient was denied a refill request for Albuterol, a bronchodialator that is meant to be taken as needed. She ended up in a life threatening asthma flare up and needed emergent care. It turns out the physician on call who was given the refill request several days prior didn’t realize that the EHR removed the Albuterol from her list and subsequently instructed that the patient needed to have a physician visit for having the medication prescribed. After going through 2 different windows and unclicking a check box, I was able to identify that the patient did in fact have an active prescription for Albuterol, but the EHR made it disappear. She has used it infrequently, probably because her asthma was well controlled. Unfortunately, she ended up in worse shape when she needed the medication the most.

It's a good thing the patient didn't go into Status Asthmaticus (http://emedicine.medscape.com/article/2129484-overview) and suffer severe complications, or die ... (if she had, would any of the system designers, programmers and/or purchasers have shared in liability?)

I think it fair to say this EHR "feature" was idiotically conceived, designed and implemented, and that term is the most polite I can come up with.  Failure to know what they were doing, especially in the domain of medicine, compounded by failure to consult someone - even someone with basic medical commonsense -  who would see the folly and danger of such a "feature" is inexcusable. 

The state of clinical IT will improve when such characters are placed very far from any computer that is to be used in life-critical settings, of which medicine is by definition, or at least have their work subject to rigorous testing and validation by those who know what they're doing.

That will not happen, of course, until health IT is more rigorously regulated.

-- SS

"We’ve resolved 6,036 issues and have 3,517 open issues": Extolling EPIC EHR Virtues at University of Arizona Health System

The public may believe that, in healthcare, only the Obamacare insurance exchange website has lots of bugs.  On those, see my Oct. 10. 2013 post "Drudge Report, Oct. 10, 2013, 9 AM EST: All that needs to be said about government, computing and healthcare" at http://hcrenewal.blogspot.com/2013/10/drudge-report-oct-10-2013-9-am-est-all.html.

Another pillar of the Affordable Care Act, electronic medical records (promoted with incentives for adopters and with penalties for non-adopters via the HITECH section of the 2009 economic recovery act or ARRA) are pretty damn bad themselves.  Only, those systems don't make it hard to find insurance.  Through bugs and other features of bad health IT, they directly interfere with safety and provision of quality care:

Bad Health IT ("BHIT") is ill-suited to purpose, hard to use, unreliable, loses data or provides incorrect data, is difficult and/or prohibitively expensive to customize to the needs of different medical specialists and subspecialists, 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. 

At my Oct. 20, 2010 post "Medical center has more than 6000 'issues' with Cerner CPOE system in four months - has patient harm resulted?" (http://hcrenewal.blogspot.com/2010/10/medical-center-has-more-than-6000.html) I observed:

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.

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

Here's another such multi-"issue"-laden EHR, this at University of Arizona Health Network.  Image of frequent periodic "EHR Update" below.

"We’ve resolved 6,036 issues and have 3,517 open issues."

[Ignore the 'kewl dark sunglasses' worn by the hipsters at the top of this announcement.  Not sure if this has something to do with EPIC, but I consider the wearing of dark sunglasses by clinicians or any other staff in a hospital setting - where people are sick and/or dying - to be in exceptionally bad taste.]

The text starts:

ISSUES UPDATE as of 4:00 p.m., Nov. 8
We’ve resolved 6,036 issues and have 3,517 open issues.

That's a total of nearly ten thousand "issues."  As of now, that is.  "Issue" is a euphemism for "glitch" a.k.a. "software defect" and/or "implementation error", see http://hcrenewal.blogspot.com/search/label/glitch.

These "issues" are  in a supposedly "mature" product for which this organization has spent enormous sums of money, that has undergone "innovation" for several decades now - in an environment free from regulation, I might add.

Many of the "issues" reduce patient safety, and could or already may have resulted in patient harm.  Such items on this listing, seen below, which is updated frequently, include:

• Pharmacy Medication Mapping Errors – Making good progress: watch for further notices.  [Perhaps these should have been tested and fixed before go-live? - ed.]

• Microbiology Results Mapping Incorrectly [does that mean "mapping" to the wrong patient? - ed.]  – all known errors fixed, monitoring and working on enhancements. [As above, perhaps these should have been tested and fixed before go-live? - ed.]

• Prescription printing - output for prescription printing has been fixed

• Refill requests for providers will be routed to the CLIN SUPPORT In Basket pool for the provider’s department.  This was a decision made by UAHN leadership. [Not sure why this is being done; perhaps for approval by managers? - ed.] 

• Errors transmitting prescriptions will also be sent to the CLIN SUPPORT In Basket.  [Errors transmitting prescriptions? That's not reassuring regarding data integrity.  See ECRI report below  - ed.]

This is not to mention that all of the "reminders" that follow are a distraction to clinical personnel, who cannot be expected to remember all of them.

Bad as this is, at my April 1, 2012 post "University of Arizona Medical Center, $10 million in the red in operations, to spend $100M on new EHR system" (http://hcrenewal.blogspot.com/2012/04/university-of-arizona-medical-center-10.html) I observed that:

... $100 million+ is probably enough to pay for AN ENTIRE NEW HOSPITAL or hospital wing ... or a lot of human medical records professionals.

To add more bitter icing to this cake, I wrote about a campaign for clinicians to speak only in wonderful terms about the new U. Arizona Health System EHR at my Oct. 3, 2013 post "Words that Work: Singing Only Positive - And Often Unsubstantiated - EHR Praise As 'Advised' At The University Of Arizona Health Network."  I observed the following about the "words that work" is the shameless 'suggested' script:

• Efficient - see aforementioned links as well as "Common Examples of Healthcare IT Difficulties" at http://cci.drexel.edu/faculty/ssilverstein/cases/

• Convenient - as above.  According to whom?  Compared to what?  Pen and paper?

• Improves patient safety and quality - see IOM report post at http://hcrenewal.blogspot.com/2011/11/iom-report-on-health-it-safety-nix-fda.html .  We as a nation are only now studying safety of this technology, and the results are not looking entirely convincing, e.g. ECRI Deep Dive Study of health IT safety at http://hcrenewal.blogspot.com/2013/02/peering-underneath-icebergs-water-level.html.  171 health IT mishaps in 36 hospitals, voluntarily reported over 9 weeks, with 8 reported injuries and 3 reported possible deaths is not what I would call something that "improves patient safety and quality" without qualifications.

• The Cadillac of its kind - according to whom?

• Patients at hospitals using this system love it -  Do most patients even know what it, or any EHR, looks like?  Have they provided informed consent to its use?

• Exciting - clinician surveys such as by physicians at http://hcrenewal.blogspot.com/2010/01/honest-physician-survey-on-ehrs.html and by nurses at http://hcrenewal.blogspot.com/2013/07/candid-nurse-opinions-on-ehrs-at.html shed doubt on that assertion.

• The best thing for our patients - again, according to whom?

• Sophisticated new system - "New"?  Not so much, just new for U. Arizona Health.  "Sophisticated", as if that's a virtue?  Too much "sophistication" is in part what causes clinician stress and burnout, raising risk

Considering the near 10,000 issues, the new ECRI Institute report "Top Ten Technology Hazards in Healthcare", 2014 edition comes to mind (https://www.ecri.org/Press/Pages/2014_Top_Ten_Hazards.aspx).  Named in that report, as has been the case for the past several years, is healthcare IT. 

This year's problem description is:

#4. Data Integrity Failures in EHRs and other Health IT Systems

"Data integrity failures" include "issues" (per the bad health IT description) such as: data loss, data corruption, data attributed to the wrong patient, etc.

ECRI Institute, a nonprofit organization, dedicates itself to bringing the discipline of applied scientific research to healthcare to discover which medical procedures, devices, drugs, and processes are best to enable improved patient care. As pioneers in this science for 45 years, ECRI Institute marries experience and independence with the objectivity of evidence-based research. Strict conflict-of-interest guidelines ensure objectivity. ECRI Institute is designated an Evidence-based Practice Center by the U.S. Agency for Healthcare Research and Quality. ECRI Institute PSO is listed as a federally certified Patient Safety Organization by the U.S. Department of Health and Human Services. For more information, visit www.ecri.org.

ECRI also produced the 2012 Deep Dive Study of Health IT Risk (http://hcrenewal.blogspot.com/2013/02/peering-underneath-icebergs-water-level.html), where in a volunteer study at 36 member PSO hospitals, 171 health IT "mishaps" were reported in just 9 weeks, 8 of which caused patient injury and 3 of which may have contribute to patient death.

In summary, The University of Arizona Health System, with components in the red, is spending hundreds of millions of dollars on an EHR system, that has had decades to mature. Yet, they are finding 10,000 "issues" already, a number of which reduce patient safety and are unresolved, with many more likely to be found.

They are also 'advising' their staff to speak in glowing, unsubstantiated terms to patients about an EHR system that has 10,000 issues, and not seeking patient consent to its use in mediating and regulating their care - or giving elective patients the information that might allow them to choose another less "buggy" hospital.

If (when) patient harm results from such cavalier hospital (mis)management, the juries are going to just love the dark sunglasses, I bet.

-- SS

Saving My Mother Yet Again. EHR Legible Gibberish - Another Example, the ED EHR Allergy List - And Legal Threats for Exposing Problems

My brain-injured mother was admitted to a suburban hospital (recently acquired by the "big hospital" where her EHR-related injuries of 2010 had occurred) Saturday morning.

She was again in a confusional state (delirium) of unknown cause, probably recurrent infection.

Of note, almost every time I see hospital EHRs, I note a problem.

In my Jan. 2011 post on this issue at the same organization, "EHR Problems? No, They're Merely Anecodotal; the Truth Must Be That I Attract Bad Electrons and Stale Bits" I observed a nurse-stated "glitchy-ness" that day that manifested as unreliability in pulling up the patients' current med lists. I had to be the conduit of my mother's meds, despite having gone through them in detail for computer entry in the exact same ED just 24 hours prior after a fall:

... My mother was having a repeat of the ischemia to the brain or "TIA" (transient ischemic attack, i.e., threatening to have a stroke), only this time the ED EHR itself was also having a TIA.

This was not the "FirstNet" ED EHR by Cerner forensically analyzed by Dr. Jon Patrick (as I wrote about here), but another ED EHR, by a company whose ICU physiological monitoring system I once as CMIO struggled with due to repeated, unexplained crashing.

On this most recent ED visit/admission to the satellite just days ago, I noted another problem with the ED EHR system (the same one that started my mother's travails at the main facility in May 2010, and now in use at the satellite).

When the ED nurse brought up my mother's allergies, they were repeated over and over and over on the ED screen, in a long recurrent list dozens of lines long, as if they'd been cut-and-pasted multiple times at each visit. She apologized to me. See images of a printout that was provided to me by an ED attendant upon my request as my mother's POA, below (names of hospital, patient, EHR, and EHR screen layout digitally redacted):

Allergy list, page 1 (excerpted from an on-screen continuous list). Click to enlarge.

Allergy list, page 2 (excerpted from an on-screen continuous list). Click to enlarge.

Allergy list, page 3 (excerpted from an on-screen continuous list). Click to enlarge.

Note that on-screen these appeared as a long, confusing list.

The repetition made the list near useless to the ED personnel (for example, they don't have time to look for the one crucial item that ISN'T a duplicate in the mess).

Legible gibberish indeed.

The ED RN just asked me about my mother's allergies, saying she could not make sense of the computer list and wanted to make sure no mistakes occurred. This is an appropriate attitude - the only appropriate attitude - for a clinician. Fortunately, I'm a doctor and know the allergies well.

The hospitalist then called me that night suggesting she would give my mother Levaquin, an antibiotic. For the umpteenth time I had to tell a doctor at these facilities my mother was allergic to Levaquin. This was in fact one of my complaints on my April 2010 warning letter to the hospital's CEO and CMO on EHR deficiencies I'd noted in my mother's care. This was just one month prior to her catastrophe, when a critical heart medication "disappeared" in the ED EHR, causing a cascade of medication continuity failure.

Yesterday I insisted the duplicate entries be removed (more precisely, "made inactive" - they still appear, but in a different color than "active" entries).

It is, on first principles, inherently harmful to the public to have critical patient data stored in disarray in an Emergency Room electronic health record.

See the above images, and ask if this is what you'd want busy ED doctors to have to wade through to figure out if a drug they're about to administer might injure or kill you.

-- SS

Post legal-threat addendum:

I'd originally posted actual screen shots (PHI and hospital name redacted) of the allergy lists provided to me by an ED attendant upon my request as my mother's POA.

On April 8, 2011, however, I received a threatening letter from the attorney representing the hospital claiming these screens were viewed by the client as "copyrighted and proprietary information" that I had "misappropriated" (stolen).

(This raises the question as to who, exactly, the "client" is - the hospital, or the EHR vendor?)

In any case, I was asked to "retract from the blog the copyrighted and proprietary information" under threat of the hospital "pursuing all remedies under the state's trade secret laws and Federal Law." Further, I was accused of "inappropriate behavior" in trying to protect my mother from further EHR-related accidents.

The allegations (actually, fabrications) of "medical records misappropriation" and "inappropriate behavior" were especially outrageous and unprofessional, considering the hospital had already altered my mother's medical record by adding the medication they missed to the ICU H&P as at this post, was caught at it, and had admitted it to me.
I have now done as asked, only posting the allergy information and dates without the background EHR tabs of the screen header, the only component that could even remotely be viewed as protected IP (i.e., of the EHR vendor).

I had a followup discussion with a senior nurse involved in the EMR project about those screens and the legal threats, which I viewed as potential retaliation aimed at discriminatorily denying my mother and I use of public accommodations, i.e., the hospital, through intimidation. (If my seeking records legitimately was "inappropriate behavior", who knew what else I might be falsely accused of to "discourage" my return?)

I was informed with a straight face that the allergy repetition was a "feature", not a bug.
The problem was "the nurse in the ED", who did not understand they needed to "look at the dates" to understand the allergy list. ["Blame the user" is typical in this domain - ed.] This senior nurse clearly had an amateur's understanding of HCI and clarity of presentation of information - or was simply talking down to me.

I provided a reminder that with 20 years of Ivy academic, big hospital (much larger than hers) and Big Pharma experience in this domain, I found her arguments specious.

Amateurism on presentation of information is a factor that promotes EHR-related error. (It is my hope the original ED nurse is not punished for protecting patients instead of "protecting the computer" and its faults.)

-- SS

An Open Letter to David Bates, MD, Chair, ONC FDASIA Health IT Policy Committee on Recommendations Against Premarket Testing and Validation of Health IT

From http://www.healthit.gov/policy-researchers-implementers/federal-advisory-committees-facas/fdasia:

The Food and Drug Administration Safety Innovation Act (FDASIA) Health IT Policy Committee Workgroup is charged with providing expert input on issues and concepts identified by the Food and Drug Administration (FDA), Office of the National Coordinator for Health IT (ONC), and the Federal Communications Commission (FCC) to inform the development of a report on an appropriate, risk-based regulatory framework pertaining to health information technology including mobile medical applications that promotes innovation, protects patient safety, and avoids regulatory duplication.

My Open Letter to the Committee's chair speaks for itself:

From: Scot Silverstein
Date: Mon, Sep 16, 2013 at 9:39 AM
Subject: ONC FDASIA Health IT Policy Committee's recommendations on Premarket Surveillance
To: David Bates

Sept. 16, 2013

David Bates, Chair, ONC FDASIA Health IT Policy Committee
via email
   
Dear David,

I am disappointed (and in fact appalled) at the ONC FDASIA Health IT Policy Committee's recommendations that health IT including typical commercial EHR/CPOE systems not be subjected to a premarket testing and validation process.  I believe this recommendation is, quite frankly, negligent. [1]

As you know, my own mother was injured and then died as a result of EHR deficiencies, and nearly injured or killed again in the recuperation period from her initial injuries by more health IT problems in a second EHR used in her care.  In my legal consulting and from my colleagues, as well as from the literature, I hear about other injuries/deaths and many "near misses" as well.  That your recommendations came in the face of the recent ECRI Deep Dive study is even more appalling, with the latter's finding of 171 health IT-related incidents in 9 weeks from 36 member PSO hospitals, resulting in 8 injuries and 3 possible deaths, all reported voluntarily. [2]

It is my expert opinion the issues that cause these outcomes would never have made it into production systems, had a reasonable, competent, unbiased premarket testing and validation process been in place.

Consequently, I have shared the FDASIA HIT Policy Committee's recommendations with the Plaintiff's Bar, and will use its recommendations in my presentations to various chapters of the American Association for Justice (the trial lawyer's association) - as well as to interested Defense attorneys so they may advise their clients accordingly.

I am also making recommendations that in any torts, individual or class, regarding EHR problems that would likely have been averted with competent premarket testing and validation, that the FDASIA HIT Policy Committee members who agreed with the recommendation be considered possible defendants.

I am sorry it has come to this.

Please note I am also posting this message for public viewing at the Healthcare Renewal weblog of the Foundation for Integrity and Responsibility in Medicine (FIRM).

Sincerely,

Scot Silverstein, MD
Consultant/Independent Expert Witness in Healthcare Informatics
Adjunct Faculty, Drexel University, College of Computing and Informatics

Notes:


[1] FDA Law Blog, Recommendations of FDASIA Health IT Workgroup Accepted, September 11, 2013, available at http://www.fdalawblog.net/fda_law_blog_hyman_phelps/2013/09/recommendations-of-fdasia-health-it-workgroup-accepted.html: "Of particular interest is the recommendation that health IT should generally not be subject to FDA premarket requirements, with a few exceptions:  medical device accessories, high-risk clinical decision support, and higher risk software use cases."

[2] "Peering Underneath the Iceberg's Water Level: AMNews on the New ECRI 'Deep Dive' Study of Health IT Events" , Feb. 28. 2013, available at http://hcrenewal.blogspot.com/2013/02/peering-underneath-icebergs-water-level.html.

-----------------------------------------------

Note: the following are listed on the linked site above as members of the committee:

Member List

• David Bates, Chair, Brigham and Women’s Hospital
• Patricia Brennan, University of Wisconsin-Madison
• Geoff Clapp, Better
• Todd Cooper, Breakthrough Solutions Foundry, Inc.
• Meghan Dierks, Harvard Medical Faculty, Division of Clinical Informatics
• Esther Dyson, EDventure Holdings
• Richard Eaton, Medical Imaging & Technology Alliance
• Anura Fernando, Underwriters Laboratories
• Lauren Fifield, Practice Fusion, Inc.
• Michael Flis, Roche Diagnostics
• Elisabeth George, Philips Healthcare
• Julian Goldman, Massachusetts General Hospital/ Partners Healthcare
• T. Drew Hickerson, Happtique, Inc.
• Jeffrey Jacques, Aetna
• Robert Jarrin, Qualcomm Incorporated
• Mo Kaushal, Aberdare Ventures/National Venture Capital Association
• Keith Larsen, Intermountain Health
• Mary Anne Leach, Children’s Hospital Colorado
• Meg Marshall, Cerner Corporation
• Mary Mastenbrook, Consumer
• Jackie McCarthy, CTIA - The Wireless Association
• Anna McCollister-Slipp, Galileo Analytics
• Jonathan Potter, Application Developers Alliance
• Jared Quoyeser, Intel Corporation
• Martin Sepulveda, IBM
• Joseph Smith, West Health
• Paul Tang, Palo Alto Medical Foundation
• Bradley Thompson, Epstein Becker Green, P.C
• Michael Swiernik, MobileHealthRx, Inc.

Federal Ex Officios

• Jodi Daniel, ONC
• Bakul Patel, FDA
• Matthew Quinn, FCC

 -- SS

A Good Way to Cybernetically Harm or Kill Emergency Department Patients ... Via An ED EHR "Glitch" That Mangles Prescriptions

Yet another healthcare IT "glitch" - that banal little word used for potentially life-threatening software defects.  (See the query link http://hcrenewal.blogspot.com/search/label/glitch for more examples.)

An EHR/command and control system (including ordering, results reporting, etc.)  for hospital Emergency Departments, Picis Pulsecheck, was recalled by FDA.

Reason?  "Notes associated with prescriptions are not printed to the prescription or to the patient chart."  The data apparently is not being sent to the printer or being stored for future visits.  Instead, data input by clinical personnel, in one of the most risk-prone medical settings, the Emergency Department, is simply going away.

This is reminiscent of the truncation of prescription drug "long acting" suffixes, apparently by a Siemens system, that led to thousands of prescription errors (perhaps tens of thousands) over more than a year's time.  I wrote about that matter, as reported by the news media, at "Lifespan (Rhode Island): Yet another health IT "glitch" affecting thousands - that, of course, caused no patient harm that they know of - yet" at http://hcrenewal.blogspot.com/2011/11/lifespan-rhode-island-yet-another.html. 

Regarding the current Picis recall, notes connected with prescriptions can be crucial to the pharmacist or the patient.  Loss of those notes - apparently due to a computer glitch and most likely in this case without the prescribing clinician knowing about it - likely have been going on for some time now, since two software versions (5.2 and 5.3) are affected.

The solution for now?

"Consignees were provided with recommended actions until they receive the necessary update."

In other words, a workaround adding more work to clinicians who now not only have to take care of patients, but in the unregulated health IT market need to (as if they don't already have enough work to do in the ED where chaos often occurs) babysit computer glitches as well - and pray they catch potential computer errors 100% of the time.

Below is the FDA MAUDE recall notice at "Medical & Radiation Emitting Device Recalls", from http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRes/res.cfm?ID=119832.

At this additional link we find that this FDA recall was "Voluntary: Firm Initiated."  They apparently informed the FDA of the "glitch."

My question is - how did the company become aware of this "glitch"?  Also, were any patients put in harm's way, or injured, as a result of the prescription data loss?

FDA Device Recall Notice.  Click to enlarge; text below.

Class 2 Recall ED PulseCheck

Date Posted	July 29, 2013
Recall Number	Z-1814-2013
Product	Picis ED Pulsecheck - EMR Software Application - 2125, Software Versions: 5.2 and 5.3. The application stores patient information in a database, and it may analyze and/or display the data in different formats for evaluation by healthcare professionals for informational purposes.
Code Information	Software Versions 5.2 and 5.3
Recalling Firm/ Manufacturer	Picis Inc. 100 Quannapowitt Parkway Suite 405 Wakefield, Massachusetts 01880
For Additional Information Contact	Support Representative 781-557-3000
Reason for Recall	Notes associated with prescription are not printed to the prescription or to the patient chart.
Action	Initial customer notifications were sent via email on June 21, 2013 informing consignees of the recall and providing further instruction regarding the software solution. Consignees were provided with recommended actions until they receive the necessary update.
Quantity in Commerce	35
Distribution	Nationwide Distribution, including the states of: AK, AR, AZ, CA, CO, DC, DE, FL, GA, ID, IN, MA, MD, MO, NH, NJ, OH, OR, SC, TN, WA, and WV.

Finally, I ask - how did this "glitch" escape the notice of the company before the software was put into production not in just one, but through two sequential versions?

I propose that the lack of health IT regulatory controls due to special accommodation makes thorough software testing less "desirable" by a company (largely due to costs).

Compare that to, say, software regulation in the Federal Aviation Administration:

FAA Aircraft Software Approval Guidelines - available at http://www.faa.gov/documentLibrary/media/Order/8110.49%20Chg%201.pdf.  Click to access.

The FAA document begins:

"This order establishes procedures for evaluating and approving aircraft software and changes to appropriate approved aircraft software procedures."

Software regulation in other mission critical industries like aviation and pharma make the health IT industry and its lack of regulation look pathetic.


-- SS

Today's Bad Health IT Systems: More Dangerous Than Paper?

I believe in 2013 that they are.

(Definition of bad health IT is here:  http://www.ischool.drexel.edu/faculty/ssilverstein/cases/)

I recently posted about two "glitches" in a major EHR seller's clinical systems, Siemens Healthcare, affecting safety-critical functions of medication reconciliation and medication ordering.

• Another Health IT "Glitch" - Can Digital Disappearing Ink Kill Patients?

• Can Digital Disappearing Ink (An EHR "Glitch") Kill Patients? Part 2

Considering these, plus the many "glitches" reported by the only EHR seller who does so via FDA's MAUDE database (see here: http://hcrenewal.blogspot.com/2011/01/maude-and-hit-risk-mother-mary-what-in.html), and the others posted at this blog at query link: http://hcrenewal.blogspot.com/search/label/glitch, the following issue needs serious consideration by policymakers.

Namely, the issue that enterprise electronic medical command-and-control systems, which today's "EHRs" in reality are, are on their face more risk-prone than the paper systems they are replacing.

The "glitches" reported above are clearly the tip of the iceberg due to industry norms of secrecy, the absence of most of the industry in reporting to FDA MAUDE or anywhere, and my limited sources of information.  It is likely the true level of "glitches" in live EHR/clinical IT installations is far, far higher  - conservatively, I believe, at least two orders of magnitude.

Workarounds to IT "glitches" such as recommended in the Siemens bulletins at the aforementioned posts cause hospital officials to have to  reliably get the notices to all users of the systems, including medical students, nurses, physicians and allied health professionals.

The workarounds also cause users to:

1)  have to deviate from habits of use acquired in training and active use of the systems in question;
2) remember, without fail, to deviate from habits of use acquired in training and active use of the systems in question, in effect giving them the responsibility of caring for sick patients and for "sick" information technology;
3) keep in mind any other extant workarounds that exist waiting for "fixes"; and
4) be constantly on guard for information storage failures.

In fact, the recent Siemens "glitches" and workarounds represent a clear danger to patient safety.  If these were more conventional medical devices, they'd be recalled.

See my Dec. 14, 2011 post "FDA Recalls Draeger Health IT Device Because This Product May Cause Serious Adverse Health Consequences, Including Death" (http://hcrenewal.blogspot.com/2011/12/fda-recalls-health-it-software-because.html) and July 23, 2012 post "Health IT FDA Recall: Philips Xcelera Connect - Incomplete Information Arriving From Other Systems"(http://hcrenewal.blogspot.com/2012/07/health-it-fda-recall-philips-xcelera.html) for examples where health IT defects similar to the Siemens issues were, in fact, recalled.

Further, with paper records or tangible images, a page or image can be lost, or it can be illegible.  In the case of lost, in any quality paper record keeping system the information stewards or others using the paper (e.g., office staff or ward clerks) will generally note the absence and act accordingly.  Further, illegible notes or orders will most often be recognized as illegible and result in attempted clarification or other corrective actions.

On the other hand, when electronic systems:

1)  lose modified information en masse as in the Siemens examples but keep the old, or
2)  when outright errors such as en masse truncation occur (as in the thousands of prescriptions whose long-acting suffixes were cut off at Lifespan in Rhode Island, see "Yet another health IT "glitch" affecting thousands" here: http://hcrenewal.blogspot.com/2011/11/lifespan-rhode-island-yet-another.html), or
3)  images are lost (see "Potential Image Loss in GE Centricity PACS" here:  http://hcrenewal.blogspot.com/2012/11/potential-image-loss-in-ge-centricity.html) without warning-

- There are no "flags" that the obsolete, truncated or missing information is erroneous.

What remains is perfectly legible, perfectly convincing and perfectly deceiving.

Electronic healthcare information systems on their face create more risk than paper record systems.  Further, the problem with "bugs" and "glitches" will not go away with today's industry models of "hiring down" and lack of regulation.  Every new upgrade or patch is suspect for introducing new bugs.

Paper does not suffer these issues, unless disappearing ink is used to cross out the old and add new information ...

Not that I am advocating for a return to 100% paper, but certain critical functions probably are best left to paper.  Further, hundreds of billions of dollars can certainly buy:

1)  a lot of Health Information Management professionals to perform continuous QA of paper,
2)  a lot of document imaging systems to make the paper records available anywhere, anytime they are needed, and
3)  a lot of data entry personnel to relieve clinicians of clerical burdens so they may use their valuable experience more productively, as guest poster Howard Brody points out at http://hcrenewal.blogspot.com/2013/07/guest-post-incompetent-management.html.
4)  a lot of sensible regulation of this industry's product quality.

-- SS

Medscape re: Class Action suit: "Doctors Who Sued EHR Company Win First Round"

Interesting article about a Class-Action lawsuit against a health IT seller, Allscripts, see Medscape link below (the story is copyrighted so I cannot repost it here).

Relevant excerpts:

On Monday, March 4, a group of doctors who are suing their electronic health record (EHR) manufacturer for selling them a "buggy" product and then discontinuing it learned that the defendant's motion to block the lawsuit and compel them to accept binding arbitration was overruled by a judge in Miami, the first step in getting a court date in what is believed to be a first-of-its-kind case.

... In December 2012, 4 physician practices -- 2 pain clinics in Florida, 1 in Missouri, and a family medicine practice in Alabama -- became plaintiffs in a class-action suit filed against Allscripts, "an action arising from an expensive, but defective electronic health records software product," according to the complaint. The bottom line: The EHR was "buggy."

Says one of the doctors plaintiffs:

Anesthesiologist Robert J. Joseph, MD, of the Pain Clinic of Northwest Florida in Panama City, a plaintiff in the suit, makes no bones about it. "Our EHR is a piece of crap," he states.

-----

Link to full article:
http://www.medscape.com/viewarticle/779721

(It seems to come up fulltext without Medscape login, but I cannot guarantee this will persist.)

-- SS

Bad health IT and its effects on willingness of patients to share sensitive information

I call your attention to this video from the 2nd International Summit on the Future of Health Privacy where HC Renewal occasional contributor Dr. Scott Monteith, a psychiatrist, presents on how health IT damages the physician-patient relationship, the bedrock of good medicine, in one case via an inexcusable health IT defect.

The defect nearly cost a woman her good reputation - and her child - by "transforming" coffee drinking into solvent sniffing.

The video is here:  http://www.healthprivacysummit.org/events/2012-health-privacy-summit/custom-129-ec40d08a35f947e487f68a5f534a9e82.aspx

Dr. Monteith on how bad health IT damages trust.  See video at this link starting at 4:40.

Dr. Monteith starts at 4:40 when he is asked

"Do you feel HIT affects the willingness of patients to share sensitive information with providers?"

His answer is a definite "yes", and the video should be seen to understand his reasons, the largest one being the trust that is injured by this technology as currently (mal)implemented, failing to maintain privacy, data integrity, affecting doctor-patient interaction (e.g., due to poor usability), etc.

His two examples where HIT has injured trust, resulting in decreased willingness of patients to share sensitive information:

• A patient feared compromised privacy regarding psychiatric information (a fear that was certainly well-justified in view of ABC's recent expose of health IT breaches as I wrote about at my Sep. 14, 2012 post "A Reason to Refuse Use of EHR's in Your Health Care, and Demand Paper.")

• An error in EHR-generated record affecting a child custody battle, with a husband alleging unfitness of the mother due to substance abuse.  The EHR incorrectly showed a damaging diagnosis due to both a data mapping flaw (lumping multiple diagnoses under the same code) and a user interface flaw (permitting all of the diagnoses lumped under that code to not be seen, only the worst one) that transformed caffeine (i.e., coffee) overuse to "inhalant abuse."  

Stunningly, Dr. Monteith reported the error was not remediated even after several years.

As seen by the voluntary reports submitted by one of many HIT sellers (link), the only one that seems to do so, and some involuntary ones such as at this link, these issues are just the "tip of the iceberg." That exact phrase was uttered by a senior FDA official himself, reflecting known severe impediments to information diffusion on harms, as I reported at this link.

Yet the government (e.g., HHS's Office of the National Coordinator for Health Information Technology, ONC) and IT industry push this technology like candy, emphasizing largely unproven benefits and completely ignoring downsides such as damaged trust, damaged reputations that could have cost a woman custody of her child, and damaged bodies.

A video of an attorney personally affected by these issues is at this link:   http://www.healthprivacysummit.org/events/2012-health-privacy-summit/custom-137-ec40d08a35f947e487f68a5f534a9e82.aspx

-- SS

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