The full text of the report is available free here.
I’ve gone through the report and will summarize it loosely below (the most interesting parts, anyway). A couple of industry experts have volunteered to provide their interpretation. Bill Stead, chair of the group, told me he will write up a short statement on the implications for hospitals and vendors for HIStalk. I’d like your thoughts, too.
Make no mistake, this report is important. The IOM has clout and is generally not seen as biased or influenced by industry. Anyone working on the front lines of patient care will identify with nearly every one of the observations and recommendations, although there’s no easy fix for most of them. The most important thought as you read, I think, is this: what traditional wisdom does the report challenge and who will be upset by that?
- HIMSS won’t like it because they didn’t think of it and it is somewhat critical of today’s systems (I expect a quick rebuttal). It’s quite a contrast to the exhibit hall.
- Not all vendors will like it because it may not align with their architecture or products and it questions today’s concept of integrated systems (note the line about monolithic, integrated systems that can’t support changing ideas – you know a couple of vendors and probably even some CIOs are shooting out of their chairs).
- HIMSS, rah-rah press, and anything Most Wired will hate it because it concludes that, despite big investments and painful implementations, today’s IT is not really helping patient care as much as it could and maybe we’re going further in the wrong direction.
- Users will like the observation that vendors don’t often take human factors design into account, resulting in systems that are hard to learn and use.
- Hospitals will take some offense because it holds them accountable for not using what they’ve bought and using automation mostly for purposes that have minimal patient care value.
- Not everybody in the government will like it because it emphasizes that healthcare needs drastic changes, not just more of the same systems, especially when it come to complicated government payment for services that aren’t necessarily in the patient’s best interest.
- Even the big hospitals that served as the site visits may not like it because, despite the mind-boggling sums all of them have spent on IT, the report doesn’t suggest impressive results. It mentioned one unnamed site (almost certainly UPMC) that has spend $500 million on IT in the past 10 years, but still isn’t where it should be.
For me, the most impactful statement echoed one I’ve made here several times recently: the government should not be in the business of funding IT systems, whether they’re archaic or state of the art. It should reward quality and let providers use whatever tools, IT or otherwise, that will help meet them.
In fact, nearly every conclusion in the report has been covered in HIStalk at one time or another (I’m not bragging on that, just pointing out that for a bunch of academics, their conclusions resonate way down here where Mr. HIStalk plies his IT trade by day and sees what they saw, which I think means they hit the target squarely).
Here’s the summary:
This report was produced by the National Academies, of which the Institute of Medicine is one division (along with the National Academy of Sciences, National Academy of Engineering, and National Research Council). Members of these groups work without compensation to advise the government and the public on science and technology issues.
Members of the Committee on Engaging the Computer Science Research Community in Health Care Informatics are:
William W. Stead, Vanderbilt University, Chair (CIO and information architect)
G. Octo Barnett, Massachusetts General Hospital (Harvard professor and research informatics)
Susan B. Davidson, University of Pennsylvania (computer science chair)
Eric Dishman, Intel (general manager of Intel’s Health Research and Innovation Group)
Deborah L. Estrin, UCLA (computer science professor)
Alon Halevy, Google (research scientist)
Donald Norman, Northwestern University (design professor)
Ida Sim, UCSF School of Medicine (associate professor of medicine and informatics director)
Alfred Spector, Google (VP of research)
Peter Szolovits, MIT (computer science professor)
Andries Van Dam, Brown University (technology and education professor)
Dio Wiederhold, Stanford University (professor emeritus of computer science)
This is an interesting group: mostly computer experts who could bring an objective viewpoint to the table (no vendors, no advocacy people, no caregivers). Some bias was obviously introduced upfront when choosing the committee members, the site visits, and the guests providing briefings (the "smart table" and Azyxxi-like analytical tools obviously were inspired by Microsoft, which did one briefing).
The committee disclaimed upfront that it did not look at all care sites and roles, particularly the 1-2 physician practice where much of the medical care is delivered in the US. It is hospital-centric.
The committee’s charter was to determine how well providers (hospitals, for the most part) are using technology support to strive towards the IOM’s vision. The tenets of that vision and visionary examples of how computers might support them are (from my interpretation and their examples):
- Comprehensive patient data. Computers could identify and count home meds, then using RFID-encoded prescription information to assess patient compliance.
- Patient-specific clinical decision support. Instead of looking at paper EKG strips, the doctor sees them overlaid with an animated electronic model of the patient’s heart. Historical information is presented in a consistent format for easy comparison.
- Application of evidence-based practice guidelines and research into practice. Doctors can subscribe to medical literature alerts, download new clinical guidelines into their systems, and use them to construct a series of patient flowcharts to choose from, when will then update disease management dashboards, order sets, and pre-programmed reminders.
- Tools that can highlight patient and population problems. A doctor can review a dashboard of all their diabetic patients, with all measures of disease color-coded so that all patients can be quickly assessed visually and interventions planned. During the patient’s visit, the system chooses drugs based on their therapeutic class and insurance coverage.
- Rapid integration of devices and historical patient information as a "learning" system. Patients run applications on their smart phones that measure activity and post it to their Facebook page widget. Inhalers are Bluetooth-enabled to monitor compliance and provide alerts tied to activity and environmental factors.
- Integration of information from alternate care sites, such as the home. Diabetics wear continuous blood glucose sensors that suggest action and dial an emergency number on their cell phone if readings advance to dangerous levels.
- Empowerment of patients and families with personal health records, education, and provider communication. EHRs allow patient access via the Internet and have an interpretation function that gives a lay explanation comparable to what a physician would provide.
What’s wrong with today’s use of IT
- There’s a big disconnect between systems and clinical practice.
- Systems place too much emphasis on clinician data entry without giving them value in return.
- Implementation cycles are too long, often measured in decades.
- Clinicians spend too much time digging through raw data that systems dump in their laps, leaving them to figure out how to use it in thinking about the patient.
- Today’s systems are build on a transaction-heavy foundation, with minimal context or grading the importance of information.
- Decision support should provide cost analysis, grade the quality of information, and allow clinicians to simulate interventions before doing them for real.
- Systems should be designed as thinking systems with transactions built in, not as transaction systems with decision support bolted on.
- Caregivers should not have to manually enter data that is being collected by electronic sensors – systems should be self-documenting.
- Users should be able to pose questions and have retrievals query multiple databases without requiring data in them to be standardized.
- Physician-patient interactions should be captured by real-time transcription and camera/microphone recording with suitable privacy consideration.
- The government’s role should be to embrace quality improvement, not to promote specific technologies that lock users into inefficient workflows. Incentives should be aimed at infrastructure, hardware, and data mining.
- IT should not be promoted en masse to clinicians until it helps them do their jobs better.
- A wide variety of payers with their own rules wastes a lot of clinician time trying to get paid.
- Clinical systems require extensive training, unlike PC applications that follow standard UI design and require no training.
- When clinicians round, applications add little value to the discussion and its results aren’t recorded anywhere for later use.
- Provider IT investments should be evaluated within four IT domains: automation, connectivity, decision support, and data mining.
- Organizations should at least scan their paper documents to make them available electronically.
Observations from the committee’s site visits
- Hospitals have a mix of paper and computer records, so users have to learn where to look.
- Work lists are usually managed on paper.
- Clinical systems were simply built to look like the paper they were supposed to replace, such as flowsheets.
- Documentation is after the fact.
- Clinical roles and responsibilities are not explicit.
- Clinical users value speed over everything else, but they don’t understand the systems that are supposed to support them.
- Legacy systems predominate, each with their own setup parameters and content, implemented with the goal of getting up and running rather than doing anything useful.
- Change management in hospitals means nobody moves ahead until the slowest party is ready.
- Biomedical devices were universally poorly integrated.
- Semantic interoperability is almost non-existent. Systems weren’t designed to guide users through the process of completing common fields with standard terminologies.
- Focus on improving care, not on the technology.
- Seek incremental gain for incremental effort, rather than huge IT projects that take forever.
- Capture all the data you can.
- Design systems around human factors principles.
- Support the cognitive function of caregivers.
- Design systems with disruptive change in mind, i.e. genomics, which are more easily supported with connected systems rather than monolithic, integrated, all-encompassing systems.
- Archive data in ways that future interpretation and analysis can yield new knowledge.
- Design technologies to eliminate ineffective work processes.
- Design systems that can put data into context.