Ralph F. Hall

Professor of Practice – University of Minnesota Law School

Counsel - Faegre Baker Daniels

Partner – Leavitt Partners

April 9, 2015

Seeking the Unified

Theory of Software

Regulation

Background and Disclosures

• Develop policy solutions

• Coalition management

• Consulting services

Partner – Leavitt Partners

• Advise clients on FDA regulatory matters, compliance issues and regulatory policy issues

Counsel – Faegre Baker Daniels

• Professor of Practice

• Supported in part by NSF and NIH GrantsUniversity of Minnesota

Law School

• Start up medical device company

• Probably PMA pathway if product successful

CEO – MR3 Medical LLC

2

Software Keys to Success Ongoing technological advances

Market needs

Payment/reimbursement

─ Value proposition

─ Who pays?

Regulatory (our topic for today)

─ Certainty

─ Effective and efficient

─ Relevant3

Core Regulatory Subjects Premarket system

─ Intended use based approach

─ Explicit pre-market approval

─ Satisfaction of pre-determined standards

─ Design systems

Label and promotional controls

Quality systems

─ Product validation and verification

Post-market systems

─ Product performance

─ Corrective actions and field actions4

Four Key Thoughts1. Current software regulatory oversight is based

on past software uses and technology

2. Current software regulatory oversight is

scattered among agencies and may seem to be

a patchwork

3. Lack of certainty and questionable rules hinder

software related advances for patient benefit

4. A new “unified” approach to software regulation

may advance patient benefit

5

Many talk about the

current state of affairs

Leaders shape the

future

6

To maximize the promise of software and related

technologies, a unitary regulatory system should provide:

- A uniform regulatory approach

- Tailored to the new technology

- Based on software function

- Risk centric

- Level and type of regulation varies with risk

- Non-platform or technology based

- Adaptable to new developments

- Using software technology tailored quality systems

- Providing certainty for all stakeholders

7

The Software Challenge:We Regulate Yesterday Well

Medtech regulation devolved for physical and

therapeutic products

─ If you drop it, it went “clunk”

─ It treated or diagnosed a patient

Medical Device Amendments 40 years ago (1976)

and SMDA 25 years ago (1990)

─ Has software changed much since 1990?

We use a 25+ year old system to regulate the 21st

Century

8

The Software Challenge:

We Regulate Yesterday Well – but differently

Software used in administrative functions not FDA

regulated

─ EHRs

─ Billing systems

─ Scheduling, inventory controls, etc.

Not FDA regulated

Other relevant systems

─ CMS, FCC, ONC

Standard development efforts

─ Connectivity9

Evolution of Software Regulation

Software oversight started from two uses

─ Software role in manufacturing

─ Software “embedded” in devices

Oversight manifested in three ways

─ Individual product reviews

─ QSR oversight activities

─ Sporadic guidance efforts

1989 draft software guidance

Handled as more “traditional” medical device

issues10

Software Evolution Technology advancing from multiple directions

Administrative (e.g. EHR) software adding more

complex and patient health centered features─ Clinical decision systems

─ Trending and alarms

─ Remote health applications

─ Data mining

Traditional medical device moving “down-market”─ Connectivity

─ CDS

─ EHR linkages

These come from very different regulatory paradigms

11

Software Evolution Software and related technologies evolved faster

than the regulatory systems

More than just operating system uses

Development of information centric software uses

Communication systems

─ Remote health

Decision support systems (including AI)

Move to consumer centric software

Rise of multi-function systems

12

Conceptual Challenges Software and related technologies used in very

different applications and settings

─ Therapy administration

─ Record keeping (e.g. EHRs)

─ Informational

─ Manufacturing and quality

─ R & D

─ Health care delivery

─ Billing and other administrative function

Different developers and processes

Separate regulatory systems evolving for these different

uses

However, these worlds are merging13

Current Balkanized Approach Application centric approach

─ MMAs

─ MDDS

─ “Health IT”

─ Embedded software

Jurisdiction centric concerns

─ FDA or someone else

Use of existing structures

─ PMA/510(k)s

─ QSRs

Enforcement discretion

On-going guidance development

Legislative efforts14

Current Initiatives Legislative initiatives

─ Medtech Act, Software Act, others

Various international efforts

─ IMDRF

SaMD regulatory framework

Draft SaMD quality system framework

─ Standard setting organizations

AAMI/UL 2800

Ongoing studies and assessments

─ Health IT report

15

Current FDA Approaches Product specific reviews

─ Embedded software

Application centric guidances

─ MMAs, MDDS

Enforcement discretion

─ Used to address some jurisdictional issues

QSR application

─ 820

Ongoing regulatory policy assessments

Stakeholder outreach16

The “Standard” Question Software currently regulated as “medical devices”

─ 21 U.S.C. §321(h).

The standard for marketing is “a reasonable

assurance” that the product is “safe and effective”

for its intended use (21 U.S.C. §393(b))

This standard makes sense for a therapeutic

product

Many software products provide information (e.g.

CDS, dosing calculators)

Is “safe and effective” the right standard or is it

information accuracy and clinical value? 17

Other Oversight Mechanisms Federal Trade Commission

─ Currently engaged in MMA oversight

Payment and reimbursement provisions

─ Meaningful use rules

Privacy rules

─ HIPAA and others

ONC

FCC

Cybersecurity oversight

Lanham Act

─ Competitor v. competitor actions

Patent

Copyright rules

State oversight 18

Pending Copyright Office Proposal

This [proposal] .. would allow researchers to

circumvent access controls … for purposes of good-

faith testing, identifying, disclosing, and fixing of

malfunctions, security flaws, or vulnerabilities.

… Petitioners seek to circumvent TPMs

[technological protection measures ] in medical

devices …supervisory control and data acquisition

(‘‘SCADA’’) systems; such as the computer code

that operate critical applications, such as

pacemaker applications …

19

Common Oversight Approaches

Agency centric

─ Limited linkages or integration

Many are application centric

─ MMAs

Based on original function of the software

─ Add-ons create confusion

Generally seek to fit software into existing

regulatory systems

─ FDA is limited by the current statute

Generally address current applications and

technologies 20

Emerging Oversight Efforts Various stakeholders addressing parts of the challenge

Congress:

─ Jurisdictional lines

IMDRF

─ Recent SaMD draft quality system framework

FDA

─ Cybersecurity initiatives

─ Premarket review processes

─ Software quality

CMS

ONC and FCC

─ Health IT report21

Accessory Challenge

An “accessory” to a medical device is historically

regulated as a medical device (see 21 U.S.C. §

321(h))

Are otherwise unregulated software functions

linked to a medical device therefore an

“accessory” and FDA regulated?

─ Could pull in many functions

─ HER type functions

Current draft accessory guidance

How should we address added functions?22

One Possible Future Continue current approaches

Congress will address jurisdiction

─ Two v. three “buckets”

─ Possible new FDA regulated software category

FDA oversight

Not utilize current pre and post-market systems

Tailored oversight and quality system

International efforts will be important

─ IMDRF

─ Standard setting groups

─ Harmonization23

One Possible Future Multiple regulatory oversight systems will remain

─ FTC, FDA, CMS, etc.

States will play a role

Separation of operational/therapeutic software,

information systems and administrative systems

Reimbursement/payment systems will attempt to

“value”

Efforts to tailor QSRs to better fit software

On-going role of enforcement discretion

Product and technology centric guidances24

Another FutureUnified Software Oversight Development of a software centric regulatory system

─ Different agencies may still play a role but

integrated

Address overlapping jurisdiction

Provide platform and application neutral oversight

Adaptable to new technologies and uses

Tailored premarket, post-market and quality systems

─ Recognize differences between software uses

Activity or function based regulation

─ Same activity or function regulated (or not) the

same way 25

What is Needed Is the current approach satisfactory or is a more

unified, tailored approach needed?

Stakeholder consensus needed for new approach

Statutory authorization probably needed

Multiple stakeholder engagement required

Current paradigms open to re-evaluation

26

Is This The Right Future?

To maximize the promise of software and related

technologies, a unitary regulatory system should provide:

- A uniform regulatory approach

- Tailored to the new technology

- Based on software function

- Risk centric

- Level and type of regulation varies with risk

- Non-platform or technology based

- Adaptable to new developments

- Using software technology tailored quality systems

- Providing certainty for all stakeholders

27

Questions and Comments

28