Harvard Study: Hospital Computerization Does Not Improve Performance (Updated 6 Apr 2015)

A republication of an earlier posting of this study. It's timely in the light of New York Times Opinion piece, "Why is health care tech still so bad?"

Title: Hospital Computing and the Costs and Quality of Care: A National Study
Authors: David U. Himmelstein, MD, Adam Wright, PhD, Steffie Woolhandler, MD, MPH Department of Medicine, Cambridge Hospital/Harvard Medical School, Cambridge, Mass;  Clinical Informatics Research and Development, Partners Healthcare System, Boston, Mass.

ABSTRACT**

BACKGROUND: Many believe that computerization will improve health care quality, reduce costs, and increase administrative efficiency. However, no previous studies have examined computerization’s cost and quality impacts at a diverse national sample of hospitals.
METHODS: We linked data from an annual survey of computerization at approximately 4000 hospitals for the period from 2003 to 2007 with administrative cost data from Medicare Cost Reports and cost and quality data from the 2008 Dartmouth Health Atlas. We also compared hospitals included on a list of the “100 Most Wired” with others.
RESULTS: Hospitals on the “Most Wired” list performed no better than others on quality, costs, or administrative costs.
CONCLUSION: As currently implemented, hospital computing might modestly improve process measures of quality but does not reduce administrative or overall costs.
© 2009 Elsevier Inc. All rights reserved. • The American Journal of Medicine (2009)
KEYWORDS: Hospital costs; Hospital quality; Information systems


Summary and Critique of the Study


Researchers from Harvard University collected data over 5 years (2003 to 2007) from a variety of different hospital data repositories


The hospital computer applications considered for this study included:

Clinical applications subscore (8 applications)

• Clinical data repository
• Computerized practitioner order entry
• Data warehousing and mining, clinical
• Electronic medical record
• Laboratory information system
• Nursing documentation
• Order entry
• Physician documentation

Administrative applications (patient-related) subscore (4 applications)

• Nurse acuity
• Nurse staffing scheduling
• Patient billing
• Patient scheduling

Administrative applications (other) sub-score (12 applications)
Budgeting

• Case mix management
• Cost accounting
• Credit collections
• Eligibility
• Data warehousing and mining, financial
• Electronic data interchange
• Executive information system
• General ledger
• Materials management
• Personnel management
• Staff scheduling 

The authors created a overall computerization score and three subscores on the basis of determining whether or not the hospital had computerized the areas listed above.  

Concerns regarding the construction and use of computerization score(s).

• No details were disclosed on how they created the level of computerization score.  
• Furthermore, no details were disclosed regarding the score distribution.  
• >> This is particularly important because correlation depends on a wide distribution of values as well as a reasonably even distribution across the range of values.  
• No information was forthcoming from the authors about these characteristics of the data set.   
• If the computerization scores were tightly clustered, then the r values (Pearson product-moment correlations) would hover around zero - and they did.

Suggested that increases in computerization may not be having the desired effects in reducing costs and increasing productivity and performance.

With respect to clinical significance of hospital computerization, the authors concluded that:

• Hospital computerization has not, thus far, achieved savings on clinical or administrative costs. 
• More computerized hospitals might have a slight quality advantage for some conditions.
• No reliable data support claims of cost savings or dramatic quality improvement from electronic medical records.

** Title/Author reference and abstract. Material below is edited for length and quoted. This study 
is available at no cost online. 


The following later post provides additional information about the effects of computerized medical records systems.

http://medicalremoteprogramming.blogspot.com/2015/03/new-york-times-opinion-why-health-care.html

Notice: Editing and Updating Articles

I've noticed a significant increase in traffic recently. I have been putting additional time, attention and effort into this blog, and apparently, it shows. I've noticed that people are reading many of the older articles as well as the new ones. Some of the information in several of the older articles is out of date and requires updating.

I am beginning the process of editing and updating many of my older articles. If you see in the title "(Updated Date)," you'll know that the article has been newly edited and updated.

Also, I am unsettled about the color scheme for the blog. Expect frequent changes if you visit regularly.

UK Perspective Regarding FDA Regulatory Requirements

A Linked-In colleague posted a link to this article. I read it and found it interesting enough to post the link and comment on it. It's by a UK publication and discusses the FDA regulatory process as it relates to Human Engineering requirements for device approval for commercialization.

Here's the link:
http://www.emdt.co.uk/daily-buzz/what-are-fda-usability-testing-requirements-device-approval?cid=nl.qmed01.20150325

In addition, I provide my own perspective on the article in the "Commentary" section below. I do not critique the article. I only attempt to expand on a few points from it.

But first, a brief summary of the article.

Article Summary

Medical errors have become an increasing concern of the FDA. I became interested in medical errors when I was a consultant at St. Jude Medical Cardiac Rhythm Division in Sylmar, CA. During my time at St. Jude (2009-2010), deaths by medical error were being reported as being 100,000 to 120,000 per year. Last year, I posted links to two articles that stated that deaths by medical errors could be closer to 400,000 per year. (http://medicalremoteprogramming.blogspot.com/2014/07/rip-death-by-medical-error-400000-year.html)

It has been noted by the FDA a large proportion of medical errors can be attributed to poorly designed medical device user interfaces. Since a fundamental mission of the FDA is increasing patient safety and reducing injuries and fatalities in the practice of medicine, the FDA has begun placing greater emphasis on improving the usability of medical device user interfaces.

This article provides measures that show the FDA's increasing emphasis on usability and human factors issues by showing the increasing frequency that companies seeking medical device clearance for the US market mention the terms "usability" and "human factors." Figure 1 from the article clearly shows the increasing usage of these terms in company filings.

The focus should be on the trends, not the absolute numbers because not all filing documents have been included in the count. But the trend clearly shows an increased emphasis by companies to increasingly use the terms "usability" and "human factors" in their filings with the FDA. The two figures that follow suggest the degree that companies have incorporated the FDA prescribed human factors engineering process and design guidance documentation.

The documents listed below are specifically targeted to defining and supporting the human factors engineering process and the development of the Human Engineer File that's included as part of a company's filing to the FDA.

• ISO 62366, Medical Devices - Application of Usability Engineering to Medical Devices
• AAMI / ANSI HE75:2009, Human Factors Engineering - Design of Medical Devices (General)

I'll discuss the documents above in greater detail and describe how they're intended to fit within the human factors engineering process when developing medical devices.

• IEC 60601-1-6 Medical electrical equipment - Part 1-6 General requirements for Safety - Collateral standard: Usability
• IEC 60601-1-8 Ed. 1, Medical Electrical Equipment - Part 1-8: General Requirements for Safety - Collateral Standard: Alarm Systems - Requirements, Tests and Guidance - General Requirements and Guidelines for Alarm Systems in Medical Equipment (General)

The two documents above are engineering standards. They're engineering specifications that medical devices must meet. They are technical and specific.

I show Figure 3 from the article before showing Figure 2. 

The increasing reference of 60601-1-8 is not surprising given the increased emphasis on safety. My real interest is in the significant increase in reference to ISO 62366. As mentioned, this is process standard the lays out how human factors engineering should be engaged to reduce "use errors." The emphasis in this standard is on the reduction of risk. Risk management is extremely well embedded in the medical device design and engineering process. It would seem that from a cultural perspective, ISO 62366 fits with the medical device engineering process. 

I want to contrast the dramatic, increasing references to ISO 62366 with the references to AAMI/ANSI HE75 shown in Figure 2 below.

References to AAMI/ANSI HE75 rise and fall from 2010 to 2013 instead of a steady upward trend that you see with ISO 62366 in Figure 3. I would like to emphasize that ISO 62366 and AAMI/ANSI HE75 should be considered as companion documents. (I'll expand on this in the Commentary section below.)

Commentary

The article does support the contention that the FDA and the companies it regulates are paying increasing attention to usability and human factors. That they're paying enough attention is another matter entirely. As new medical devices are introduced we should see two things. First, the use error rate for the newly introduced medical devices (once users have adapted to them) should decline in relationship to other similar devices currently in use. Second, we should see over time the number of per year of deaths and injuries from medical errors begin to decline. This will take time to detect.

Without a doubt, the push by the FDA to define a human engineering process in the design and testing of medical devices, and to press for testing under actual or simulated conditions is needed. In many ways the FDA is mirroring many of the processes that have already been adopted by the US Department of Defense (DoD) in the area of human engineering. Admittedly, the DoD doesn't always get it right, there is an understanding within the DoD that it is important ... life saving, battle-winning important ... to insure that those at the controls can do their jobs quickly, effectively and with as few errors as possible.  So from that standpoint, the FDA has adopted processes from programs that have proven effective. But the FDA has just passed the starting line. And much more will be required going forward.

ISO 62366 vs AAMI/ANSI HE75

As I mentioned earlier ISO 62366 and AAMI/ANSI HE75 should be consider complementary or companion documents. HE75 is a much larger document than 62366 and includes a significant amount of device design guidance and guidelines. 62366 is almost entirely a process document that's devoted to directing how to go about managing the research and development process of a medical device. In addition, the focus of 62366 is managing risks, risks in the realm of reducing use errors.

I found it interesting that references to HE75 were not increasing at the rate as references to 62366. I would have expected Figures 2 and 3 to have a similar appearance with respect to 62366 and HE75 in large part because the documents significantly overlap. In fact I might have reasonably expected references to HE75 to outpace 62366 because HE75 includes design specific guidelines in addition.

One possible reason for references to HE75 not being referenced in the same accelerated way as HE75 may have to do with the fact that the European Union has not adopted HE75, so it's required for medical devices that will be marketed in the EU (CE).  (I am currently unaware of the regulatory requirements of other countries on this matter.) Medical device companies are international companies and the documents that they file in one country are generally the same in each country. Thus since the EU hasn't adopted HE75, references to HE75 and HE75's use as a foundational process and design document may be less.

DESIGN RATIONALE

I'm not sure that this is true at this point in time, but I am certain that the following will be true going forward at some time in the future. I believe that the FDA will hold companies to account for their user interface designs. I believe that the FDA will demand that companies clearly define how they came up with their user interface designs and that those designs are well-grounded in empirical evidence.

This is what I mean ... the FDA will demand that the design choices ... these include: controls, placement of controls, number of controls, actions performed by controls, the way the control responds, methods for interacting with the device (e. g., touch screen, buttons, mouse), size of the display, etc. ... for medical device user interfaces must be grounded in empirical data.

Commercial websites are often designed by graphic artists. Often times the design of webpages reflect the artist's aesthetic sensibilities. Layout appear they way that they do because they look good.

I believe that the FDA will require that user interface designs for medical devices have an empirically grounded design rationale. Companies will be required to point to specific research finding to justify the design and the design choices that they made. Furthermore, as the design of the user interface evolves with each iteration of testing, the FDA will require that changes to the design be based on research findings.

Finally, I believe that soon if it is not occurring already, that the FDA will require:

1. That companies submit documentation to show in detail the full evolutionary design process beginning from product inception, including ...
2. Detailed pre-design research ... population(s), method(s), research questions and rationale, etc ... as well as the findings and what they suggest for the design of the user interface
3. A design that includes with a full discussion of the design rationale ... why was it designed the way it was ... 
4. A detailed description of the evolution of the design that include full and clear justification(s) for each change in the design ... and require that changes be grounded empirical data 
5. A full description of pre-commercialization testing process and method ... with a clear justification for why this testing meets FDA testing requirements
6. And a complete and clear analysis of the testing data.

What I'm suggesting above is that the process of designing and testing a medical device user interface should be more than going through the prescribed steps, collecting the data, doing the tests, etc. There should be a clear thread that ties all the steps together. When in a subsequent step, one should be able to point back to the previous steps for the rationale to explain why the user interface was designed to appear and operate the way it does ... to this point.

As near as I can tell, what I described above is rigorous than is currently required by the FDA. However, I believe that it would be in any company's best interest to follow what I've suggested because there may come a time when the FDA's enforcement becomes more rigorous. 

Another reason may be lawsuits. If a company can show that it went beyond the FDA's regulatory requirements at the time, those suing would likely have less of a chance of collecting damages. And if damages were awarded, they may likely be lower. Also, if the company went beyond the FDA requirements, it would be likely that there would be fewer people injured and that should lower damages.

FINALLY

This article has been a springboard for me to discuss a number of topics related to human engineering for medical devices user interfaces. This topic will remain a central part of this blog. I'll return this within a week or two, and discuss in depth other topics related to the human engineering process for medical device user interfaces.