Overview of regulatory and compliance in
software development for medical devices
Oleksandr Prokopchuk,
Business analyst
Agenda
• Introduction – demystifying regulations
• Regulating bodies & definitions
• Types of regulated software
• Brief overview of IEC 62304
• SDLC and outputs
• “Rules of the game” to do a compliance work on project
• Q&A
Introduction
• Medical products are different from other consumer goods or products.
• The primary purpose of implementing regulatory systems for medical devices is to
protect public health and ensure safety and performance.
• Software that is incorporated into a medical device, or which is a standalone medical
device, is subject to regulation from various jurisdictions (principally the EU and the US).
• The risks associated with each type of device type differ
• Why are regulatory controls for medical devices complicated?
MD regulatory landscape “looks like”
Medical Device Regulations
• Medical devices are highly regulated:
–FDA approval (United States)
• UL listing might be required by customer
–CE mark (Europe)
–MHW approval (Japan)
–Other national requirements
FDA Approval
• Pre-Market Approval (PMA)
- Path to market for new devices
- Generally requires clinical trials
- Company submits extensive documentation and data
• 510(K)
- Establish “substantial equivalence” to a predicate (existing) device
- May include clinical trials
- Less extensive documentation and data
In 2016, the FDA approved 3,006 510(k) devices compared with 47 PMA devices
(Source: www.fda.gov).
CE Mark
• Indicates that product satisfies European safety
requirements
• Managed by “notified bodies”, such as:
- TUV (Germany)
- BSI, SGS (United Kingdom)
Medical Device Definition
 Medical devices range from
 Simple Devices
Tongue depressors, gloves and bedpans
 Complex Devices
Programmable pacemakers
Laser surgical devices
 Medical Device Classification – Class I, II, and III
• Class I devices include those with the lowest risk
• Class III devices includes those with the greatest risk.
Medical Device Definition
"an instrument, apparatus, implement, machine, contrivance, implant, in
vitro reagent, or other similar or related article, including a component part,
or accessory which is:
• recognized in the official National Formulary, or the United States
Pharmacopoeia, or any supplement to them,
• intended for use in the diagnosis of disease or other conditions, or
in the cure, mitigation, treatment, or prevention of disease, in man or
other animals, or intended to affect the structure or any function of the
body of man or other animals,
• and which does not achieve any of it's primary intended purposes
through chemical action within or on the body of man or other animals
and which is not dependent upon being metabolized for the achievement
of any of its primary intended purposes."
Intended Use / Purpose
• Intended use or intended purpose refers to “the use for which the device is
intended according to the data supplied by the manufacturer on the
labelling, in the instructions and/or in promotional materials”
(Article 1(2)g of Directive 93/42/EEC)
• Thus, the concept of “intended use” often determines whether a product is
a MD or general health wellness support service.
Software – Special Attention
• FDA Principles of Software Validation, General Guidance, 2002
3.3 Software Is Different From Hardware
“Because of its complexity, the development process for software should
be even more tightly controlled than for hardware, in order to prevent
problems that cannot be easily detected later in the development
process”.
“……. software engineering needs an even greater level of managerial
scrutiny and control than does hardware engineering”.
Types of Regulated Software
Medical Device Software
• Software that is actually a part
of the medical device itself
• Software that is an accessory
to a medical device
• Software that itself is a medical
device
Non-Device Software that is part of:
• The production system
• The quality system
• Systems that are used to create
and maintain records required
by FDA regulations
IEC 62304 background
IEC 62304:2015 Medical Device Software Lifecycle
• Specifically created for medical device software
• IEC 62304 defines the software development and verification activities which MD
manufacturers must comply with
• SDLC includes risk management, configuration management and problem
resolution processes guided by IEC 62304 at each phase
• Under IEC 62304, responsibility of the manufacturer also goes beyond the
release of the software product, with particular emphasis on product
maintenance
• The manufacturer has to monitor and document the feedbacks both within
organizations and users.
• This feedback must be analyzed to determine whether a problem exists
Status of IEC 62304
• Approved by both IEC and ISO as an international standard (joint development
effort)
• Adopted by CENELEC as EN and harmonized 11/08 under the MDD, AIMDD
• Adopted by ANSI as US national standard (replacing ANSI/AAMI)
• Recognized by FDA for use in premarket submissions
• China – CFDA adopted 62304
• Translations exist in French, German, Spanish, Chinese and Japanese
• Adopted as a Japan Industry Standard
CENELEC is the European Committee for Electrotechnical Standardization and is
responsible for standardization in the electrotechnical engineering field.
AIMDD – Active Implantable Médical Devices Directive
62304 philosophy
• Safe medical device software requires risk management, quality management and
good software engineering
• Good software engineering requires critical thinking – can’t be done by checklist
• Manufacturers know more about their products than regulators
• The variety of medical devices requires a variety of approaches – one size does not
fit all
• Resources should be used on what is important
• A standard should have minimum requirements, not best practices
62304 Software Safety Classification
Software System Overall
• Class A: No injury or damage to health is possible
• Class B: Non-serious injury is possible
• Class C: Death or serious injury is possible
Classification shall be documented
Software System may have lower worst case risk than device overall, but
cannot be higher
• Both direct and indirect harm are included
• Class C is the default assumption
IEC 62304 - What is it?
• A framework – processes, activities and tasks
 process is the top level, a process has activities and an activity has tasks.
Specific requirements in IEC 62304 are generally at the task level.
• Identifies requirements for what needs to be done and what needs to be
documented
• Specifies a software safety classification system
 additional requirements apply as safety classification increases
IEC 62304 - What is not in it?
• Does not prescribe how to accomplish requirements –
 Not a “how to” with defined methods or practices
• Does not require a specific software life cycle
• Does not specify documents
 What to document, not where it must go.
• All of these decisions are left to the manufacturer
Software Development Procedure
• Typical SDLC phases are:
Requirements
Design
Implementation
Integration and Test
Design Transfer (to production)
Maintenance
QMS Documents outputs during SDLC
Requiremen Design
ts
Risk Management Report
Design And Development Plan
User Requirements
Specification
System Requirements
Specification
Software Requirements
Specification
Software Specification
Supporting Material
Design Requirements
Specification
Unit Test Plan
Unit Test Protocol
Unit Test Report
Code Review Checklist
System Requirements
Traceability Matrix
System Integration Test Plan
System Integration Test
Protocol
System Integration Test
Report
Design Review for Medical
Device Software
Implementatio Integration & Design
n
Test
transfer (to
production)
Maintenance
Tips for successful compliance on project
• Software for medical devices costs 0 USD if there are no compliance
accompanying documentation
• Involve your team to collaborate on compliance works – both on clients’
and your side as you need their SME support
• Build your professional compliance network – it will help to manage
practical cases on regulations
• FDA and other regulatory bodies are constantly changing – be always
updated with the law.
• Usually compliance consultant from contractor side (like DA) takes a role
of Quality Assurance. This is because most of the compliance
documents require authorized signature of trained person only.
• All responsible stakeholders who should sign the documents off have to
show and prove regulatory body their training records.
• The MD manufacturer can outsource any kind of work to third party but not
liability and compliance to regulations
Oleksandr Prokopchuk
Business Analyst
Oleksandr Prokopchuk@dataart.com
https://www.facebook.com/aleksander.prokopchuk
Oleksandr.Prokopchuk@dataart.com
Q&A