FDASIA Regulations SubGROUP

1. FDASIA Regulations SubGROUP May 30, 2013

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

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 job • protect patient safety (whatever that means), • while minimizing any side effects

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

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

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

10. Focus of the Regulations Subgroup Begin by analyzing any existing problems in the following areas: • Patient safety not fully protected • Regulatory overkill that imposes unjustified costs • Innovation unduly inhibited • Regulatory ambiguity that impedes compliance or adds uncertainty • Regulatory duplication that wastes resources or frustrates compliance

11. Our conceptual Approach And where we need help from the other committees

12. 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 • 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 • Mislead someone through the information it provides? • Factual error • Objectively wrong advice • Subjectively not the best advice?

13. Building up to regulation

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

15. Risks of an automated system • Examples of Adverse Events Related to Health IT Reported to FDA (2010)

16. More Risk

17. What do we need from Risk Assessment and Innovation Subgroup? • Conceptual approach to safety • See discussion above • Specific safety risks, • with enough explanation to understand how they arise • 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: • UDI • CPOE • MDDS • Mobile apps that act as accessories to medical devices (e.g. companion software for blood glucose meter) • Mobile apps that transform a cell phone into a medical device (e.g. electronic stethoscope) • CDS • EHR • Hospital IT networks of interoperable medical devices • What else?

19. Regulations Breakout session

20. Goals & Objectives of Regulation • Regulation must do its job • protect 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: • 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); • 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; • 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); • to the extent feasible, specify performance objectives, rather than specifying the behavior or manner of compliance that regulated entities must adopt; and • 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 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

27. We stand on whose shoulders? • Report of the Bipartisan Policy Center: An Oversight Framework for Assuring Patient Safety in Health Information Technology (2013) • 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 • CDS Coalition analysis of the factors that cause a user to be substantially dependent on software (2013) • Institute of Medicine (IOM) Report “Health IT and Patient Safety: Building Safer Systems for Better Care” • 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? • A. Krouse, “iPads, iPhones, Androids, and Smartphones: FDA Regulation of Mobile Phone Applications as Medical Devices,” 9 Indiana Health Law Review, 731 (2012) • 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 • 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. • What else?

29. Background The committee is charged with identifying the following: • Current areas of regulatory duplication, ambiguity, or oversight confusion. • Current areas of regulatory success and “best practices.” • Regulatory gaps in relation to identified patient safety and innovation needs. • Relative strengths and weaknesses of our current regulatory structure as it relates to health it and patient safety. • Strategies to improve efficiency and avoid duplicative regulatory processes. • Non-regulatory activities (existing or potential) that should be considered. Is there anything else we ought to be considering?

30. AMBIGUITY IN THE LAW First 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: • Administrative • Clinical: EHR, CPOE, CDS • Medical 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 Not Regulated by FDA Regulated by FDA Scale connected to a computer for tracking weight loss 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 Scale connected remotely to physician for real-time management of weight as a measure associated with congestive heart failure

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

34. Clinical Decision Support Software • FDA’s preliminary definition of CDS Software • Conversion • Algorithms (fixed or iterative) • Formulae • Database look-ups or comparisons • Rules or associations • Clinical Decision • Patient specific • Actionable result • Information • Data from a medical device • Environmental data (e.g., pollen count, temp.) • Demographic data (e.g., age, sex, socio-economic status)

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

36. CIMIT/Continua/FDA January, 2010

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

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

39. 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?

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

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

42. Design control complexities for open ended system • Postmarket challenges for root cause analysis, reporting and remediation • 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. DUPLICATION Looks 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 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

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

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.