FDASIA Regulations SubGROUP

53
FDASIA REGULATIONS SUBGROUP May 30, 2013

description

FDASIA Regulations SubGROUP. May 30, 2013. Topics. Background on the task before the Regulations Subgroup Distinguishing the Regulations Subgroup from the Risk Assessment & Innovation Subgroup What we need from the other subgroups. Background. - PowerPoint PPT Presentation

Transcript of FDASIA Regulations SubGROUP

FDASIA REGULATIONS SUBGROUP

May 30, 2013

2

Topics

1. Background on the task before the Regulations Subgroup

2. Distinguishing the Regulations Subgroup from the Risk Assessment & Innovation Subgroup

3. What we need from the other subgroups

3

Background

• The purpose of regulation is to solve a problem, not to exist for its own sake.

• So the process of developing regulatory approaches must start with the problem to be solved.

4

The Three Agencies 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.

5

The Regulations Subgroup will Propose

• Factors or approaches that could be included in a risk-based regulatory approach for health IT to promote innovation and protect patient safety; and

• Approaches to avoid duplicative or overlapping regulatory requirements.

6

Goals & Objectives of Regulation

• Regulation must do its jobprotect patient safety (whatever that

means), while minimizing any side effects

7

Subgroup’s twin objectives

Identify--

1. Evidence driven problems

2. Problem driven solutions

8

Subgroup meeting process

• By statute we were selectedNot because of regulatory expertiseNot because somehow we represent the public in some political

science senseBut because we reflect a diverse (almost random) set of regulatory

users

• So we will operate in a focus group style, Offering input to the agencies similar to market researchResponding to the specific topics posed by Congress and the

agenciesNot by trying to do the agency’s work for them

9

Done by standing on the shoulders of others

• Step 1 of our process is collecting the work already done by others, and soliciting the views of those not on the subcommittee

• Step 2—analyzing the collected data and filling in gaps as best we can

• Step 3—sorting and presenting to the agencies1. Validated problems that need to be addressed

2. Recommended elements fashioned to address those problems

10

Focus of the Regulations Subgroup

Begin by analyzing any existing problems in the following areas:

1. Patient safety not fully protected

2. Regulatory overkill that imposes unjustified costs

3. Innovation unduly inhibited

4. Regulatory ambiguity that impedes compliance or adds uncertainty

5. Regulatory duplication that wastes resources or frustrates compliance

OUR CONCEPTUAL APPROACHAnd where we need help from the other committees

12

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?

13

Building up to regulationRegulation

Private Oversight

Risks of an Automated System

Risks of a Manual System

14

Risks of a manual system• Paper health record system

Recording keeping mistakesLimited access to records

• Unaided doctor decision-makingDecision-making errors in diagnosis and treatment (confirmation

bias, attribution errors, commission bias, investigation errors, etc.)

• Non-mobile health system, where you have to go for a doctor’s visitLimited data for decision-makingUntimely care

• Non-networked medical devices operating independentlyLost coordination

15

Risks of an automated systemCategory Examples

Errors of Commission

Example 1: An error occurred in software used to view and document patient activities. When the user documented activities in the task list for one patient and used the “previous” or “next” arrows to select another patient chart, the first patient’s task list displayed for the second patient.

Example 2: A nuclear medicine study was saved in the wrong patient’s file. Investigation suggested that this was due to a software error.

Example 3: A sleep lab’s workstation software had a confusing user interface, which led to the overwriting and replacement of one patient’s data with another patient’s study.

Errors of Omission or Transmission

Example 1: An EMR system was connected to a patient monitoring system to chart vital signs. The system required a hospital staff member to download the vital signs, verify them, and electronically post them in the patient’s chart. Hospital staff reported that, several times, vital signs have been downloaded, viewed, and approved, and have subsequently disappeared from the system.

Example 2: An operating room management software application frequently “locked up” during surgery, with no obvious indication that a “lock-up” was occurring. Operative data were lost and had to be re-entered manually, in some cases from the nurse’s recollection.

Example 3: An improper database configuration caused manual patient allergy data entries to be overwritten during automatic updates of patient data from the hospital information system.

Examples of Adverse Events Related to Health IT Reported to FDA (2010)

16

More Risk

Errors in Data Analysis

Example 1: In one system, intravenous fluid rates of greater than 1,000mL/hr were printed as 1 mL/hr on the label that went to the nursing/drug administration area.

Example 2: A clinical decision support software application for checking a patient’s profile for drug allergies failed to display the allergy information properly. Investigation by the vendor determined that the error was caused by a missing codeset.

Example 3: Mean pressure values displayed on a patient’s physiological monitors did not match the mean pressures computed by the EMR system after systolic and diastolic values were entered.

Incompatibility between Multi-Vendor Software Applications or Systems

Example 1: An Emergency Department management software package interfaces with the hospital’s core information system and the laboratory’s information system; all three systems are from different vendors. When lab results were ordered through the ED management software package for one patient, another patient’s results were returned.

Example 2: Images produced by a CT scanner from one vendor were presented as a mirror image by another vendor’s picture archiving and communication system (PACS) web software. The PACS software vendor stipulates that something in the interface between the two products causes some images to be randomly “flipped” when displayed.

17

What do we need from Risk Assessment and Innovation Subgroup?

1. Conceptual approach to safety• See discussion above

2. Specific safety risks, • with enough explanation to understand how they arise

3. Specific elements of innovation in the software development process,

• with enough explanation to understand what needs to be protected

18

Input needed from Taxonomy Subgroup

To get to a meaningful level in analyzing such issues as duplication and regulatory ambiguity, we will have to determine whether such areas as the following are within scope:

1. UDI

2. CPOE

3. MDDS

4. Mobile apps that act as accessories to medical devices (e.g. companion software for blood glucose meter)

5. Mobile apps that transform a cell phone into a medical device (e.g. electronic stethoscope)

6. CDS

7. EHR

8. Hospital IT networks of interoperable medical devices

9. What else?

19

REGULATIONSBreakout session

20

Goals & Objectives of Regulation

• Regulation must do its jobprotect patient safety (whatever that

means), while minimizing any side effects

21

Executive Order 13563 -- Improving Regulation and Regulatory Review

• Our regulatory system must protect public health, welfare, safety, and our environment while promoting

economic growth, innovation, competitiveness, and job creation. be based on the best available science. allow for public participation and an open exchange of ideas. promote predictability and reduce uncertainty. identify and use the best, most innovative, and least burdensome tools for

achieving regulatory ends. take into account benefits and costs, both quantitative and qualitative. ensure that regulations are accessible, consistent, written in plain language, and

easy to understand. measure, and seek to improve, the actual results of regulatory requirements.

22

Executive Order 13563 -- Improving Regulation and Regulatory Review

Each agency must, among other things: 1. propose or adopt a regulation only upon a reasoned determination that its benefits

justify its costs (recognizing that some benefits and costs are difficult to quantify);

2. tailor its regulations to impose the least burden on society, consistent with obtaining regulatory objectives, taking into account, among other things, and to the extent practicable, the costs of cumulative regulations;

3. select, in choosing among alternative regulatory approaches, those approaches that maximize net benefits (including potential economic, environmental, public health and safety, and other advantages; distributive impacts; and equity);

4. to the extent feasible, specify performance objectives, rather than specifying the behavior or manner of compliance that regulated entities must adopt; and

5. identify and assess available alternatives to direct regulation, including providing economic incentives to encourage the desired behavior, such as user fees or marketable permits, or providing information upon which choices can be made by the public.

23

Executive Order 13563 -- Improving Regulation and Regulatory Review• Sec. 3. Integration and Innovation. Some sectors and industries face a

significant number of regulatory requirements, some of which may be redundant, inconsistent, or overlapping. Greater coordination across agencies could reduce these requirements, thus reducing costs and simplifying and harmonizing rules. In developing regulatory actions and identifying appropriate approaches, each agency shall attempt to promote such coordination, simplification, and harmonization. Each agency shall also seek to identify, as appropriate, means to achieve regulatory goals that are designed to promote innovation.

• Sec. 4. Flexible Approaches. Where relevant, feasible, and consistent with regulatory objectives, and to the extent permitted by law, each agency shall identify and consider regulatory approaches that reduce burdens and maintain flexibility and freedom of choice for the public. These approaches include warnings, appropriate default rules, and disclosure requirements as well as provision of information to the public in a form that is clear and intelligible.

24

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

25

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

26

Ancillary goals• Maintaining predictability and minimizing disruption

Avoid duplication among agencies and lawsJurisdiction 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 spectrumRegulations written to be clear and predictableCategories 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

27

We stand on whose shoulders?1. Report of the Bipartisan Policy Center: An Oversight

Framework for Assuring Patient Safety in Health Information Technology (2013)

2. A Call for Clarity: Open Questions on the Scope of FDA Regulation of mHealth: A whitepaper prepared by the mHealth Regulatory Coalition (2010), and subsequent policy papers, including mhealth use cases

3. CDS Coalition analysis of the factors that cause a user to be substantially dependent on software (2013)

4. Institute of Medicine (IOM) Report “Health IT and Patient Safety: Building Safer Systems for Better Care”

5. S. Hoffman, “Finding a Cure: The Case for Regulation and Oversight of Electronic Health Record Systems,” 22 Harvard Journal of Law & Technology 103 (2008).

28

We stand on whose shoulders?1. A. Krouse, “iPads, iPhones, Androids, and Smartphones:

FDA Regulation of Mobile Phone Applications as Medical Devices,” 9 Indiana Health Law Review, 731 (2012)

2. Proceedings of joint meeting of FDA, Center for Integration of Medicine and Innovative Technology and the Continua Health Alliance, on Medical Device Interoperability: Achieving Safety And Effectiveness 2010

3. Comments submitted to the International Medical Device Regulators Forum (IMDRF) on the Standalone Software Work Item by groups such as the mHealth Regulatory Coalition -- European Union working group.

4. What else?

29

Background

The committee is charged with identifying the following:

1. Current areas of regulatory duplication, ambiguity, or oversight confusion.

2. Current areas of regulatory success and “best practices.”

3. Regulatory gaps in relation to identified patient safety and innovation needs.

4. Relative strengths and weaknesses of our current regulatory structure as it relates to health it and patient safety.

5. Strategies to improve efficiency and avoid duplicative regulatory processes.

6. Non-regulatory activities (existing or potential) that should be considered.

Is there anything else we ought to be considering?

30

AMBIGUITY IN THE LAWFirst let’s consider what other groups have already identified

31

Bipartisan Policy Center • “An Oversight Framework for Assuring Patient Safety in

Health Information Technology” Feb. 2013• FDA’s current regulatory approach for medical devices not well-

suited for Health IT. • Safety of medical devices depends on how they are

manufactured • Health IT relies on how it is designed and developed, but also on

how it is customized, implemented, and used.shared responsibility among developers, implementers, and users at various

stages of Health IT life cycle – design, implementation and customization; maintenance, and operations; risk identification and mitigation.

3 types of software:AdministrativeClinical: EHR, CPOE, CDSMedical devices (Class I, II, III)

32

mHealth Regulatory Coalition• “A Call for Clarity: Open Questions on the Scope of FDA

Regulation of mHealth” Dec. 2010• Challenge No. 1: Distinguish wellness from medical purpose

Spectrum of intended uses for a Weight Scale

Scale connected to a computer for tracking weight loss

Scale connected remotely to

physician for real-time management

of weight as a measure

associated with congestive heart

failure

Scale connected for

monthly download by dietitian of a

person managing

obesity

Scale connected to a physician for

weekly monitoring of a

person recovering

from bariatric surgery

Scale connected to a physician for daily monitoring in the management of a person with brittle diabetes

Not Regulated by FDA

Regulated by FDA

33

mHealth Regulatory Coalition• Challenge No. 2: the “Accessory Rule”

• Under FDCA, a product that supports (i.e. is connected to) a medical device can be:

A medical device in its own rightA “component” of the medical deviceAn “accessory” of the medical device

Regulate as the parent deviceResult: cellular networks such AT&T and Verizon would be regulated as

accessories?

• Challenge No. 3: software modularization

34

Clinical Decision Support Software• FDA’s preliminary definition of CDS Software

Information• Data from a

medical device• Environmental

data (e.g., pollen count, temp.)

• Demographic data (e.g., age, sex, socio-economic status)

Conversion• Algorithms

(fixed or iterative)

• Formulae• Database look-

ups or comparisons

• Rules or associations

Clinical Decision• Patient specific• Actionable

result

35

CDS Software• What qualifies as CDS?

• Examples:Provide a questionnaire for collecting patient-specific lab results

and compute the prognosis of a particular condition or disease,Perform calculation that result in an index or scoreCalculate dosage for a specific medication or radiation treatment, Provide recommendations that aid a clinician in making a diagnosis

or selecting a specific treatment for a patient.

• How should it be regulated?• Assess whether user is substantially dependent

CIMIT/CONTINUA/FDAJanuary, 2010

1. The scope of FDA regulation. The circumstances when the following might be regulated directly (as opposed to simply being part of a system that must be validated):

• Cell phone/smart phone (what functionality/use might cross the line)

• Home hub use case that includes PCs and servers• Off the shelf software used on a cell phone or PC

2. The level of FDA regulation• Can home or mobile devices that may be swept into an FDA

regulated system be placed in class I and exempted from premarket clearance (on the basis of a favorable risk benefit assessment)

• Can connectivity devices remain in class I even when a class II medical device is added to the system

3. Intended use questions.• How do we cope with intended uses that evolve with new

learning/experience? Can we get to market with tool claims that do not claim specific clinical utility?

• Can we just get clearance for a general connectivity claim, without specifying the system?

• Does co packaging or selling items together necessarily change the intended use?

4. Evidence required for clearance. If the medical device manufacturer is responsible for the claimed system, but the components of the system are open-ended—

• How does the company demonstrate substantial equivalence?

• Can the company demonstrate certification to a standard or specification for an interface, rather than validating every possible part of the system.

• Can we come up with a new paradigm for clearing these connected devices that classifies or stratifies these devices based on risk (for example, based on acuity), and does not require the traditional evidence for validating systems designed for low risk/acuity devices.

5. Standards for clearance. Does FDA have any minimum requirements for substantial equivalence for remote monitoring devices or mHealth devices, such as

• Latency• Human factors design issues• Limits on appropriate population• Ability to use open source platform• Acceptable use environment• Usability issues• Protection against interference by other software

6. Design control complexities for open ended system

7. Postmarket challenges for root cause analysis, reporting and remediation

8. Can industry benefit from learning from the collective adverse events

43

Institute of Medicine• IOM Report “Health IT and Patient Safety: Building Safer

Systems for Better Care”, Nov. 2011• Lack of guidelines on information sharing, contractual

restrictions, such as non-disclosure and confidentiality clauses required by some vendors, limit transparency Some vendors allow users to share information through industry

conferences, sponsored user group meetings, blogs, etc. However, the ability of users and researchers to share such information outside industry-controlled venues can be limited by nondisclosure clauses.

Need for health IT community to share details, such as screen- shots of risk-enhancing interfaces, descriptions of potentially unsafe processes, and other components of health IT products associated with adverse events.

44

Article on EHR Regulation and Oversight

• S. Hoffman, “Finding a Cure: The Case for Regulation and Oversight of Electronic Health Record Systems,” 22 Harvard Journal of Law & Technology 103 (2008).

• EHR potential for errors because:• fragmentation of data; • failure to integrate all hospital systems; and • human-computer interface difficulties rooted in the machine rules’ failure to

reflect work organization or expected provider behavior.

• Privacy and security concerns – HIPAA unclear: what entities are covered and what PHI requires patient authorization

• Since 2008 – Jan. 2013 Omnibus Rule extends the business associate designation to subcontractor that “creates,

receives, maintains, or transmits [PHI] on behalf of the business associate.” Includes “marketing” communications: communications directly (or indirectly)

paid for by third parties (e.g., being paid by a drug manufacturer to communicate information about a new drug).

45

Article on EHR Regulation and Oversight

• Legal and administrative regulation needed to support adoption of safe EHR• To compel adoption of EHR – establish a legal mandate requiring

their use by all health care providers• Government regulation is necessary to prevent market failure.

Without a governmentally mandated adverse event reporting requirement, the public may never find out which products are defective or inferior to others

• The threat of litigation might discourage sloppy software engineering, but in the realm of complex HIT, liability might be so difficult to prove that vendors will believe they bear little risk

• Market forces alone cannot be trusted to ensure interoperability of EHR systems. Interoperability would likely be disfavored by vendors because it could reduce profits and increase costs – e.g. practice of customizing products to accommodate providers’ preferences

46

Article: Regulation of Mobile Apps• A. Krouse, “iPads, iPhones, Androids, and Smartphones:

FDA Regulation of Mobile Phone Applications as Medical Devices,” 9 Indiana Health Law Review, 731 (2012)

• Informational vs. diagnosis mobile health apps• FDA “Guidance for the Content of Premarket Submissions

for Software Contained in Medical Devices” software should be labeled major, moderate, or minor.A major label is a software enabled device that “could directly result

in death or serious injury to the patient or operator.”A moderate label applies to a software device that could result in a

minor injury.A minor label applies a software device that is unlikely to cause an

injury.

47

DUPLICATIONLooks at the laws

Discuss other groups

48

Look at the laws• Adverse event reporting

Dec. 21, 2012 ONC Safety Plan calls for enhanced adverse event reporting

FDA has existing adverse event reporting system

• Regulatory use of standards and design issuesONC says greater use of standards in Dec. 21, 2012 Safety planFDA recognizes standards and uses them in reviews

• Unclear how the two systems operate with regard to software both agencies might regulateCDSMDDSMobile appsImaging softwareInteroperable hospital networks/systems

49

Bipartisan Policy Center• Develop standards and guidelines

• Independent “voluntary consensus bodies”— developers, implementers, users, health IT and safety experts, and consumers

• Safety reportingCreating a safety reporting silo that only focuses on health IT would be

duplicative Use Patient Safety Organizations (PSOs), certified and evaluated by

the Agency for Healthcare Research and Quality (AHRQ) to report patient safety events associated with Health IT

Patient Safety Act authorized AHRQ to facilitate the development of a network of patient safety databases (NPSD), to which PSOs, health care providers, can voluntarily contribute non-identifiable patient safety work product

AHRQ Common Formats - common definitions and reporting formats used to facilitate the collection and reporting of patient safety events.

50

mHealth Regulatory Coalition – White Paper, 2010• Communication technologies such as spectrum bands –

under jurisdiction of FCC• Body Area Networks (BANs) or Personal Area Networks (PANs),

worn on the person of the patient, that may operate in either dedicated or unlicensed spectrum bands

• Need for new policy perspectives that account for the change from a component focus to one that is systems, platform interface, and network oriented.

51

Institute of Medicine • HHS should work with the private sector to assess the impact of health IT

on patient safety and minimizing the risk of its implementation and use • HHS should fund a new Health IT Safety Council to evaluate criteria for safe

use of health IT.• The Council should operate within an existing voluntary consensus standards

organization such as National Quality Forum (NQF)

• ONC should make comparative user experiences across vendors publicly available. ONC should develop a Common Reporting format for Health IT-related

adverse events ONC should develop standardized testing procedures to assess the

safety of health IT products. • ONC and AHRQ should work with vendors and healthcare organizations to

promote post deployment safety testing of EHR• ONC certification bodies should adopt criteria relating to EHR safety.

• AHRQ should fund the development of new methods for measuring the impact of Health IT on safety utilizing data collected by EHRs.

52

IOM Recommendations Cont’d• Congress should establish an independent federal entity

for investigating patient safety deaths, serious injuries, or potentially unsafe conditions associated with health IT.

• The Secretary of HHS should monitor and publicly report on the progress of health IT safety annually, and if progress toward safety and reliability is not sufficient – direct FDA to develop necessary framework for regulation for EHR, HIE and PHR.

• HHS should support research on user-centered design and human factors applied to health IT.

53

Article on EHR Regulation and Oversight

• Certification Commission for Healthcare Information Technology (“CCHIT”), a private-sector organization, created in 2004

• Composed of 3 industry associations: • the American Health Information Management Association; • the Healthcare Information and Management Systems Society; and • the National Alliance for Health Information Technology.

• HHS awarded CCHIT a 3-year contract with a mandate to develop certification criteria and an inspection procedure for EHR systems in the areas of office-based ambulatory care, inpatient care, and interoperability.

Applicants must pay CCHIT for certification

• CCHIT is an industry-run organization, and its certification criteria are vulnerable to criticism as being excessively favor- able to vendors.