FDASIA REGULATIONS SUBGROUP May 30, 2013

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 2

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. 3

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. 4

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. 5

Goals & Objectives of Regulation Regulation must do its job protect patient safety (whatever that means), while minimizing any side effects 6

Subgroup’s twin objectives Identify-- 1. Evidence driven problems 2. Problem driven solutions 7

Subgroup meeting process By statute we were selected Not because of regulatory expertise Not because somehow we represent the public in some political science sense But 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 research Responding to the specific topics posed by Congress and the agencies Not by trying to do the agency’s work for them 8

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 agencies 1. Validated problems that need to be addressed 2. Recommended elements fashioned to address those problems 9

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 10

OUR CONCEPTUAL APPROACH And where we need help from the other committees

What does safety mean? Assure that the software does not 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? 12

Building up to regulation Regulation Private Oversight Risks of an Automated System Risks of a Manual System 13

Risks of a manual system Paper health record system Recording keeping mistakes Limited access to records Unaided doctor decision-making Decision-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 visit Limited data for decision-making Untimely care Non-networked medical devices operating independently Lost coordination 14

Risks of an automated system 15 CategoryExamples 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)

More Risk 16 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.

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 17

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? 18

REGULATIONS Breakout session 19

Goals & Objectives of Regulation Regulation must do its job protect patient safety (whatever that means), while minimizing any side effects 20

Executive Order 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. 21

Executive Order 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. 22

Executive Order 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. 23

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 24

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 25

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 26

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). 27

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 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? 28

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? 29

AMBIGUITY IN THE LAW First let’s consider what other groups have already identified 30

Bipartisan Policy Center “An Oversight Framework for Assuring Patient Safety in Health Information Technology” Feb 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:  Administrative  Clinical: EHR, CPOE, CDS  Medical devices (Class I, II, III) 31

mHealth Regulatory Coalition “A Call for Clarity: Open Questions on the Scope of FDA Regulation of mHealth” Dec Challenge No. 1: Distinguish wellness from medical purpose  Spectrum of intended uses for a Weight Scale 32 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

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 right  A “component” of the medical device  An “accessory” of the medical device  Regulate as the parent device  Result: cellular networks such AT&T and Verizon would be regulated as accessories? Challenge No. 3: software modularization 33

Clinical Decision Support Software FDA’s preliminary definition of CDS Software 34 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

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 score  Calculate 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 35

CIMIT/CONTINUA/FDA January, 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

Institute of Medicine IOM Report “Health IT and Patient Safety: Building Safer Systems for Better Care”, Nov 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. 43

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 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). 44

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 45

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. 46

DUPLICATION Looks at the laws Discuss other groups 47

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 issues ONC says greater use of standards in Dec. 21, 2012 Safety plan FDA recognizes standards and uses them in reviews Unclear how the two systems operate with regard to software both agencies might regulate CDS MDDS Mobile apps Imaging software Interoperable hospital networks/systems 48

Bipartisan Policy Center Develop standards and guidelines Independent “voluntary consensus bodies”— developers, implementers, users, health IT and safety experts, and consumers Safety reporting  Creating 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. 49

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. 50

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. 51

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. 52

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. 53