Johner Institut

Medical Device Regulation

7 Steps to MDR Compliance

Astrid Schulze• Graduate in economics• 20 years entrepreneur in quality

management and approval of medical devices and softwareSince 2017 at the Johner Institute:

• Lead Link Berlin Circle• Senior Consultant QM & Regulatory Affairs

258

165

3062

9141

9888

14520

24500

0 5000 10000 15000 20000 25000 30000

Not known

Multifactorial

Other product related cause

Production failure

Design failure

Cause not known/not detectable

No product related causes

Statistical evaluation of reported and conclusively evaluated risksCause of error

Source: Bundesinstitut für Arzneimittel und Medizinprodukte Status: 4.8.2017

MDR Jungle: ChallengesUncertainty, Excessive Demand

Efforts, Costs, Market Delay

Non-Compliance

Closure of medium-sized companies or their sale to large companies.

7

6

5

4

3

2

1

Update of Intended Use and Performance Claims

Audit and Re-Registration, Market Launch

Implementation of UDI System

Update of QM System incl. PMS

Demonstration of Performance Claims, Update Technical File

(Re)Classification and Method of Conformity Assessment

Project planning

Get familiar with the MDR Define transition period for every product Decide (tentatively), which product should be

marketed in the future Identify and inform partners (Authorized representatives, Importers, Distributors, OEM-/PLM) Install UDI-Team Disignation of the Regulatory Affairs Officer

7

6

5

4

3

2

1 Project planning

Activities

60 177 pages

23 123 articles

12 17 annexes

MDD MDR

8

Clinical Evaluation

Major Challenge!

Classification

Manufacturer Authorized Representative

DistributorImporter

Economic Operator

Other Person

UDI = DI + PISource: http://perspectives.3ds.com/wp-content/uploads/Life-Sciences-UDI-Label-Axendia.png

DI: Device IdentifierPI: Production Identifier

MDR: “The UDI is comprised of the UDI-DI and the UDI-PI. Note: The word "Unique" does not imply serialization of individual production units.”

“Compliance officer”Person responsible for regulatory compliance

Responsibilities

Qualification

ImplementationAt least one per manufacturerSMEs: can be externalAuthorized representative has access to

Conformity of devices checked according to QMSTechnical documentation and declaration up-to-datePMS requirements are metReporting obligations are fulfilled

University degree (law, medicine, engineering, pharmacy)OR 4+ years of experience in regulatory affairs or QMArticle 15

Get familiar with the MDR Define transition period for every product Decide (tentatively), which product should be

marketed in the future Identify and inform partners (Authorized representatives, Importers, Distributors, OEM-/PLM) Install UDI-Team Disignation of the Regulatory Affairs Officer

7

6

5

4

3

2

1 Project planning

Template Project plan Tabular Product overview Calculator for transition periods Effort calculator

Activities

Tools

Update Medical purpose and Intended Use Specify performance claims quantitatively

research alternatives (alternative methods, technologies, products)

Collect UDI-DI data If necessary, Update risk policy

7

6

5

4

3

2

1

Update of Intended Use and Performance Claims

Template Intended Use Checklist Intended Use Form sheets UDI-Data

Activities Tools

Decide (finally) which products will be further marketed

Submit application (audit, approvals) to notified bodies

Clarify the need for an Expert Group Revise project plan

7

6

5

4

3

2

1

(Re)Classification and Method of Conformity Assessment

Activities

Classification

Annex IITechnical Documentation

Annex X Conformity Ass. by Type

Examination

Annex IXConformity Ass. based on QM System and Ass. of TD

Annex XI (Part A): Conf. Ass. by Product

Conformity Verification: Production QS

Annex IV and VDoC to MDR

CE marking without NB

Annex IV and VDoC to MDR

CE marking with NB

I IIb, III I*, IIa, IIb, IIII*, IIa

IIa

Specific Assessment

Procedure including

expert panels

(scrutiny)

Annex XI (Part B): Conf. Ass. by Product

Conformity Verification: Product Verification (done by NB)

III*, IIb*

IIb, IIIIIb, IIII*, IIa

6.3. Rule 11 Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: − death or an irreversible deterioration of a person's state of health, in

which case it is in class III; or − a serious deterioration of a person's state of health or a surgical

intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software are classified as class I.

7

6

5

4

3

2

1

Demonstration of Performance Claims, Update Technical File

Research new requirements Perform or update usability if necessary Collect PMCF data, update clinical evaluation, perform

clinical assessment if necessary, create PMS and PMCF plan

Update labeling (including UDI) Revise instructions for use Revise risk management file

Activities

MDDEssential Requirements

(Annex I)

MDRGeneral Safety &

Performance Requirements (Annex I)

MDRTechnical Documentation

(Annex II)

Input sanitization

Detection, recovery, audit log

Update, security patch concept

Authentification (password, biometric)

IT Security Requirements

Malware protection e.g. anti-virus

Operating system, browsers (versions)

“Other software” (games, firewalls, …)

Sensors and actors

Unreliable network

Screen size, resolution, orientation

Physical and clinical environment

Usage (e.g. 2nd screen)

Network reliability, uptime

Ports, IP-ranges, protocols, encryption

Routing

Network bandwidth, latency

Network characteristics

Clinical Data

Clinical investigation (same product)

Clinical investigation (other product)

Scientific literature, clinical

experience

Post-Market Clinical Follow-up

Clinical Evaluation

“Clinical Study”

MDDEssential Requirements

(Annex I)

MDRGeneral Safety &

Performance Requirements (Annex I)

MDRTechnical Documentation

(Annex II)

— software verification and validation (describing the software design and development process and evidence of the validation of the software, as used in the finished device. This information shall typically include the summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer); Annex II 6.1. (b)

Software

Verification and Validation

Testing: In-house

Testing: actual/simulated environ.

Different hardware and OS

Design, development process

Close to IEC 62304 requirements

!SW Safety Class A?

7

6

5

4

3

2

1

Demonstration of Performance Claims, Update Technical File

Research new requirements Perform or update usability if necessary Collect PMCF data, update clinical evaluation, perform

clinical assessment if necessary, create PMS and PMCF plan

Update labeling (including UDI) Revise instructions for use Revise risk management file

Activities Tools

„New Requirements“ Checklist MDD-MDR-Delta-Document Templates for all files Proposal for file structure

7

4

3

2

1

5 Implementation of UDI System

6

UDI = DI + PISource: http://perspectives.3ds.com/wp-content/uploads/Life-Sciences-UDI-Label-Axendia.png

DI: Device IdentifierPI: Production Identifier

MDR: “The UDI is comprised of the UDI-DI and the UDI-PI. Note: The word "Unique" does not imply serialization of individual production units.”

UDI = DI + PI

DI: Device IdentifierPI: Production Identifier

Must be unique for these attributes Brand or trade name Device version or model Labelled as single use Packages sterile Need for sterilization before use Quantity of devices provided in a package Critical warning or contraindications

Must be unique for these attributes Lot or serial number Software identification Expiration date Manufacturing date in case it

is the only attribute

UDI for standalone Software

DI: Device Identifier PI: Production IdentifierMust be changed if change of Intended use Functionality including algorithms Architecture including DB scheme Technology including OS User interface Interoperability Safety Performance or efficiency

Must be changed if Bug –fix only Security patch only Minor UI change (not safety related)

No PI for individual downloads

One DI for CD and download version

V 2.7.11

Update QM system to ISO 13485: 2016 compliance

Perform a test audit

7

5

6

4

3

2

1

Update of QM System incl. PMS List of new and changed procedures Templates for procedures and form sheets Audit-Checklist

Activities Tools

ISO 13485:2016

ISO 13485:2012

To be addressed

Identification of requirements

Management responsibility

Resource management, suppl.

Risk management

Conformity assessment

Development, production

PMS, vigilance, communication

CAPA

Monitoring of output

Clinical evaluation

7

6

5

4

3

2

1

Update of Intended Use and Performance Claims

Audit and Re-Registration, Market Launch

Implementation of UDI System

Update of QM System incl. PMS

Demonstration of Performance Claims, Update Technical File

(Re)Classification and Method of Conformity Assessment

Project planning

www.johner-institut.de/kontakt

christian.johner@johner-institut.de

+49 (7531) 94500 20

Johner Institut GmbH

Here you get help:

www.johner-institute.com/contact

Johner Institut