Upload
mobcon
View
33
Download
0
Tags:
Embed Size (px)
Citation preview
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
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