Regulatory Success with Digital Combination Products Samir A. Shah, PhD

Associate Director, Regulatory Affairs

1

FDA Mission: Protect and promote public health

Potential benefits of technologies developed through a rapid, iterative culture

methodical, capital-intensive process of generating evidence

2 Competing Interests Cause Regulatory and Organizational Challenges

2

Agenda

Why software is regulated and how

3 organizational challenges

5 tips for regulatory success

3

Device (and software) development has more changes in plans in shorter time intervals

4

Regulatory trust in design controls allows devices to reach the market more quickly (subject to inspection)

5

Software and Drug Products are Different

Software can be changed quickly and easily

Small changes can cause significant problems that may not be detected by software testing

Person who wrote code is different than person who maintains code

Software isn’t always user friendly

Job Job Job Job

6

Medical software requires even greater controls during design

7

Historical Regulation of Software

8

?

? 9

10

Design Controls

11

Code Implementation

Software Design Specifications

Architectural Design Chart

Functional Specification (includes hardware, system requirements)

User Requirement Specification

Unit Test Testing

Integration Testing

Verification Testing

Validation Testing

Business / Marketing Requirements System Validation + Human Factors

Design Controls Unresolved Anomalies

for Software Development

Confirms was met

Software Requirement Specification

2011: Human Factors Review for most Medical Devices

12

2014-2016: Software Changes, Cybersecurity, combo product HF

13

2015: Introduced “deregulatory” guidances

14

2017: 21st Century Cures

15

Software and Electronics Consensus Standards

16

Medical Electrical Equipment/Wireless

Medical Device and Health App Software

Connected Medical Devices

Systems and Software Engineering

AAMI TIR69 IEC 62304 IEC/AAMI TIR 80001 series ISO/IEC/IEEE 24765

IEEE.ANSI C63 27 IEC 82304 AAMI/UL 2800 ISO/IEC 24748-1

IEC 60601-1 IEC/TR 80002 ISO/IEC 24748-2

IEC 60601-1-2 AAMI TIR36 ISO/IEC 24748-5

IEC 60601-1-6 AAMI TIR45 ISO/IEC 42020

IEC 60601-1-8 Risk Management Cybersecurity ISO/IEC 26515

IEC 60601-1-10 ISO 14971 UL 2900 series ISO/IEC 20246

IEC 60601-1-11 ISO/TR 24971 AAMI TIR57 ISO/IEC 26513

Adapted from slides by Rob Packard of Medical Device Academy

Digital Health Regulatory Challenge #1

Unclear regulatory pathway for software associated with a pharmaceutical product

Citizen Petition about digital combination products 17

Digital Health Regulatory Challenge #2

New team members Different terminologies,

priorities, and processes Many with little experience

working on FDA regulated products

Clinical Lead

CMC Lead

Tox Lead

Reg Lead Marketing Lead

Regulatory Device Lead

Device Lead

Project Leader

Device Quality

UX Engineer

Elec-Mech Engineers

Validation Engineers

Software Engineers

Security Privacy

18

Digital Health Regulatory Challenge #3

It’s complex, not just complicated

Each area affects others

19

5 Tips to Overcome these 3 Challenges

Tip #1: Expand the risk management process, regardless of regulatory classification

• Risk management: ISO 14971 • Electrical equipment: IEC

60601 • Software: IEC 62304 and

IEC/TR 80002 • Cybersecurity • Human Factors

Medical device frameworks

• Over or under dose (Threshold Human Factors Guidance)

• Consistent with the label (Promotional Guidance)

• Effect of software on use of drug and therefore, clinical outcome

Drug frameworks

21

Tip #2: Communicate the software so it is easier to understand

Dilbert Cartoon on Requirements, January 29, 2006

22

Communicating software is challenging because there are many different options and paths

23

Better software communication reduces later rework

Align on vocabulary / terminology “Alert,” “message,” or “notification”?

Create documents that allow all functional areas to assess risks from their specialization’s perspective

24

Tip #3: Add timeline scenarios for uncertainty to ensure you communicate with regulators frequently and thoroughly

Regulatory interactions are valuable because they will identify risks not considered by the sponsor if the regulators understand your software

25

Add one more timeline scenario: if FDA says yes, if FDA says no, and if FDA doesn’t have enough information to answer

26

At <big company>, code deployed once per week. At <startup>,

deploying code 40-50 times per day.

MOVE FAST AND BREAK THINGS. Unless you are breaking stuff,

you are not moving fast enough - Letter to Facebook investors by Mark Zuckerburg

Can be fixed in the next version based on user feedback only if you can wait another 60 – 90 days for regulatory feedback

27

Tip #4: Support all software feedback with a clinical guideline, a clinical study, or robust data

Software can hook our attention Software can also affect use and

affect clinical outcome Have design inputs that trace to a

clinical guideline and/or define limits of accuracy

28

Tip #5: Organize for responsiveness not efficiency

29

Tip #5: Organize for responsiveness not efficiency

Build relationships across team member areas to ensure free communication Strive not just to understand the “what” of other team member areas, but “why” Reflect on the basis of minimizing a risk when it affects another team member’s

area

30

Regulatory Success with Digital Combination Products

1. Expand the risk management process, regardless of regulatory classification

2. Communicate the software so it is easier to understand

3. Add timeline scenarios for regulatory uncertainty to ensure you communicate frequently and thoroughly

4. Support all software feedback with a clinical guideline, a clinical study, or robust data

5. Organize for responsiveness not efficiency

samir.shah@tevapharm.com