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

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