Overview of regulatory and compliance in software development for medical devices Oleksandr Prokopchuk, Business analyst

Agenda Introduction – demystifying regulations Regulating bodies & definitions Types of regulated software Brief overview of IEC 62304 SDLC and outputs “Rules of the game” to do a compliance work on project Q&A

Introduction Medical products are different from other consumer goods or products. The primary purpose of implementing regulatory systems for medical devices is to protect public health and ensure safety and performance. Software that is incorporated into a medical device, or which is a standalone medical device, is subject to regulation from various jurisdictions (principally the EU and the US). The risks associated with each type of device type differ Why are regulatory controls for medical devices complicated?

MD regulatory landscape “looks like”

Medical Device Regulations Medical devices are highly regulated: FDA approval (United States) UL listing might be required by customer CE mark (Europe) MHW approval (Japan) Other national requirements

FDA Approval Pre-Market Approval (PMA) - Path to market for new devices - Generally requires clinical trials - Company submits extensive documentation and data 510(K) - Establish “substantial equivalence” to a predicate (existing) device - May include clinical trials - Less extensive documentation and data In 2016, the FDA approved 3,006 510(k) devices compared with 47 PMA devices (Source: www.fda.gov).

CE Mark Indicates that product satisfies European safety requirements Managed by “notified bodies”, such as: - TUV (Germany) - BSI, SGS (United Kingdom)

Medical Device Definition Medical devices range from Simple Devices Tongue depressors, gloves and bedpans Complex Devices Programmable pacemakers Laser surgical devices Medical Device Classification – Class I, II, and III Class I devices include those with the lowest risk Class III devices includes those with the greatest risk.

Medical Device Definition "an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is: recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, 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 intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it's primary 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 primary intended purposes."

Intended Use / Purpose Intended use or intended purpose refers to “the use for which the device is intended according to the data supplied by the manufacturer on the labelling, in the instructions and/or in promotional materials” (Article 1(2)g of Directive 93/42/EEC) Thus, the concept of “intended use” often determines whether a product is a MD or general health wellness support service.

Software – Special Attention FDA Principles of Software Validation, General Guidance, 2002 3.3 Software Is Different From Hardware “Because of its complexity, the development process for software should be even more tightly controlled than for hardware, in order to prevent problems that cannot be easily detected later in the development process”. “……. software engineering needs an even greater level of managerial scrutiny and control than does hardware engineering”.

Types of Regulated Software Medical Device Software Software that is actually a part of the medical device itself Software that is an accessory to a medical device Software that itself is a medical device Non-Device Software that is part of: The production system The quality system Systems that are used to create and maintain records required by FDA regulations

IEC 62304:2015 Medical Device Software Lifecycle IEC 62304 background IEC 62304:2015 Medical Device Software Lifecycle Specifically created for medical device software IEC 62304 defines the software development and verification activities which MD manufacturers must comply with SDLC includes risk management, configuration management and problem resolution processes guided by IEC 62304 at each phase Under IEC 62304, responsibility of the manufacturer also goes beyond the release of the software product, with particular emphasis on product maintenance The manufacturer has to monitor and document the feedbacks both within organizations and users. This feedback must be analyzed to determine whether a problem exists

Status of IEC 62304 Approved by both IEC and ISO as an international standard (joint development effort) Adopted by CENELEC as EN and harmonized 11/08 under the MDD, AIMDD Adopted by ANSI as US national standard (replacing ANSI/AAMI) Recognized by FDA for use in premarket submissions China – CFDA adopted 62304 Translations exist in French, German, Spanish, Chinese and Japanese Adopted as a Japan Industry Standard CENELEC is the European Committee for Electrotechnical Standardization and is responsible for standardization in the electrotechnical engineering field. AIMDD – Active Implantable Médical Devices Directive

62304 philosophy Safe medical device software requires risk management, quality management and good software engineering Good software engineering requires critical thinking – can’t be done by checklist Manufacturers know more about their products than regulators The variety of medical devices requires a variety of approaches – one size does not fit all Resources should be used on what is important A standard should have minimum requirements, not best practices

62304 Software Safety Classification Software System Overall Class A: No injury or damage to health is possible Class B: Non-serious injury is possible Class C: Death or serious injury is possible Classification shall be documented Software System may have lower worst case risk than device overall, but cannot be higher Both direct and indirect harm are included Class C is the default assumption

IEC 62304 - What is it? A framework – processes, activities and tasks process is the top level, a process has activities and an activity has tasks. Specific requirements in IEC 62304 are generally at the task level. Identifies requirements for what needs to be done and what needs to be documented Specifies a software safety classification system additional requirements apply as safety classification increases

IEC 62304 - What is not in it? Does not prescribe how to accomplish requirements – Not a “how to” with defined methods or practices Does not require a specific software life cycle Does not specify documents What to document, not where it must go. All of these decisions are left to the manufacturer

Software Development Procedure Typical SDLC phases are: Requirements Design Implementation Integration and Test Design Transfer (to production) Maintenance

QMS Documents outputs during SDLC   Requirements Design Implementation Integration & Test Design transfer (to production) Maintenance Risk Management Report Design And Development Plan User Requirements Specification System Requirements Specification Software Requirements Specification Software Specification Supporting Material Design Requirements Specification Unit Test Plan Unit Test Protocol Unit Test Report Code Review Checklist System Requirements Traceability Matrix System Integration Test Plan System Integration Test Protocol System Integration Test Report Design Review for Medical Device Software

Tips for successful compliance on project Software for medical devices costs 0 USD if there are no compliance accompanying documentation Involve your team to collaborate on compliance works – both on clients’ and your side as you need their SME support Build your professional compliance network – it will help to manage practical cases on regulations FDA and other regulatory bodies are constantly changing – be always updated with the law. Usually compliance consultant from contractor side (like DA) takes a role of Quality Assurance. This is because most of the compliance documents require authorized signature of trained person only. All responsible stakeholders who should sign the documents off have to show and prove regulatory body their training records. The MD manufacturer can outsource any kind of work to third party but not liability and compliance to regulations

Oleksandr Prokopchuk Business Analyst Oleksandr Prokopchuk@dataart.com https://www.facebook.com/aleksander.prokopchuk Oleksandr.Prokopchuk@dataart.com

Q&A