2. Overview of regulatory and compliance in software development for medical devices
Oleksandr Prokopchuk,
Business analyst

4. 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

5. 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?

6. MD regulatory landscape “looks like”

7. 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

8. 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, (k) devices compared with 47 PMA devices (Source:

9. CE Mark Indicates that product satisfies European safety requirements
Managed by “notified bodies”, such as:
- TUV (Germany)
- BSI, SGS (United Kingdom)

10. 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.

11. 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."

12. 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.

13. 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”.

14. 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

15. IEC 62304:2015 Medical Device Software Lifecycle
IEC background
IEC 62304:2015 Medical Device Software Lifecycle
Specifically created for medical device software
IEC 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 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

16. 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

17. 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

18. 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

19. 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 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

20. IEC 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

21. Software Development Procedure
Typical SDLC phases are:
Requirements
Design
Implementation
Integration and Test
Design Transfer (to production)
Maintenance

22. QMS Documents outputs during SDLC
Requirements
Design
Implementation
Integration & Test
Design transfer (to production)
Maintenance
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

23. 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

24. Oleksandr Prokopchuk
Business Analyst
Oleksandr

25. Q&A