healthy4u: MAUDE

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

I believe in 2013 that they are. (Definition of bad health IT is here:  <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/">http://www.ischool.drexel.edu/faculty/ssilverstein/cases/</a>) 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. <ul><li><a href="http://hcrenewal.blogspot.com/2013/08/another-health-it-glitch-can.html">Another Health IT "Glitch" - Can Digital Disappearing Ink Kill Patients?</a> </li></ul><ul><li><a href="http://hcrenewal.blogspot.com/2013/08/can-digital-disappearing-ink-ehr-glitch.html">Can Digital Disappearing Ink (An EHR "Glitch") Kill Patients? Part 2</a></li></ul> Considering these, plus the many "glitches" reported by the only EHR seller who does so via FDA's MAUDE database (see here: <a href="http://hcrenewal.blogspot.com/2011/01/maude-and-hit-risk-mother-mary-what-in.html">http://hcrenewal.blogspot.com/2011/01/maude-and-hit-risk-mother-mary-what-in.html</a>), and the others posted at this blog at query link: <a href="http://hcrenewal.blogspot.com/search/label/glitch">http://hcrenewal.blogspot.com/search/label/glitch</a>, 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" (<a href="http://hcrenewal.blogspot.com/2011/12/fda-recalls-health-it-software-because.html">http://hcrenewal.blogspot.com/2011/12/fda-recalls-health-it-software-because.html</a>) and July 23, 2012 post "Health IT FDA Recall: Philips Xcelera Connect - Incomplete Information Arriving From Other Systems"(<a href="http://hcrenewal.blogspot.com/2012/07/health-it-fda-recall-philips-xcelera.html">http://hcrenewal.blogspot.com/2012/07/health-it-fda-recall-philips-xcelera.html</a>) 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: <a href="http://hcrenewal.blogspot.com/2011/11/lifespan-rhode-island-yet-another.html">http://hcrenewal.blogspot.com/2011/11/lifespan-rhode-island-yet-another.html</a>), or 3)  images are lost (see "Potential Image Loss in GE Centricity PACS" here:  <a href="http://hcrenewal.blogspot.com/2012/11/potential-image-loss-in-ge-centricity.html">http://hcrenewal.blogspot.com/2012/11/potential-image-loss-in-ge-centricity.html</a>) 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 <a href="http://hcrenewal.blogspot.com/2013/07/guest-post-incompetent-management.html">http://hcrenewal.blogspot.com/2013/07/guest-post-incompetent-management.html</a>. 4)  a lot of sensible regulation of this industry's product quality. -- 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 recent...

Đọc thêm »

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 (<a class="l" href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm">Manufacturer and User Facility Device Experience</a>) 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 <a href="http://www.picis.com/solutions/emergency-department/ed-pulsecheck.aspx" target="_blank">PICIS "Pulsecheck" EHR</a> for emergency departments: <blockquote class="tr_bq"><a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1725683" target="_blank">Report Date     05/14/2010</a> 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.</blockquote> "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. <blockquote class="tr_bq">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. </blockquote> 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." <blockquote class="tr_bq">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).</blockquote> This is not a resounding statement of confidence in health IT... <blockquote class="tr_bq">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.  </blockquote> 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

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

Đọc thêm »

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 <a href="http://sydney.edu.au/engineering/it/~hitru/index.php?option=com_content&task=view&id=91&Itemid=146" target="_blank">disturbing to say the least</a>.  This was a task the American members of the American Medical Informatics Association (<a href="http://www.amia.org/" target="_blank">AMIA</a>) should have taken on.  It's not as if they're <a href="http://jamia.bmj.com/site/icons/amiajnl8946.pdf" target="_blank">unaware of clinical IT problems</a>. 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 (<a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm" target="_blank">MAUDE</a>) 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 <a href="http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3243129/" target="_blank">at this link</a>), AMIA Annual Symposium Proceedings 2011;2011:853-7 the Australian researchers including Medical Informaticist and critical thinker Dr. Enrico Coiera (see <a href="http://content.yudu.com/Library/A1xcz9/Pulse+ITMagazineJuly/resources/56.htm" target="_blank">here</a>) analyzed healthcare information technology (HIT) events associated with patient harm submitted to the MAUDE database: <blockquote class="tr_bq">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. </blockquote> 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, <a href="http://hcrenewal.blogspot.com/2010/02/fda-on-health-it-adverse-consequences.html" target="_blank">link</a>) 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): <blockquote class="tr_bq">Medication problems represented 41% of the events of these types: <ul><li>Wrong patient</li><li>Wrong dose or overdose</li><li>Missed and delayed doses</li></ul> Clinical process problems represented 33% of the events: <ul><li>Use errors in entering information ("use error" is an error due to poor and confusing design, as opposed to "user errors")</li><li>Poor functionality of CPOE and PACS</li></ul> Exposure to radiation occurred in 15% of the events Surgery problems occurred in 11% of the events.</blockquote> 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 <a href="http://hcrenewal.blogspot.com/2012/02/hospitals-and-doctors-use-health-it-at.html" target="_blank">here</a> and <a href="http://hcrenewal.blogspot.com/2012/09/from-what-i-can-tell-epic-was.html" target="_blank">here</a>).  The IOM itself has instituted a "watch and wait" policy, a likely unique special accommodation in current regulation of medical devices (see <a href="http://hcrenewal.blogspot.com/2011/11/iom-report-on-health-it-safety-nix-fda.html" target="_blank">here</a>). 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: <blockquote class="tr_bq"><a href="http://www.pulseitmagazine.com.au/index.php?option=com_content&view=article&id=1159:victoria-aims-for-more-open-ict-strategy&catid=16:australian-ehealth&Itemid=327" target="_blank">Victoria aims for more open ICT strategy</a>  Pulse+IT Magazine Kate McDonald 02 October 2012 The newly formed Victorian Information and Communications Technology Advisory Committee (VITAC) has released a <a href="http://www.vic.gov.au/ictstrategy/wp-content/uploads/2012/08/Victorian-ICT-Strategy-2012-Public-Consultation-Draft1.pdf" target="_blank">draft strategy (PDF)</a> 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.</blockquote> 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: <blockquote class="tr_bq">The subsequent fallout from the Ombudsman's report led to the Victorian government cancelling several programs, including the $323 million <a href="http://www.pulseitmagazine.com.au/index.php?option=com_content&view=article&id=1002:why-the-axe-fell-on-healthsmart&catid=16:australian-ehealth&Itemid=328" target="_blank">HealthSMART</a> program, an ambitious project to roll out common eHealth infrastructure throughout Victoria's public health services. This included implementing iSOFT's (now CSC) <a href="http://www.isofthealth.com/en-gb/Solutions/UK%20Patient%20Management/iPM.aspx" target="_blank">i.PM</a> patient administration system and <a href="http://www.cerner.com/" target="_blank">Cerner's</a> clinical information system in its hospitals, as well as <a href="http://www.intersystems.com/trakcare/" target="_blank">InterSystems' TrakCare</a> platform for community health agencies.</blockquote> I note that another article in eHealth Insider mentions the same strategy in the UK, "<a href="http://www.ehi.co.uk/news/ehi/8048" target="_blank">Winchester switches off Cerner in ED</a>": <blockquote class="tr_bq">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.</blockquote> The U.S. has yet to learn these lessons, and will likely <a href="http://hcrenewal.blogspot.com/2010/12/professors-at-harvard-and-nottingham.html" target="_blank">repeat the same mistakes</a> 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 <a href="http://hcrenewal.blogspot.com/2010/08/smoking-gun-internal-fda-memorandum-of.html" target="_blank">2010 FDA internal memo on health IT risks</a>: <blockquote class="tr_bq">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.</blockquote> From the <a href="http://hcrenewal.blogspot.com/2011/11/iom-report-on-health-it-safety-nix-fda.html" target="_blank">2012 IOM report on health IT safety</a>: <blockquote>... 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. </blockquote><blockquote>… “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.”</blockquote> 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

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

Đọc thêm »

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

<center style="font-weight: bold;">"You should not have to work around something that is not in the way" - SS</center> 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 <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-idiots-part-1.html">here</a>, part 2 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and.html">here</a>, part 3 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_24.html">here</a>, part 4 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_26.html">here</a>, part 5 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_27.html">here</a>, part 6 is <a href="http://hcrenewal.blogspot.com/2009/02/it-makes-healthcare-easier-is-this.html">here</a>, part 7 is <a href="http://hcrenewal.blogspot.com/2009/03/information-technology-makes-healthcare.html">here</a>, and part 8 is <a href="http://hcrenewal.blogspot.com/2009/03/malpractices-of-multitudes-mission.html">here</a>. 2011 addendums: a post that can be considered part 9 is <a href="http://hcrenewal.blogspot.com/2011/04/special-k-red-berries-mission-hostile.html">here</a>, part 10 is <a href="http://hcrenewal.blogspot.com/2011/12/ehr-mission-hostile-user-experience.html">here</a>.) Here is an addendum, part 10, from the FDA <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm" style="font-family: arial;">Maude</a> (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: <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=2045867" style="font-family: arial;"></a> <blockquote style="font-family: arial;">FDA MAUDE REPORT <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=2045867">CERNER POWERCHART </a> 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 </blockquote>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? <blockquote style="font-family: arial;"> <a href="http://www.thefreedictionary.com/criminal+negligence">criminal negligence</a> - (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)</blockquote> 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 <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=lawsuit">here</a>. 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

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

Đọc thêm »

MAUDE and HIT Risks: What in God's Name is Going on Here?

As I wrote at my last post "<a href="http://hcrenewal.blogspot.com/2011/01/healthcare-it-delirium.html" style="font-family: arial;">Healthcare IT Delirium</a>": <blockquote style="font-family: arial;">The field of health IT has become delirious. On top of an irrational exuberance (see <a href="http://hcrenewal.blogspot.com/search?q=irrational+exuberance">this blog query</a>) largely unsupported by the literature (e.g. <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=2009">here</a>), the technology is <a href="http://hcrenewal.blogspot.com/search/label/Healthcare%20IT%20experiment">experimental</a>, its rollout is a grand national experiment in social re-engineering of medicine, there is no patient <a href="http://hcrenewal.blogspot.com/2009/03/draft-patient-rights-statement-and.html">informed consent</a>, nobody is in control, and <a href="http://hcrenewal.blogspot.com/2010/02/fda-on-health-it-adverse-consequences.html">nobody is taking responsibility for regulating the domain</a> despite known risks. The results will very likely reflect the Wild West free-for-all that is now extant.</blockquote> It's worse. Some time ago I posted on a number of cases of health IT malfunction from the FDA's <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm">MAUDE</a> (Manufacturer and User Facility Device Experience) database of medical device risks. See posts on MAUDE <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=MAUDE">here</a> and <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=maude_death">here</a>. Center for Public Integrity Investigative reporter Fred Schulte had also written on the MAUDE reports and other "glitches" at a Nov. 2009 report "<a href="http://www.publicintegrity.org/2009/11/24/7011/switch-electronic-records-getting-mixed-reviews-hospitals-and-clinics" target="_blank">Switch to electronic records getting mixed reviews at hospitals and clinics</a>." <blockquote style="font-family: arial;">MAUDE data represents reports of adverse events involving medical devices. The data consists of voluntary reports since June 1993, user facility reports since 1991, distributor reports since 1993, and manufacturer reports since August 1996. MAUDE may not include reports made according to exemptions, variances, or alternative reporting requirements granted under 21 CFR 803.19. </blockquote> Either I missed a Titanic boatload of cases, or MAUDE has been appended since my posts, because MAUDE links such as <a href="http://google2.fda.gov/search?q=maude+cerner+millenium&x=8&y=7&client=FDAgov&site=FDAgov&lr=&proxystylesheet=FDAgov&output=xml_no_dtd&getfields=*&ie=UTF-8&access=p&sort=date%3AD%3AL%3Ad1&entqr=3&oe=UTF-8&ud=1&filter=0">this</a> , <a href="http://google2.fda.gov/search?q=Cerner+millenium&x=6&y=7&client=FDAgov&site=FDAgov&lr=&proxystylesheet=FDAgov&output=xml_no_dtd&getfields=*&ie=UTF-8&access=p&sort=date%3AD%3AL%3Ad1&entqr=3&oe=UTF-8&ud=1&filter=0&start=50">this</a> and <a href="http://google2.fda.gov/search?q=cerner+powerchart&x=19&y=18&client=FDAgov&site=FDAgov&lr=&proxystylesheet=FDAgov&output=xml_no_dtd&getfields=*&ie=UTF-8&access=p&sort=date%3AD%3AL%3Ad1&entqr=3&oe=UTF-8&ud=1&filter=0&start=30">this</a> are now returning a Mother Lode of cases, at least from one vendor where these events are reported (other vendors' products suffer similar problems). Examples just from light browsing cause the hair to stand up on my head (there are many, many more at the MAUDE links above):<a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1581240"></a> <blockquote face="arial"><a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1584195" style="font-family: arial;">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1584195</a> CERNER MILLENIUM CPOE, POWER CHART Event Type Injury Patient Outcome Life Threatening; Event Description The cpoe system serves and documents all transactions of communication pertaining to the patient's care. Orders are entered and delivered to an anticipated recipient and the action ordered is executed. The device-recipient interface has been unreliable with specific etiologies for failure not yet resolved or understood. Examples include orders to transfer patient from icu to a non-icu bed. Patient is moved to another bed but recipient care team does not receive communication and was not aware patient was under their charge. Patient had seizures on floor for hours throughout the night. Other patients had orders for lab tests, chemical tests on body fluids, cytological analysis of body fluids, cultures on body fluids, pathology on or specimen, and others that are not executed by the recipient, leaving the patient undiagnosed after having taken risks for a procedure. Such interface failures have been known by the vendor for years as reported by its own support team. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1581240">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1581240</a> CERNER MILLENIUM CPOE, POWERCHART Back to Search Results Event Type Injury Patient Outcome Life Threatening; Hospitalization Disability Event Description The displays, formats, layouts, and interfaces of the cpoe tools at this institution contain elevated degrees of user unfriendliness. This toxic effect on the user is manifested by, to mention a few, more than 20 electronic silos in which orders are stored and extensive wordiness using descriptors that are highly irrelevant to the task of the care of pts with critical illness. This manifests itself in several ways, one of which is the ordering of duplicate medications and treatments, some of which get to the pt. These should be reported to pharmacopoeia data bases but often are not. This pt was being infused both total parenteral nutrition and a concentrated dextrose solution, the combined rate of which and cumulative dose caused pulmonary edema. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1577753">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1577753</a> CERNER MILLENIUM CPOE Back to Search Results Event Type Injury Patient Outcome Life Threatening; Hospitalization Disability Event Description Stress test orders are ambiguous. An example of the order states "stress test adenosine/dobutamine w/imaging nm -stress test adenosine nm-". Order displays on 4 lines on the screen. The type of test that the doctor intended to be performed is unclear, resulting the risk of incorrect pharmacological modalities being used. This caused life threatening acute asthma attack in patient with background asthma who incorrectly received an infusion of adenosine. All patients ordered pharmacological stress tests become subject to said risk. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1578421"> http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1578421</a> CERNER MILLENIUM CPOE Back to Search Results Event Type Injury Patient Outcome Life Threatening; Other Event Description When a pt having been in the hospital preoperatively, begins its post-operative course in the recovery room or intensive care unit, post op orders are electronically entered by deleting the unneeded orders that have been active, leaving the orders that are still needed, and adding new ones. There can be upwards of 300 lines of "active" orders on a complicated pt. Precise and safe post-operative ordering requires a time consuming line by line review of each order, counter-intuitively canceling those that are not needed. This does not always occur for any number of reasons, not the least of which is that the task is time consuming and user-unfriendly. The incidence of commingling the pre and post op orders in a hospital with cpoe instruments of care is unk, but not uncommon. At least one pt was placed at risk when the clean post operative abdomen was irrigated based on the pre-op order. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1574909"> http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1574909</a> CERNER MILLENIUM CPOE Back to Search Results Event Type Injury Patient Outcome Life Threatening; Event Description This cpoe product allows doses to be ordered that are not a multiple-s- of the pill size. A representative example is 20mg atenolol po daily. Pill size is 25mg. This feature facilitates dosing errors and enables dangerously absurd dosing without warning. When the reports such dose having been given, the clinician is left to wonder, what dose was given, actually. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1570802">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1570802</a> CERNER MILLENIUM CPOE, POWER CHART Back to Search Results Event Date 07/11/2006 Event Type Injury Patient Outcome Life Threatening; Hospitalization Required Intervention Event Description Hospital wide breakdown of system of electric charts and electric order gadgets resulted in confusion, neglect, failed communications and delayed treatments in the days immediately following the surgery, leaving patient with permanent musculoskeletal disability and mental anguish. Breakdowns of this magnitude endanger hundreds of patients simultaneously. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1665473">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1665473</a> CERNER MILLENIUM CPOE, POWER CHART Back to Search Results Event Date 10/09/2006 Event Type Malfunction Patient Outcome Other; Event Description It has been discovered that the medication review screen consisting of a list of the medications on the left most column and a grid indicating the number of doses administered in each time period. The defect manifests itself in the representation of exactly what medication was administered. For pts who are taking two or more forms of the same pharmacological agent, eg nitroglycerin in the paste form, sub lingual form, and pill form, the name of the medication is represented as "nitroglycerin" on the list. The number of times it was administered is confusingly listed as a number in parentheses without clarity on which form of the medication was administered, creating confusion in the clinician and risk to the pt. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1726923">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1726923</a> CERNER MILLENIUM CPOE, POWER CHART Event Date 04/03/2010 Event Type Injury Patient Outcome Life Threatening; Other Event Description The computerized physician order entry instruments were deployed. Pleural fluid specimen were obtained. Chemical and cytological analysis was ordered on the specimen using the cpoe instruments. The specimen was not analyzed as ordered. Cytology results did not become available. Similar dysfunction appeared in more than 6 patients. The hospital has resorted to paper forms to clarify the dysfunction of this cpoe instrument. The patients may have cancer causing the fluid build up. This will not be known until time passes. There may be resultant delay in diagnosis of chest organ cancer. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1766892">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1766892</a> CERNER MILLENIUM CPOE Event Date 07/08/2010 Event Type Injury Patient Outcome Life Threatening; Event Description The active and active prn medication list had 7 potassium doses and routes, 2 tylenol doses and routes, 3 magnesium doses, 3 narcotic medications and doses, and 6 sodium chloride and sodium phosphate orders. The defects in the device and human factors at the interface enabled duplicate, triplicate, and more medications, enabling the nurse to potentially decide the treatment for this pt. The exact incidence of medication duplication from (b)(4) systems is unk, but common. </blockquote> Some examples of mere "malfunctions", again just from random browsing of the MAUDE data: <blockquote> <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=358222">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=358222</a> Model Number RELEASE 500 Event Date 10/03/2001 Event Type Malfunction Patient Outcome Other; Event Description Please see initial report. Event Description A user entered an order during the order entry process, with a frequency of every 8 hours and then used the ad hoc scheduling feature to modify the defaulted administration times for that frequency. After this was done, the user changed the frequency of the order to a 12-hour frequency without modifying the ad hoc administrations times. The software did not clear the previously entered ad hoc administration times to adjust to the default times for the new frequency. This resulted in a patient receiving a medications 3 times a day as opposed to 2 times a day. The drug was carbamazepene. This incorrect order frequency was repeated for 3 days, ultimately resulting in the patient receiving of total of 3 extra doses over a 3-day period (1 extra dose per day). On the fourth day, the nurse caring for the patient noticed the inconsistency in the order and conducted a further investigation with the pharmacist. The patient was discharged on time; no extended stay was necessary as a result of the overmedication. The patient's carbamazepene levels were checked during a follow-up visit that occurred 5 days after discharge, and were noted as normal at that time.<a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1365512">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1365512</a> Model Number 2007.01 - 2007.17 Event Date 12/30/2008 Event Type Malfunction Patient Outcome Other; Event Description The issue involves cerner millennium powerchart message center inox. When the results folder is filtered by event set and the event set display and event set name are different, result filtering may not function correctly. If the result filter is in message center and is an inclusive filter, results may be filtered out incorrectly. The impact associated with this issue is that patient care may be delayed or missed as follow-up may not occur. Cerner has not received communication on any adverse patient events as a result of this issue. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1247673">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1247673</a> Model Number 2007 Event Date 10/30/2008 Event Type Malfunction Manufacturer Narrative Cerner distributed a priority review flash notification on nov 13, 2008 to all potentially impacted client sites. The software notification includes a description of the issue and an interim workflow adjustment to prevent the malfunction. A software modification is being developed to address the issue for all sites that could be potentially impacted. Cerner corporation will provide a follow-up report when the software correction is available. Event Description This issue involves the overview with reminder functionality on powerchart and affects sites that use cerner millennium powerchart (powerchart. Exe). If a currently open pt chart is replaced with another pt chart, and reminders are subsequently viewed in the detail pane of this visit, the incorrect patient's reminder may de displayed. Pt care could be adversely affected, as clinical decisions could be based on the wrong pt info. Cerner has not received communication of any adverse pt events as a result of this issue. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1097561"> http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1097561</a> Model Number 2007.13 Event Date 06/30/2008 Event Type Malfunction Event Description The issue involves the task list functionality in carenet, and affects users that utilize the task list to view and document pt activities. When encounter security is turned on and the user documents an activity in task list, utilizing the previous or next arrows to select another pt chart, the single pt task list displays tasks for incorrect pt. Clinicians may view and document a pt's activity in another pt's record. Pt care may be affected as clinical decisions could be based on incomplete, invalid, or inappropriate info. Cerner has not received communication of an adverse pt event as a result of this issue. Cerner has distributed a priority review flash notification july 30, 2008, to all potentially impacted client sites. The software notification includes a description of the issue and an interim workflow adjustment to prevent the malfunction. A software modification is being developed to address the issue for all sites that could be potentially impacted. Cerner corporation will provide a follow-up report when the modification is available. Additional model #: 2007. 16. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1051313">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1051313</a> Model Number 2001 THROUGH 2007 Event Date 04/23/2008 Event Type Malfunction Manufacturer Narrative Cerner has distributed a priority review flash notification may 23, 2008 to all potentially impacted clients sites. The notification includes a description of the issue and an interim workflow adjustment to prevent the malfunction. User documentation is being updated to address the issue for all sites that could be potentially impacted. Cerner corporation will provide a follow-up report when the documentation is available. Event Description The issue involves the order entry formats in powerorders and affects sites that use powerorders and medication profile. When creating the volume dose detail in the order entry formats (oef), the strength order formats require the volume dose to have an "=" sign as a prefix label. Failure to adhere to this build can result in an inpatient prescription order converted to produce an outpatient prescription that may be misleading. This only occurs when the inpatient order used is verified with a pharmacy product and the formulation used does not exactly match the dose. A formulation factor of more or less than one is used to achieve the volume and the order is then converted to a prescription. For example, 500 mg = 1 tab or 250 mg times 2 tabs = 500 mg. Patient care could be adversely affected, as a patient could receive either more or less of a medication therapy than intended. Cerner has received communication of order discrepancies discovered during a chart review as a result of this issue. </blockquote>Again, there are many, many more examples like these in MAUDE, and I haven't even looked for data from other mfg's yet. My relative was nearly killed last year by this technology due to issues like these, the risks of which I've been writing about for more than ten years now. Alert to Sarah Palin: "Death panels?" Who needs death panels when technology like this is mediating our care and is planned for "urgent" national rollout with "meaningful use" rules and Medicare-penalty extortion - er, gentle coercion - directed towards healthcare organizations and clinicians? I repeat, from the title of this post: What in God's Name is Going on Here? and: U.S. government, regulatory agencies and consumer watchdogs: where are you? -- SS Jan. 21, 2011 addendum: One wonders if the EHRevent site I wrote about at "<a href="http://hcrenewal.blogspot.com/2010/11/ehreventorg-web-site-to-collect-ehr_15.html">EHRevent.org: Web Site to Collect EHR Safety Reports</a>" and at "<a href="http://hcrenewal.blogspot.com/2010/11/emrevent-survey-amateurism-bias-or.html">EHRevent: survey amateurism, bias, or something else?</a>" will be as frank as MAUDE.

MAUDE and HIT Risks: What in God's Name is Going on Here?

As I wrote at my last post " Healthcare IT Delirium ": The field of health IT has become delirious. On top of an irrational exuber...

Đọc thêm »

EHRevent.org CEO Edward Fotsch MD: The Real Challenge with EHRs is -- User Error?

Additional detailed answers to the questions I raised <a href="http://hcrenewal.blogspot.com/2010/11/ehreventorg-web-site-to-collect-ehr_15.html">here</a> and <a href="http://hcrenewal.blogspot.com/2010/11/emrevent-survey-amateurism-bias-or.html">here</a> about a new site EHRevent.org, for reporting of healthcare IT-related medical errors, can now be found at a HIStalk interview entitled "HIStalk Interviews Edward Fotsch MD, CEO, PDR Network (EHR Event)" <a href="http://histalk2.com/2010/11/22/histalk-interviews-edward-fotsch-md-ceo-pdr-network-ehr-event">at this link</a>. It is an interesting interview. I certainly find the recognition of need for an EHR/clinical IT problems reporting service a major cultural advancement in healthcare. It's still unclear to me how -- and why -- this organization originated with little to no public knowledge and involvement, especially considering the organization types mentioned below that participated, and how it will function in interactions with myriad healthcare IT stakeholders. Here's an explanation by Dr. Fotsch: <blockquote>... We work with a not-for-profit board called the iHealth Alliance. They Alliance is made up of medical society executives, professional liability carriers, and liaison representatives from the FDA. They govern some of the networks that we run, and in exchange for that, help us recruit physicians. Professional liability carriers, for example, promote our services that send drug alerts to doctors because that’s good and protective from a liability standpoint. In the course of our conversations with them roughly a year ago, when we were talking about adding some drug safety information into electronic health records, we came across the fact that there were concerns from the liability carriers that there was no central place for reporting adverse EHR events or near misses or potential problems or issues with electronic health records. [Translation: the carriers saw their losses potentially increasing as a result of litigation arising from EHR-related lawsuits, and decided to do something proactive- ed.] They were interested in creating a single place where they could promote to their insured physicians that they could report adverse EHR events. Then it turned out that medical societies had similar concerns. [That must have been one of the best-kept secrets on Earth considering the promotion EHR's have received as a miracle-working technology, and the lack of expression of concerns from those societies - ed.] Rather than have each of them create a system, the Alliance took on a role of orchestrating all of the interests, including some interest from the FDA and ONC in creating an electronic health record problem reporting system. That’s how it came into play. Our role in it, in addition to having a seat on the iHealth Alliance board, was really in network operations — in running the servers, if you will, which didn’t seem like a very complicated task. Since business partners we rely on for our core business were interested in it, it was easy to say yes. It frankly turned out to be somewhat more complicated than we originally thought [I predict they haven't seen anything yet; wait until they get knee deep into real world EHR issues - ed.], but now it’s up and available.</blockquote> While I find the recognition of need for an EHR/clinical IT reporting service a major advancement, I am nonetheless troubled by certain statements made by Dr. Fotsch. They seem at odds with the theoretic and empirical findings of medical informatics, social informatics, human-computer interaction and other fields relevant for health IT evaluation, and/or seem to demonstrate biases about HIT. My comments are in red italics: <blockquote>Fotsch: … Probably what we’re seeing more often than not, the real challenge with EHRs like any technology, turns out to be some form of user error. [What about contributory or causative designer error? – ed.] “I didn’t know it would do that" [Why did the user not know? Lack of training, poor manuals, or overly complex information systems lacking informative messages and consistency of control-action relationships, as an example? -ed] ... or “I didn’t know that it pre-populated that" [Why did it pre-populate? Was that inappropriate for the clinical context, such as <a style="font-style: italic; font-weight: bold;" href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_24.html">in this example</a>?] ... or “I didn’t know I shouldn’t cut and paste" [Then why did the software designers enable cut and paste, without some informative message on overuse, such as length of text cut and pasted?– ed.] ... or “I wasn’t paying attention to this" [Perhaps due to distractions from <a style="font-weight: bold;" href="http://www.tinyurl.com/hostileuserexper" rel="nofollow">mission hostile user interfaces</a>? -ed] ... or maybe the user interface was a little confusing [What is "a little confusing?" (Is that like "A little pregnant?) And why was it confusing? User intellectual inadequacy, or software design issues leading to cognitive overload? - ed.] Actual software errors appear to be the exception rather than the rule as it relates to EHR events. ["Actual software errors" are defined as, what, exactly--? Loss of database relational integrity as a result of a programming error, as apparently recently happened at Trinity Health, a large Catholic hospital chain as reported in HIStalk? Memory leaks from poor code? Buffer overflows? What?] That’s at least as I understand it. [Understand it from whom? Hopefully not from me or my <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/">extensive website</a> on the issues - ed.]</blockquote> In summary, a "blame the user" attitude seems apparent. There appears to be little acknowledgment of the concept of IT "errorgenicity" - the capacity of a badly designed or poorly implemented information system to facilitate error, and of the systemic nature of errors in complex organizations to which ill-done IT can contribute. These are concepts understood long ago in mission critical settings, as in this mid 1980's piece from the Air Force cited in my previously-linked <a href="http://www.tinyurl.com/hostileuserexper">eight part series on mission hostile health IT</a>: <blockquote> From "<a href="http://hcibib.org/sam/">GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE</a>" ESD-TR-86-278 August 1986 Sidney L. Smith and Jane N. Mosier The MITRE Corporation Prepared for Deputy Commander for Development Plans and Support Systems, Electronic Systems Division, AFSC, United States Air Force, Hanscom Air Force Base, Massachusetts.<a href="http://hcibib.org/sam/"></a> ... SIGNIFICANCE OF THE USER INTERFACEThe design of user interface software is not only expensive and time-consuming, but it is also critical for effective system performance. To be sure, users can sometimes compensate for poor design with extra effort. Probably no single user interface design flaw, in itself, will cause system failure. But there is a limit to how well users can adapt to a poorly designed interface. As one deficiency is added to another, the cumulative negative effects may eventually result in system failure, poor performance, and/or user complaints.Outright system failure can be seen in systems that are underused, where use is optional, or are abandoned entirely. There may be retention of (or reversion to) manual data handling procedures, with little use of automated capabilities. When a system fails in this way, the result is disrupted operation, wasted time, effort and money, and failure to achieve the potential benefits of automated information handling. In a constrained environment, such as that of many military and commercial information systems, users may have little choice but to make do with whatever interface design is provided. There the symptoms of poor user interface design may appear in degraded performance. Frequent and/or serious errors in data handling may result from confusing user interface design [in medicine, this often translates to reduced safety and reduced care quality - ed.] Tedious user procedures may slow data processing, resulting in longer queues at the checkout counter, the teller's window, the visa office, the truck dock, [the hospital floor or doctor's office - ed.] or any other workplace where the potential benefits of computer support are outweighed by an unintended increase in human effort. In situations where degradation in system performance is not so easily measured, symptoms of poor user interface design may appear as user complaints. The system may be described as hard to learn, or clumsy, tiring and slow to use [often heard in medicine, but too often blamed on "physician resistance" - ed.] The users' view of a system is conditioned chiefly by experience with its interface. If the user interface is unsatisfactory, the users' view of the system will be negative regardless of any niceties of internal computer processing. </blockquote><a href="http://hcibib.org/sam/"></a> I am not entirely happy when the CEO of an organization taking on the responsibility of being a central focus for EHR error reporting makes statements that are consistent with unfamiliarity with important HIT-relevant domains, as well as a possible pro-IT, anti-user biases. For that reason as well as the other questions raised at my prior posts (such as the onerous legal contract and apparent lack of ability of the public to easily view the actual report texts themselves), I cannot recommend use of their site for EHR problems reporting. I recommend the continued use of the FDA facilities until such time as a compelling argument exists to do otherwise. -- SSAddendum 11/28/10:This passage ends the main essay at my site "<a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/">Contemporary Issues in Medical Informatics: Common Examples of Healthcare Information Technology Difficulties</a>" and is quite relevant here: <blockquote style="font-family: arial;"> ... An article worth reviewing is "Human error: models and management", James Reason (a fitting name!), BMJ 2000;320:768-770 (18 March), <a href="http://www.bmj.com/cgi/content/full/320/7237/768">http://www.bmj.com/cgi/content/full/320/7237/768</a>:Summary points: <ul><li>Two approaches to the problem of human fallibility exist: the person and the system approaches </li></ul><ul><li>The person approach focuses on the errors of individuals, blaming them for forgetfulness, inattention, or moral weakness </li></ul><ul><li>The system approach concentrates on the conditions under which individuals work and tries to build defenses to avert errors or mitigate their effects</li></ul><ul><li>High reliability organizations---which have less than their fair share of accidents---recognize that human variability is a force to harness in averting errors, but they work hard to focus that variability and are constantly preoccupied with the possibility of failure.</li></ul><o:p></o:p></blockquote>-- SS

EHRevent.org CEO Edward Fotsch MD: The Real Challenge with EHRs is -- User Error?

Additional detailed answers to the questions I raised here and here about a new site EHRevent.org , for reporting of healthcare IT-relate...

Đọc thêm »

FDA MAUDE Database: Patient Outcome - Death

I present another health IT problem case from the FDA's voluntary <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm">MAUDE</a> (Manufacturer and User Facility Device Experience) database below. From FDA's description of MAUDE: <ul style="font-style: italic;"><li>MAUDE data represents reports of adverse events involving medical devices. The data consists of voluntary reports since June 1993, user facility reports since 1991, distributor reports since 1993, and manufacturer reports since August 1996. MAUDE may not include reports made according to exemptions, variances, or alternative reporting requirements granted under 21 CFR 803.19. </li><li>The on-line search allows you to search CDRH database information on medical devices which may have malfunctioned or caused a death or serious injury. MAUDE is scheduled to be updated monthly and the search page reflects the date of the most recent update. FDA seeks to include all reports received prior to the update. However, the inclusion of some reports may be delayed by technical or clerical difficulties.</li><li>MAUDE data is not intended to be used either to evaluate rates of adverse events or to compare adverse event occurrence rates across devices. Please be aware that reports regarding device trade names may have been submitted under different manufacturer names. Searches only retrieve records that contain the search term(s) provided by the requester. </li></ul> I somehow missed the following case when I wrote the Oct. 2009 post '<a style="font-weight: bold;" href="http://hcrenewal.blogspot.com/2009/10/out-policy-is-to-always-have-unabashed.html">Our Policy Is To Always Have Unabashed Faith In The Computer ... Except When It Screws Up, And Then It's The Doctor's Fault</a>' but I have added it there as well: <blockquote> <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1656460">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1656460</a> CERNER MILLENIUM POWERCHART CPOE Event Date 11/19/2006 Event Type: Death Patient Outcome: Death The medication review screen of the subject device does not specify the exact dose in milligrams of combination medications. For example, narcotics are combined with tylenol in at least two strengths. Liquid narcotic tylenol-oxycodone combination is reported in ml, not mg. The exact dose of tylenol is not specified and requires knowledge of the combination medication dose in the volume specified. Certain fields of the grid do not specify the volume, but rather state "date/time" requiring another click or pop up screen. The immediate knowledge of tylenol dosage in mg is directly related to understanding and preventing excessive doses. In the subject, 10 ml of acetaminophen-oxycodone is indicated as having been given 3 times over 4 hours. That means that 1950 mg of tylenol was administered in 4 hours while the patient was in a state of starvation and receiving other medication that increase the effects of tylenol. This dose would equate to 11,700 mg of tylenol over 24 hours, nearly 3 times the maximum daily dose in otherwise health people. In the ensuing days, the patient developed acute renal failure, presumably acute tubular necrosis, and died. In the absence of other etiology, the excess tylenol was the culprit. This was not considered as etiology ante-mortem. The counterintuitive screen impaired the professionals. The pharmacist did not recognize and stop the medication, the nurses administered it, and the excessive dose, clinically meaninglessly listed as a volume of 10 ml -given 3 times in 4 hours- of acetaminophen-oxycodone, was missed by the physicians. Adverse events have been ascribed to "user error" by vendors. The device offers a potent propensity to life endangering oversights. There are other screens on this device which present information that interfere with clinically useful visualization of data. [Who designed these screens, I ask? Clinicians, or business IT personnel used to designing inventory systems for widget control? - ed.] The data does not flow to the professionals. It is not represented in a meaningfully useful manner. The professionals need to hunt for it. As such, the user unfriendly screens [see <a href="http://www.tinyurl.com/hostileuserexper">this link</a> on mission hostile HIT - ed.] impair safe medical care consistent with the impediment to expedient professional understanding of what, exactly, is the dose of medication and how much was administered to the patient. This sentinel case of death is directly attributed to user unfriendly screens on this device.</blockquote> How many cases like this, as well as "near misses" related to health IT go unreported, nationwide and worldwide? As in my paper "<a href="http://www.scribd.com/doc/28747771/Remediating-an-Unintended-Consequence-of-Healthcare-IT-A-Dearth-of-Data-on-Unintended-Consequences-of-Healthcare-IT">Remediating an Unintended Consequence of Healthcare IT: A Dearth of Data on Unintended Consequences of Healthcare IT</a>", nobody really knows; these devices are unregulated with no requirements for reporting. However, let's roll it out nationally anyway, because HIT will deterministically "revolutionize" medicine. Just ignore those spoil-the-party, man-behind-the-curtain prattle from writers <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=2009">like these</a>. We can safely ignore all contrarian research and literature, of course, as we all know HIT will revolutionize medicine from the definitive certainty of HHS in "<a href="http://hcrenewal.blogspot.com/2010/07/new-england-journal-on-meaningful-use.html">The 'Meaningful Use' Regulation for Electronic Health Records</a>", NEJM, Blumenthal and Tavenner (10.1056/NEJMp1006114, July 13, 2010): <blockquote>The widespread use of electronic health records (EHRs) in the United States is inevitable. EHRs will improve caregivers’ decisions and patients’ outcomes. Once patients experience the benefits of this technology, they will demand nothing less from their providers. Hundreds of thousands of physicians have already seen these benefits in their clinical practice. [Except for those who <a href="http://archinte.ama-assn.org/cgi/content/short/167/13/1400">haven't</a> - ed.] </blockquote> And our government's called <a href="http://www.bp.com/sectiongenericarticle.do?categoryId=3&contentId=2006926">BP Energy Company</a> cavalier? I offer no additional comments. -- SS

FDA MAUDE Database: Patient Outcome - Death

I present another health IT problem case from the FDA's voluntary MAUDE ( Manufacturer and User Facility Device Experience ) database b...

Đọc thêm »

Health IT and 'High Regulatory Standards': Criminal Negligence for Implementing Defective Systems That Put Data in the Wrong Charts?

Over at the <a href="http://www.histalk.com/">HIStalk</a> blog (a blog whose owner remains anonymous, and who uses an ISP that does not reveal information that could be used to identify him, apparently out of fear of retaliation for controversial stories he posts), the following appeared: <blockquote><a href="http://histalk2.com/2010/07/10/monday-morning-update-71210/" rel="bookmark" title="Article about: Monday Morning Update 7/12/10">Monday Morning Update 7/12/10</a> From Holy Smoke: “Re: Cerner. Misidentification incidents have been reported with Cerner PowerChart and Millenium in hospitals in Indiana, Michigan, and others after a Cerner upgrade. Entries are placed in the wrong electronic chart and reviewed data is for the wrong patient.” Unverified. I saw nothing in the FDA’s <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm" target="_blank">Maude database</a>, so if it’s happening, customers should file an experience report. </blockquote> While the reports are "unverified", I can add that the FDA MAUDE database would not show any data if this problem were recent, as I believe MAUDE contributions are reviewed by FDA before posting. (7/21/10 addendum: various sources confirm this occurred at a religious-denomination hospital chain headquartered in the Great Lakes region of the U.S.) However, as I wrote in Oct. 2009 at <a href="http://hcrenewal.blogspot.com/2009/10/out-policy-is-to-always-have-unabashed.html">"Our Policy Is To Always Have Unabashed Faith In The Computer ... Except When It Screws Up, And Then It's The Doctor's Fault</a>", the MAUDE database does contain some error reports from this vendor (one of the very few HIT vendors who actually file such reports) such as: <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?id=64345"></a><blockquote><a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?id=64345">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?id=64345</a> Cerner Millennium RadNet Auto Launch Study and Auto Launch Report software functionalities. Defects in the Auto Launch functionality make it possible for a mismatch of patient data. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.CFM?MDRFOI__ID=946706">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.CFM?MDRFOI__ID=946706</a> Patient care delay. The issue involves functionality in cerner millennium powerchart office and powerchart core and affects users that utilize the powerchart inbox and message center inbox. In results to endorse or sign and review, if the user clicks ok and next multiple times in quick succession while attempting to sign a result or a document, the display could lag behind the system's processing of the action, and multiple results or documents could be signed without the user's review. In message center, when clicking ok and next or accept and next, or when deleting or completing messages and moving to the next task, a document could be signed or a message could be deleted without the user's review. Results could be endorsed or documents could be signed without physician review, which could impact patient care. Cerner received communication that a patient's follow-up care was delayed as a result of this issue. <a href="http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.CFM?MDRFOI__ID=753029">http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/Detail.CFM?MDRFOI__ID=753029</a> Microbiology set up a program within the cerner computer system to automate the reporting system for hsv (herpes simplex virus)testing. The system was tested with the assistance of cerner and found to be working appropriately. The new system was operational for approximately 3 weeks when it was determined that the first word of the sentence, "no" was inappropriately dropping off of the following sentence: "no herpes simplex virus type 1 or herpes simplex virus type 2 detected by dna amplification. " as such, two of five patients were incorrectly informed that they had hsv before the error was detected. One had started an antiviral creme treatment. The other three did not have follow-up visits until after the correct results were determined. Cerner has looked at the program and has not provided an answer for the system issue. In the interim, the previous manual review and entry process is being used. </blockquote> Assuming the current reports from anonymous whistleblower "Holy Smoke" are true, I note the following. My observations apply to any vendor and/or healthcare organization that puts defective HIT into use in patient care-- At my April 2010 post "<a href="http://hcrenewal.blogspot.com/2010/04/healthcare-it-corporate-ethics-101.html">Healthcare IT Corporate Ethics 101: 'A Strategy for Cerner Corporation to Address the HIT Stimulus Plan'</a>", I'd written: <blockquote>A profoundly disappointing lesson in the ethics of the healthcare IT sector (and the B-schools as well) can be gleaned from the following, a paper written by a Cerner employee and two health industry colleagues for a <a href="http://www.fuqua.duke.edu/">Duke Fuqua School of Business</a> course. The course is "Health Economics & Strategy (<a href="http://www.fuqua.duke.edu/admin/stuserv/courseinfo/hlthmgmt326.html">HLTHMGMT 326</a>), Distance Executive MBA" (syllabus <a href="http://faculty.fuqua.duke.edu/%7Edbr1/teaching/syllabusWEMBA.pdf">here</a> in PDF) ... The paper is entitled "A STRATEGY FOR CERNER CORPORATION TO ADDRESS THE HIT STIMULUS PLAN." </blockquote>The paper was scrubbed from the Duke Fuqua School of Business Site on or around April 16, 2010 but a cached copy is <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/Aycock-Prasad-Stiber-Cerner-2009.pdf">available here</a>. In that paper what I believe is a <a href="http://www.answers.com/topic/combination-in-restraint-of-trade-2">combination in restraint of trade</a> was suggested: <blockquote>This paper seeks to clarify these implications [of the the economic 'stimulus' package - ed.], understand the strengths and weaknesses of various players in the industry and recommend a strategy for Cerner Corporation to maximize its profit from the stimulus package and thereby secure a dominant position in the HIT industry. ... We recommend that Cerner collaborate with other incumbent vendors to establish high regulatory standards, effectively creating a barrier to new firm entry.</blockquote> High standards? I have some suggestions regarding "high regulatory standards." I agree that high, in fact, the highest regulatory standards should be upheld. I think I can safely state that a common regulatory standard in healthcare is that those involved in patient care, even peripherally, act with sound judgment and with patient well being as a foremost concern. Those acting recklessly and dangerously might be found negligent in a civil sense, or if acting recklessly in a willful and knowing manner, might be found criminally negligent. Two descriptions of criminal negligence: <blockquote><a href="http://www.thefreedictionary.com/criminal+negligence">Criminal negligence</a> - (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). <a href="http://definitions.uslegal.com/c/criminal-negligence/">Criminal negligence</a> is conduct which is such a departure from what would be that of an ordinary prudent or careful person in the same circumstance as to be incompatible with a proper regard for human life or an indifference to consequences. Criminal negligence is negligence that is aggravated, culpable or gross.(PDF). </blockquote> It is damn well clear that electronic medical records systems must function without unpredictable data errors that put data into the wrong persons' charts, thus producing two errors and two possibilities for patient harm: an erroneous absence of appropriate data in one patient's chart, and an erroneous presence of inappropriate data in another's. This is not a theoretical argument open to debate, and this is not a drill. A recent IT-related data error involving one single medication nearly killed my relative. In addition, the "<a href="http://jama.ama-assn.org/cgi/content/extract/301/12/1276">learned intermediary</a>" excuse used to punt liability onto physicians and other clinicians for patient harm due to IT errors does not apply here, and this is also not open to debate. Physicians, even the most learned, are not clairvoyant; they should not be expected to know which chambers are empty and which chambers are loaded in a game of cybernetic <a href="http://en.wikipedia.org/wiki/Russian_roulette">Russian Roulette</a> with the data on their patients. Having an EMR maintain fundamental relational integrity, i.e., not place clinical data entered in good faith by trusting clinicians in another patients' chart, is not rocket science. Those who design, those who implement, and those who put into production (i.e., for use by physicians, nurses and other clinicians in the care of patients) any health IT "upgrade" without the extensive testing, testing and more testing necessary to prove proper operation on such a fundamental point as maintenance of relational integrity (i.e., correct patient identity in data storage and retrieval) knew, should have known, or should have made it their business to know that doing so puts patients at risk of injury or death. Putting an "upgraded" software application with such fundamental defects into actual use in real, live patients care environments - for whatever reason, e.g., finances, vendor marketing pressures, meeting planned objectives and numbers, obtaining a bonus, etc. - reflects in my view: <blockquote>"... a departure from what would be that of an ordinary prudent or careful person in the same circumstance as to be incompatible with a proper regard for human life or an indifference to consequences."</blockquote> Thus: In upholding the highest regulatory standards, if patients are harmed or die as a result of this type of HIT snafu, criminal charges against the responsible IT, clinical and administrative personnel would be an appropriate remedy to this type of negligence. As I wrote at "<a href="http://hcrenewal.blogspot.com/2010/07/4-billion-military-emr-ahlta-to-be-put.html">$4 Billion Military EMR "AHLTA" to be Put Out of Its Misery?</a>", in my view as of 2010 legal actions are the only way that the domain of healthcare IT can be returned to a field "of, by and for" clinicians, instead of "of, by and for" those who live off the hard work of clinicians and their patients. -- SS

Health IT and 'High Regulatory Standards': Criminal Negligence for Implementing Defective Systems That Put Data in the Wrong Charts?

Over at the HIStalk blog (a blog whose owner remains anonymous, and who uses an ISP that does not reveal information that could be used to...

Đọc thêm »