Overview Of Issues And Global Cooperation In Software Regulation Larry Kessler, Sc.D. Director, Office of Science and Engineering Laboratories CDRH, FDA

Everyone’s goal To “tame the beast” i.e., to ensure the safety and effectiveness of medical device software in all its various types To do this not only in the US, but with our international partners The challenge is complexity! Regulatory approach and compliance determination can be costly Software and device connectivity are among the most complex Software provides 100 times more complexity than mere electronics; As a regulator; It is harder to provide criteria for software acceptability and -Harder to assess those criteria More expensive to meet them Collaboration between Industry and regulators ensures the least regulatory overhead possible!

Global Harmonization Task Force Goals To harmonize regulation of medical devices among members and provide a model for medical device regulation for countries other than the five founding members GHTF was founded in the early ‘90s for the purpose of harmonizing the way member countries regulate medical devices The guidance documents developed to promote this harmonizing among member countries are also useful to other countries that wish to regulate medical devices.

GHTF Members Founding members represent: Australia - Canada European Union - Japan United States of America Industry and regulatory bodies Interested other parties, e.g., WHO Member countries are: Australia, Canada, the European Union, Japan and the United States of America Representatives from regulatory authorities and industry participate in GHTF meetings.

GHTF Challenges Differing regulatory paradigms Maturity of systems varies Significant cultural differences Incorporating non-binding “guidance” into legislation and/or regulation difficult for FDA in short time period Economic incentives and disincentives

Accomplishments to Date A forum for open discussion of issues important to regulators and industry Development of harmonized guidance, especially quality systems and adverse event reporting Education for nations with new regulations Beginning to identify emerging issues

Global Harmonization Task Force Study Group 1: Regulatory Requirements for Premarket Review Study Group 2: Medical Device Vigilance/ Post-Market Surveillance Study Group 3: Quality System Requirements and Guidance Study Group 4: Quality systems auditing practices Study Group 5: Clinical evidence

5.0 GHTF Strategic Goals and Tasks 5.1 Emerging Regulatory Challenges The GHTF will encourage and support the timely identification of opportunities to promote regulatory convergence in addressing regulatory challenges including those of emerging public health risks and new medical technologies. The GHTF will implement a process to identify these new risks and technologies in order to achieve regulatory convergence in their management.

GHTF Ad hoc formed on medical device software The goal…. to study the incorporation of software specific measures into existing study group documents Identify areas where new software related documents might be introduced Use existing extensive work in the standards community on software The goal…. To draw together disparate regulatory paradigms where possible and thereby reduce the burden of software compliance on industry Comply once…. comply nearly everywhere I am current GHTF poobah! Sorry Larry I don’t know your exact title there! But we can use this forum to drive complexity (diversity of regulatory approach) out of the global marketplace We have new ad hoc starting up real soon which will address software in the GHTF for the first time.

60601-1 3rd edition FDA recognition likely Clause 14.1 now provides a system context for coherent application of a series of software standards and guidance; Clause 14.4 PEMS - development lifecycle (IEC 62304) Clause 14.6 Risk management process The new 60601-1 has taken 10 years to put together and the ideas has always been to provide a system engineering structure for software. The new standard can provide a skeleton on which to hang other standards like IEC 62304, and guidance like the two AAMI TIR’s. Open source software is not being utilized as much as it could because there was no real risk management systems context in the standards world for components. Network connectivity introduces new types of risks since it assembles things never intended to be used in a safety related way to an environment which is highly safety centric. The new 60601-1 will cover the middle ground in the business model component-device-system

More 60601-1 3rd edition Mandatory compliance with 14971 integrates risk management processes into the design of devices and their software, i.e., IEC 62304 AAMI TIR software risk management AAMI TIR software validation Incorporation of Open source Networking connectivity The new 60601-1 has taken 10 years to put together and the ideas has always been to provide a system engineering structure for software. The new standard can provide a skeleton on which to hang other standards like IEC 62304, and guidance like the two AAMI TIR’s. The same set of industry and regulators has been instrumental all along to provide a path of least resistance to an holistic compliance approach Open source software is not being utilized as much as it could because there was no real risk management systems context in the standards world for components. Network connectivity introduces new types of risks since it assembles things never intended to be used in a safety related way to an environment which is highly safety centric. The new 60601-1 will cover the middle ground in the business model component-device-system

IEC 62304 IEC 62304 (also to be recognized by FDA) is the international successor to AAMI SW68 Likely to emerge as the single global standard for medical device software engineering Written to ‘plug-in’ to 3rd edition Application guidance for IEC 62304 (to be finalized soon) -IEC TIR NNNNN-Medical device risk management – Guidance on the application of ISO 14971 to medical device software Comply once …use many times! Will have its own application guidance published soon, FDA may be able to rely on compliance with this standard for much of its Premarket submissions Soon to be harmonized in the EU. designed to be the next step down from 60601-1 clause 14 No normative references to 3rd edition because timelines were not aligned perfectly.

AAMI TIR on Software risk management Guidance on how to incorporate the hazard management techniques which software professionals are familiar with into a risk management process consistent with ISO 14971 Will provide product-centric complement to the process-centric ISO 14971 All to often software practitioners cannot relate system risks to their own hazard domain and finally this guidance speaks to their need. 14971 is too abstract for software (and hardware) engineers, but with this in hand the software engineers can see how what tey do in designing mitigations fits in the risk management context.

AAMI TIR on validation of software for regulated processes For software used in the production of a device Intended to provide an awareness of concepts and tools that can be applied to the task of software validation Directly applies to 21 CFR 820.70(i) Provides production engineering context to the process centric ISO 14971 For the first time a guidance is published on manufacturing software. Many production lines are automated and they have always been regulated but many manufacturers never knew the extent and rigor of what was expected.

Incorporation of open source FDA is reassessing the way in which open source is treated. Often the development environment is quite well structured with very able and well documented processes. We must learn to harness the technical innovations of the industry towards FDA regulatory mission; Automatic code analysis Modeling Simulation Open source is just one type of OTS software and in our industry it is not being used in the way it might. We need to provide a structured way for device manufactures to use Open source in an open way. By rethinking the COTS guidance we can provide the Open source developers with the advance tools they need to satisy their customers, the device makers. Communication of risk management through the chain of commerce is the key

Reengineering of OTS software approach FDA revising COTS guidance document to encourage a risk management approach to the incorporation of COTS in devices and in device production Providing an emphasis on product which can harness the technical innovations of the industry towards product integrity Open source is just one type of OTS software and in our industry it is not being used in the way it might. We need to provide a structured way for device manufactures to use Open source in an open way. By rethinking the COTS guidance we can provide the Open source developers with the advance tools they need to satisy their customers, the device makers. Communication of risk management through the chain of commerce is the key

Network connectivity As systems of devices become pervasive it becomes difficult to understand who is responsible for the safety and effectiveness of the device systems. Need to rely on a systems engineering approach as the regulatory context ISO/IEC 80001 (NWIP just approved) Joint IEC TC62a, ISO TC215 with strong liaison from TC210, TC212 We must perfect our regulatory model to be better able to evaluate systems of devices. The next best step, and probably a necessary one, is to encourage a standard for this topic, and let industry develop the baseline on a consensus basis.

In summary FDA continues to provide a global example for collaboration between medical device regulators and Industry Identifying a suitable standards and guidance structure for many aspects of software related compliance, open, least burdensome, system oriented letting the science assist the compliance Thank you for your warm applause.