Skip to main content

Currently Skimming:

6 A Shared Responsibility for Improving Health IT Safety
Pages 125-168

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 125...
... Achieving the desired reduction in harm will depend on a number of factors, including how the technology is designed, how it is implemented, how well it fits into clinical workflow, how it supports informed decision making by both patients and providers, and whether it is safe and reliable. An environment of safer health IT can be created if both the public and private sectors acknowledge that safety is a shared responsibility.
From page 126...
... are faced with competing priorities, including maximizing profits and maintaining a competitive edge, which can limit shared learning, and have adverse consequences for patient safety. Shared learning about safety risks and mitigation strategies for safer health IT among users, vendors, researchers, and other stakeholders, can optimize patient safety and minimize harm.
From page 127...
... This lack of reported instances of harm is consistent with other areas of patient safety, including paper-based patient records and other manually based care systems, where there is ample evidence that most adverse events are never reported, even when there are robust programs encouraging health professionals to do so (Classen et al., 2011; Cullen et al., 1995)
From page 128...
... However, to maintain a competitive advantage, many vendors may not be motivated to allow users to disclose patient safety–related risks associated with their health IT products. Many vendors place these clauses within the boilerplate language, and in the absence of comprehensive legal review, users may not even realize these restrictions exist when signing their contracts.1 If more users carefully search for such clauses and negotiate terms that allow them to share information related to patient safety risks, vendors may be more likely to exclude such clauses.
From page 129...
... In many other industries, user 2 ONC-ATCBs as of April 2011 include the Certification Commission for Health Information Technology; Drummond Group, Inc.; ICSALabs; InfoGard Laboratories, Inc.; SLI Globan Solutions; and Surescripts LLC.
From page 130...
... Recommendation 3: The ONC should work with the private and public sectors to make comparative user experiences across vendors publicly available. Another way to increase transparency in the private sector is to require reporting of health IT–related adverse events through health care provider accrediting organizations such as The Joint Commission or the National Committee for Quality Assurance (NCQA)
From page 131...
... One example of the type of data that are likely to be important would be override rates for important types of safety warnings on alerts and warnings built into electronic health records (EHRs)
From page 132...
... . These councils provide a voice to stakeholder groups -- including consumers, health professionals, health care organizations, professional organizations (e.g., the American Medical Informatics Association [AMIA]
From page 133...
... Additionally, vendors can help mitigate safety risks by employing highquality software engineering principles, as discussed in Chapter 4. Usability represents an exceptionally important issue overall, and undoubtedly affects safety.
From page 134...
... Postimplementation Similar to the preimplementation and implementation phases, standards and criteria will be necessary to ensure that users have appropriately implemented health IT products and integrated them into the entire sociotechnical system. In the postimplementation phase, the largest share of the work involves health professionals and organizations working with vendors to ensure patient safety.
From page 135...
... If the workforce is not educated and trained correctly, workers will be less likely to use health IT as effectively as their properly trained counterparts. Educating health professionals about health IT and safety can help them understand the complexities of health IT from the perspective of the sociotechnical system.
From page 136...
... Appointing a chief medical and/or nursing information officer allows for health care organizations to hold someone accountable for the implementation and use of health IT. As discussed in Chapter 3, truly being able to use health IT products and ensuring their safety requires a unique set of skills.
From page 137...
... If not properly trained on how to use a specific technology, health professionals may not only miss an opportunity to make their own processes safer and more efficient, but also may in fact develop unsafe conditions. At a minimum, clinicians need to be trained to recognize that health IT can improve quality of care while being cognizant of its potential to negatively impact patient safety if used inappropriately.
From page 138...
... To varying degrees, hospitals and other health care organizations require health professionals to be able to use health IT. For example, they often require clinicians to receive a certain number of hours of introduction to the health IT product before granting privileges.
From page 139...
... While a bottom-up approach may yield some improvements in safety, it is limited in its breadth. Gaps will arise that require a more comprehensive approach, for example, ensuring processes are in place to report, investigate, and make recommendations to mitigate unsafe conditions associated with health IT–related incidents.
From page 140...
... , and NIST, among other federal agencies, are becoming more actively involved in guiding the future direction of health IT, indicating that patient safety will also require a shared responsibility among federal agencies. However, currently funded government programs are just one part of a multifaceted solution to improving patient safety and health IT.
From page 141...
... The committee categorized health IT–related adverse events as deaths, serious injuries, and unsafe conditions.4 While deaths and serious injuries are concrete evidence of harm that has already occurred, unsafe conditions can represent the precursors of the events that cause death and serious injuries and are generally greater in volume and provide the proactive opportunity to identify vulnerabilities and mitigate them before any patient is harmed. Analysis of unsafe conditions would produce important information that could potentially have a greater impact on systemically improving patient safety and would enable the adoption of corrective actions that could prevent death or serious injury.
From page 142...
... However, pharmaceutical drugs and medical devices are very different from health IT products such as EHRs, health information exchanges, and personal health records. As part of the meaningful use program, the ONC employed a similar mechanism for EHR vendors to list their products.
From page 143...
... Examples of Quality Management Principles and Processes Numerous industries have set standards for quality management principles and processes to help identify, track, and monitor both known and unknown safety hazards. Some examples of quality management principles and processes include the following: the Hazard Analysis Critical Control Point (HACCP)
From page 144...
... HACCP systems are used in the dairy, meat, and fish and seafood industries and are currently being adapted for use in the pharmaceutical industry. Another example of quality management principles and processes can be found in FDA's QSR for medical devices, which are also called current good manufacturing practices.
From page 145...
... In particular, the management subsystem and the production and process controls subsystem may be useful in considering what quality management principles apply to health IT. The management subsystem can be useful within health IT because it emphasizes the importance of management's role in making sure quality management principles and pro
From page 146...
... . Another example of quality management principles and processes can be found with ISO, which sets standards for industries around the world.
From page 147...
... However, not all vendors do, and the level of comprehensiveness of these quality management principles and processes is unknown. An industry standard is needed to ensure comprehensive quality management principles and processes are adopted throughout the health IT industry to provide health care organizations and the general public assurance that health IT products meet a minimum level of safety, reliability, and usability.
From page 148...
... Furthermore, the committee considers quality management principles and processes to be critical for the safety of health IT products and therefore does not want to limit the adoption of quality management principles and processes to those vendors participating in the meaningful use program. Finally, the committee discussed the role of professional associations and societies such as HIMSS.
From page 149...
... Regular Reporting of Health IT–Related Deaths, Serious Injuries, or Unsafe Conditions As discussed previously, to ascertain the volume and types of patient safety risks and to strengthen the market, reports of adverse patient safety events need to be collected. Regular reporting of adverse events is a widely used practice to identify and rectify vulnerabilities that threaten safety.
From page 150...
... The term nonpunitive is used here to mean that reports of health IT–related adverse events should be free from punishment or retaliation as a result of reporting. Some systems mandate reports of adverse events and patient safety incidents, while others allow for confidential, voluntary reporting (WHO, 2005)
From page 151...
... The NASA/VA Patient Safety Reporting System is an external, nonpunitive system modeled after NASA ASRS and accepts reports of close calls and actual adverse events where harm has occurred. Reports are protected from disclosure and no individuals are iden tified explicitly in these reports or in the subsequent safety investi gations.
From page 152...
... Instead, their purpose is to identify vulnerabilities and hazards that can then be prioritized for the institution of corrective actions to mitigate the identified risks. The committee believes systems that encourage both vendors and users to report health IT–related adverse events are needed to improve the safety of patient care.
From page 153...
... As a result, shared knowledge of such events is incomplete and any effort to understand and prevent such events from occurring in the future is far from optimal. The committee believes it is in the best interest of the public for deidentified, verified health IT–related adverse events to be released transparently to the public for the purpose of shared learning, and the responsibility for identifying and reporting events lies with both vendors and users of health IT.
From page 154...
... A mandate entails expectations that vendors will report adverse events and that some sort of penalty would result for failing to report events. To create a program of mandatory reporting, direction will need to come from a federal entity with adequate expertise, capacity, and authority to act.
From page 155...
... FDA, NASA, AHRQ, states, and others are all able to collect users' reports of health IT–related adverse events. As discussed earlier, the complexity of health IT differs so greatly from FDA's current portfolio that the committee believes FDA would have to institute approaches that are different from their current approach were they to oversee a health IT–related adverse event reporting program for users.
From page 156...
... These barriers inhibit not only users' abilities to report to the government, but also sharing of health IT–related adverse events with vendors, other users, and consumer groups. To have an adequate system of reporting and shared learning, each of these barriers needs to be addressed.
From page 157...
... Aggregation of reports of health IT–related adverse events -- reports of deaths, serious injury, or unsafe conditions -- should be conducted to identify patterns. Analyses of these reports can lead to identification of specific patient safety risks, potentially particular to a specific vendor or product.
From page 158...
... Additionally, standards of analysis may not be used in the same way across multiple entities, calling into question the reliability of the analyses conducted. Ideally, as depicted in Figure 6-3, reports of health IT–related adverse events or unsafe conditions from both users and vendors would be aggregated and analyzed by a single entity that would identify reports for immediate investigation.
From page 159...
... Body Investigate Adverse Events and Provide Unsafe Conditions Feedback Feedback FIGURE 6-3 Reporting system for learning and improving patient safety.
From page 160...
... A unique knowledge base is needed to understand thoroughly and diagnose ways to improve the interface between health care delivery and health IT, which, as discussed in Chapter 3, is extraordinarily complex and requires the understanding of a large number of sociotechnical domains. The committee considered a variety of alternatives to objectively analyze reports of unsafe events as well as conduct investigations into health IT–related adverse events in the way the committee envisions.
From page 161...
... • Lessons from these investigations need to be shared broadly from a respected source so that future adverse events can be averted. To truly improve patient safety, a new approach is needed.
From page 162...
... The committee believes that an independent, federal entity is the best option to provide a platform to support shared learning at a national level. The entity would have the following functions: • Aggregate reports of health IT–related adverse events from at least vendors and users; • Analyze the aggregated reports to identify patterns; • Investigate reports of health IT–related patient deaths or serious injury; • Investigate trends of reports of unsafe conditions; • Recommend corrective actions to the Secretary of Health and Human Services;
From page 163...
... Multiple factors contribute to unsafe conditions and adverse events, making it potentially difficult to differentiate between health IT–related or other factors until an investigation has been conducted. If a broader system for all adverse events is created, the spirit of the committee's recommendations should be recognized and considered.
From page 164...
... Taking a phased, risk-based approach can help address this concern. FDA has chosen to not exercise regulatory authority as discussed previously, and controversy exists over whether some health IT products such as EHRs should be considered medical devices.
From page 165...
... Proactive measures have to be taken to ensure health IT products are developed and implemented with safety as a primary focus through the development of industry-wide measures, standards, and criteria for safety. Surveillance mechanisms will be available to identify, capture, and investigate adverse events to improve the safety of health IT continually.
From page 166...
... 2011. "Global trigger tool" shows that adverse events in hospitals may be ten times greater than previously measured.
From page 167...
... 2002. Reporting of adverse events.
From page 168...
... 1999. The perceived effectiveness of total quality management as a tool for quality improvement in emergency medicine.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.