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