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
+49 (7531) 94500 20
Johner Institut GmbH
Here you get help:
www.johner-institute.com/contact
Johner Institut
Top Related