amdis 2013 fda oversite classen

© 2006 HCC, Inc. CD000000-0000XX

FDA OVERSIGHT OF

HIT

ITS COMING AND YOU

CAN’T STOP IT

David C Classen MD, MS

Associate Professor of Medicine University of Utah

and

CMIO Pascal Metrics

June 2013 AMDIS

Health IT and Patient Safety: Building Safer Systems for Better Care

EMBARGOED UNTIL NOVEMBER 10, 2011, 10:30 AM

The New Challenge : Reducing Harm with HIT

Department of Health and

Human Services

OFFICE OF

INSPECTOR GENERAL

15,000 Medicare

beneficiaries

per month

experience

adverse events

contributing to

death

State with Safety

Program Flat-line

Improvement

Is safety improving in the US?

Landrigan CP, Parry GJ, Bones CB, Hackbarth AD, Goldmann DA, Sharek PJ.

Temporal trends in rates of patient harm resulting from medical care. New England

Journal of Medicine. 2010 Nov; 363(22):2124-2134.

6

Slope: 0.98 (95% CI 0.93, 1.04 p = 0.47)

Trends in All Harms Over Time: External

Landrigan et al., New Engl J Med 2010; 363: 2124-34

12

Features of safer health IT

13

Recommendations: Summary

Current market forces are not adequately addressing the

potential risks associated with use of health IT

All stakeholders must coordinate efforts to identify and

understand patient safety risks associated with and prevented

by health IT :

Facilitating the free flow of information about HIT

Creating a reporting and investigating system for health IT–

related deaths, serious injuries, or unsafe conditions

Researching and developing standards and criteria for safe

design, implementation, and use of health IT

16

Recommendation 1

The Secretary of Health and Human Services (HHS) should

publish an action and surveillance plan within 12 months that

includes a schedule for working with the private sector to

assess the impact of health IT on patient safety and

minimizing the risk of its implementation and use. The plan

should specify:

a. The Agency for Healthcare Research and Quality

(AHRQ) and the National Library of Medicine (NLM)

should expand their funding of research, training, and

education of safe practices as appropriate, including

measures specifically related to the design,

implementation, usability, and safe use of health IT by all

users, including patients.

(continued on next slide)

17

Recommendation 1 (continued)

b. The Office of the National Coordinator for Health IT (ONC)

should expand its funding of processes that promote safety

that should be followed in the development of health IT

products, including standardized testing procedures to be

used by manufacturers and health care organizations to

assess the safety of health IT products.

c. ONC and AHRQ should work with health IT vendors and

health care organizations to promote post-deployment safety

testing of EHRs for high prevalence, high impact EHR-

related patient safety risks.

d. Health care accrediting organizations should adopt

criteria relating to EHR safety.

e. AHRQ should fund the development of new methods for

measuring the impact of health IT on safety using data

from EHRs.

18

Recommendation 2

The Secretary of HHS should ensure insofar as possible that

health IT vendors support the free exchange of information

about health IT experiences and issues and not prohibit

sharing of such information, including details (e.g.,

screenshots) relating to patient safety.

Recommendation 3

ONC should work with the private and public sectors to make

comparative user experiences across vendors publicly

available.

19

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

Recommendation 5

All health IT vendors should be required to publicly register

and list their products with ONC, initially beginning with EHRs

certified for the meaningful use program.

20

Recommendation 6

The Secretary of HHS should specify the quality and risk

management process requirements that health IT vendors

must adopt, with a particular focus on human factors, safety

culture, and usability.

21

Recommendation 7

The Secretary of HHS should establish a mechanism for both

vendors and users to report health IT–related deaths, serious

injuries, or unsafe conditions.

a. Reporting of health IT–related adverse events should be

mandatory for vendors.

b. Reporting of health IT–related adverse events by users

should be voluntary, confidential, and nonpunitive.

c. Efforts to encourage reporting should be developed, such

as removing the perceptual, cultural, contractual, legal, and

logistical barriers to reporting.

22

Recommendation 7-8

23

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.

25

Recommendation 9

a. 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 the FDA to exercise all available authority to

regulate EHRs, health information exchanges, and PHRs.

b. The Secretary should immediately direct the 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 Recommendation 9a

above.

1. Continuously improve the safety of health IT products: • Code of conduct: ONC will work with developers on a code of conduct that commits developers

to: Work with Patient Safety Organizations (PSOs) — or similar entities — to report, aggregate,

and analyze health IT – related safety events

• Support providers in reporting safety events

• Collaborate with private sector efforts to make comparative user experience with different EHR

systems more available ONC-Authorize Accrediting Bodies’ (ONC-ACB’s) surveillance and ONC

certification: o ONC will leverage ONC-ACB surveillance and live testing to ensure safety

features are functional in live environments and that developers address safety complaints

• ONC will continue to incorporate safety into its standards and certification criteria

• Manufacturer and User Facility Device Experience: ONC will monitor health IT adverse event

reports to the FDA’s MAUDE database

2. Improve understanding of health IT and patient safety: • AHRQ Common Formats to enhance provider reporting: The Agency for Healthcare Research

and Quality (AHRQ) and ONC will work with providers and PSOs to incorporate AHRQ Common

Formats into providers’ health IT and reporting systems. AHRQ Common Formats allow for

easy, real-time reporting and aggregation of patient safety events and risks

• PSOs and AHRQ to collect, aggregate and analyze patient safety reports: AHRQ, in

collaboration with ONC, will work with PSOs, providers, and developers to add a focus of health

IT to their collection, aggregation, analysis, and mitigation of providers’ adverse event reports

• AHRQ will also provide guidance to PSOs on how they can work with providers to use health IT

to improve reporting and mitigate health IT risks

3. Promote safe use of health IT as part of a culture of safety among providers: • Align Centers for Medicare & Medicaid Services’ (CMS’) safety standards for health care

facilities, its interpretive guidance, and surveyor trainings to add a focus on health IT and patient

safety

4. Incorporate safety requirements into Meaningful Use:

CMS Medicare and Medicaid EHR Incentive Programs and ONC’s Standards and

Certification Criteria rulemakings have been and will continue to be used to improve

patient safety

5. Establish Priority Areas:

• ONC plans to lead a public-private process to identify health IT safety priority areas,

measures, and targets – building from current research to develop health IT safety

guides and assess effectiveness of health IT safety interventions

• HHS plans to support research and development of tools and guidance for using health

IT to improve safety and mitigate health IT safety risks

6. Establish the ONC Safety Program:

• Coordinate the implementation of the Health IT Safety Plan

• Comprehensively analyze data from identified reporting programs

• Eliminate or significantly reduce inefficiencies across the programs

• Develop policies and procedures to establish an ad hoc HHS multi-agency committee

to address major health IT safety issues

7. Evaluate and monitor approaches:

• During implementation, ONC will continually evaluate the effectiveness of the Health IT

Safety Plan and determine whether additional actions are required to better capitalize on

health IT’s potential to improve patient safety

• ONC will collaborate with FDA and the Federal Communications Commission (FCC), to

produce a report that proposes a strategy and recommendations for an appropriate, risk-

based regulatory framework for health IT which promotes safety and innovation

AN OVERSIGHT FRAMEWORK FOR PATIENT SAFETY AND HEALTH IT 29

Food and Drug Administration Safety and Innovation Act of 2012

The Food and Drug Administration (FDA) Safety and Innovation Act of 2012, which was passed by Congress and signed into law in July 2012, requires the HHS secretary, “acting through the Commissioner of Food and Drugs, and in consultation with the National Coordinator for Health Information Technology and the Chairman of the Federal Communications Commission,” to post a report within 18 months that “contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.”

An Oversight Framework for

Patient Safety and Health IT JANET MARCHIBRODA

DIRECTOR, HEALTH INNOVATION INI TIATIVE AT THE B IPARTI SAN POLICY CENTER

BRIEF ING DOCUMENT

MARCH 15, 2013


Why a Different Oversight Framework for Clinical Software is

Needed

Safety in health IT is a shared responsibility among developers, implementers, and users across the health IT life cycle

Health IT safety relates not only to how it is designed and developed, but also how it is customized, implemented and used.

Health IT is constantly being upgraded and modified.

Importantly, health IT is designed to inform—not take the place of—clinical decision-making.

Many factors (beyond design and development) impact patient safety in health IT:

Quality of data that resides in systems

Level of interoperability and exchange

Integration of software into clinical workflows

Appropriateness of clinical interventions


Oversight Framework Should Reflect the Following Five Principles:

1. Any framework should recognize and support the important role that health IT plays in improving quality, safety and cost-effectiveness of care, as well as the patient’s experience of care.

2. Assuring patient safety, along with enabling positive patient outcomes, is a shared responsibility that must involve the entire health care system

3. Any framework for patient safety in health IT should be risk-based, flexible and not stifle innovation.

4. Existing safety and quality-related processes, systems, and standards should be leveraged for patient safety in health IT.

5. Reporting of patient safety events related to health IT is essential; a non-punitive environment should be established to encourage reporting, learning and improvement.


Focus on Principle 1: Any Framework Should Recognize the Important Role That Health IT Plays in Improving Health and Health Care

Research shows that health IT has a positive impact on the quality, safety, and cost-effectiveness of health care

Health IT plays a critical foundational role in rapidly emerging delivery system and payment reforms, such as accountable care arrangements and the patient-centered medical home

However, because of its widespread adoption, we must work together to continuously improve the quality and safety of systems


Focus on Principle 2: Assuring Safety is a Shared Responsibility

throughout the Health IT Life Cycle


Focus on Principle 3: Any Framework for Patient Safety in Health IT Should be Risk-Based, Flexible, and Not Stifle Innovation

Health care is a continually evolving ecosystem that is now undergoing considerable change.

Health IT plays a foundational role for rapidly emerging delivery system and payment reforms.

Clinical software changes frequently—sometimes weekly to address new requirements and user needs

Any framework for health IT should be flexible enough to support the innovation needed for a rapidly changing health care system and evolutionary nature of clinical software


Focus on Principle 4: Existing safety and quality-related processes, systems, and standards should be leveraged

Policies, processes, systems and standards which are well-established, should be leveraged for patient safety and health IT oversight.

Duplicative processes should not be created.


Focus on Principle 5: Reporting of Patient Safety Events is Essential; A Non-Punitive Environment Should be Established to

Encourage Reporting, Learning and Improvement

Any framework for patient safety in health IT should be data-driven. Reporting is essential to understanding the nature and magnitude of health IT-related events

The framework should support and promote reporting, sharing, and analysis of patient safety events in a non-punitive environment that maintains confidentiality and enables learning and improvement

Aggregation and analysis of events and timely feedback to developers, implementers, and users is also crucial so that necessary changes can be made and future risk mitigated


A Risk-Based Oversight Framework for Health IT

39 AN OVERSIGHT FRAMEWORK FOR PATIENT SAFETY AND HEALTH IT

Factors That Determine Level of Oversight


Key Components of an Oversight Framework for Clinical Software

that Protects Patients and Assures Patient Safety

1. Agreement on and adherence to recognized standards and guidelines for assuring patient safety in the development, implementation and use of health IT

2. Support for the implementation of standards and guidelines as well as development and dissemination of best practices through education, training, and technical assistance

3. Developer, implementer, and user participation in patient safety activities, including reporting, analysis (e.g. identification of root cause), and response (e.g. corrective action, mitigation of future risk), while leveraging patient safety organizations

4. Creation of a learning environment through the aggregation and analysis of data to identify and monitor trends, mitigate future risk, and facilitate learning and improvement

The Three Agencies (FDA,FCC,ONC) Must Propose

A strategy and recommendations on

an appropriate, risk-based regulatory

framework pertaining to health

information technology, including

mobile medical applications, that

promotes innovation, protects patient

safety, and avoids regulatory

duplication. 42

What does safety mean?

Assure that the software does not --

1. Hurt someone? – IT accessory to a medical device causes the device to hurt

someone

– Pretty hard for standalone IT to hurt someone directly

2. Fail to help someone? – Related to effectiveness

– Does less that it promises to do Maybe fails to consider human factors to allow proper use

Breaks down at inconvenient times

Poor design means it is ineffective at its task

– But the harm may be similar to the manual system it was supposed to improve, heightened by dependence

3. Mislead someone through the information it provides? – Factual error

– Objectively wrong advice

– Subjectively not the best advice?

43

Protecting patient safety

Is the regulation narrowly tailored to do its job?

The manner and degree of regulation should be based on level

of risk to patients

44

While Minimizing side effects

Protecting innovation

Allow for Off Label Use – we probably need a part of the

framework that can accommodate “off label use”, as many of

our pediatric specialists and researchers advance practice

faster than the new approvals may process

Expedient – timely approvals of new products, innovation, and fixes/repairs/replacements of same

Lightweight – seek to reduce the cost burden to patients, families,

and providers of care, vs. increase it through the addition of

regulatory compliance costs

45

Ancillary goals

Maintaining predictability and minimizing disruption Avoid duplication among agencies and laws

Jurisdiction of FDA should not be diminished in its spheres of expertise and experience, e.g., regulation/clearance/approval of medical devices. Its current jurisdiction should not be transferred to ONC, FCC etc.

As a corollary, the other respective Agencies, ONC, FCC, should have primacy in their own regulatory spaces, e.g.,

ONC – certification of EHRs, FCC – broadcast spectrum

Regulations written to be clear and predictable

Categories of products to be regulated should be defined as clearly as possible.

Dedicated efforts must be made to harmonize definitions internationally

Stakeholders should have ongoing input as part of the regulatory development process into the respective regulatory agencies as new applications emerge, since the applications’ environment is constantly evolving and will continue to do so in the future

46

SCOPE--Products Types -

Categories

EHRs (installed, Saas)

Hospital Information Systems-of-systems

Decision support algorithms

Visualization tools for anatomic, tissue images, medical imaging and waveforms

? Health Information Exchanges

Electronic/robotic patient care assistants

Claims processing

Health benefit eligibility

Practice management / Scheduling / Inventory management

Healthcare provider communication tools (e.g., email, paging)

Population management tools

Software using historical claims data to predict future utilization/cost of care

Cost effectiveness analytic software

Diseases severity scoring algorithms

Electronic guideline distribution

Disease registries

In Scope Out of Scope

Draft Risk Framework, v1.5

49

Safety as a system property

Safety is a characteristic of a sociotechnical system

System-level failures occur almost always because of

unforeseen combinations of component failures

50

Questions?

http://www.healthit.gov/policy-

researchers-

implementers/federal-advisory-

committees-facas/fdasia

amdis 2013 fda oversite classen

Health & Medicine