FDA on health IT risk: reckless, or another GM-like political coverup? "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."

In my Sept. 16, 2013 post "An Open Letter to David Bates, MD, Chair, ONC FDASIA Health IT Policy Committee on Recommendations Against Premarket Testing and Validation of Health IT" (http://hcrenewal.blogspot.com/2013/09/an-open-letter-to-david-bates-md-chair.html) I wrote:

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.

The resultant April 2014 report is out: "FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework."  It is available at http://www.healthit.gov/sites/default/files/fdasiahealthitreport_final.pdf.

The report is an academic idealist's and industry's dream.  It is a patient's nightmare.

Instead of regulation, the report recommends the creation of a nebulous "Health IT Safety Center" (pgs. 16 and 25) as a "public-private entity with broad stakeholder engagement, that includes a governance structure for the creation of a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing and ongoing efforts."  In other words, a toothless organization without true regulatory authority.

The recommendations of the Health IT Policy Committee have apparently been taken seriously by FDA. 

This FDA announcement recently appeared (FDA is part of HHS):

http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm390988.htm

HHS News Release
For Immediate Release: April 3, 2014

Proposed health IT strategy aims to promote innovation, protect patients, and avoid regulatory duplication

HHS today released a draft report that includes a proposed strategy and recommendations for a health information technology (health IT) framework, which promotes product innovation while maintaining appropriate patient protections and avoiding regulatory duplication. The congressionally mandated report was developed in consultation with health IT experts and consumer representatives and proposes to clarify oversight of health IT products based on a product’s function and the potential risk to patients who use it.

... As proposed in the draft report, posted on the ONC, FDA and FCC websites, there would be three health IT categories, based on function and level of risk, that focus on what the product does, not on the platform on which it operates (mobile medical device, PC, or cloud-based, for example).

The first category, products with administrative health IT functions, poses little or no risk to patient safety and as such requires no additional oversight. They include software for billing and claims processing, scheduling, and practice and inventory management.

The second category, products with health management heath IT functions, includes software for health information and data management, medication management, provider order entry, knowledge management, electronic access to clinical results and most clinical decision support software.

Products with health management health IT functions are of sufficiently low risk and thus, if they meet the statutory definition of a medical device, FDA does not intend to focus its oversight on them. Instead, the draft report proposes relying primarily on ONC-coordinated activities and private sector capabilities that highlight quality management principles, industry standards and best practices.

The characterization of these admitted medical devices as "sufficiently low risk" is in my opinion grossly negligent.

For instance, GM concealed an ignition flaw that resulted in 13 deaths.  Look what's happening now in that sector.  Revelations of corporate wrongdoing and Congressional investigations:

http://www.nytimes.com/2014/03/31/business/us-regulators-declined-full-inquiry-into-gm-ignition-flaws-memo-shows.html

U.S. Agency Knew About G.M. Flaw but Did Not Act
By MATTHEW L. WALD
MARCH 30, 2014

Federal regulators decided not to open an inquiry on the ignitions of Chevrolet Cobalts and other cars even after their own investigators reported in 2007 that they knew of four fatal crashes, 29 complaints and 14 other reports that showed the problem disabled air bags, according to a memo released by a House subcommittee on Sunday.

Then in 2010, the safety agency came to the same decision after receiving more reports that air bags were not deploying.

The memo also revealed that General Motors approved the faulty design of the switch in 2002 even though the company that made the part, Delphi, warned the automaker that the switch did not meet specifications. This followed a warning the year before — when the Saturn Ion was being developed — but G.M. said that “a design change had solved the problem,” according to the memo.
Continue reading the main story
Related Coverage

The striking new details in the memo bolster the contention that both G.M. and the National Highway Traffic Safety Administration, more than previously acknowledged, ignored or dismissed warnings for more than a decade about a faulty ignition switch that, if bumped, could turn off, shutting the engine and disabling the air bags. General Motors has recalled nearly 2.6 million cars and has linked 13 deaths to the defect.

13 deaths, and we get this:

A House subcommittee, which gathered more than 200,000 pages of documents from G.M. and 6,000 pages from the agency, will hold a hearing on Tuesday. Mary T. Barra, General Motors’ chief executive, and David Friedman, the acting administrator of the safety agency, are scheduled to testify. Both are also scheduled to testify before a Senate panel on Wednesday.

“The problems persisted over a decade, the red flags were many, and yet those responsible failed to connect the dots,” Fred Upton, a Republican of Michigan and the chairman of the House Energy and Commerce Committee, said in a statement.

The most damaging finding in the memo concerned the four fatal crashes that went unheeded by regulators.

In a presentation dated Nov. 17, 2007, the safety agency’s investigators reported to its Office of Defects Investigation on the fatal crashes, as well as broad range of complaints and other reports about cars shutting off.

“The panel did not identify any discernible trend and decided not to pursue a more formal investigation,” the House memo said. The findings reinforce an analysis by The New York Times published March 8 that found the agency had received more than 260 complaints about Cobalts, Ions and other cars in the recall, citing potentially dangerous shutdowns.

While GM is being grilled and raked over the coals, the health IT industry is likely going to get the healthcare industry's most generous and unprecedented special regulatory accommodation by FDA due to its products being deemed of "sufficiently low risk" (?) not to merit attention.

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

The FDA statement is particularly reckless (or worse) given the following points.

I add that the following are just highlights off the top of my head, and non-inclusive of all known facts on health IT risk:

(1)  FDA's own 2010 "Internal Memo on HIT Risk", "not intended for public use" but exposed by Center for Public Integrity investigative reporter Fred Schulte (http://www.publicintegrity.org/authors/fred-schulte) when he was with the Huffington Post Investigative Fund (as described at http://hcrenewal.blogspot.com/2010/08/smoking-gun-internal-fda-memorandum-of.html), stated:
 

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

They then go on to categorize the known risk factors and the impediments to knowing about their occurrence: 

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

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

In other words, FDA does not know the level of risk due to systematic impediments to information diffusion.

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

I think it axiomatic to state that it is, at best, seriously misleading to now state a technology is of "low risk" while internally having admitted that the risk level is not known due to impediments to that knowledge.  That situation has not changed since this memo's internal FDA dissemination, and its disclosure by Schulte.

This is inexplicable on its face on scientific grounds.

Further, another HHS agency, the Agency for Healthcare Research and Quality (AHRQ, http://www.ahrq.gov/) has also taxonomized in detail a rich tapestry of "how health IT can cause harm."  See "AHRQ Health IT Hazards Manager Report" at http://healthit.ahrq.gov/sites/default/files/docs/citation/HealthITHazardManagerFinalReport.pdf and its contained list of harms on pg. 29, reproduced below.

AHRQ has no regulatory authority.  These failure modes are expensive to deal with, thus many will likely only be dealt with by the industry (if at all) after patient harms or near-misses.  Patients, however, are not experimental subjects for the debugging and "improvement" of experimental IT systems.

AHRQ Health IT Hazard Manager Report - Hazard Modes of Health IT (click to enlarge)

Surely FDASIA is aware of this.

(2)  FDA CDRH Director Jeff Shuren MD, JD's own statement that the known risks are "the tip of an iceberg" at the HIT Policy Committee, Adoption/Certification Workgroup on February 25, 2010, where the topic was "HIT safety" (The text is available at this link):

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

Considering the admitted impediments to information diffusion, it's likely even at this point that FDA knew the number of injuries and deaths was far larger than GM's mere 13 ignition defect-related deaths.

(3)   FDA's MAUDE (Manufacturer and User Facility Device Experience) database is a voluntary medical device defects reporting system, but is not specifically purposed for health IT and is almost unknown to typical health IT users as a resource for reporting flaws. 

MAUDE reports show health IT devices are literally festooned with an incredible number of flaws, as if they come from dirt-floor-covered software sweatshops with little oversight.

These are defects that have made it into live hospital and caregiver devices, and have led to reported harms and death (see http://hcrenewal.blogspot.com/2011/01/maude-and-hit-risk-mother-mary-what-in.html).

The voluntary nature of this MAUDE reporting by just a few HIT sellers, and lack of knowledge of it by health IT users as a resource, cannot fail to lead to the conclusion that the problems are far worse than this limited dataset indicates.

(4)  The prestigious U.S. Institute of Medicine of the National Academies (http://www.iom.edu/), perhaps the top scientific authority in this country, also admitted the risk levels of health IT were unknown due to systematic impediments to knowing.  IOM noted this in their late 2011 study on EHR safety:

... While some studies suggest improvements in patient safety can be made, others have found no effect. Instances of health IT–associated harm have been reported. However, little published evidence could be found quantifying the magnitude of the risk.

Several reasons health IT–related safety data are lacking include the absence of measures and a central repository (or linkages among decentralized repositories) to collect, analyze, and act on information related to safety of this technology. Another impediment to gathering safety data is contractual barriers (e.g., nondisclosure, confidentiality clauses) that can prevent users from sharing information about health IT–related adverse events. These barriers limit users’ abilities to share knowledge of risk-prone user interfaces, for instance through screenshots and descriptions of potentially unsafe processes. In addition, some vendors include language in their sales contracts and escape responsibility for errors or defects in their software (i.e., “hold harmless clauses”). The committee believes these types of contractual restrictions limit transparency, which significantly contributes to the gaps in knowledge of health IT–related patient safety risks.

The IOM did note, contrary to FDA's current finding that these systems are of "sufficiently low risk", that:

These barriers to generating evidence pose unacceptable risks to safety.[IOM (Institute of Medicine). 2012. Health IT and Patient Safety: Building Safer Systems for Better Care (PDF). Washington, DC: The National Academies Press, pg. S-2.]

Also in the IOM report:

… “For example, the number of patients who receive the correct medication in hospitals increases when these hospitals implement well-planned, robust computerized prescribing mechanisms and use barcoding systems. But even in these instances, the ability to generalize the results across the health care system may be limited. For other products— including electronic health records, which are being employed with more and more frequency— some studies find improvements in patient safety, while other studies find no effect.

More worrisome, some case reports suggest that poorly designed health IT can create new hazards in the already complex delivery of care. Although the magnitude of the risk associated with health IT is not known, some examples illustrate the concerns. Dosing errors, failure to detect life-threatening illnesses, and delaying treatment due to poor human–computer interactions or loss of data have led to serious injury and death.”

IOM could not have stated the reality more explicitly than via their statement "the magnitude of the risk associated with health IT is not known."

(5)   Surely FDA (and the FDASIA committees responsible for the new Report) are aware of  the ECRI Institute's Deep Dive study results from a study they carried out within their PSO-member hospitals (http://hcrenewal.blogspot.com/2013/02/peering-underneath-icebergs-water-level.html).  I would call 171 voluntarily-reported health IT-related mishaps in 36 hospitals over 9 weeks, with 8 injuries and 3 possible deaths, an alarming study.

In fact, in 2014 based on their PSO data, the ECRI Institute identified health IT as #1 of the "Top Ten Technology Risks in Healthcare" (http://hcrenewal.blogspot.com/2014/04/in-ecri-institutes-new-2014-top-10.html):

CONCERN #1: Data integrity failures with health information technology systems 

With the federal government offering financial incentives for hospitals and physician practices to adopt EHR systems, use of these systems more than tripled from 2009 through 2012. “Health IT systems are very complex,” says James P. Keller, M.S., vice president, technology evaluation and safety, ECRI Institute. “They are managing a lot of information, and it’s easy to get something wrong” if the systems are not designed and implemented well. While appropriately designed and implemented systems can provide complete, current, and accurate patient care information so that the clinician can make appropriate treatment decisions, the presence of incorrect data can lead to incorrect treatment, potentially leading to patient harm.

Karen Zimmer, MD, medical director of the ECRI Institute, says the reports of so many types of errors and harm got the staff's attention in part because the program captured so many serious errors within just a nine-week project last spring.  The volume of errors in the voluntary reports was she says:

"an awareness raiser.  If we're seeing this much under a voluntary reporting program, we know this is just the tip of the iceberg; we know these events are very much underreported" (http://www.healthleadersmedia.com/print/TEC-290834/HIT-Errors-Tip-of-the-Iceberg-Says-ECRI).

I certainly would NOT aver that this technology's risk level is of "sufficiently low risk" to not warrant formal regulation by a body skilled in software regulation, as is FDA., e.g., for medical devices and for IT used in pharmaceutical clinical trials data management and drug manufacturing.

See for example "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" at http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm.

(I would really not enjoy being in a position to have to make such an averment about "sufficiently low risk" under GM ignition investigation-like conditions... )

(6)  Surely FDA (and the FDASIA committees responsible for the new Report) are aware of the data reported by the medical malpractice insurer CRICO, that insures the Harvard medical community (see http://hcrenewal.blogspot.com/2014/02/patient-safety-quality-healthcare.html):

... CRICO recently analyzed a year’s worth of medical malpractice claims in its comparative database [from numerous sources] and found 147 cases in which EHRs were a contributing factor. Computer systems that don’t “talk” to each other, test results that aren’t routed properly, and mistakes caused by faulty data entry or copying and pasting were among the EHR-related problems found in the claims, which represented $61 million in direct payments and legal expenses.  ... Half of the 147 cases resulted in severe injury.  [Death numbers are unstated - ed.]

Note that these numbers were an examination of lawsuits filed; most medical malpractice never gets to the point of an actual filed lawsuit due to the unfavorable economics of the medical malpractice industry.  Perhaps 5% of actual events ever get filed, thus CRICO's data is also a "tip of an iceberg."

(7)  Surely FDA (and the FDASIA committees responsible for the new Report) are aware of mass risk introduced by faulty systems such as in the incident in Rhode Island, at Lifespan Healthcare (http://hcrenewal.blogspot.com/2011/11/lifespan-rhode-island-yet-another.html), where thousands of prescriptions were altered by faulty HIT without physician knowledge.  Suffixes for the long acting version of a drug (e.g., "XL" or "XR") were dropped:

PROVIDENCE, R.I. (WPRI) - Rhode Island State Senator Jamie Doyle says he is shocked to hear a Lifespan computer glitch caused thousands of patients to receive the wrong types of medication. [Appx. 2,000 across five Lifespan hospitals according to the Providence Journal, see below, and the WaPo - ed.]

Doyle is now calling for an independent review of all the hospitals Lifespan runs, and a review of the Rhode Island Department of Health.

The DOH is investigating after learning patients who were supposed to receive medications taken once a day instead received medications meant to be taken more than once per day.  [In other words, they were taking short acting drugs on a long-acting once a day schedule, thus being massively under-dosed - ed.]

(8)  The FDA (and the FDASIA committees responsible for the new Report) surely cannot be unaware of all of the "glitches" reported on in-situ health IT systems, as cataloged at this blog under the tag "glitch" and as of this writing numbering 25 posts, some including patient deaths.  See the results of the query link: http://hcrenewal.blogspot.com/search/label/glitch.

(9) Surely FDA (and the FDASIA committees responsible for the new Report) cannot be unaware that FDA itself had to recall health IT with flaws "serious enough to cause patient death":

FDA recall.  McKesson Anesthesia Care – Patient Case Data May Not Match Patient Data:  Use of this affected product may cause serious adverse health consequences, including death. 
http://hcrenewal.blogspot.com/2014/03/ehr-recall-use-of-this-affected-product.html

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

FDA Recall: Philips Xcelera Connect - Incomplete Information Arriving From Other Systems
http://hcrenewal.blogspot.com/2012/07/health-it-fda-recall-philips-xcelera.html

FDA recall:  An ED EHR "Glitch" That Mangles Prescriptions
http://hcrenewal.blogspot.com/2013/08/a-good-way-to-cynernetically-harm-or.html

(10)  FDA (and the FDASIA committees responsible for the new Report) are surely not unaware of my own report to its MAUDE database (because the hospital denied my request to issue the report itself) of a fundamental defect in a widely used health IT system, Eclipsys Sunrise, that nearly caused the death of my mother... AFTER she was seriously injured due to a flaw in an ED's EHR that did lead a year later to her death:

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1729552

ECLIPSYS SUNRISE CLINICAL MANAGER      
Event Date 06/12/2010
Event Type  Injury   Patient Outcome  Hospitalization,Other,Life Threatening,Required Intervention
Event Description

The eclipsys sunrise clinical manager emr/cpoe is in use at (b) (6) hospital. This system appears to have a serious deficiency: an apparent lack of date constraint validity checking when users are seeking information on prior medication orders and administration. (b) (6), (b) (6) was admitted (b) (6) 2010, for cerebrovascular problems. Famotidine iv was started prophylactically to prevent gastric problems, but was discontinued and changed to protonix a few days later due to suspicion of causing severe agitation and confusion, causing her to pull her lines. Around (b) (6) 2010, patient was transferred to physical therapy floor in the hospital. Hospital considers such a transfer to be a "discharge" and "readmission. " however, patient did poorly, had to be sent back to med-surg floor several days later. Due to having pulled a percutaneous endoscopic gastrostomy tube -peg tube-, she was started on TPN on (b) (6) 2010. In the first bag of tpn solution was 40 mg. Famotidine. Patient's mental status began deteriorating and she began to get very, very agitated and confused once again. Eclipsys sunrise problem/bug was noted when son, a physician informaticist -and author of this report- noted the 40 mg famotidine in the tpn bag, and reported to the floor rn that this was contraindicated. The rn pulled up the medication order and administration records on the eclipsys sunrise clinical manager system to confirm famotidine had been administered previously. Famotidine was shown only as being ordered for tpn on (b) (6), but not prior. The rn selected a date constraint entry box, at which time a calendar widget popped up. The rn set the date constraint back to (b) (6), then (b) (6), then (b) (6) 2010, but the use of the famotidine at that time did not appear. Son of patient demanded the famotidine be stopped anyway, which it was, and that an allergy entry be entered. However, it was fortunate son was a physician and remembered the name of the medicine. In tracing this error today, it was found that the data from admission on (b) (6) to "discharge" to physical therapy floor (b) (6) 2010, was unavailable since it was considered a "prior admission" although the patient had never left the hospital physically. The sunrise system, however, failed to flag the (b) (6) 2010 date constraint entries as 'out of bounds' for the current admission. The validity of the date constraints was not checked, preventing the rn user from realizing he should have called up the prior admissions records. If son of patient had not been a physician, famotidine might have been continued and patient might have suffered more severe consequences than she did after the 40 mg was given in the first tpn bag. As it was, she spent the next three days in a severe delirium and is only slowly recovering. That the eclipsys sunrise ehr did not alert its user that the date constraints they set for seeking medication ordering and administration data were out of bounds -beyond the range of the current "admission" -is a significant and severe oversight and/or bg, and a danger to patients not fortunate enough to have a physician informaticist son closely monitoring their care.

Addendum May 4, 2014:

(11)   CMS: "we do not have any information that supports or refutes claims that a broader adoption of EHRs can save lives."  (But let's spend hundreds of billions of dollars anyway.)

CMS: "we do not have any information that supports or refutes claims that a broader adoption of EHRs can save lives."  [But let's spend hundreds of billions of dollars anyway.]  Click to enlarge.

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

Note that these ten points themselves, all I had time to write about this morning, themselves represent a "tip of the iceberg" regarding health IT risks.

In my opinion it's immensely reckless for FDA to make a statement that "products with health management heath IT functions, includes software for health information and data management, medication management, provider order entry, knowledge management, electronic access to clinical results and most clinical decision support software ... are of sufficiently low risk" so as to not warrant formal regulation that is already in place for other healthcare software sectors.

Fortunately, the public gets to comment via this announcement:

Proposed Risk-Based Regulatory Framework and Strategy for Health Information Technology Report; Notice to Public of Availability of the Report and Web Site Location; Request for Comments
http://www.regulations.gov/#!documentDetail;D=FDA_FRDOC_0001-4678

I feel, however, that the decision is a given, and that the health IT industry has such regulatory capture that public comments will be ignored.  (Not that I won't try.)

Finally:

I ponder what ever happened to the inquiry responses about health IT defects and harm sought by the Senate Finance Committee, as reported in the Washington Post:

Electronic medical records draw frequent criticisms
By Alexi Mostrous
Washington Post Staff Writer
Sunday, October 25, 2009

http://www.washingtonpost.com/wp-dyn/content/article/2009/10/24/AR2009102400967.html?hpid%3Dtopnews&sub=AR

... the Senate Finance Committee has amassed a thick file of testimony alleging serious computer flaws from doctors, patients and engineers unhappy with current systems.

On Oct. 16, the panel wrote to 10 major sellers of electronic record systems, demanding to know, for example, what steps they had taken to safeguard patients. "Every accountability measure ought to be used to track the stimulus money invested in health information technology," said Sen. Charles E. Grassley (Iowa), the panel's ranking Republican.

The results of that request seem to have gone to the recycle bin.

-- SS

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

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

Health IT FDA Recall: Philips Xcelera Connect - Incomplete Information Arriving From Other Systems

Another health IT FDA recall notice, this time on middleware, an interface engine that routes data:

Week of July 11

Product description:  

Philips Xcelera Connect, Software R2.1 L 1 SP2, an interface engine for data exchange [a specialized computer and accompanying software package - ed.]. Philips Xcelera Connect R2.x is a generic interface and data mapping engine between a Hospital Information System (HIS), Imaging Modalities, Xcelera PACS and Xcelera Cath Lab Manager (CLM). This interface engine simplifies the connection by serving as a central point for data exchange. The data consists only of demographic patient information, schedules, textual information and text reports.

Classification:  Class II

Reason For Recall	Xcelera Connect R2.1 L 1 SP2 , incomplete information arriving from unformatted reports interface

The data consists "only" of demographic patient information, schedules, textual information and text reports?

This is a dangerous fault mode, indeed.

"Incomplete information" moving between a hospital information system, imaging systems, a PACS system used to manage the images, and a cardiac cath lab can lead to very bad outcomes (and million dollar lawsuits), such as at "Babies' deaths spotlight safety risks linked to computerized systems", second example.

Note that the interface engine is in release 2.1, level 1, service pack 2.

In other words, a critical hardware/software product such as this undergoes constant tweaking (like Windows).

As a Class II device, at least the software is vetted to some degree by FDA:

Class II devices are those for which general controls alone are insufficient to assure safety and effectiveness, and existing methods are available to provide such assurances.^[8][10] In addition to complying with general controls, Class II devices are also subject to special controls.^[10] A few Class II devices are exempt from the premarket notification.^[10] Special controls may include special labeling requirements, mandatory performance standards and postmarket surveillance.^[10] Devices in Class II are held to a higher level of assurance than Class I devices, and are designed to perform as indicated without causing injury or harm to patient or user. Examples of Class II devices include powered wheelchairs, infusion pumps, and surgical drapes.^[8][10]

One wonders how testing of tweaks and updates to this product is done, if at all, other than on live and unsuspecting patients.

When you go into the hospital you are not just putting your life in the hands of the doctors and nurses, you're putting your life into the hands of computer geeks and software development experiments.

-- SS

July 25, 2012 Addendum:

The WSJ covered this here:  http://blogs.wsj.com/cio/2012/07/20/philips-recalls-flawed-patient-data-system/.  From their report:

... The problem that led to the recall: hitting the “enter” button, to start a new paragraph, in the summary field of heart test reports, sometimes caused the text entered below that point to be stripped from the report as it was transmitted into the patient’s electronic health record. And doctors later reviewing the patient’s electronic health record would not necessarily know they had received only part of the report, which could lead them to make “incorrect treatment decisions,” Philips said in a letter to hospitals.

...  Mike Davis, managing director at The Advisory Board Company, a healthcare research firm, says in the case of the Xcelera Connect, Philips should have caught the problem in testing. “How the hell does this get out? It shows there wasn’t good quality assurance processes in place.”

Indeed.

-- SS