Keren Elghouzzi-Kazachinsky,
Head of SW QA, Physio-Logic Ltd.
February 2017
Digital Health
The Regulatory Landscape
2
Head of SW QA/RA and Certification Project Manager A Software Quality and Software Engineering Process expert with
over 20 years of experience in SW industries with Motorola, AirbusIndustry and Medical Devices industries
Leading the Physio-Logic Software Quality & Regulations, providingservices to medical devices companies in all aspects of Softwareregulations
Large track record of successfully supporting Medical DevicesCompanies thru Implementation of IEC62304, Agile deployment,Software QA/RA, Software V&V, ISO 13485 Certification, CE markingand FDA regulatory requirements and certification of SW suppliers
Bsc in Physics- Paris VII, BSEE from Technion, specialized in Bio-medical technologies
Digital Health context
4
Includes many aspect of our health:
Analysis of big data to support Healthcare improvement
Digital medical devices
Consumer engagement
Telemedicine, Personalized medicine,
Health Management
Wearable devices
And many more ….
Digital Health components
5
A compilation of:
On-line Platforms
Mobile Medical Apps
Cloud-based storage of health information
Distributed System
Wireless Capabilities
One key component: Software
Enabling Functionalities & responsible for potential failures:
Sw Challenges in Medical Devices
6
Internet Of Things:
Safety is not only at Device level but at System level
Sw Development
8
Development Tools• Requirement Management and traceability• Code analysis tool• Automated testing tool• ALM
Characteristics of Medical Device SW Algorithm – rely on complex math
calculation Sophisticated GUI SW Interfacing with HW Sw Reuse Sw Testing
SW
Ch
all
en
ge
s
Regulatory Challenges
9
Balance between Innovation and Regulations:
The conflict between protecting
public health and stifle innovation
10
Do we apply the appropriate regulatory requirements applicable to our product?
What is the best regulatory strategy?
The Impact of Regulation –the Early Stage
Wrong doing, under doing, over
doing? …
Are we budgeted and staffed
appropriately?
Matching expectations with
investors?
Kind of Software
Software as part of a Medical DeviceSoftware that is a component; integral part of a medical device
Embedded Software e.g., software that
Controls a CT scanner
Measures the foetal heart rate as part of the foetal monitor
SW as a Standalone = Software as a Medical Device App that uses patient data to create dosage plans for radiation
App that displays ECG signal
12
FDA - Key points and existing guidance
13
• What is its classification?FDA database on product classification of medical devices
• 510K guidance?FDA's website: medical devices guidances search page
• How do I design it?FDA guidance on software design , the General Principles of Software Validation; Final Guidance for Industry
and FDA Staff
• What do I put in my 510k submission ?FDA gives instructions about software in medical device in the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices.
FDA – Digital Health related Guidance
14
FDA issued several guidance ; Risk-based approach strategy :
Management of Cybersecurity in Medical devices , Oct. 2014
Scope of the guidance: to identify relevant cybersecurity issues that should be
considered in the design and development to document potential cybersecurity risks to mitigate those risks with the measures and controls
Radio Frequency Wireless Technology for Medical Devices, August 2013
Scope of the guidance: FDA regulates the design, development and testing … FCC oversees Bandwidths in which Medical Devices
operate
FDA Regulated vs. Non-Regulated MDDS
“The success of digital health “requires that many medical devices be interoperable with other types of medical devices and with various types of health information technology. The foundation for such inter-communication is hardware and software that transfer, store, convert formats, and display medical device data or medical imaging data.”
MDDS Final Guidance (Feb 9, 2015): FDA does not intend to enforce compliance, But MDDS does not include:
Products intended for active patient monitoring i.e.
clinical context requires a timely response
The clinical condition (disease or diagnosis) requires a timely response
Modifies the medical device data, and
Control the functions or parameters of any connected medical device
FDA Regulated vs. Non-Regulated Mobile Apps
MMA Final Guidance (Feb. 2015) – the FDA defined
“Mobile Medical Apps” software that meet both:
the definition of a Medical Device “intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man”
AND are used as an accessory to a “regulated medical device”
OR transform a mobile platform into a “regulated medical device.”
EU - Key points and existing guidance
18
• Is your software a medical device?MEDDEV 2.1.6 Guidelines on the qualification and classification of stand alone software.
MEDDEV 2.1/1Definitions of "medical devices", "accessory" and "manufacturer"
• What is its classification?MEDDEV 2.4.1 rev9 Comprehensive interpretation of the classification rules of the 93/42 directive.
• How to do clinical evaluation?MEDDEV 2.7.1 rev 4 Clinical evaluation - Guide for manufacturers and notified bodies contains recommendations about clinical evaluation, may impact S/W Design.
Other useful documents: • European Commission Manual on borderline and classification for medical
devices
• Team NB FAQ : Implementation of EN 62304:2006 vs MDD 93/42/EEC.
Revision of MEDDEV 2.1/6 SaMD
Classification of Software as a Medical Device ,July 2016
Standalone Software must have a medical purpose to be qualified as medical device Intended purpose
Software claims is a Key !
Same classification rules as active medical device (rule 9-12 of Annex IX to directive 93/42/EEC) Class I-IIb
New EU MDR much stricter
New and much stricter medical device regulation , signed by EU and to become effective in 3 years.
New SaMD classification
New Class for Software device– Rule 10a: The rule 10a classification approach is based on both the
purpose of the device and the risk assessment of this device.
A single risk with high severity can push a standalone software in Class III.
New expectations for QMS, risk categorization, clinical evaluation
IEC 62304:2015 Amdt 1
Major Changes:
Clarification of Scope of the standard
Modifications of Software Safety
Classification – new risk based approach
Requirements on Legacy Software
Increased #of clauses applicable to Class A
Take Home Messages
Functionality and risk will dictate to what extent your health IT product be regulated
Lack of clarity make it challenging to navigate the regulatory maze at this time
Consult and develop defensible regulatory strategy
Turn regulation from necessary evil to competitive advantage