Risk Assessments: Patient Safety and Innovation

1. Risk Assessments:Patient Safety and Innovation 28 June 2013

2. Committee Members David Bates, Chair, Brigham and Women’s Hospital •Patricia Brennan, University of Wisconsin-Madison •Geoff Clapp, Better •Todd Cooper, Breakthrough Solutions Foundry, Inc. •Meghan Dierks, Harvard Medical Faculty, Division of Clinical Informatics •Esther Dyson, EDventure Holdings •Richard Eaton, Medical Imaging & Technology Alliance •Anura Fernando, Underwriters Laboratories •Lauren Fifield, Practice Fusion, Inc. •Michael Flis, Roche Diagnostics •Elisabeth George, Philips Healthcare •Julian Goldman, Massachusetts General Hospital/ Partners Healthcare •T. Drew Hickerson, Happtique, Inc. •Jeffrey Jacques, Aetna •Robert Jarrin, Qualcomm Incorporated •Mo Kaushal, Aberdare Ventures/National Venture Capital Association •Keith Larsen, Intermountain Health •Mary Anne Leach, Children’s Hospital Colorado •Meg Marshall, Cerner Corporation •Mary Mastenbrook, Consumer •Jackie McCarthy, CTIA - The Wireless Association •Anna McCollister-Slipp, Galileo Analytics •Jonathan Potter, Application Developers Alliance •Jared Quoyeser, Intel Corporation •Martin Sepulveda, IBM •Joseph Smith, West Health •Paul Tang, Palo Alto Medical Foundation •Bradley Thompson, Epstein Becker Green, P.C •Michael Swiernik, MobileHealthRx, Inc. Federal Ex Officios •Jodi Daniel, ONC •Bakul Patel, FDA •Matthew Quinn, FCC

3. FDASIA Group • Charter • The Food and Drug Administration Safety and Innovation Act (FDASIA) directed the HHS Secretary, acting through the Commissioner of the U.S. Food and Drug Administration (FDA), and in consultation with ONC and the Chairman of the FCC, to develop a report that contains a proposed strategy and recommendations on • an appropriate, risk-based regulatory framework for health IT, including medical mobile applications, • that promotes innovation, • protects patient safety, • and avoids regulatory duplication.  • The FDA, FCC, and the HHS Office of the National Coordinator for Health IT (ONC) will review and consider the recommendations provided by the Health IT Policy Committee, based on input from the workgroup, as the three agencies write the report. • Goal: recommended regulatory framework for regulation of HIT

4. Work Product Approaches • Critique of current regulation / exemplars (slides 7-19) • Experiences with current regulation • Innovation Requirements (slides 20 – 28) • General requirements • Specific requirements - stratified by source of innovation • Suggested framework for innovation (slides 29 - 35)

5. Regulatory Group Purpose of regulation is to solve known problems.

6. IOM Report • Government’s Role (IOM Report) • “The government in some cases is the only body able to • provide policy guidance and direction to complement, bolster, and support private-sector efforts and • to correct misaligned market forces.”

7. Question What has been the impact of current regulation on innovation?

8. Existing Regulation • FDA • Medical Device regulation: • Labeling • Manufacturing practices • Pre-marketing approval • ONC • ARRA Certification • Promotes “Best Practice” • Meaningful Use • Implements “Best Practice” • SureScripts Certification • Promotes “Best Practice” • FCC

9. Medical Device Definition (FDA) • SEC. 201. [321] For the purposes of this Act – • (h) The term "device" … means an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is-- • (1)recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them, • (2)intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or • (3)intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of its principal intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its principal intended purposes.

10. Medical Device Definition (FDA) • SEC. 201. [321] For the purposes of this Act – • (h) The term "device" … means an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is-- • (1)recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them, • (2)intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or • (3)intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of its principal intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its principal intended purposes. • Point:Regulatory Discretion

11. Question What are the differences between Medical Devices and Software?

12. Medical Device versus HIT Physical Device • Physical • Long development / enhancement cycles • Fixed functionality • Task oriented • Measured against the task • Environment of operation relatively defined and static • Contributing suppliers more controlled and measureable Software • Virtual • Constant change • Major releases, minor releases updates of currently running software • Network connectivity: security, privacy, upgradeability • Customization and configuration expectation • What does Pre-Marketing Approval mean when distributing monthly updates? • Configurable by design • Tools to extend the products function • Can be process oriented vs single task • Measured against practice impact, not absolutes • Environment (hardware, other software on hardware) more open • Contributing suppliers layered with many contributions not specifically designed for healthcare – e.g., PC or phone operating system

13. 21 CFR Chapter 1

14. Part 820 – Quality System Regulation • General Purpose: • Device manufacturers are required to establish and follow set procedures and policies to help ensure that their products consistently meet set requirements, specifications and are safe and effective. The quality systems for FDA-regulated products (food, drugs, biologics, and devices) are known as current good manufacturing practices (CGMP’s). • How does this fit with Health IT? • At high level, QSR is focused on traditional manufacturing and needs to consider application to traditional software development. • Most Relevant Sections • Subpart B: Management Controls • Subpart C: Design Controls • Subpart E: Purchasing Controls • Subpart J: Corrective and Preventive Action • Subpart M: Records • AAMI published report on application of 5 QSR requirements to MDDS http://www.aami.org/publications/AAMINews/May2012/sw87.html • AAMI is now working on a broader project for HIT

15. FDA: Medical Device Regulation Pros • Process control, not outcomes – standard, consistent manufacturing process that can be applied to software • Confidence in resulting product Cons • Clarity • Who is subject to regulation? • Implementation barriers – knowledge & overly prescriptive • Geared to physical devices – needs some adjustments – adds and subtractions – to fit with medical software • Issue: start small without regulation, but then applying regulation after the fact

16. ONC Certification Regulation • Motivation: defined outcomes • Government is funding a capital improvement to healthcare practice • Therefore, obligation to promote good products • Therefore, defined “Best Practice” • Effect: • Assumption of known Best Practice where not known • Specification of Best Practice and certifying specific test behaviors limits innovation • Working to the test – “Compliance Innovation”

17. ONC Certification RegulationRole of Measurement • Policy • Intent, vision, goal • Outcomes orientation • Measurement – test cases • Specific imagined implementation “Not everything that can be counted counts, and not everything that counts can be counted.” – Einstein or Cameron “You can only manage what you measure.” ~Deming

18. ONC Certification RegulationOther Impacts to Innovation • Endorsement and empowerment of private certification regimens: SureScripts • Another certification involving “Best Practice” • Little option to avoid this certification even though not specifically mandated by ONC • “Best Practice” defined in less transparent, less responsive system; i.e., private entity • Constant reporting of “changes” to software with unclear consequence of triggering re-certification • Uncertainty increase causes innovation decrease – every incentive NOT to change • Does not fit with constant updates of software

19. Comparison of Approaches FDA Medical Device ONC Certification Outcomes control “Best Practice” feature definitions Pre-use approval Impact Reduced flexibility (defined features), reduced innovation Empowered added private regulation Non-productive work to test – “Compliance Innovation” Less market neutral – favors existing software with defined features Regulatory avoidance: control each features and test script • Process control • Pre-marketing approval – in some cases • Impact • Can be positive when combining software from different sources – increased trust • Lack of clarity (flipside of Regulatory Discretion) yields policy uncertainty • Entry impedance • Clarity on requirements & process – purpose of AAMI report • Late entry into process with existing product • Continued overhead: heavy process versus agile development • If fully applied to local implementation, devastating to market – Blood Bank example • Regulatory avoidance: dis-qualify for regulatory inclusion

20. Questions What are the specific innovation requirements? Stratified by level of innovation or opportunity for innovation

21. Nature of Innovation RiskGeneral Attributes / Requirements IOM Report, Appendix D StringencyInnovation FlexibilityInnovation • Defined as the number of implementation paths to meet compliance. . InformationInnovation • Defined as if a regulation promotes more or less complete information in the market. Measurement Innovation Goal Attainment Specificity

22. Sources of Innovation / RiskFull Spectrum of the SocioTechnical System • Developed software – vendor and local • Software setup / customization / extensions • Integration with medical processes – sociotechnical system • Communication devices • Combining technologies • Predictable (e.g., HL7 interfaces) • Non-predictable (e.g., end user combination of available technologies – software and hardware)

23. Questions • What are the innovation requirements? • Stratified by level of innovation or opportunity for innovation • Vended software • Local creation of software • Local configuration of software • Local extension of software – using provided tools • Local combination of technologies • Communication devices • Interoperability: HL7 interface, service calls, database sharing,

24. Vended Software • Innovation requirements • Policy clarity • In / out of regulatory focus • Re-certification / re-authorization rules • Consistent international regulatory framework • Interoperability Standards – mixed effect • Increased innovation opportunity for small-scale product to plug into existing market; “development ecosystem” • Defined endpoint decreases innovation • Limited governmental direction; facilitate market driven standards • Eliminate / minimize defined features / certification • Process controls can enhance innovation – trust method • Goals – set problems-to-solve agenda for innovation • Provide pathway to become compliant with • Transparency between suppliers and with consumers • Accept relative risk • Shift some process control to post-distribution • Framework of non-punitive disclosure of issues • Accountability model • Consistent national and international standards • Transparency of process, artifacts, and results

25. Locally Developed Software • Innovation requirements • Policy clarity • In / out of regulatory focus • Re-certification / re-authorization rules • Interoperability Standards – mixed effect • Increased innovation opportunity for small-scale product to plug into existing market; “development ecosystem” • Defined endpoint decreases innovation • Limited governmental direction; facilitate market driven standards • Eliminate / minimize defined features / certification • Process controls can enhance innovation – trust method • Goals – set problems-to-solve agenda for innovation rather than feature agenda • Provide pathway to become compliant with existing software (i.e., software developed before regulatory focus) • Transparency into supplied software (locally developed software most often leverages pieces of software intended or not for medical use) • Accept relative risk • Shift some process control to post-distribution • Framework of non-punitive disclosure of issues • Local process controls • Turnaround time: lightweight process adaptable to different level of development effort and scope • Iterative development / implementation cycles • Controlled pilots with real patient data and informed users • Accountability model • National process controls – administered locally & available for audit • Local, continuous oversight • Surveillance: feedback loop of results • Local control , governance , and accountability for pilot use

26. Locally Configured Software • Innovation requirements • Transparency into supplier process and results • Open communication of issues • Adequate training and documentation of supplied software • Local process controls: review, testing, implementation, and surveillance • None to little federal oversight: inheritance of supplier oversight • Accountability model • Integration with local medical processes • Testing of configuration • Surveillance of results • Reporting of local results

27. Locally Extended Software • Innovation requirements • Transparency into supplier process and results • Open communication of issues • Adequate training and documentation of supplied software • Local process controls: review, testing, implementation, and surveillance • Accept relative risk • Framework of non-punitive disclosure of issues • Turnaround time: lightweight process adaptable to different level of development effort and scope • Iterative development / implementation cycles • Controlled pilots with real patient data and informed users • Local process controls • None to little federal oversight: inheritance of supplier oversight • Accountability model • Integration with local medical processes • Testing of extended software • Surveillance of results • Reporting of local results • Local control , governance , and accountability for pilot use

28. Local Combination of Technologies • Innovation requirements • Local process controls • Accountability model • Expectations of suppliers

29. Biggest picture(Regulatory Group –review July 8th) Looking at the three agencies together, is there a better way to regulate HIT?

30. Assumptions • Everyone is interest in patient safety. • We need innovation to solve problems in healthcare. • IT tools have a central role in solving cost and quality issues. • We need to encourage more, not less, participation in this innovation and this sector.

31. “Status Quo is not always the safest state.” • Risk of the innovation • Risk of the status quo • Neither is risk free • Balance of risk

32. Regulatory Approach • Standard approach • Risk • Regulation • Mitigate innovation harm • Reverse • Promote innovation • Address patient risk • Address regulation

33. Regulatory Approach • Legal framework • Prevention of then known risks • Prescriptive • Inhibits transparency • Effort to mitigate innovation risk • Learning framework • Predicated on transparency • Acceptance of relative risk • Effort to prevent only the out of bounds errors • E.g., lose track of the patient focus

34. IOM Report • To encourage innovation and shared learning environments, the committee adopted the following general principles for government oversight: • Focus on shared learning, • Maximize transparency, • Be nonpunitive, • Identify appropriate levels of accountability, and • Minimize burden.

35. Shared Learning / Market Forces • “Transparency” • No barriers to sharing data – remove artificial barriers • Repository of data • Post marketing surveillance • Breakdown legal barriers for transparency • Sharing of test cases and results