Showing posts with label MAUDE. Show all posts
Showing posts with label MAUDE. Show all posts

Saturday, October 6, 2012

Healthcare IT Transparency Could Stand Some Improvement

Transparency in the health IT sector is akin to the transparency of Pb (lead).

The following report comes from the FDA Maude (Manufacturer and User Facility Device Experience) voluntary-reporting database, reported by a (likely unhappy) biomedical engineer a month after the "incident" - the nature of which is deliberately kept hidden.  This is regarding the PICIS "Pulsecheck" EHR for emergency departments:

Report Date     05/14/2010

PICIS INC. CARESUITE ED PULSECHECK S/W, TRANSMISSION & STORAGE PATIENT DATA
Event Type:  Other
Patient Outcome:  Required Intervention

Event Description

The customer has reported a patient incident that has prompted a review of their internal process and possible issues surrounding the incident. The customer report alleges the involvement of picis' ed (emergency dept. ) electronic health record application, whereby, duplicate results were received by the picis ehr application from an enterprise info system, which, when displayed in their entirety may have contributed to some degree of confusion for the treating physician - the context of which the customer has declined to clarify any further.  [What in the world? -ed.] At this time, we have been informed by the customer that they are restricted by senior leadership from disclosing any specific details regarding the patient's status, the specific type of result or evidence of application performance to support picis' investigation.

"Restricted by senior leadership from disclosing any specific details regarding the patient's status, the specific type of result or evidence of application performance to support Picis' investigation?"

That is perverse on its face, and probably in violation of Joint Commission safety standards on reporting of incidents that could affect other organizations.


Manufacturer Narrative

Picis' investigation into the reported incident is based on a limited exchange of info with the customer, as well as our internal review of the application design and current configuration in use at the reporting site. Review of configuration files, existing system build at the client site, interface specification documents and previous customer communications demonstrate that the customer implemented and accepted the picis edis in 2008. During this process, the picis edis system was configured to display all results sent from the customer's enterprise system rather than configuring the results display in 'overwrite' mode. Prior to acceptance, an investigation by picis and the client revealed that it was the sending system, sending multiple duplicate results messages [great quality - ed.] and a request was made by the customer of that enterprise vendor [I can only wonder who that was - ed.] to investigate. However, due to the enterprise system's protocol for 'add on' tests, it was not possible to utilize the 'overwrite' configuration due to the risk of filtering out unique results and subsequently not presenting the clinicians with important info. Therefore, the customer elected to have all results displayed.

A workaround that apparently, from the limited information provided, led to physician confusion..."the context of which the customer had", not very helpfully, "declined to clarify any further."

Hospitals also are required to have add'l safeguards in place for the handling of critical results including expedited reporting of critical results with a licensed responsible caregiver rather than relying solely on standard results reporting processes (joint commission national patient safety goal 02. 03. 01).

This is not a resounding statement of confidence in health IT...

The customer is currently working with a 3rd party integration consultant to improve the handling of results sent to picis' electronic health record application. We are providing support as it is requested. At this time, no corrective action is needed. 

The "senior leadership" that withheld details was protecting what, exactly?  Money and contracts, perhaps; conflicts of interest, possibly ... but not patients.

All I can say is:

Imagine if this was a report on a new drug suspected of harming people. 

What in heaven's name was going on here?

As I've written many times, and as illustrated by this MAUDE report, the health IT industry must first be transformed into one of evidence-driven IT practices and transparency before anyone touting its products has any business even speaking about the technology "transforming medicine."

-- SS

Wednesday, October 3, 2012

Honesty and Good Sense on Electronic Medical Records From Down Under

Australians seem to not be as seduced by the Siren Song of cybernetic miracles as health IT leaders in the United States.

It took an Australian computer scientist at U. Sydney to dissect and perform a detailed analysis of the internals of an American EHR system, the results of which were disturbing to say the least.  This was a task the American members of the American Medical Informatics Association (AMIA) should have taken on.  It's not as if they're unaware of clinical IT problems.

It also seems to take a group of Australian researchers at the Univ. of New South Wales, the Australian Patient Safety Foundation, and the University of South Australia to perform a forensic analysis on U.S. data in the FDA's Manufacturer and User Facility Device Experience (MAUDE) database, instead of Americans themselves. 

At least AMIA allowed the Australians the opportunuty to present their findings.

In "Patient Safety Problems Associated with Heathcare Information Technology: an Analysis of Adverse Events Reported to the US Food and Drug Administration" (free fulltext at this link), AMIA Annual Symposium Proceedings 2011;2011:853-7 the Australian researchers including Medical Informaticist and critical thinker Dr. Enrico Coiera (see here) analyzed healthcare information technology (HIT) events associated with patient harm submitted to the MAUDE database:

We downloaded all 899,768 reports that were submitted to MAUDE from January 2008 to July 2010 and searched for events using a broad definition of HIT as “hardware or software that is used to electronically create, maintain, analyse, store, receive, or otherwise aid in the diagnosis, cure, mitigation, treatment, or prevention of disease, and that is not an integral part of (1) an implantable device or (2) medical equipment.” We retrieved and classified 678 reports describing 436 unique events using a previously published methodology. Of the 436 HIT-related events that we examined, 11% (n=46) were associated with patient harm [this excludes the "near misses" - ed.] ... In this paper we specifically focus on examining the 46 events where HIT problems were associated with patient harm.

These submissions are voluntary, and due to systematic, severe impediments to submissions as below, this data likely represents a very small fraction ("tip of the iceberg" per FDA itself, link) of the true incidence of these events.  See the addendum to this post "Systematic impediments to voluntary reporting of health IT risks."

Summarizing the Australian researchers' findings (read the entire paper at the link above):


Medication problems represented 41% of the events of these types:

  • Wrong patient
  • Wrong dose or overdose
  • Missed and delayed doses

Clinical process problems
represented 33% of the events:
  • Use errors in entering information ("use error" is an error due to poor and confusing design, as opposed to "user errors")
  • Poor functionality of CPOE and PACS

Exposure to radiation occurred in 15% of the events

Surgery problems occurred in 11% of the events.

The authors recommended that "strategies to improve the safety of HIT should focus on designing safe user interfaces, integrated checks of key identifiers and decision support, and engineering safer clinical processes."

Unfortunately, that does not appear to be occurring in the U.S. to any significant degree.  "Certification" of health IT to meet government criteria for financial incentives is unrelated to such measures and is in my view symptomatic of industry regulatory capture (see here and here).  The IOM itself has instituted a "watch and wait" policy, a likely unique special accommodation in current regulation of medical devices (see here).

I reiterate this MAUDE data is voluntary and the impediments to its reporting systematic and severe.  See addendum to this post.

In the category of good sense on electronic medical records, I note the following articles:

Victoria aims for more open ICT strategy 

Pulse+IT Magazine
Kate McDonald
02 October 2012

The newly formed Victorian Information and Communications Technology Advisory Committee (VITAC) has released a draft strategy (PDF) describing how the state government should manage and use ICT to better provide government services.

The strategy recommends that the government engage more closely with the ICT sector and move away from customised products in favour of existing market offerings.

... It recommends that the government engage with the ICT market early in the procurement lifecycle. “We will avoid being locked into single suppliers by favouring open standards and will be open to any qualified ICT provider regardless of size. Procurement of ICT services will be made more efficient.”

The strategy should also provide guidance to agencies to move away from customised major ICT developments and use existing market offerings with little or no customisation instead.

What this means is abandoning the approach of large, single-source (monolithic), proprietary clinical information systems from large health IT vendors that try to cover everything, in favor of smaller, open standards-based "best-of-breed" applications (from vendors of all sizes) that can be woven together to meet users' needs:

The subsequent fallout from the Ombudsman's report led to the Victorian government cancelling several programs, including the $323 million HealthSMART program, an ambitious project to roll out common eHealth infrastructure throughout Victoria's public health services.

This included implementing iSOFT's (now CSC) i.PM patient administration system and Cerner's clinical information system in its hospitals, as well as InterSystems' TrakCare platform for community health agencies.

I note that another article in eHealth Insider mentions the same strategy in the UK, "Winchester switches off Cerner in ED":

The Royal Hampshire County Hospital in Winchester has switched off Cerner Millennium in A&E and moved to Patient First.  The electronic patient record system will also be switched off for theatres and order communications at the old Winchester and Eastleigh Healthcare NHS Trust ... Basingstoke and North Hampshire was pursuing an alternative IT strategy, built around a 'best of breed' approach to building on its existing systems.

The U.S. has yet to learn these lessons, and will likely repeat the same mistakes at the cost of hundreds of billions of dollars.

Unfortunately, I have no answers.  I see no way to avoid it, considering the HITECH momentum that favors the large-vendor monolithic product model.

-- SS

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

Addendum.  Systematic impediments to voluntary reporting of health IT risks:

From the 2010 FDA internal memo on health IT risks:

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.

From the 2012 IOM report on health IT 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. These barriers to generating evidence pose unacceptable risks to safety.
… “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.”

Not knowing the magnitude of the risks is an effect of the impediments, and does not represent a good environment for national implementation in my view.

I also add "fear of medical malpractice litigation" to the lists above.

-- SS

Wednesday, December 14, 2011

The EHR Mission Hostile User Experience, Part 10: Cerner Powerchart - via FDA's MAUDE Database

"You should not have to work around something that is not in the way" - SS

Some time ago, I'd written an eight part (later expanded to nine part) series on health IT mission hostile user interfaces and experiences.

(Note: Part 1 of this series is here, part 2 is here, part 3 is here, part 4 is here, part 5 is here, part 6 is here, part 7 is here, and part 8 is here. 2011 addendums: a post that can be considered part 9 is here, part 10 is here.)

Here is an addendum, part 10, from the FDA Maude (Manufacturer and User Facility Device Experience) Database. I do not know who wrote it or where it was from. It was received by FDA as indicated on 3 April 2011:


FDA MAUDE REPORT

CERNER POWERCHART

Event Type Other

Event Description

I am writing to report a problem in the design of the cerner powerchart computer provider order entry (cpoe) product. As i will describe below, these design flaws are largely responsible for approximately 100 medication errors per day in our 240 bed hosp. The (b)(6) hosp in (b)(6) is a 240 bed teaching hosp. We are owned by the (b)(6). We have to be one of the only hospitals in the country to fully implement cpoe with two entirely different electronic medical records (emr).

In 2007, we completed a comprehensive cpoe implementation using idx 3. 1 (which was later purchased by general electric). Our self-reported medication error rate was <2 error reports per day. In (b)(6) of 2010, we transitioned our emr to cerner millennium - powerchart (b)(4). This implementation was done as a first step to converge onto a single electronic medical record across the (b)(6) enterprise.

Despite extensive nursing informatics support (approx. 7000 hrs per month for the first six months after implementation), our error rate went from approx. 176 medication errors per day one month after implementation to approx. 100 medication errors per day currently. It has been stable at this level for at least the past 3 months. Many of these errors involve high risk medications (e. G. Heparin, morphine). In order to understand the etiology of the errors, i need to explain how cerner processes cpoe orders.

With cerner, orders are grouped into plans ("powerplans"). These plans can include sub-plans ("phases") and sub-sub-plans ("sub phases"). A typical orders display screen appears as follows: (b)(4). Under the plans is an order tab which displays other orders.

This design allows two distinct sources of error.

First, there is no consistent way to view orders for medications. A medication order can display either in a plan, sub-plan, or under the orders tab. In order to find a given medication, cerner mandates that you click through each and every plan. This facilitates duplication of both medication and non-medication orders (there is a medication checker which is so poorly designed and does little to aid the pharmacists in detecting duplicate medications).

Second and more dangerous, high risk intravenous medications can be run either inside or outside of the plan. Cerner programming [i.e., the user interface design -ed.] does not keep high risk medications in a consistent spot. It is very easy to stop monitoring for heparin (which is included in the heparin plan) while continuing the heparin (which is outside the plan) or vice-versa.

As you can probably guess, we formed multiple interdisciplinary teams to address these deficiencies.
[Workarounds - ed.]

I was the lead physician on the orders team. Although we were unable to reduce the error rate, it is not close to an acceptable level. Again, i believe this is because of the design of the cerner product which is why i chose to bring this to your attention. With issues this complex, i am a firm believer that "seeing is believing. " if desired, i would be happy to arrange a web conference to demonstrate my concerns.

Brand Name CERNER POWERCHART COMPUTER
Type of Device NONE
Manufacturer (Section F) CERNER
Manufacturer (Section D) CERNER
Device Event Key 2081342
MDR Report Key 2045867
Event Key 1942844
Report NumberMW5020161
Device Sequence Number 1
Product Code LNX
Report Source Voluntary
Reporter Occupation Other
Type of Report Initial
1 Device Was Involved in the Event
1 Patient Was Involved in the Event
Date FDA Received 04/03/2011
Is This An Adverse Event Report? No
Is This A Product Problem Report? No
Device Operator Service Personnel
Was The Report Sent To Manufacturer? No
Is the Device an Implant? No
Is this an Explanted Device?
Page Last Updated: 11/30/2011

I will let the FDA report speak for itself, with only one question:

When will the designers, developers, purchasers and implementers of medical devices like this start to be held criminally liable for patient injuries that occur from the risk these devices pose to patient safety?

criminal negligence - (law) recklessly acting without reasonable caution and putting another person at risk of injury or death (or failing to do something with the same consequences)

It's not as if the issues related to good user interface design are a mystery, nor have those issues been a mystery for at least a few decades.

An EHR design as described, if accurate, while perhaps "nifty" in some way from the computer-techie perspective, would require significant recklessness to design and to actually implement in a life-critical setting.

Those who try to point out these issues internally are sometimes subject to retaliation (for not being a "team player", of course, which in today's parlance means someone who is silent, or silenced, or a co-conspirator regarding managerial mediocrity, malfeasance, or madness). An example is here. We at Healthcare Renewal simply refuse membership on that team.

(Did I mention this deterministic miracle-making technology is slated via the HITECH Act for rollout in the U.S., unless the medical professional or organization is willing to accept progressive cuts to their Medicare reimbursement?)

-- SS