Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 125
6
A Shared Responsibility for
Improving Health IT Safety
As discussed in Chapter 2, the use of health IT in some areas has sig-
nificantly improved the quality of health care and reduced medical errors.
Continuing to use paper medical records can place patients at unnecessary
risk for harm and substantially constrain the country’s ability to reform
the health care system. However, there are clearly cases in which harm
has occurred associated with new health IT. The committee believes safer
health care is possible in complex, dynamic environments—which are the
rule in health care—only when achieving and maintaining safety is given
a high priority.
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 pri-
vate sectors acknowledge that safety is a shared responsibility. Actions are
needed to correct the market and commit to ensuring the safety of health
IT. A better understanding and acknowledgement of the risks associated
with health IT and its use, as well as how to maximize the benefits, are
needed. An example of a new kind of error that can occur with IT which
did not occur previously is the “adjacency error,” in which a provider se-
lects an item next to the one intended from a pulldown menu, for example
picking “penicillamine” instead of “penicillin.” Such errors occur in many
products, but effective solutions have not yet generally been fielded. This
chapter details the actions to be taken by both the public and private sectors
that the committee believes will be necessary for the creation of an environ-
125
OCR for page 126
126 HEALTH IT AND PATIENT SAFETY
ment in which IT improves safety overall, and the new problems created by
health IT are minimized.
THE ROLE OF THE PRIVATE SECTOR:
PROMOTING SHARED LEARNING ENVIRONMENTS
This chapter broadly defines the private sector to include health IT ven-
dors, insurers, and the organizations that support each of these groups (e.g.,
professional societies). Health care organizations, health professionals, and
patients and their families are also considered part of the private sector.
The public sector generally refers to the government. Operationally, the
line between the private and public sectors is not completely clear, because
some organizations operate in both sectors.
The current environment in which health IT is designed and used does
not adequately protect patient safety. However, the private sector has the
ability to drive innovation and creativity, generating the tools to deliver
the best possible health care and directly improve safety. In this regard, the
private sector has the most direct responsibility to realign the market, but
it will need support from the public sector.
The complexity and dynamism of health IT requires that private-sector
entities work together through shared learning to improve patient safety.
Manufacturers and health professionals have to communicate their capa-
bilities and needs to each other to facilitate the design of health IT in ways
that achieve maximum usability and safety. Patients and their families need
to be able to interact seamlessly with health professionals through patient
engagement tools. Health care organizations ought to share lessons learned
with each other to avoid common patient safety risks as they adopt highly
complex health IT products.
However, today’s reality is that the private sector currently consists of a
broad variety of stakeholders lacking a uniform approach, and potentially
misaligned goals. The track record of the private sector in responding to
new safety issues created by IT is mixed. Although nearly all stakeholders
would endorse the broad goals of improving the quality and safety of pa-
tient care, many stakeholders (particularly vendors) are faced with compet-
ing 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 stake-
holders, can optimize patient safety and minimize harm.
As discussed in Chapters 4 and 5, there are many opportunities for the
private sector to improve safety as it relates to health IT, but to date, little
action has been taken. Insufficient action by the private sector to improve
patient safety can endanger lives. The private sector must play a major role
OCR for page 127
127
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
in addressing this urgent need to better understand risks and benefits associ-
ated with health IT, as well as strategies for improvement and remediation.
As it stands now, there is a lack of accountability on the part of vendors,
who are generally perceived to shift responsibility and accountability to us-
ers through specific contract language (Goodman et al., 2010). As a result,
the committee believes a number of critical gaps in knowledge need to be
addressed immediately, including the lack of comprehensive mechanisms
for identifying patient safety risks, measuring health IT safety, ensuring safe
implementation, and educating and training users.
Developing a System for Identifying Patient Safety Risks
The committee believes that transparency, characterized by develop-
ing, identifying, and sharing evidence on risks to patient safety, is essential
to a properly functioning market where users would have the ability to
choose a product that best suits their needs and the needs of their patients.
However, the committee found sparse evidence pertaining to the volume
and types of patient safety risks related to health IT. Indeed, the number of
errors reported both anecdotally and in the published literature was lower
than the committee anticipated. This led primarily to the sense that poten-
tially harmful situations and adverse events caused by IT were often not
recognized and, even when they were recognized, usually not reported. 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 profes-
sionals to do so (Classen et al., 2011; Cullen et al., 1995).
Information technology can assist organizations in identifying, trouble-
shooting, and handling health IT–related adverse events. Digital forensic
tools (e.g., centralized logging, regular system backups) can be used to
record data during system use. After an adverse event occurs, recorded
data—such as log-in information, keystrokes, and how information is trans-
ported throughout the network—can be used to identify, reconstruct, and
understand in detail how an adverse event occurred (NIST, 2006).
Because of the diversity of health IT products and their differing effects
on various clinical environments, it is essential that users share detailed
information with other users, researchers, and the vendor once information
regarding adverse events is identified. Examples of such information include
screenshots or descriptions of potentially unsafe processes that could help
illustrate how a health IT product threatened patient safety. However, as
discussed in Chapter 2, users may fear that sharing this information may
violate nondisclosure clauses and vendors’ intellectual property, exposing
them to liability and litigation. Although there is little evidence on the
OCR for page 128
128 HEALTH IT AND PATIENT SAFETY
impact of such clauses, the committee believes users may be less likely to
share information necessary to improve patient safety, given these clauses.
If it is clearly understood that transparently sharing health IT issues
with the public is for the purpose of patient safety, vendors ought to agree
to remove such restrictions from contracts and work with users to explicitly
define what can be shared, who it can be shared with, and for what pur-
poses. 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 negoti-
ate terms that allow them to share information related to patient safety
risks, vendors may be more likely to exclude such clauses. Furthermore,
if it were easier to know which vendors had standard contracts that al-
lowed for sharing, users might be more likely to select those vendors.
However, users—particularly smaller organizations—are not part of a “co-
hesive community” with the legal expertise or knowledge to negotiate such
changes. Therefore, the committee believes the Secretary of the Department
of Health and Human Services (HHS) should provide tools to motivate
vendors and empower users to negotiate contracts that allow for sharing
of patient safety–related details and improved transparency. The Secretary
ought to investigate what other tools and authorities would be required to
ensure the free exchange of patient safety–related information.
Recommendation 2: The Secretary of HHS should ensure insofar as
possible that health IT vendors support the free exchange of informa-
tion about health IT experiences and issues and not prohibit sharing
of such information, including details (e.g., screenshots) relating to
patient safety.
The committee recognizes that, short of Congressional and regula-
tory action, the Secretary cannot guarantee how contracts are developed
between two private parties. However, the committee views prohibition of
the free exchange of information to be the most critical barrier to patient
safety and transparency. The committee urges the Secretary to take vigorous
steps to restrict contractual language that impedes public sharing of patient
safety–related details. Contracts should be developed to allow explicitly for
sharing of health IT issues related to patient safety. One method the Secre-
tary could use is to ask the Office of the National Coordinator for Health
Information Technology (ONC) to create a list of vendors that satisfy this
1 Personal communication, E. Belmont, MaineHealth, September 21, 2011.
OCR for page 129
129
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
requirement and/or those that do not. If such a list were available, users
could more easily choose vendors that allow patient safety–related details
of health IT products to be shared. Having such a list could also motivate
vendors to include contractual terms that allow for sharing of patient
safety–related details and, as a result, be more competitive to users. The
ONC could also consider creating minimum criteria for determining when
a contract adequately allows for sharing of patient safety–related details.
These criteria need to define the following:
• What situations allow for sharing patient safety–related details of
health IT products;
• What content of health IT should be shareable;
• Which stakeholders the information can be shared with, including
other users, consumer groups, researchers, and the government;
and
• What the limitations of liability are when such information is shared.
Private certification bodies such as the ONC-authorized testing and
certification bodies (ONC-ATCBs)2 could also promote the free exchange
of patient safety-related information. This could be implemented for ex-
ample through the creation of a new type of certification that requires this
information to be shared.
The Secretary could ask the ONC to develop model contract language
that would affirmatively establish the ability of users to provide content
and contextual information when reporting an adverse event or unsafe
condition. Additionally, HHS could educate users about these contracts and
develop guidance for users about what to look for before signing a contract.
This education could potentially be done through the ONC’s regional ex-
tension centers or the Centers for Medicare & Medicaid Services’s (CMS’s)
quality improvement organizations. This effort could also be supported by
various professional societies.
To identify how pervasive these clauses are, the Secretary may need to
conduct a review of existing contracts. Although the Secretary may not be
privy to vendor–purchaser contracts, HHS could conduct a survey or ask
vendors to voluntarily share examples of their contract language. Under-
standing the magnitude of these clauses would be a critical first step.
Once this information is available, comparative user experiences can be
made public. There is currently no effective way for users to communicate
their experiences with a health IT product. 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.
OCR for page 130
130 HEALTH IT AND PATIENT SAFETY
reviews appear on online forums and other similar guides, while indepen-
dent tests are conducted by Consumer Reports and others. These reviews
allow users to better understand the products they might be purchasing.
Perhaps the more powerful aspect of users being able to rate and compare
their experiences with products is the ability to share and report lessons
learned. Comparative user experiences for health IT safety need to be cre-
ated to enhance communication of safety concerns and ways to mitigate
potential risks.
To gather objective information about health IT products, researchers
should have access to both test versions of software provided by vendors
and software already integrated in user organizations. Documentation for
health IT products such as user manuals also could be made available to
researchers. Resources should be available to share user experiences and
other measures of safety specifying data from health IT products. The pri-
vate sector needs to be a catalyzing force in this area, but governance from
the public sector may be required for such tools to be developed.
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). Professional associations of
providers could also play this role. One of the tools the ONC could provide
to facilitate the implementation of Recommendation 3 is the development
of a uniform format for making these reports, which could be coordinated
through the Common Formats.3 However, it is important to note that a
public-sector entity could also lead change in this regard.
Finally, a more robust and comprehensive infrastructure is needed for
providing technical assistance to users who may need advice or training to
safely implement health IT products. Shared learning between users and
vendors in the form of feedback about how well health IT products are
working can help improve the focus on safety and usability in the design of
health IT products and identification of performance requirements. Tools to
foster this feedback in an organized way are needed to promote safety and
quality. The learning curve for safely using health IT–assisted care varies
widely and technical assistance needs to be provided to users at all levels.
3 The Common Formats are coordinated by the Agency for Healthcare Research and Quality
(AHRQ) in an effort to facilitate standardized reporting of adverse events by creating general
definitions and reporting formats for widespread use (AHRQ, 2011a).
OCR for page 131
131
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
Measuring Health IT Safety
Another area the committee identified as necessary for making health
IT safer is the development of measures. As is often said in quality improve-
ment, you can only improve what you measure. Currently, few measures
address patient safety as it relates to health IT; without these measures, it
will be very difficult to develop and test strategies to ensure safe patient
care. Although there has been progress in developing general measures of
patient safety, the committee concluded that safety measures focusing on
the impact of health IT must go beyond traditional safety measures (as
discussed in Chapter 3) and are urgently needed.
Measures of health care safety and quality are generally developed by
groups such as professional societies and academic researchers and undergo
a voluntary consensus process before being adopted for widespread use.
During the measure development process, decisions need to be made such
as identifying what metrics can be used as an indicator of health IT safety,
specifications of the metrics, and the criteria against which measures can be
evaluated. Policies for measure ownership and processes for evaluating and
maintaining measures will also need to be created. 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).
The committee believes a consensus-based collaborative effort that
would oversee development, application, and evaluation of criteria for
measures and best practices of safety of health IT—a Health IT Safety
Council—is of vital need. For example, the council could be responsible
for identifying key performance aspects of health IT and creating a priori-
tized agenda for measure development. Given that the process for develop-
ing health IT safety metrics would be similar to developing measures of
health care safety and quality, a voluntary consensus standards organization
would effectively be able to house the recommended council. Because of
the ubiquity and complexity of health IT, all health IT stakeholders ought
to be involved in the development of such criteria. HHS ought to consider
providing the initial funding for the council because the need for measures
of safety of health IT is central to all stakeholders. The more costly process
of maintaining measures ought to be funded by private-sector entities.
Recommendation 4: The Secretary of HHS should fund a new Health
IT Safety Council to evaluate criteria for assessing and monitoring the
safe use of health IT and the use of health IT to enhance safety. This
council should operate within an existing voluntary consensus stan-
dards organization.
OCR for page 132
132 HEALTH IT AND PATIENT SAFETY
One existing organization with a strong history of convening groups and
experience with endorsing health care quality and performance measures
that could guide this process is the National Quality Forum (NQF). The
NQF is a nonprofit organization whose mission is to develop consensus on
national priorities and endorse standards for measuring and publicly report-
ing on health care performance based on measures submitted from measure
developers. Of particular note, the NQF hosts eight member councils, whose
purposes are to build consensus among council members toward advancing
quality measurement and reporting (NQF, 2011). 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]), vendors (e.g., individually and
through societies such as the Healthcare Information and Management Sys-
tems Society [HIMSS]), and insurers—to identify what types of metrics are
needed and the criteria for doing so. Measures should be NQF-endorsed,
a process that applies nationally accepted standards and criteria. The NQF
could provide guidance in identifying criteria against which to develop
health IT safety measures to help gain consensus on the right set of policies.
The ensuing task of developing measures of health IT safety needs to be
undertaken by a variety of entities. To accomplish this, some research will
be needed for measure development because good measures currently do
not exist; these efforts should be supported by the Agency for Healthcare
Research and Quality (AHRQ), the National Library of Medicine, and the
ONC, as discussed in Recommendation 1. Health care organizations and
even vendors could partner with more traditional measurement develop-
ment organizations, for example the NCQA can create measures that would
by default be subjected to the NQF consensus approval process.
Ensuring Safer Implementation
Efforts to safely implement health IT must address three phases: pre-
implementation, implementation, and postimplementation of health IT.
Preimplementation
Vendors, with input from users, play the most significant role in the
preimplementation phase of health IT. Vendors ought to be able to assert
that their products are designed and developed in a way that promotes
patient safety. Currently, health IT products are held to few standards with
respect to both design and development. Although it is typically the role of
standards development organizations such as the American National Stan-
dards Institute, the Association for the Advancement of Medical Instrumen-
tation, Health Level 7 (HL7), and the Institute of Electrical and Electronics
OCR for page 133
133
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
Engineers to develop such standards, criteria, and tests, a broader group
of stakeholders including patients, users, and vendors should participate
in creating safety standards and criteria against which health IT ought to
be tested.
Vendors are currently being required by the ONC to meet a specific set
of criteria in order for their products to be certified as eligible for use in
HHS’s meaningful use program. These criteria relate to clinical functional-
ity, security, and interoperability and may be helpful for but not sufficient
to ensure health IT–related safety. The American National Standards Insti-
tute, as the body that will accredit organizations that certify health IT, and
certification bodies such as the Certification Commission for Healthcare
Information Technology serve a vital function in this regard because they
have the ability to require that patient safety be an explicit criterion for
certification of EHRs. Doing so would be an important first step.
Another step that can be taken by the private sector prior to implemen-
tation of health IT is for vendors and manufacturers to declare they have
addressed safety issues in the design and development of their products,
both self-identified issues and those detected during product testing. Such
a declaration ought to include the safety issues considered and the steps
taken to address those issues. A similar declaration for usability has been
supported by the National Institute of Standards and Technology (NIST),
which has developed a common industry format for health IT manu-
facturers to declare that they have tested their products for usability and
asks manufacturers to show evidence of usability (NIST, 2010). Declara-
tions also ought to be made with respect to vendor tests of a health IT
product’s reliability and response time, both in vitro and in situ (Sittig and
Classen, 2010). Such declarations could provide users and purchasers of
health IT with information as they determine which products to acquire.
Additionally, vendors can help mitigate safety risks by employing high-
quality software engineering principles, as discussed in Chapter 4.
Usability represents an exceptionally important issue overall, and un-
doubtedly affects safety. However, it would be challenging to mandate us-
ability. Although some efforts are beginning to develop usability standards
and tools as discussed in Chapter 4, more publicly available data about and
testing regarding usability would be helpful in this area. EHRs should in-
creasingly use standards and conformance testing to ensure that data from
EHRs meet certain standards and would be readable by other systems to
enable interoperability is practical.
Besides providing feedback to vendors about their products, users
also have important responsibilities for safety during the preimplementa-
tion phase. Users need to make the often difficult and nuanced decision of
choosing a product to purchase, as discussed in Chapter 4. If a product
does not meet the needs of the organization and does not appropriately
OCR for page 134
134 HEALTH IT AND PATIENT SAFETY
interface with other IT products of the organization, safety problems can
arise. Similarly, organizations need to be ready to adopt a new product in
order for the transition to be successful.
Implementation
Industry-developed recommended (or “best”) practices and lessons
learned ought to be shared. There are instances where generic lessons are
learned and recommended practices can be shared between health profes-
sionals through mediums such as forums, chat rooms, and conferences.
Lessons can also be shared through training opportunities such as continu-
ing professional development activities. Questions arise such as whether to
roll out a health IT product throughout an entire health care organization
at once or in parts. Health care providers are continually attempting to de-
termine the most effective configuration of health IT products for their own
specific situations (e.g., drug interactions should be displayed as warnings
in such a way that clinicians do not suffer from alert fatigue, leading clini-
cians to turn off all alerts). A user’s guide to acquisition and implementation
ought to be developed by both the private and public sectors. Some efforts
are currently under way, including programs at HIMSS and the ONC, but
more work is needed, and the committee believes that such user’s guides
should receive public support, though they might be developed by private
entities.
Opportunities also exist for users to learn more about safer implemen-
tation and customization of health IT products. For example, what lessons
have been learned regarding customization of specific health IT products?
What experiences have others had integrating a specific pharmacy system
with a particular EHR? Lessons from such experiences, once they are widely
shared, can greatly impact implementation. It will be critical for users and
vendors to communicate as health IT products are being implemented to
ensure they are functioning correctly and are fitting into clinical workflow.
Postimplementation
Similar to the preimplementation and implementation phases, stan-
dards and criteria will be necessary to ensure that users have appropriately
implemented health IT products and integrated them into the entire socio-
technical system. In the postimplementation phase, the largest share of the
work involves health professionals and organizations working with vendors
to ensure patient safety.
Postimplementation tests, as discussed in Chapter 4, will be essential
to monitoring the successful implementation of health IT products. Few
tests currently exist, and more will need to be developed. For example, self-
OCR for page 135
135
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
assessments could monitor the product’s down time, review the ability to
perform common actions (e.g., review recent lab results), and record patient
safety events. Ongoing tests of how the product is operating with respect to
the full sociotechnical system could identify areas for improvement to ensure
the product fits into the clinical workflow safely and effectively (Classen
and Bates, 2011; Sittig and Classen, 2010; Sittig and Singh, 2009). These
tests are also a way for users to work with vendors to ensure that products
have been installed correctly. Developers of these postimplementation tests
should gather input from health care organizations, clinicians, vendors, and
the general public. Similar to how organizations such as the Leapfrog Group
validate tests for effective implementation of computerized provider order
entry systems, an independent group ought to validate test results for imple-
mentation of all health IT. Conducting these tests is so important for ensur-
ing safety that they ought to become a required standard and linked to a
health care organization’s accreditation through The Joint Commission or
others. Periodic inspections could also be conducted onsite by these external
accreditation organizations (Sittig and Classen, 2010). Other ways to require
these tests be performed include actions from the public sector, including
regulation, such as including postimplementation testing in meaningful use
criteria, but the committee feels postimplementation testing is too important
to be tied only to the initiatives of a particular government program. These
issues of safer implementation and safer use will continue to be an ongoing
challenge with each new iteration of software and will continue to be an
important area of focus long after the meaningful use program is completed.
Training Professionals to Use Health IT Safely
Education and training of the workforce is critical to the successful
adoption of change. 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. This allows health professionals to
transfer context- and product-specific skills, and therefore to be safer and
more effective. For example, a team of clinicians using a new electronic
pharmacy system needs to be trained on the functionalities of the specific
technology. Otherwise, the team is susceptible either to being naïve to the
abilities of the technology or to unnecessarily developing workarounds that
may undermine the larger sociotechnical system.
As discussed in earlier chapters, basic levels of competence, knowl-
edge, and skill are needed to navigate the highly complex implementation
of health IT. Because health IT exists at the intersection of multiple disci-
plines, a variety of professionals will need training in this relatively new
OCR for page 158
158 HEALTH IT AND PATIENT SAFETY
A Reporting System for Learning and Improving Patient Safety
On their own, vendors and users generally do not have the broad ex-
pertise needed to conduct investigations as envisioned by the committee.
Vendors and users also may not be impartial arbiters of why an adverse
event occurred. As a result, external methods are needed to conduct rigor-
ous investigations of health IT–related adverse events.
Reports could be aggregated and analyzed by multiple entities, such as
the PSOs, but trends in data may not be as easily identified if spread out
among the more than 80 PSOs because of the smaller number of reports
each organization would receive. 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.
Reports to this entity would have to include identifiable data to allow
for investigators to follow up in the event the reported incident requires
investigation, but, as discussed previously, full confidentiality protections
must be applied to the reports. Reports would need to be received in an
identifiable manner from the PSOs or another collecting agency and with
enough information to investigate (e.g., specific vendor, model number).
The entity would have the discretion to investigate two categories of
reports: (1) novel reports that result in death or serious injury and (2) trends
of reports of unsafe conditions (e.g., multiple health care organizations find
that a specific pharmacy system accepts only 100 characters of a particular
EHR’s notes section that allows 125 characters, resulting in the incorrect
filling of orders). Prioritization among the reports would be determined
on a risk-based hazard analysis. Cases resulting in death or serious injury
should be investigated immediately. Reports should be kept confidential
and nonpunitive for the purposes of learning. Reports of unsafe conditions
should be analyzed and monitored continually and investigated using a risk-
based hazard analysis. Which reports to investigate ought to be determined
by the explicit risk-based prioritization system that the investigatory entity
employs. Reports by vendors should already contain identifiable data.
In keeping with the principle of transparency, reports and results of
investigations should be made public. Public release of results of investiga-
tions could build off the NTSB process, which separates facts discovered by
the investigators from opinions and conclusions drawn by the investigators.
A feedback loop from the investigatory body back to both the vendors and
users is essential to allow groups to rectify any systemic issues that were
found to introduce risk into their systems.
OCR for page 159
Reporting Collecting Aggregating, Analyzing, and Investigating Disclosing
Aggregate
User Reports Vendor Reports
Users
PSO Public
Analyze
(Voluntary)
– Researchers
Reports
Vendors Collecting – Consumers
(Mandatory) Body
Investigate
Adverse Events and Provide
Unsafe Conditions Feedback
Feedback
FIGURE 6-3
Reporting system for learning and improving patient safety.
159
OCR for page 160
160 HEALTH IT AND PATIENT SAFETY
Potential Actors
It is the intent of the committee to build on the current patient safety
environment and to maximize the potential for all stakeholders to have a
part in ensuring patient safety. However, for the reasons mentioned above,
the current system does not adequately address the significant needs of a
comprehensive process to learn from health IT–related patient safety risks.
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 ana-
lyze reports of unsafe events as well as conduct investigations into health
IT–related adverse events in the way the committee envisions. The alterna-
tives considered include FDA, AHRQ, the CMS, the ONC, and entities in
the private sector.
• FDA is largely an oversight entity. Adding investigative responsi-
bilities of the nature envisioned by the committee would be at odds
with its oversight functions. Additionally, FDA lacks the resources
in terms of capacity and expertise, limiting its ability to act in this
area.
• AHRQ primarily supports research and technical assistance activi-
ties regarding quality and safety. It is not an oversight or inves-
tigative agency. AHRQ is also not an active implementer and is
not operationally oriented. For AHRQ to take on the functions
envisioned by the committee would require a complete change in
the agency’s charge and internal expertise.
• The CMS is an administrative agency that has demonstrated its
leverage with users of health IT through the development of the
EHR incentive program and conditions of participation. These
programs, while important, contain punitive elements and are inap-
propriate for completing the aggregative, analytic, and investigative
functions described above. The CMS also has little internal exper-
tise relating to clinical workflow and use of technology to support
cognition and therefore does not have the infrastructure needed to
support these tasks. Additionally, while the CMS could potentially
serve in this role, the CMS’s authority focuses on providers associ-
ated with Medicare and Medicaid and is not as expansive as the
committee believes is needed.
• The ONC coordinates health IT efforts and influences the develop-
ment of policy related to health IT but has no formal authority in
this area; it is not an operating division of HHS. It is not clear to
OCR for page 161
161
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
the committee that the ONC has the clinical and operations exper-
tise to conduct investigations of health IT–related adverse events.
• Privatesector organizations such as The Joint Commission, the
NCQA, and the NQF play an important role in ensuring safety.
However, these organizations are mostly dependent on short-term
funding streams, often seeking “soft money” to sustain specific
projects and programs. As a result, programmatic content may be
shaped in part by funders. Moreover, these groups—even working
in collaboration with one another—may not have the far-reaching
influences of a federal entity and do not have the mandate or
breadth to be able to conduct such investigations at a national
level. These groups also do not possess the expertise and ability to
properly investigate these issues.
Investigating patient safety incidents related to health IT does not
match the internal expertise of any existing entity. Given the status quo, the
committee concludes that no existing entity has the necessary attributes to
perform the crucial function of investigating health IT–related patient safety
incidents as envisioned by the committee. The needed functions are under
the jurisdiction of multiple federal agencies, and efforts are uncoordinated
and are not as comprehensive as a safety-oriented system ought to be. A
multiagency structure could be envisioned, but as discussed previously,
oversight and investigative functions should not be housed in the same
entity. The committee concludes the envisioned necessary functions cannot
be realized solely through current structures, and a new entity is needed
that can pull together the following desired goals in an integrated fashion
in a way current alternatives cannot achieve:
• A comprehensive system for identifying and investigating deaths,
injuries, and unsafe conditions has to be separated explicitly from
oversight functions.
• Broad categories of expertise are required to investigate an adverse
event fully.
• Vendors and users need to be held accountable publicly for patient
deaths, injuries, and potentially unsafe conditions.
• A streamlined approach is needed to reduce wasteful duplication
and inconsistencies.
• 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. The commit-
tee believed that the experiences of other industries such as transportation
and nuclear energy in creating the NTSB and the NRC were instructive, and
OCR for page 162
162 HEALTH IT AND PATIENT SAFETY
concluded that the development of an independent, federal entity was best
suited to performing the needed above-described analytic and investigative
functions for health IT–related adverse events in a transparent, nonpunitive
manner.
The committee envisions an entity that would be similar in structure
to the NTSB or the NRC, which are both independent federal agencies cre-
ated by and reporting directly to Congress. Among other responsibilities,
these entities conduct investigations, for the purpose of ensuring safety. The
NTSB is a nonregulatory agency that does not establish fault or liability
in the legal sense but investigates incidents. The NRC is a regulatory body
that has the ability to issue fines and fees. The committee considered both
agencies and concluded the NTSB to be most similar to the needs of health
IT–assisted care.
An independent, federal entity analogous in form and function to the
NTSB is needed. This entity would not have enforcement power and would
be nonpunitive. Instead, it would have the authority to conduct investiga-
tions and, upon their completion, make recommendations. The NTSB
makes nonbinding recommendations to the Secretary of the Department of
Transportation, who then must state within 90 days whether the depart-
ment intends to perform the recommended procedures in total, carry the
recommendations out in part, or refuse to adopt the recommendation. In
this case, an entity would make similar recommendations to the Secretary of
HHS. Although delivering nonbinding recommendations can be described
by some as a flaw, the committee believes that the flexibility it provides is
a strength, allowing for the health care organizations, vendors, and exter-
nal experts to determine the best course forward collectively. If requested
by the Secretary, the entity could also perform other functions, such as
coordinating with existing bodies, both public and private, as appropri-
ate. Investigations could involve representatives from all impacted parties,
including vendors and users involved in the incident, as well as experts in
the various sociotechnical dimensions of health IT safety. 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;
OCR for page 163
163
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
• Provide feedback to vendors and users following investigations;
and
• Disclose results of the investigations to the public, including re-
searchers and consumers.
Recommendation 8: The Secretary of HHS should recommend that
Congress establish an independent federal entity for investigating
patient safety deaths, serious injuries, or potentially unsafe conditions
associated with health IT. This entity should also monitor and analyze
data and publicly report results of these activities.
It is also important to recognize that the line between health IT–related
adverse events and other adverse events will likely become increasingly
blurry. 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 recommenda-
tions should be recognized and considered.
NEXT STEPS
Patients must be kept safe in the midst of the current large-scale rollout
of health IT. While it is clear to the committee that the market has failed to
keep patients safe with respect to health IT, the committee believes trans-
parency is the key to improving safety. To truly address health IT safety,
many actions will be needed to correct the market; ways to improve flow of
communication and correct the market have to be created carefully. When
combined, removing contractual restrictions, establishing public reporting,
and having a system in place for independent investigations can be a power-
ful force for improving patient safety.
Achieving transparency, safer health IT products, and safer use of
health IT will require the cooperation of all stakeholders. Without more
information about the magnitude and types of harm, the committee con-
cluded that other mechanisms were necessary to understand how to best
approach health IT safety.
The committee believes the current state of safety and health IT is not
acceptable; specific actions are required to improve the safety of health
IT. The first eight recommendations are intended to create conditions and
incentives to encourage substantial industry-driven change without formal
regulation. However, because the private sector to date has not taken sub-
stantive action on its own, the committee believes a follow-up recommen-
dation is needed to regulate health IT formally if the actions recommended
OCR for page 164
164 HEALTH IT AND PATIENT SAFETY
to the private and public sectors are not effective.11 If the first eight recom-
mendations are determined by the Secretary of HHS to be not effective, the
Secretary should direct FDA to exercise all authorities to regulate health IT.
The committee was of mixed opinion on how FDA regulation would
impact the pace of innovation but identified several areas of concern regard-
ing immediate FDA regulation. The current FDA framework is oriented
toward conventional, out-of-the-box, turnkey devices. However, health
IT has multiple different characteristics, suggesting that a more flexible
regulatory framework will be needed in this area to achieve the goals of
product quality and safety without unduly constraining market innovation.
For example, as a software-based product, health IT has a very different
product life cycle than conventional technologies. These products exhibit
great diversity in features, functions, and scope of intended and actual
use, which tend to evolve over the life of the product. 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. If the Secretary deems it necessary to regulate EHRs and
other health IT products not currently regulated by FDA, clear determina-
tions will need to be made about whether all health IT products classify as
medical devices for the purposes of regulation. The committee also believes
that if FDA regulation is deemed necessary, FDA will need to commit suf-
ficient resources and add capacity and expertise to be effective.
The ONC and the Secretary should examine progress critically toward
achieving safety and, if needed, determine when to move to the next stage.
HHS should report annually to Congress and the public on the progress
of efforts to improve the safety of health IT beginning 12 months from the
release of this report. In these reports, the Secretary should make clear why
she does or does not believe further oversight actions are needed. In parallel,
the Secretary should ask FDA to begin planning the framework needed for
potential regulation consistent with Recommendations 1 through 8 so that,
if she deems FDA regulation to be necessary, the agency will be ready to
act, allowing for the protection of patient safety without further delay. FDA
will need to coordinate these efforts with the actors identified in Recom-
mendations 1 through 8, including AHRQ and the ONC, among others. In
addition, the Secretary will also need to devise new strategies to stimulate
the private sector to meet its responsibility of ensuring patient safety. The
committee recognizes that not all of its recommendations can be acted on
by the Secretary alone and that some will require congressional action.
11 One member disagrees with the committee and would immediately regulate health IT as
a Class III medical device, as outlined in Appendix E.
OCR for page 165
165
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
Recommendation 9a: The Secretary of HHS should monitor and publicly
report on the progress of health IT safety annually beginning in 2012. If
progress toward safety and reliability is not sufficient as determined by
the Secretary, the Secretary should direct FDA to exercise all available
authorities to regulate EHRs, health information exchanges, and PHRs.
Recommendation 9b: The Secretary should immediately direct FDA
to begin developing the necessary framework for regulation. Such a
framework should be in place if and when the Secretary decides the
state of health IT safety requires FDA regulation as stipulated in Rec-
ommendation 9a above.
CONCLUSION
Today the nation is just scaling up with EHRs, and, as a result, the
health IT environment is both very dynamic and also stressed. Patient
safety is too important to ignore, but clear routes to solid policies that
will improve performance are still wanting. Because of the lack of concrete
evidence about how to best improve patient safety, the private and public
sectors should work together to take the first steps toward identifying the
data and building an evidence base for improving health IT–related patient
safety. Lessons should be learned from other industries focusing on safety.
Although it is important to recognize that none of those reporting systems
is perfect, a critical lesson to be learned from these experiences is that safety
demands systems of continual learning.
Health IT is a quickly changing field, particularly with respect to
outpatient services, and products are being developed continually for the
improvement of patient outcomes and more effective care delivery. The
functions and types of health IT–related adverse events requiring analysis
and investigation will change over time. To this end, the approaches identi-
fied in this report should be monitored continually and revised as needed.
The identified actor or set of actors should be given the flexibility and lati-
tude to amend its charge as appropriate.
Creating an infrastructure that supports shared learning about and im-
proving the safety of health IT is needed to achieve better health care. Pro-
active 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. Transparency and
cooperation between the private and public sectors is the key to creating
the necessary infrastructure to build safer systems that will lead to better
care for all Americans.
OCR for page 166
166 HEALTH IT AND PATIENT SAFETY
REFERENCES
AHRQ (Agency for Healthcare Research and Quality). 2011a. Common formats. http://www.
pso.ahrq.gov/formats/commonfmt.htm (accessed May 8, 2011).
AHRQ. 2011b. Georgraphic directory of listed patient safety organizations. http://www.pso.
ahrq.gov/listing/geolist.htm (accessed August 9, 2011).
American Society for Quality. 2011. The history of quality—overview. http://asq.org/learn-
about-quality/history-of-quality/overview/overview.html (accessed June 17, 2011).
Bagian, J. P., C. Lee, J. Gosbee, J. DeRosier, E. Stalhandske, N. Eldridge, R. Williams, and
M. Burkhardt. 2001. Developing and deploying a patient safety program in a large
health care delivery system: You can’t fix what you don’t know about. Joint Commission
Journal on Quality Improvement 27(10):522-532.
Chow-Chua, C., M. Goh, and T. B. Wan. 2003. Does ISO 9000 certification improve business
performance. International Journal of Quality & Reliability Management 20(8):936-953.
Classen, D. C., and D. W. Bates. 2011. Finding the meaning in meaningful use. New England
Journal of Medicine 365(9):855-858.
Classen, D. C., R. Resar, F. Griffin, F. Federico, T. Frankel, N. Kimmel, J. C. Whittington,
A. Frankel, A. Seger, and B. C. James. 2011. “Global trigger tool” shows that adverse
events in hospitals may be ten times greater than previously measured. Health Affairs
30(4):581-589.
Cohen, L. 1979. Innovation and atomic energy: Nuclear power regulation, 1966-present. Law
and Contemporary Problems 43(1):67-97.
Cullen, D. J., D. W. Bates, S. D. Small, J. B. Cooper, A. R. Nemeskal, and L. L. Leape. 1995.
The incident reporting system does not detect adverse drug events: A problem for quality
improvement. Joint Commission Journal on Quality Improvement 21(10):541-548.
Dahiya, S., R. K. Khar, and A. Chhikara. 2009. Opportunities, challenges and benefits of
using HACCP as a quality risk management tool in the pharmaceutical industry. Quality
Assurance Journal 12(2):95-104.
DeRosier, J., E. Stalhandske, J. P. Bagian, and T. Nudell. 2002. Using health care failure mode
and effect analysis: The VA National Center for Patient Safety’s prospective risk analysis
system. Joint Commission Journal on Quality Improvement 28(5):248-267, 209.
FDA (Food and Drug Administration). 2009. The quality system regulation. http://www.
fda.gov/MedicalDevices/DeviceRegulationandGuidance/PostmarketRequirements/
QualitySystemsRegulations/MedicalDeviceQualitySystemsManual/ucm122391.htm (ac-
cessed June 1, 2011).
Gardner, R. M., J. M. Overhage, E. B. Steen, B. S. Munger, J. H. Holmes, J. J. Williamson,
D. E. Detmer, and the AMIA Board of Directors. 2009. Core content for the sub-
specialty of clinical informatics. Journal of the American Medical Informatics Association
16(2):153-157.
Gastineau, D. A. 2004. Will regulation be the death of cell therapy in the United States? Bone
Marrow Transplant 33(8):777-780.
Glasgow, J., J Scott-Caziewell, and P. Kaboli. 2010. Guiding inpatient quality improvement:
A systematic review of lean and six sigma. Joint Commission Journal on Quality and
Patient Safety 36(12):531-532.
Goodman, K. W., E. S. Berner, M. A. Dente, B. Kaplan, R. Koppel, D. Rucker, D. Z. Sands, P.
Winkelstein, and the AMIA Board of Directors. 2011. Challenges in ethics, safety, best
practices, and oversight regarding HIT vendors, their customers, and patients: A report
of an AMIA special task force. Journal of the American Medical Informatics Association
18(1):77-81.
Grabowski, H. G., and J. M. Vernon. 1977. Consumer protection regulation in ethical drugs.
American Economic Review 67(1):359-364.
OCR for page 167
167
A SHARED RESPONSIBILITY FOR IMPROVING SAFETY
Hauptman, O., and E. B. Roberts. 1987. FDA regulation of product risk and its impact upon
young biomedical firms. Journal of Product Innovation Management 4(2):138-148.
HHS (Department of Health and Human Services). 2010. Health information technology:
Initial set of standards, implementation, specifications, and certification criteria for
electronic health record technology; final rule. Federal Register 75(144):44590-44654.
IOM (Institute of Medicine). 2011 (unpublished). Vendor responses—summary. Washington,
DC: IOM.
ISO (International Organization for Standardization). 2011. Quality management principles.
http://www.iso.org/iso/iso_catalogue/management_and_leadership_standards/quality_
management/qmp.htm (accessed May 26, 2011).
Johansen, I., M. Bruun-Rasmussen, K. Bourquard, E. Poiseau, M. Zoric, C. Parisot, and M.
Onken. 2011. A quality management system for interoperability testing. Paper presented
at 23rd International Conference of the European Federation for Medical Informatics,
Oslo, Norway, August 28, 2011, to August 31, 2011.
The Joint Commission. 2011. Sentinel events. Chicago: The Joint Commission.
Kim, D. U. 2002. The quest for quality blood banking program in the new millennium the
American way. International Journal of Hematology 76(Suppl 2):258-262.
Laflamme, F. M., W. E. Pietraszek, and N. V. Rajadhyax. 2010. Reforming hospitals with IT
investment. McKinsey Quarterly 20:27-33.
Leape, L. L. 2002. Reporting of adverse events. New England Journal of Medicine
347(20):1633-1638.
Marcus, A. A. 1988. Implementing induced innovations: A comparison of rule-bound and
autonomous approaches. Academy of Management Journal 31(2):235-256.
NASA (National Aeronautics and Space Administration). 2011a. Confidentiality and incen-
tives to report. http://asrs.arc.nasa.gov/overview/confidentiality.html (accessed April 18,
2011).
NASA. 2011b. Immunity policy. http://asrs.arc.nasa.gov/overview/immunity.html (accessed
April 18, 2011).
National Academy for State Health Policy. 2010. Patient safety toolbox. http://www.nashp.
org/pst-welcome (accessed June 24, 2011).
NIST (National Institute of Standards and Technology). 2006. Guide to integrating forensic
techniques into incident response. Gaithersburg, MD: NIST.
NIST. 2010. Computerized common industry format template for electronic health record
usability testing. Gaithersburg, MD: NIST.
NQF (National Quality Forum). 2011. NQF: Governance and leadership. http://qualityforum.
org/About_NQF/Governance_and_Leadership.aspx (accessed June 24, 2011).
ONC (Office of the National Coordinator for Health Information Technology). 2011. Health
IT workforce development program facts at a glance. http://healthit.hhs.gov/portal/server.
pt?open=512&objID=1432&mode=2 (accessed June 24, 2011).
Quality and Safety Education for Nurses. 2011. Quality and safety competencies. http://www.
qsen.org/competencies.php (accessed July 19, 2011).
Schneider, P. 1996. FDA & clinical software vendors: A line in the sand? Healthcare Informatics
13(6):100-102, 104, 106.
Shuren, J. 2010. Statement to IOM Committee on Patient Safety and Health Information
Technology. Statement read at the Workshop of the IOM Committee on Patient Safety
and Health Information Technology, Washington, DC.
Sittig, D. F., and D. C. Classen. 2010. Safe electronic health record use requires a comprehen-
sive monitoring and evaluation framework. Journal of the American Medical Association
303(5):450-451.
Sittig, D. F., and H. Singh. 2009. Eight rights of safe electronic health record use. Journal of
the American Medical Association 302(10):1111-1113.
OCR for page 168
168 HEALTH IT AND PATIENT SAFETY
U.S. Congress, Senate Subcommittee on Labor, Health and Human Services, and Education.
2000. Testimony of Leape, L.
VanRooyen, M. J., J. G. Grabowski, A. J. Ghidorzi, C. Dey, and G. R. Strange. 1999. The
perceived effectiveness of total quality management as a tool for quality improvement in
emergency medicine. Academic Emergency Medicine 6(8):811-816.
Veterans Affairs National Center for Patient Safety. 2011. FAQ: How do you define an in-
tentional unsafe act? http://www.patientsafety.gov/FAQ.html (accessed August 9, 2011).
Walshe, K., and S. M. Shortell. 2004. Social regulation of healthcare organizations in the
United States: Developing a framework for evaluation. Health Services Management
Research 17(2):79-99.
Weeda, D. F., and N. F. O’Flaherty. 1998. Food and Drug Administration regulation of blood
bank software: The new regulatory landscape for blood establishments and their vendors.
Transfusion 38(1):86-89.
WHO (World Health Organization). 2005. WHO draft guidelines for adverse event reporting
and learning systems: From information to action. Geneva: World Health Organization
Press.
