Digital Health Think Tank kick-off meeting June 14, 2016

Overview Scope World of today Trends World of tomorrow – a desired state 2

Types of Medical Device Software 3 Software used in the manufacturing process of a device Software as a device Software in a device inas u

Vision Goal is for patients to have access to high quality, safe and effective products Imagine a model where … …regulatory decisions for software are timely and of high quality 4

Summary of Current Medical Device Software Regulations Establishment Registration and Device Listing (21 CFR 807) Quality System Regulation (21 CFR 820) –All software requires design control Medical Device Reporting (21 CFR 803) and Corrections (21 CFR 806) Labeling (21 CFR 801) Premarket Submissions: –Most class I devices can be legally marketed without FDA premarket clearance of a 510(k) submission. –510(k) (Most class II devices, few class I) –PMA - Premarket approval application or De Novo submission (Class III)

Software review and oversight Premarket review (for most class II and class III) –Paper submission –Review process Intended use, Device Description Level of concern determination Software artifacts Labelling –Regulatory decision (clearance/approval) Post market reporting (MDR, Recalls) Changes/modifications –Some require – traditional 510(k) / special 510(k) –Some don’t require submissions Inspections to confirm design controls applied –Based on quality processes expected for all medical devices 6

Premarket Submissions Amount and detail/depth of documentation depends on the Level of Concern (pre- mitigation risk to patient from your device) –Major (Death or serious Injury) –Moderate (Minor Injury) –Minor (unlikely to cause any injury) These artifacts are reviewed within the general decision making criteria for that submission type (e.g. substantial equivalence for 510k and reasonable assurance of safety and effectiveness for PMA) 7 Software Artifacts Software DescriptionDevice Hazard Analysis (HA) Software Requirements Specifications (SRS) Architecture Design Chart (ADC) Software Design Specifications (SDS) Traceability Analysis Software Development Environment Description (SDED) Verification and Validation Documentation (V&V) Revision Level History (RLH) Unresolved Anomalies (UA) Off-the-Shelf Documentation (OTS) Cybersecurity (CS)

Rapidly Evolving Landscape Most medical devices rely heavily software Software development practices are evolving Changes to software are easy and more frequent Connectivity of devices have lead to new risks Diagnostics and analytics rely heavily on software 8

Different Perspectives 9 The Chasm Technical camp Engineering + R&D departments Regulations Camp Regulators/auditors “Translators” …QA personnel, RA personnel, Analysts … Business camp Business leaders, Customers, patients Systems and software must reflect patient needs

Macro trends Age of –Short development life-cycles (36 mo  18 mo  3-6mo  continuous) –Constant change and delivery (expected and accepted norm) –Continuous learning –Social product development –Globalization Business drivers –Rapid new product introduction timelines –Drive to differentiate by leveraging software and connectivity –Drive to deliver in a global market place 10 5 Hot trends in Software development hiring (CIO magazine) 1.Mobile 2.Big Data 3.Cloud 4.DevOps 5.UI staffing/5-hot-trends-in-software-development- hiring.html#slide1 5 Hot trends in Software development hiring (CIO magazine) 1.Mobile 2.Big Data 3.Cloud 4.DevOps 5.UI staffing/5-hot-trends-in-software-development- hiring.html#slide1

Software development trends Highly accessible software development – a world where everyone programs Plug-ins replacing full-fledged programs Program Language and platform agnostic – graphical, language closer to simple English for programming Social programming teams Verification commoditized / automated Source management – GitHub, etc. Distribution – mostly cloud or the app store 11

Current State of Digital Health Current Infrastructure Regulatory Situation 12 regulatory paradigm software development timelines + software development practices + rapid changes staff expertise Review emerging issues – (cybersecurity; digital health products) Support (review and consults) for increasing volume of submissions in 49 branches staff capacity

Desired State Policies and reviews are focused on higher risk products Focus on higher risk products Ability to assess QS capability Align industry practice to QSR Rely on QSR capability Submission content scaled to QMS capability Leverage post-market data for rapid changes Scaled premarket requirements to QS Staff trained in technical skills Experts for challenging topics + consistency Staff with skills and support Proactively engage with stakeholders Align with technological, clinical and product delivery advances Continuously clarify and learn 13

Axes to consider When –Risk of the product –Premarket v/s postmarket –How often (changes) –Event based (premarket) v/s continuous What should FDA review –Product level content –Format of review –Firm’s capabilities to create, manage, prevent and sustain 14

A new paradigm Imagine a world – where we have an Agile regulatory framework that assures safety and effectiveness through –Quality regulatory decisions –Timely decisions - in line with product cycle time –Learns from real world use 15

Open questions – Bridging Across “The Chasm” How good is our current regulatory system –Lots of paper – does it help? –Modifications – are we clear? –Decision cycle time Axes to consider –Relying on an organization’s capability Key performance indicators (KPI) Development methods and process –no one single process works for each firm ( software-development-methodologies-work/) –Submission content and format –QMS for software 16

17 The Software/Systems Development Lifecycle. Tuesday, November 18th, With David Mantica. SDLC Trends in 2014 and Beyond:.

Questions / Brain storming on scope 18