IN FORCE undated

40 Draft guidance document on conduct of Medical Device Software under MDR 2017 2025-Oct-21 1945 KB

Document text

Google Form Link for providing comments on the Guidance document on Medical Device Software https://forms.gle/2jp8TmSJLypcwb2T9

Medical Devices Division, Central Drugs Standard Control Organization, Ministry of Health and Family Welfare, Govt. of India Central Drugs Standard Control Organization (Medical Devices Division)

Guidance Document

Title: Guidance Document on Medical Device Software

Doc No. :

Draft for stakeholder comments

Notice:
This guidance document is aimed only for creating public awareness about Regulations of Medical Device Software and is not meant to be used for legal or professional purposes. The readers are advised to refer to the statutory provisions of Drugs and Cosmetics Act and the Medical Devices Rules, 2017 and respective Guidelines/Clarifications issued by CDSCO from time to time for all their professional needs.

INDEX

Abbreviations

1.0 PURPOSE

1 2.0 SCOPE

1 3.0 MODE OF SUBMISSION

1 4.0 GUIDANCE

1 4.1 KEY DEFINITIONS

2 4.2 TYPES OF MEDICAL DEVICE SOFTWARE

4.3 INTENDED USE STATEMENT OF MEDICAL DEVICE SOFTWARE

10
4.4 RISK-BASED CLASSIFICATION

4.5 APPLICABLE STANDARDS

17 4.6 REQUIREMENTS OF QUALITY MANAGEMENT SYSTEM (QMS) FOR
MEDICAL DEVICE SOFTWARE

19 4.7 REGULATORY PATHWAY FOR MARKETING OF MEDICAL DEVICE
SOFTWARE

20 4.8 LICENSING AUTHORITIES FOR MEDICAL DEVICE SOFTWARE

22 4.9 DOCUMENTS REQUIRED FOR GRANT OF TEST LICENCE
FOR THE PURPOSE OF CLINICAL INVESTIGATIONS OR TEST
OR EVALUATION OR DEMONSTRATION OR TRAINING OF MEDICAL
DEVICE SOFTWARE, NOT FOR COMMERCIALIZATION

24 4.10 CLINICAL INVESTIGATION OF INVESTIGATIONAL MEDICAL DEVICE
SOFTWARE AND CLINICAL PERFORMANCE EVALUATION OF
NEW IN VITRO DIAGNOSTICS MEDICAL DEVICE SOFTWARE

25 4.11 PERMISSION TO MANUFACTURE/IMPORT INVESTIGATIONAL
MEDICAL DEVICE/NEW IVD PRIOR TO COMMERCIALIZATION

25 4.12 DOCUMENTS REQUIRED FOR GRANT OF MANUFACTURING/IMPORT
LICENCE FOR SALE OR FOR DISTRIBUTION OF MEDICAL DEVICE
SOFTWARE

27 4.13 POST MARKETING REGULATORY REQUIREMENTS

Annexure A: Document checklists

ABBREVIATIONS

Adverse event ACP

Algorithm Change Protocol AI

Artificial Intelligence API

Application Programming Interface CDSCO

Central Drugs Standard Control Organization CLA

Central Licensing Authority FSC

Free Sale Certificate FSCA

Field Safety Corrective Action IMS

Image Management System IVD

In vitro Diagnostic(s) LA

Licensing Authority LIS

Laboratory Information System MSC

Market Standing Certificate MDR

Medical Devices Rules NCC

Non Conviction Certificate PMS

Post Marketing Surveillance PSUR

Periodic Safety Update Report SaMD

Software as a Medical Device SiMD

Software in a Medical Device SUSAR

Suspected Unexpected Serious Adverse Events SLA

State Licensing Authority QMS

Quality Management System

Page 1 of 44

1.0 PURPOSE:
1 To provide guidance to Indian manufacturers and importers for the submission of 2 application to the Licensing Authority (LA) for obtaining license/permission for 3 manufacturing or import of Medical Device Software (including In vitro Diagnostic 4 (IVD) Medical Device Software) under the Medical Devices Rules (MDR), 2017. 5 2.0 SCOPE:
6 This guidance document applies to Software products which attract the definition 7 of a “Medical Device” as stipulated in the MDR-2017.
8 This guidance document pertains to the Software categorized as follows: 9

Software in a medical device (SiMD). 10
Software as a medical device (SaMD). 11 This guideline reflects current practices based on MDR-2017 and should not be 12 misconstrued as a new regulatory control on Medical Device Software (including 13 In vitro Diagnostic (IVD) Medical Device Software). 14 NOTE:
15 For the purposes of this document, SaMD and SiMD (including IVD medical 16 device software) shall be referred to as “Medical Device Software” 17 hereinafter, unless otherwise specified.
18

19 3.0 MODE OF SUBMISSION
20  Applications for grant of Test licence for Medical Device Software shall be 21 submitted in the National Single Window System (NSWS) portal, i.e., 22 www.nsws.gov.in. 23  Applications for grant of registration/permission/license (other than Test 24 license) for Medical Device Software shall be submitted in the Online system 25 for Medical Devices (MD online portal), i.e., www.cdscomdonline.gov.in.
26

Page 2 of 44

4.0 GUIDANCE 28 Medical Device Software are regulated under the provisions of the Drugs & 29 Cosmetics Act, 1940 and the MDR-2017, made thereunder. Words and 30 expressions used in this guidance document shall have the meaning respectively 31 assigned to them in the Drugs & Cosmetics Act, 1940 and the MDR-2017 made 32 thereunder.
33 4.1 KEY DEFINITIONS 34 4.1.1 “Active medical device” - means a medical device, the operation of 35 which depends on a source of electrical energy or any other source of energy 36 other than the energy generated by human or animal body or gravity. 37 4.1.2 "Clinical evidence" means, in relation to,— 38 (i) an in vitro diagnostic medical device, is all the information derived from 39 specimen collected from human that supports the scientific validity and 40 performance for its intended use; 41 (ii) a medical device, the clinical data and the clinical evaluation report that 42 supports the scientific validity and performance for its intended use. 43 4.1.3 "Clinical investigation" means the systematic study of an 44 investigational medical device in or on human participants to assess its safety, 45 performance or effectiveness.
46 4.1.4 "Clinical performance evaluation" means the systematic performance 47 study of a new in vitro diagnostic medical device on a specimen collected from 48 human participants to assess its performance.
49 4.1.5 "Intended use" means the use for which the medical device is intended 50 according to the data supplied by the manufacturer on the labelling or in the 51 document containing instructions for use [or electronic instructions for use] of 52 such device or in promotional material relating to such device, which is as per 53 approval obtained from the Central Licensing Authority.
54

Page 3 of 44

4.1.6 "Investigational medical device" in relation to a medical device, other 56 than in vitro diagnostic medical device, means a medical device which does 57 not have its predicate device or which is licensed under the MDR-2017 however 58 it claims for new intended use or new population or material or major design 59 change and is being assessed for safety or performance or effectiveness in a 60 clinical investigation.
61 4.1.7 “Medical Device” - All devices including an instrument, apparatus, 62 appliance, implant, material or other article, whether used alone or in 63 combination, including a software or an accessory, intended by its 64 manufacturer to be used specially for human beings or animals which does 65 not achieve the primary intended action in or on human body or animals by 66 any pharmacological or immunological or metabolic means, but which may 67 assist in its intended function by such means for one or more of the specific 68 purposes of ― 69 (i) diagnosis, prevention, monitoring, treatment or alleviation of any disease 70 or disorder; 71 (ii) diagnosis, monitoring, treatment, alleviation or assistance for, any injury 72 or disability; 73 (iii) investigation, replacement or modification or support of the anatomy or of 74 a physiological process; 75 (iv) supporting or sustaining life; 76 (v) disinfection of medical devices; and 77 (vi) control of conception. 78

79 4.1.8 “Medical device grouping” means a set of devices having same or 80 similar intended uses or commonality of technology allowing them to be 81 classified in a group not reflecting specific characteristics. 82 4.1.9 “Medical purposes” include, but are not be limited to, diagnosis, 83 prevention, monitoring, mitigation, prediction, treatment, etc., of any disease 84 or pathological condition or state. 85 4.1.10 "New in vitro diagnostic medical device" means any medical device 86 used for in vitro diagnosis that has not been approved for manufacture for sale 87

Page 4 of 44

or for import by the Central Licensing Authority and is being tested to establish 88 its performance for relevant analyte(s) or other parameter related thereto 89 including details of technology and procedure required.
90 4.1.11 "Predicate device" means a device, first time and first of its kind, 91 approved by the Central Licensing Authority for marketing in the country and 92 has the similar intended use, material of construction, and design 93 characteristics as the device which is proposed for licence in India.
94

Page 5 of 44

4.2 TYPES OF MEDICAL DEVICE SOFTWARE
96  Generally, Medical Device Software consists of two types:
97 (1) Software in a medical device (SiMD) 98 (2) Software as a medical device (SaMD). 99  Not all software used within healthcare is qualified as a medical device. 100  Software can be considered to be active devices because they rely on a 101 source of energy other than energy generated by the human/animal body 102 or gravity. 103 4.2.1 Software in a Medical Device (SiMD) 104  SiMD refer to software that are considered as a “part of” the medical device 105 hardware and that drive or influence the use of that medical device. These 106 may also be referred to as “embedded software”, “firmware”, or “micro- 107 code”. 108 NOTE:
109 SiMD drive or influence the use of a medical device, indicates that it can:
110 (i) operate, modify the state of, or control the device either through an 111 interface or via the operator of the device, or 112 (ii) supply output related to the (hardware) functioning of that device. 113  SiMD do not have or perform a medical purpose on their own, nor are they 114 intended to create new information on their own for any medical purposes 115 as defined in Section 4.1.9. 116  Embedded software is specialized programming in a microchip or on 117 firmware embedded in a medical device, either as part of a microchip or as 118 part of another application that influences the microchip – to control the 119 functioning of the device. It includes applications, firmware, middleware, 120 and operating systems that execute on a single microprocessor or cluster 121 of microprocessors “embedded” within additional logic. 122 NOTE:
123 • Firmware is a type of software that provides control for a device’s 124 specific hardware. It provides the needed instructions and guidance for 125 the device to communicate with other devices or perform a set of basic 126

Page 6 of 44

tasks and functions as intended. 127 • Middleware is a type of software that lies between an operating system 128 and the applications running on it. 129  SiMD also includes software required by a hardware medical device to 130 perform the hardware’s medical device intended use, even if/when sold 131 separately from the hardware medical device. 132  Software that controls a medical device -- some software, including mobile 133 apps, can control or adjust a medical device through a connection, either 134 physical or utilising wireless technology such as Bluetooth or Wi--Fi 135 features. 136 Illustration (Examples of SiMD): 137 Example (1): The embedded software/firmware in a cardiac pacemaker is 138 regulated as a component of that pacemaker, because it is supplied as part 139 of the device and is necessary for the device to function. 140 Example (2): An embedded software that controls or drives an insulin pump 141 to deliver a calculated dose of insulin. 142 Example (3): Software that is built (pre-installed) into an IVD 143 analyser/instrument (e.g., operating software in a clinical analyser, point of 144 care analyser or personal use IVD such as a glucose meter). In these 145 cases, the software is a part of a device and is not considered to be a 146 separate or distinct device.
147 Example (4): Software that is supplied separately (which is installed on a 148 computer interface) to an IVD analyzer/instrument but intended to operate 149 or influence the IVD. In these cases, the software is a distinct IVD that is 150 separate from the IVD analyser/instrument. 151 NOTE:
152 The above-mentioned examples are only suggestive of some of the different 153 types Medical Device Software, and are not exhaustive in nature. 154

155

Page 7 of 44

4.2.2 Software as a Medical Device (SaMD) 156  SaMD may also be referred to as “standalone software” or “not 157 embedded/without being a part of” a hardware medical device. 158  SaMD are those software that are, either alone or in combination, intended 159 to be used to perform one or more medical purposes without being part of 160 a hardware medical device, wherein, 161 “without being part of” means software does not necessarily require a 162 hardware medical device to achieve its intended medical purpose. 163  SaMD perform a medical purpose on their own and they intended to create 164 new information on their own for any medical purposes as defined in 165 Section 4.1.9. 166  SaMD is capable of running on general purpose (non-medical purpose) 167 computing platforms, wherein 168 “Computing platforms” include hardware and software resources (e.g. 169 operating system, processing hardware, storage, software libraries, 170 displays, input devices, programming languages, etc.), and,
171 “Operating systems” refer to any server, workstation, mobile platform, or 172 any other general purpose hardware platform that may be required by 173 SaMD to run on. 174  SaMD may be interfaced with other medical devices (including hardware 175 medical devices and/or other SaMD software) as well as general purpose 176 software. 177  Mobile apps, AI/ML-based software and Cloud/Network-based software 178 that meet the definition stated in Section 4.1.7 above and do not drive or 179 influence the use of another hardware medical device shall be 180 considered as SaMD. 181  Commercial off-the-Shelf (COTS) software that meet the definition as 182 stated in Section 4.1.7 shall be considered as SaMD. 183  SaMD is increasingly being deployed on general-purpose (non-medical 184 purpose) hardware and delivered, in diverse care settings, on a multitude 185 of technology platforms (e.g., personal computers, smart phones, and in 186 the cloud) that are easily accessible. It is also being increasingly 187

Page 8 of 44

interconnected to other systems and datasets (e.g., via networks and over 188 the Internet).
189 Illustrations (Examples of SaMD): 190 Example (1): A software intended for image analysis of body fluid 191 preparations or digital slides to perform cell count and morphology reviews. 192 Example (2): A Computer Aided Detection (CAD)-based software intended 193 to provide information that may suggest or exclude medical conditions by 194 analyzing X-ray images or ECGs. 195 Example (3): An AI/ML-based tool intended for triage, and/or screening of 196 cancer lesions.
197 NOTE:
198  The above-mentioned examples are only suggestive of some of the 199 different types Medical Device Software, and are not exhaustive in 200 nature.
201 4.2.3 Software that are NOT covered under the MDR-2017 202  Software that do not attract the definition of a Medical Device (as stated in 203 Section 4.1.7 above). 204 Illustrations (Examples of Software that are not SiMD/SaMD): 205  Software that rely on data from a medical device, but do not have a 206 medical purpose, e.g., software that encrypt data for transmission from a 207 medical device. 208  Software that monitor performance or proper functioning of a medical 209 device for the purpose of servicing the device. 210  Software that alter the representation of data for embellishment/cosmetic 211 or compatibility purposes. 212  Software that perform actions such as transfer, storage, archive data, 213 convert, format, communication, simple search, lossless compression. 214  Hospital/Clinical Information systems that support the process of patient 215

Page 9 of 44

data management (intended only for patient admission, for scheduling 216 patient appointments/visits, for insurance and billing/invoicing purposes, 217 enabling clinical communication such as voice calling, video calling, to 218 store and transfer patient information (patient identification, vital intensive 219 care parameters and other documented clinical observations) generated 220 in association with the patient’s treatment). 221  Communication systems intended for general purposes, and is used for 222 transferring both medical and non-medical information (e.g. email 223 systems, mobile telecommunication systems, video communication 224 systems, paging, etc.) to transfer electronic information. Different types 225 of messages are sent such as prescription, referrals, images, patient 226 records, etc. 227  Laboratory Information Systems (LIS) are not qualified as medical 228 devices, wherein the main intended use is the management and 229 validation of incoming information obtained from IVD analyzers 230 connected to the system, such as calibration, quality control, product 231 expiry and feedback (e.g. retesting of samples needed) through 232 interconnections with various analytical instruments (technical and 233 clinical validation). The post-analytical process allows communication of 234 laboratory results, statistics and optional reporting to external databases. 235  Image Management System (IMS): a software-based system primarily 236 intended to be networked with digital pathology systems, in order to 237 access, display, annotate, manage, store, archive and share collections 238 of digitised patient images. 239 NOTE:
240 The above-mentioned examples are only suggestive of some of the different 241 types of software that may not be classified as Medical Device Software, and 242 are not exhaustive in nature.

243

Page 10 of 44

4.3 INTENDED USE STATEMENT OF MEDICAL DEVICE SOFTWARE 244  The definition of “Intended use” means the use for which the medical 245 device is intended according to the data supplied by the manufacturer on 246 the labelling or in the document containing instructions for use of such 247 device or in promotional material relating to such device, which is as per 248 approval obtained from the CLA (Section 4.1). 249  Key elements that may be considered while framing the Intended 250 Use/Intended Purpose statement for the Medical Device Software: 251 a) Medical Purposes (e.g., diagnosis, prevention, monitoring, mitigation 252 prediction, treatment, etc.) 253 b) Intended Disease or Condition (e.g., critical, serious, non-serious, etc.) 254 NOTE:
255 The specific disease or condition intended to be targeted by the Medical 256 Device Software, if any, should ideally be mentioned in the intended use 257 statement. The state of condition/disease (e.g., chronic or acute) should 258 also be considered.
259 c) Intended Patient Populations (e.g., general population, specific subgroup 260 like pediatric, geriatric, specific age group, ethnicity, etc.) 261 d) Intended Users (e.g., non-clinical user/user without a medical qualification, 262 health care professionals that include nurses, radiologists, dentists, primary 263 care physicians, specialist care physicians, etc.) 264 e) Intended Use Environment (e.g., home use, primary care/virtual primary 265 care, hospital, specialty clinics, etc.) 266 f) Contraindications (the specific medical conditions/comorbidities wherein 267 the Medical Device Software should not be used or may provide erroneous 268 results) 269 g) Medical device software function, including:
270 i. Medical device software inputs (e.g., from human user, medical 271 device, non-medical device, or consumer product) 272 ii. Medical device software outputs (e.g., this may include clinical 273

Page 11 of 44

interpretation or intervention (diagnosis, mitigation, treatment, 274 prediction, probability, prognosis, prescription, recommended 275 treatment/therapy, radiation treatment plans, etc.), workflow 276 recommendations (recommended surgical tools, recommended 277 additional tests, recommended imaging modality/parameters, etc.), 278 or/and data for use in medical purpose (anatomy measurements, 279 volume, or segmentation, image reconstruction/de-noising, processed 280 signals such as ECG, etc.)) 281 iii. Explanation of how the medical device software inputs and 282 outputs fit into the clinical or healthcare workflow (e.g., output 283 targeted to humans or for other medical devices, whether it informs 284 clinical management, or drives it, etc.) 285 NOTE:
286 • It is pertinent to note that not all elements will be applicable to all 287 Medical Device Software. 288 • For certain Medical Device Software, information such as 289 contraindications, etc. may be included elsewhere and not in the 290 intended use statement.
291 • The intended use statement should be clinically meaningful and 292 measurable.
293

294 h) In addition to the above, the following key elements should be 295 considered in the intended use statement of In-vitro diagnostic (IVD) 296 medical device software: 297 i. The analyte(s)/parameter(s) being analyzed (e.g., concentration of 298 anti-HIV antibodies, etc.) 299 ii. The type of sample/specimen to be use for analysis (e.g., blood 300 plasma, urine, etc.) 301 iii. Intended diagnostic level (e.g., screening, diagnosis aid, staging of 302 disease, prognosis, etc.) 303 iv. Limitations to the intended use, i.e., the specific 304 conditions/comorbidities/medications/analyte variant for which 305 the software may yield erroneous result, if any, (e.g., changes in 306

Page 12 of 44

image quality may limit the efficiency by which a software analyzes 307 stained slides; specific subtypes/variants of pathogens for which 308 sensitivity and consequently the software performance may be affected) 309 v. Whether the IVD software is intended to yield quantitative, semi- 310 quantitative or qualitative results. 311

312 4.4 RISK-BASED CLASSIFICATION 313  As per Rule 4 in Chapter II of the MDR-2017, all medical devices (including 314 Medical Device Software) are classified as shown in Table 1.
315 Table 1. Risk classification of medical devices as per the MDR-2017. 316 Degree of risk Classification Low risk Class A Low moderate risk Class B Moderate high risk Class C High risk Class D  The risk class of the Medical Device Software is fundamentally based on 317 the intended use of the software and the applicable parameters specified 318 in First Schedule of MDR-2017. 319  Medical Device Software, which drives a device of influences the use of a 320 device, falls automatically in the same risk class. 321  Medical Device Software, which is independent of any other medical 322 device, is classified in its own right using the parameters specified in the 323 First Schedule of MDR-2017. 324

325

Page 13 of 44

4.4.1 Factors to be considered for risk classification of SaMD
326  All SaMD shall be classified using the classification parameters and 327 provisions as specified in the First Schedule of the MDR-2017. 328  The intended use of the SaMD as provided by the manufacturer shall be 329 fundamental to the risk classification of SaMD. 330  Additionally, subject to the parameters laid out in the First Schedule of 331 MDR-2017 and as specified by the intended use statement, the following 332 factors may be considered in determining the risk class of a SaMD:
333 Table 2. Risk classification of SaMD. 334 Note: SaMD intended to be used by non-clinical users in a "serious situation or condition" as described 335 here, without the support from specialized professionals, may be considered as SaMD used in a "critical 336 situation or condition". It may, hence, influence the risk classification of the SaMD. 337 a) Significance of information provided by SaMD for health care 338 decision making, viz. Treatment or diagnosis, Drive clinical 339 management or/and Inform clinical management.
340 i. Treatment or diagnosis: This infers that the information provided 341 by the SaMD will be used to take an immediate or near term action to:
342  Treat/prevent or mitigate by connecting to other medical devices, 343 medicinal products, general purpose actuators or other means of 344 providing therapy to a human/animal body, or/and 345  Diagnose/screen/detect a disease or condition (i.e., using sensors, 346 data, or other information from other hardware or software devices, 347 pertaining to a disease or condition). 348 ii. Drive clinical management: This infers that the information 349 provided by the SaMD shall be used to aid in treatment, aid in 350 diagnoses, to triage or identify early signs of a disease or condition 351 or/and will be used to guide next diagnostics or next treatment 352 State of healthcare situation or condition Significance of information provided by SaMD to health care decision Treatment or diagnosis Drive clinical management Inform clinical management Critical D C B Serious
C B A Non-serious B A A

Page 14 of 44

interventions.
353  To aid in treatment by providing enhanced support to safe and 354 effective use of medicinal products or a medical device. 355  To aid in diagnosis by analyzing relevant information to help predict 356 risk of a disease or condition or as an aid to making a definitive 357 diagnosis. 358  To triage or identify early signs of a disease or conditions. 359 iii. Inform clinical management: This infers that the information 360 provided by the SaMD will not trigger an immediate or near term action. 361 However, the SaMD shall:
362  Inform of options for treating, diagnosing, preventing, or mitigating a 363 disease or condition, and/or 364  Provide clinical information by aggregating relevant information 365 (e.g., disease, condition, drugs, medical devices, population, etc.) 366 b) The health care situation or condition for which the SaMD is 367 intended to be used, viz. critical, serious or non-serious 368 situation/condition. 369 i. Critical situation/condition: These refer to situations or conditions 370 where accurate and/or timely diagnosis or treatment action is vital to 371 avoid death, long-term disability or other serious deterioration of health 372 of an individual patient or to mitigating impact to public health.
373 SaMD is considered to be used for a critical situation/condition when:
374  The type of disease/condition is life threatening (including incurable 375 states), requires major therapeutic interventions, and/or time 376 critical (i.e. progression of the disease/condition is such that it may 377 affect the user’s ability to reflect on the output information).
378  Intended target population is fragile with respect to the disease or 379 condition (e.g., vulnerable population, etc.) 380  Intended for use by specialized trained users. 381 ii. Serious situation/condition: This refers to those 382

Page 15 of 44

situations/conditions where accurate diagnosis or treatment is of vital 383 importance to avoid unnecessary interventions (e.g., biopsy) or timely 384 interventions are important to mitigate long term irreversible 385 consequences on an individual patient’s health condition or public 386 health. SaMD is considered to be used in a serious situation or 387 condition when:
388  The type of disease/condition is moderate in progression (often 389 curable), does not require major therapeutic interventions, and/or 390 the intervention is not expected to be time critical, in order to avoid 391 death, long term disability or other serious deterioration of health, 392 whereby providing the user an ability to detect erroneous 393 recommendations.
394  Intended target population is NOT fragile with respect to the disease 395 or condition. 396  Intended for use by either specialized trained users or non-clinical, 397 untrained users.
398 NOTE:
399 SaMD intended to be used by non-clinical users in a "serious situation 400 or condition" as described here, without the support from specialized 401 professionals, may be considered as SaMD used in a "critical situation 402 or condition". 403 iii. Non-Serious situation/condition: This refers to a 404 situation/condition where an accurate diagnosis and treatment is 405 important but not critical for interventions to mitigate long term 406 irreversible consequences on an individual patient's health condition or 407 public health. SaMD is considered to be used in a non-serious situation 408 or condition when: 409  The type of disease/condition is slow with predictable progression 410 disease states (e.g., minor chronic illness or states, etc.), may not 411 be curable but can be managed effectively, requires only minor 412

Page 16 of 44

interventions, and interventions are mostly non-invasive in nature, 413 providing the user the ability to detect erroneous recommendations.
414  Intended target population is individuals who may not always be 415 patients. 416  Intended for use by either specialized trained users or non-clinical, 417 untrained users.
418  The risk class shall be confirmed by CDSCO upon review of the medical 419 device details such as intended use, design characteristics, etc. 420  In exercise of the powers conferred under sub-rule (3) of Rule 4 of MDR- 421 2017, CDSCO has classified a list of Medical Device Software and In-vitro 422 Diagnostic Medical Device Software, which are published on the CDSCO 423 website. This list is dynamic and is subject to revision from time to time 424 under the provisions of MDR-2017. 425 NOTE: 426 If several rules apply to the same device, based on the performance 427 specified for the device by the manufacturer, the strictest rules resulting in 428 the higher classification shall apply (First Schedule, MDR-2017). 429

Page 17 of 44

4.5 APPLICABLE STANDARDS 430  The medical device software shall conform to the standards laid down by 431 the Bureau of Indian Standards or as may be notified by the Ministry of 432 Health and Family Welfare in the Central Government, from time to time. 433  If no such standard(s) are available, the device(s) shall conform to the 434 International Organisation for Standardisation (ISO) or the International 435 Electro Technical Commission (IEC), or by any other pharmacopeial 436 standards. 437  In case if the standards are not specified under above points, the device 438 shall conform to the validated manufacturer’s standards. 439  The following standards may be applicable to all medical device software: 440  IS/ISO 13485 standard (Medical Devices—Quality Management 441 Systems— Requirements for Regulatory Purposes) 442  IS/ISO 14971 Medical devices — Application of risk management to 443 medical devices. 444  IEC/TR 80002-1 Medical device software – Part 1: Guidance on the 445 application of ISO 14971 to medical device software. 446  IS/ISO/TR 80002-2 Medical Device Software Part 2 Validation of 447 Software for Medical Device Quality Systems. 448  IS/IEC/TR 80002-3 Medical device software Part 3: Process reference 449 model of medical device software life cycle processes. 450  IS 16124 Systems and Software Engineering - Software Life Cycle 451 Processes 452  IS/ISO/IEC 62304 Medical device software – Software life cycle 453 processes. 454  IS/IEC 82304-1 Health software: Part 1 general requirements for product 455 safety. 456  IEC 81001-5-1 adds requirements about cybersecurity. 457  IEC 62366-1 adds requirements about man-machine interface 458 ergonomics. 459  IS 16458/ISO/IEC 16085 — Systems and Software Engineering — Life 460 Cycle Processes — Risk Management 461

Page 18 of 44

 IS/ISO/IEC 23894 — Information Technology — Artificial Intelligence — 462 Guidance on Risk Management 463  IS/ISO/IEC 42001 — Information technology — Artificial intelligence — 464 Management system 465  IS/ISO/IEEE 11073 Health Informatics - Point-of-Care Medical Device 466 Communication 467  ISO 24291 — Health informatics — Applications of machine learning 468 technologies in imaging and other medical applications 469 NOTE:
470 The above list mentions some of the standards that may be applicable for 471 Medical Device Software. The standard(s) that may be applicable to a 472 particular Medical Device Software is not limited to the list provided above.
473

Page 19 of 44

4.6 REQUIREMENTS FOR QUALITY MANAGEMENT SYSTEM (QMS) FOR 474 MEDICAL DEVICE SOFTWARE 475  The manufacturer of a Medical Device Software need to establish Quality 476 Management System (QMS) in respect of the organizational structure and 477 the entire software lifecycle (design, development, product planning, 478 configurations, deployment, maintenance, etc.). 479  The indigenous manufacturers are required to establish and maintain 480 procedure and records which demonstrate conformance to the requirements 481 of QMS and submit an undertaking stating compliance with the requirements 482 of QMS as specified in the Fifth Schedule of MDR-2017 as part of their 483 application for grant of manufacturing license. 484  In case of import, the overseas manufacturer shall ensure that their 485 manufacturing facility complies with the QMS requirements and need to 486 submit a notarized copy of QMS certificate issued by the National Regulatory 487 Authority or the competent authority in their application for grant of Import 488 license.

489

Page 20 of 44

4.7 REGULATORY PATHWAY FOR MARKETING OF MEDICAL DEVICE 490 SOFTWARE 491

492 Figure 1. Flow chart illustrating the regulatory pathway to be followed for 493 medical device software for marketing in the country. 494

Page 21 of 44

495 Figure 2. Flow chart illustrating the regulatory pathway to be followed for IVD 496 medical device software for marketing in the country.

497

Page 22 of 44

4.8 LICENSING AUTHORITIES FOR MEDICAL DEVICE SOFTWARE 498  The Medical device software are required to be licenced for manufacturing 499 or import for sale and marketing in the country by the LA as per the 500 provisions prescribed under the MDR-2017 (Table 3 and Table 4). 501 Table 3. Licensing Authorities for grant of license/permission for 502 manufacturing/import for marketing of medical devices in the country. 503

504 Licenses/Permissions under MDR-2017
Class A Class B Class C Class D Test license CLA CLA CLA CLA Manufacturing license SLA SLA CLA CLA Import licence CLA CLA CLA CLA Clinical Investigation of Investigational MD /Clinical Performance Evaluation of new IVD CLA CLA CLA CLA Permission for manufacturing of Investigational MD/new IVD CLA CLA CLA CLA Sale and distribution SLA

SLA SLA SLA MSC/NCC
Manufacturing SLA

SLA CLA CLA Import CLA CLA CLA CLA FSC (only in case of manufacturing) SLA SLA CLA CLA Special Code CLA CLA CLA CLA

505 Abbreviations: MD: Medical Device, CLA: Central Licensing Authority, SLA: State Licensing Authority, MSC: 506 Market Standing Certificate, NCC: Non-conviction certificate, FSC: Free Sale Certificate. 507 NOTE 1: Class A (non-sterile and non-measuring) medical devices are exempted from the licensing 508 requirements under MDR-2017, such medical device software shall be registered as per Chapter IIIb of MDR- 509 2017 in the MD online portal.
510 NOTE 2: The time line required for processing various license applications is mentioned in the MDR-2017. 511

512 NOTE: 513  The applicant(s) may ensure whether the medical device software, for 514 which application is to be submitted, is listed in the risk classification lists 515

Page 23 of 44

published by the CLA. If so, the same may be followed as risk 516 classification for the applied devices.
517  In case the medical device software has a similar intended use as the 518 device mentioned in the published risk classification lists, they may follow 519 the same risk classification for the applied medical device software. 520  In case the medical device software is not listed in the published risk 521 classification lists, they may seek clarification from the CLA regarding its 522 risk classification. 523  In case the medical software falls in the category of an investigational 524 medical device (IMD) or new IVD medical device, the applicant(s) need to 525 obtain prior permission of IMD/new IVD from the CLA under the MDR- 526 2017 for conduct of Clinical Investigation/Clinical Performance Evaluation 527 in the country. 528  It may also be ensured that the medical device software that attract the 529 definition of IMD or new IVD do not get approved for marketing in the 530 country without obtaining permission from the CLA for its 531 import/manufacturing under the MDR-2017.

532

Page 24 of 44

4.9 DOCUMENTS REQUIRED FOR GRANT OF TEST LICENCE FOR THE 533 PURPOSE OF CLINICAL INVESTIGATIONS OR TEST OR EVALUATION 534 OR DEMONSTRATION OR TRAINING OF MEDICAL DEVICE SOFTWARE, 535 NOT FOR COMMERCIALIZATION 536  In order to obtain a Test licence (Form MD-13) to manufacture small 537 quantities of medical device software for the purpose of Clinical 538 Investigations or Test or Evaluation or Demonstration or Training, the 539 applicant need to submit an online application in Form MD-12 in NSWS 540 portal along with the requisite documents as per Rule 31 and fee as 541 specified in the Second Schedule of MDR-2017. 542  In order to obtain a Test licence (Form MD-17) to import small quantities 543 of medical device software for the purpose of Clinical Investigations or 544 Test or Evaluation or Demonstration or Training, the applicant needs to 545 submit an online application in Form MD-16 in the NSWS portal along 546 with the requisite documents as per Rule 40 and fee as specified in the 547 Second Schedule of MDR-2017. 548  The requisite document checklists are given in Annexure A. The list of 549 documents required for such applications is also available in the NSWS 550 portal. 551 NOTE:
552 The applicant may mention number of installations/number of copies/ 553 number of downloads of the medical device software as the quantity 554 proposed for obtaining test license. 555

556

Page 25 of 44

4.10 CLINICAL INVESTIGATION OF INVESTIGATIONAL MEDICAL DEVICE 557 SOFTWARE AND CLINICAL PERFORMANCE EVALUATION OF NEW IN 558 VITRO DIAGNOSTICS MEDICAL DEVICE SOFTWARE 559  No person or sponsor shall conduct any Clinical Investigation of an 560 Investigational Medical device (IMD) or Clinical Performance Evaluation of 561 new IVD on human participants or on any specimen derived from human 562 body, respectively, except in accordance with the permission granted by 563 the CLA as specified in MDR-2017. 564  For Medical Device software that fall under the definition of an IMD or new 565 IVD medical device, a permission to conduct Clinical investigation (Form 566 MD-23) or Clinical Performance Evaluation (Form MD-25), respectively, is 567 required to be obtained by the CLA by submitting an application through 568 the MD online portal with requisite documents (Refer Rule 51 and Rule 59) 569 and fee as specified in the Second Schedule of MDR-2017. 570 4.11 PERMISSION TO MANUFACTURE/IMPORT INVESTIGATIONAL 571 MEDICAL DEVICE (IMD)/NEW IVD PRIOR TO COMMERCIALIZATION 572  In case of IMD, a permission in Form MD-27 shall be obtained from CLA 573 for the import/manufacture IMD prior to grant of import/manufacturing 574 license for marketing in the country (Chapter VII, MDR-2017).
575  In case of new IVD, permission in Form MD-29 shall be obtained from CLA 576 for the import/manufacture new IVD prior to grant of import/manufacturing 577 license for marketing in the country (Chapter VII, MDR-2017). 578  The applicant shall submit application in Form MD-26 through the CDSCO 579 MD Online portal along with requisite documents and fee as specified in 580 the Fourth Schedule and Second Schedule, respectively, of MDR-2017 for 581 obtaining permission in Form MD-27 for import/manufacturing of IMD in 582 the country. 583  The applicant shall submit application in Form MD-28 through the CDSCO 584 MD Online portal along with requisite documents and fee as specified in 585 the Fourth Schedule and Second Schedule, respectively, for obtaining 586 permission in Form MD-29 for import/manufacturing of new IVD in the 587 country. 588

Page 26 of 44

 In case the clinical investigation or clinical performance evaluation is 589 conducted on such devices in India, then the clinical data generated is 590 required to be submitted along with the above-mentioned application. 591  The requisite document checklists are given in Annexure A. 592 NOTE:
593 For more details, please refer to Chapter VII and Chapter VIII of MDR- 594 2017. 595

596

Page 27 of 44

4.12 DOCUMENTS REQUIRED FOR GRANT OF MANUFACTURING/IMPORT 597 LICENCE FOR SALE OR FOR DISTRIBUTION OF MEDICAL DEVICE 598 SOFTWARE 599  The requisite document checklists (specific to the type of licence 600 application) for Medical Device and IVD are given in Annexure A. 601  The applicants may refer to Figure 1 and Figure 2 for determining the 602 corresponding Application Form (Legal form) number. 603  In case, any of the documents specified in the checklist is deemed not 604 applicable, then the applicant needs to submit the rationale/justification 605 for the non-applicability of such document/requirement for Medical 606 Device Software. 607  Also, the applicant may refer the Tool Tips for information that needs 608 to be filled in the Legal Form and also the technical documents that 609 need to be uploaded as part of a checklist for review by the LA. The 610 Tool Tips are published on the CDSCO website (www.cdsco.gov.in) 611 4.12.1 Guidance on the legal documentation applicable for medical 612 device software 613  For obtaining a licence to manufacture or import for sale and/or 614 marketing of medical device software in the country, the applicant(s) 615 shall submit an online application in MD online portal with the requisite 616 fee, as specified in the Second Schedule along with respective 617 documents as per the Fourth Schedule of MDR-2017.
618  If any of the points in the Legal form is not applicable, then the 619 applicant may mention “Not applicable” or “NA” (e.g, if shelf life is not 620 applicable, it should be mentioned as “NA” in the Legal Form). 621  The Site/Plant master file may outline the infrastructure and work 622 environment (such as equipment, information, communication 623 networks, tools, and the physical facility, etc.) used to support the 624 development, production, and maintenance of the Medical Device 625 Software. The said details need to be maintained and submitted as 626 part of the Site/Plant Master File. 627  In addition, the organization chart and personnel qualification details 628 of the organization is also required to be submitted. 629

Page 28 of 44

 If any of the contents of the Site or Plant master file (as specified in 630 Appendix I, Part III of Fourth Schedule of MDR-2017) is deemed not 631 applicable, then the applicant(s) needs to submit the 632 rationale/justification for the non-applicability of such requirement for 633 Medical Device Software. 634  The manufacturers shall furnish details on company/firm constitution 635 along with a copy of the establishment/site ownership/tenancy 636 agreement. These documents shall be duly notarized.
637  In case of import, the applicant shall furnish a Power of Attorney (PoA) 638 along with undertaking from the authorized agent as per Part I of Fourth 639 Schedule of MDR, 2017. The PoA must be duly authenticated in India 640 either by a Magistrate of First Class or by Indian Embassy in the country 641 of origin or by an equivalent authority through apostille. 642  The importer(s) are also required to submit a copy of the Wholesale 643 licence/Manufacturing licence/Registration Certificate in Form MD-42 644 among other requirements. 645  The applicants are advised to go through the document checklists 646 available on the CDSCO MD Online portal (also provided in Annexure 647 A) for a complete list of legal documentation requirements. 648 4.12.2 Guidance on the technical documentation applicable for 649 medical device software
650 (A) Executive Summary – Device description, intended use, 651 specifications including variants, etc. 652 Software/Firmware Description 653 Software description, including overview of operationally significant 654 software features, analyses, inputs and outputs is required to be added in 655 the Device Master File (DMF). 656 a) Specify the name of the software 657 b) Specify the version of the software, provide a statement about software 658 version naming (specify all fields and their meanings) 659 c) Provide a description of the software including the identification of the 660 device features that are controlled by the software, the programming 661

Page 29 of 44

language/compiler versions used, hardware platform, operating system (if 662 applicable), use of Off-the-shelf software (if applicable), a description of 663 the software development lifecycle. 664 d) Intended User/operator of the software 665 [Examples: patient (self-use), primary caregiver, primary care physicians, 666 specialist physicians, radiologists, non-clinical user, etc.]
667 e) Intended patient population 668 [Examples: general population, specific vulnerable groups (pediatrics, 669 geriatrics), specific age group, specific ethnicity, etc.] 670 f) Intended user environment, or the setting within which the software is 671 intended to be used 672 [Examples: non-clinical environment (home use, etc.), general health care 673 (dental/general physician’s clinics, primary care centers, etc.), specialty 674 health care (emergency rooms, operation theaters, oncology departments, 675 etc.)] 676 g) Analysis methodology used (if any) 677 [Examples: Rule-based calculations, online test administration, artificial 678 intelligence (AI)/machine learning (ML), neural networks, fixed or adaptive 679 algorithms] 680 h) Role of software and its output within the health care intervention 681 i. Whether the software impacts/influences or replaces any otherwise 682 manual or clinician performed actions? 683 [Examples: automated steps, triages patients, provides a definite 684 diagnosis or suggests likely diagnosis for further confirmation by 685 physician, performs or recommends treatment, identifies a region of 686 interest for further review] 687 ii. Contribution to the clinical decision 688 [Examples: intended as an aid to current practice, intended to replace 689 all or a part of a current practice, etc.] 690 iii. Whether the intended software output is dependent on other steps 691

Page 30 of 44

during the health care intervention 692 [Examples: software that use output/clinical decisions from prior 693 steps such as medical image overlays and reconstruction]
694 i) Software inputs and outputs 695 i. Inputs and their format to the Medical Device Software 696 [Examples: data, images (specify modality), measurements (specify 697 units), sensor/attachments, report, questionnaire] 698 ii. Source of the inputs. 699 [Examples: user, other medical devices, other nonmedical devices or 700 software.] 701 iii. If the software is designed to be interoperable and transmit, 702 exchange, and/or use information through an electronic interface with 703 another medical/nonmedical product, system, or device – specify the 704 methods, standards, and specifications used. 705 iv. Outputs and their formats: include test setup, acceptance criteria, and 706 results 707 [Examples: diagnostic information, treatment information, control 708 signals for device hardware, images (specify modality), 709 measurements (specify units), alarms, alerts, or reports, etc.] 710 v. To whom are the outputs provided (output targets)?
711 [Examples: patients, caregivers, healthcare professionals, 712 technicians, researchers, health records, interoperable systems, 713 medical devices, etc.] 714 vi. Data or information flow of the software 715 [Examples: inputs or outputs transmitted locally, via cloud storage, by 716 disk drive, or wirelessly] 717 vii. Whether the software interacts with any networked devices. 718 viii. Whether cloud or network storage is used. 719 ix. Degree of autonomy of software (i.e., whether its output impacts 720

Page 31 of 44

subsequent clinical action/decision without user intervention 721 (autonomous), or requires a user supervision (supervised autonomy), 722 or only intended as an aid for the user in clinical decision making 723 (non-autonomous).
724 j) Software change management 725 i. Degree of learning, i.e., change autonomy 726 [Examples: self-learning (autonomous updates effectuated and 727 controlled from within the software, externally controlled changes 728 (non-autonomous updates either effectuated by the user or the 729 manufacturer) 730 ii. Domain of learning or change implementation 731 [Examples: international, national, regional, patient-specific, site- 732 specific, etc.] 733 iii. Infrastructure for installation, updates and error corrections 734 [Examples: distribution channels such as app stores, web pages, web 735 application, etc., and installation locations such as mobile phones, 736 hardware medical devices, wearable devices, cloud, personal 737 computers, etc.] 738 (B) Substantial equivalence with predicate medical device software 739  The applicant(s) shall submit a substantial equivalence evidence in 740 tabular format between applied software and predicate software in 741 respect to the intended use, risk class, applicable standards, design 742 characteristics (e.g., the type of algorithm/technology used to code the software 743 (whether self-trainable, passive, machine-learning-based, procedural 744 languages, etc.), platforms for operation, nature and type of output, target user 745 of software output, training models used, if any, etc.), manufacturing and 746 testing process, performance, safety, effectiveness, and other 747 characteristics (as applicable). 748

749

750

Page 32 of 44

(C) Essential Principles of safety and performance 751  The applicant shall refer to the Essential principles checklist for 752 demonstrating conformity to the essential principles of safety and 753 performance of the Medical Device, published on the CDSCO website. 754  While demonstrating the conformance to the essential principles, the 755 manufacturer shall ensure the following for Medical Devices Software: 756 a) The software should be developed, manufactured and maintained in 757 accordance with the state of the art taking into account the principles 758 of development life cycle (e.g., rapid development cycles, frequent 759 changes, the cumulative effect of changes), risk management (e.g., 760 changes to system, environment, and data), including information 761 security (e.g., safely implement updates), verification and validation 762 (e.g., change management process). 763 b) Software that is intended to be used in combination with mobile 764 computing platforms should be designed and developed taking into 765 account the platform itself (e.g. size and contrast ratio of the screen, 766 connectivity, memory, etc.) and the external factors related to their 767 use (varying environment as regards level of light or noise).
768 c) Manufacturers should set out minimum requirements concerning 769 hardware, IT networks characteristics and IT security measures, 770 including protection against unauthorized access, necessary to run 771 the software as intended.
772 (D) Risk management
773 The Medical Device Software are associated with some unique challenges 774 that are generally not evident for other medical devices, which are 775 summarized below:
776 a) Direct benefit and risks for patients are not always present. 777 b) Deployed on a multitude of technology/hardware platforms. 778 c) Interconnected to other systems and datasets. 779 d) Rapid development cycles and frequent changes. 780 e) Often an update made available by the manufacturer is left to the 781

Page 33 of 44

user of the medical device software to install. 782 f) Deployment at scale and at pace, outside control of manufacturer. 783 g) Information security with respect to safety considerations (e.g., 784 Cyber security, preservation of patient confidentiality and privacy, 785 integrity and availability of information). Local legislation and 786 regulations on data protection and privacy should be complied with. 787 h) Computer-human interaction. 788 Considering this, the manufacturers/importers need to consider and 789 comply with the following: 790  Applicable standards such as IS/ISO 14971, IS/ISO 62304, etc. need to 791 be followed and complied to. 792  The risk management plan/protocol should be devised and the Risk 793 Management Report generated by the manufacturer as per the IS/ISO 794 14971 (and other applicable standards) shall be submitted as part of the 795 license application as applicable (see Annexure A for submission 796 requirements). 797  The manufacturer/importer is required to consider and ensure 798 implementation of surveillance/monitoring mechanisms for the risks 799 associated with Medical device software, in relation to injury or damage 800 to the health of people and reduction of effectiveness, wherein “reduction 801 of effectiveness” can result from inadequate, incorrect, or absent data 802 supplied to a human or product at an inappropriate time, rate, or with an 803 inadequate method. 804  The manufacturers/importers are required to consider and ensure 805 implementation of surveillance/monitoring mechanisms for indirect 806 harms associated with Medical Device Software (e.g., introduction of 807 unintended bias in clinical decision-making because of a Medical Device 808 Software output may be considered as an indirect harm to the patient). 809  The process for identification and analysis of these risks (including 810 indirect harms) should be considered iteratively and should be carried 811 out over the total product lifecycle of the device. 812  The risk management process should be integrated across the entire 813 lifecycle of the Medical Device Software. 814  Software change management should be ensured and properly 815

Page 34 of 44

documented as part of the risk management plan by the manufacturer.
816  Details on periodic updation of the Medical Device Software and 817 corrections/changes associated with risks should be added in the risk 818 management plan. 819  In this regard, an Algorithm Change Protocol (ACP) may be devised, 820 wherever applicable based on the nature and risks associated with the 821 Medical Device Software. The ACP shall include an overview of all the 822 procedures to be followed so that any changes/modifications made in 823 the Medical Device Software do not compromise its safety and intended 824 use. The ACP may contain the following information:
825 a) A data management plan that includes a data management protocol, 826 risk assessment plan, new data collection protocols, and quality 827 assurance process. 828 b) A performance evaluation and monitoring plan, describing 829 assessment metrics, a statistical analysis plan, assessment 830 frequency, performance targets, and post market monitoring 831 overview. 832 c) An algorithm retraining plan (if applicable) to described retraining 833 objectives, methods that will be employed to improve algorithm 834 performance, the approach to performance evaluation, and potential 835 impacts to intended purpose. 836 d) A software update plan, describing version tracking, verification and 837 validation methods, update triggers, update procedures, and 838 approaches to transparently communicating updates to end users. 839 e) A rollback plan, describing triggers, backup and recovery procedures, 840 and communication to users. 841  The ACP may be submitted as part of the Risk Management File, if 842 applicable. 843  Risks associated with process validation and benchmarking should be 844 carefully documented and assessed – including the decisions for 845 selecting specific datasets, reference standards, parameters and metrics 846 to justify such validation processes.
847 [For example, in case of AI-based SaMD, careful consideration needs to be 848

Page 35 of 44

given to documenting how and why specific data or datasets are selected to 849 train, externally validate and retrain the model (e.g. post-deployment retraining).] 850 (E) Device Design 851 System and Software Architecture Design/Diagram: 852  Detailed depiction of functional units and software modules may include 853 state diagrams as well as flow charts to present a roadmap of the device 854 design to facilitate a clear understanding of: 855 a) The modules and layers that make up the system and software. 856 b) The relationships among the modules and layers. 857 c) How users or external products, including IT infrastructure and 858 peripherals (e.g. wirelessly connected medical devices) interact with 859 the system and software. 860 d) How users or external products, including IT infrastructure and 861 peripherals (e.g., wirelessly connected medical devices) interact 862 with the system and software. 863 [Example: A module could represent – a finished hardware device within a system 864 of hardware and software products, a hardware component within a finished 865 hardware device, a finished software product within a system of software 866 products, or a software function within a finished software product. A module is 867 not specifically meant to describe code-level software functions.] 868 Software Requirement Specifications: 869  The software requirement specifications (SRS) document the 870 requirements of the software. This typically includes functional 871 performance, interface design, developmental, and other requirements 872 for the software. In effect, this document describes what the Medical 873 Device Software is supposed to do. 874 [Example: Hardware requirements, programming language requirements, 875 interface requirements, performance and functional requirements] 876

Page 36 of 44

Software Design Specifications: 877  The software design specifications (SDS) describe the implementation 878 of the requirements for the Medical Software Device. The SDS 879 describes how the requirements in the SRS are implemented. 880 (F) Software versioning and traceability
881  The applicant(s) shall ensure traceability of the Medical Device Software 882 – this is essential for identification (e.g. software version) for the post- 883 market traceability/ follow-up (track and trace) of the software to the 884 users (e.g. physicians or patients) in the event of a Field Safety 885 Corrective Action (FSCA) or product defect in post market phase. 886  Description of software versioning and traceability system implemented 887 for the software may be included in the Device Master File. 888 (G) Software verification and validation 889 The Device Master File should contain information on: 890  The software design and development process. 891  Evidence of the validation of the software, as used in the finished 892 device. If there are differences between the version of software that was 893 tested and the version in the finished device, then a description of the 894 differences and an assessment of the potential effect of the differences 895 on the safety and effectiveness of the device needs to be submitted. 896  Summary results of all verification, validation and testing performed both 897 in-house and in a simulated or actual user environment prior to final 898 release. It should also address all of the different hardware 899 configurations and, where applicable, operating systems identified in the 900 labelling.
901  For Medical Device Software that work together or in conjunction with 902 other medical devices or systems, issues relating to the interoperability 903 have to be carefully considered and addressed as appropriate. 904  Implemented cyber security risk control methods that should be verified 905 and validated against specified design requirements or specifications 906

Page 37 of 44

prior to implementation. 907 (H) Clinical Evidence
908  Medical Device Software may function in a way that instead of yielding 909 a direct clinical output, they provide indirect clinical benefits to the 910 subject such as: 911 a) Improving quality and consistency of care 912 b) Enhancing human abilities and mental health support 913 c) Removing administration burden 914 d) Timely care, informed decision 915 e) Earlier diagnosis and prevention 916 f) Reducing cognitive errors 917 g) Reducing burden of diagnostic and treatment activities for a patient 918  The applicant(s) shall ensure the determination of the valid clinical 919 association/scientific validity of a Medical Device software, 920 demonstrating that it corresponds to the clinical situation, condition, 921 indication or parameter defined in its intended purpose. 922  Types of data to support valid clinical association/scientific validity may 923 include: 924 a) Technical Standards, Literature searches 925 b) Professional medical society guidelines 926 c) Systematic scientific literature review 927 d) Clinical Investigation/Clinical performance studies 928 e) Published Clinical data
929 f) Secondary data analysis 930  Validation of technical performance/analytical performance – to 931 demonstrate the ability of a Medical Device Software to accurately, 932 reliably and precisely generate the intended output, from the input 933 data. Evidence supporting Technical Performance/Analytical 934 Performance should be generated through verification and validation 935 activities. 936  Validation of the Clinical Performance is the demonstration of the 937

Page 38 of 44

ability of a Medical Device Software to yield clinically relevant output 938 in accordance with the intended purpose. 939  Details of the Clinical Investigation/Clinical Performance evaluation 940 (including study outcomes) of Medical Device Software may be 941 submitted as part of the Device Master File, if applicable. 942 (I) Software Labelling
943  The Device Master File should typically contain a complete set of 944 labelling information associated with the device as per the 945 requirements of Chapter VI of MDR-2017.
946  Generally, device labelling information includes the following:
947 a) Copy of original label of the device, including accessories if any, 948 and its packaging configuration; 949 b) Instructions for use (Prescriber’s/User manual); 950 c) Product brochure; and 951 d) Promotional material. 952  The Medical Device Software should be identified with an identifier, 953 such as version, revision level and date of build release/issue. 954  Software can be supplied in different forms and there may be 955 difficulties in presenting device information for certain forms (e.g. web- 956 based software). Generally, software can be broadly categorised into 957 two groups based on the mode of supply: 958 a) supplied in physical form, or 959 b) supplied without a physical form 960  If the software is delivered on a physical medium, e.g. CD or DVD, 961 each packaging level shall bear particulars printed in indelible ink on 962 the label, as specified in Chapter VI of MDR-2017. 963  For Medical Device Software without a physical form or packaging, the 964 instructions for use may be available electronically. In this situation, as 965 a good practice, the device may incorporate a means for the user to 966 easily access the electronic label via the software itself or via inclusion 967

Page 39 of 44

of a web address or other means. 968  The developer may display the regulatory requirement (Please refer 969 Chapter VI, MDR-2017) on the primary landing page and as a screen 970 shot in any app store. 971  A screenshot of the software graphical interface (e.g., splash screen) 972 which displays the elements for identification, including software 973 version number, may be submitted as a part of Device Master File. 974  For downloadable software where the downloading and installation is 975 to be done by the end-user, it may be ensured that the user is provided 976 with sufficient information (e.g., Internet address/weblink to download 977 the software, software installation guide or procedure, etc.) for proper 978 installation of such downloadable software. 979  An appropriate system for version controls and access rights controls 980 should be in place to allow timely tracing of the software versions. 981  Software lacking a user interface such as middleware for image 982 conversion, shall be capable of transmitting the label information 983 through an Application Programming Interface (API). 984 4.13 POST MARKETING REGULATORY REQUIREMENTS 985 4.13.1 Fulfillment of conditions of license/permissions 986  The applicant is required to comply with the conditions of the 987 licence/permission as prescribed in the MDR-2017 with respect to the 988 post marketing requirements for medical devices. 989  In case any special (additional) conditions are imposed by the Licensing 990 Authority at the time of approval of the licence/permission, then the 991 applicant shall submit a condition fulfilment application through the MD 992 Online portal accompanied with supporting documents within the time 993 period specified by the Licensing Authority. 994 4.13.2 Post approval change notification 995  Changes to a Medical Device Software refer to any modifications made 996 throughout its lifecycle, including the maintenance phase. 997  Medical Device Software may undergo a number of changes 998

Page 40 of 44

throughout its product life cycle.
999  The changes are typically meant to: 1000 a) Correct faults,
1001 b) Improve the software functionality and performance to meet 1002 customer demands, 1003 c) Keep a software product usable in a changed or changing 1004 environment. 1005 d) Ensure safety and effectiveness of the device is not compromised 1006 (e.g. security patch). 1007  Due to the non-physical nature of software, a software change 1008 management process needs specific considerations to achieve the 1009 intended result regarding traceability and documentation. 1010  Major changes and minor changes to medical devices are specified in 1011 the Sixth Schedule of MDR-2017. 1012  Subject to the provisions laid out in the Sixth Schedule of the MDR- 1013 2017, changes in respect of following shall be considered as major 1014 change in respect of Medical Device Software:
1015 a) Design characteristics which shall affect quality in respect of its 1016 specifications, indication for use, and performance; 1017 b) the intended use or indication for use; 1018 c) the name and address of, -
1019 i. the domestic manufacturer or its manufacturing site;
1020 ii. overseas manufacturer or its manufacturing site (for import 1021 only); 1022 iii. authorized agent (for import only). 1023 d) Label excluding change in font size, font type, colour, label design. 1024 e) Manufacturing process, equipment or testing which shall affect 1025 quality of the device 1026  Subject to the provisions laid out in the Sixth Schedule of the MDR- 1027 2017, changes in respect of following shall be considered as minor 1028 change in respect of Medical Device Software:
1029 a) Design which shall not affect quality in respect of its specifications, 1030 indications for use, performance and stability of the medical 1031 device. 1032

Page 41 of 44

b) in the manufacturing process, equipment, or testing which shall not 1033 affect quality of the device. 1034 c) Revisions for bug fixes and security patches, etc., which does not 1035 affect intended use, safety and performance of the medical device 1036 software.
1037  In case of change in constitution of the firm, which is considered as a 1038 major change, the same shall be notified to the LA as per the stipulated 1039 timeline specified under the MDR-2017 and the applicant shall submit 1040 a fresh application along with the requisite documents to obtain a new 1041 licence for marketing of Medical Device Software in the country under 1042 the MDR-2017. 1043  The licence holder shall submit a PAC notification/request through the 1044 MD Online portal to the CLA or the SLA, as the case may be, for any 1045 major/minor changes (including software version update) to Medical 1046 Device Software. 1047 NOTE: 1048  In case any changes are to be made as per the approved ACP, the 1049 manufacturer/importer (on behalf of overseas manufacturer) shall submit 1050 an approval request/notification with the LA prior to implementation. A 1051 PAC approval is mandatory for major changes, while notification is 1052 required for minor changes. 1053  If a registered Medical Device Software has been updated such that it 1054 significantly changes the indications for use and/or the intended use of 1055 the Medical Device Software and there is an increase in its Risk class 1056 (E.g., Class B to Class C), then the applicant shall need to apply for an 1057 endorsement licence for the same.

1058

Page 42 of 44

4.12.3 Post marketing surveillance (PMS) 1059 Once the Medical Device Software is in the market, the 1060 manufacturer/importer shall maintain vigilance for any direct/indirect harm 1061 to the user/patient(s), reduction in effectiveness, and any vulnerability to 1062 intentional and unintentional security threats as part of PMS. 1063 Manufacturers/importers should maintain documented procedure for PMS 1064 and consider the following as part of their PMS: 1065  Corrections and corrective actions may be required when a process is 1066 not correctly followed or the Medical Device Software does not meet its 1067 specified requirements (i.e., when a nonconforming process or product 1068 exists). 1069  Non-conforming Medical Device Software should be contained to 1070 prevent unintended use or delivery. The detected nonconformity should 1071 be analyzed and actions taken to eliminate the detected nonconformity 1072 (i.e., correction); and to identify and eliminate the cause(s) of the 1073 detected nonconformity (i.e., corrective action) to prevent recurrence of 1074 the detected nonconformity in the future. In some cases, a potential 1075 nonconformity may be identified, and actions such as safeguards and 1076 process changes can be taken, to prevent nonconformities from 1077 occurring (i.e., preventive action). 1078  Nonconformities in a Medical Device Software may lead to inaccurate 1079 or incorrect test results, mixing up of patient results, failure to deliver 1080 therapy, calibration errors resulting in incorrect patient positioning 1081 during therapy, incorrect image display, calculation errors, software 1082 bugs leading to malfunction, etc. 1083  A detailed procedure/plan should be devised for post-market 1084 surveillance (PMS) and response. The manufacturer/importer needs 1085 to ensure that they have the ability to handle product recalls and 1086 implement corrective actions (e.g. bug fixes, cyber alerts, software 1087 patches) in a timely and effective manner (Planning, conducting and 1088 reporting of corrective action), and to identify any recurring problems 1089 requiring attention.
1090  A Field Safety Corrective Action (FSCA) may be initiated when the 1091

Page 43 of 44

manufacturer/importer becomes aware of such nonconformities/certain 1092 risks associated with use of the Medical Device Software through post- 1093 market monitoring and surveillance, such as through tracking of product 1094 complaints/feedback.
1095  Adverse events (AE) for Medical Device Software may arise due to:
1096 a) Shortcomings in the design of the software 1097 b) Inadequate verification and validation of the software code 1098 c) Inadequate instructions for use 1099 d) Software bugs introduced during implementation of new features 1100  The license holder shall inform the SLA or the CLA, as the case may 1101 be, of the occurrence of any suspected unexpected serious adverse 1102 event (SUSAR) and action taken thereon including any product recall 1103 within 15 days of such event coming to the notice of the license holder. 1104  The importer shall inform the Licensing Authority, within a period of 15 1105 days of any administrative action taken on account of any adverse 1106 reaction, such as market withdrawal, regulatory restrictions, 1107 cancellation of authorization or declaration of the medical device as not 1108 of standard quality by the regulatory authority of the country of origin or 1109 by any regulatory authority of any other country, where the medical 1110 device is marketed, sold or distributed. 1111  The manufacturer/importer shall immediately inform SLA or CLA, as 1112 the case may be, if there are reasons to believe that a Medical Device 1113 Software which has been placed in the market, may be unsafe for the 1114 patients, wherein unsafe in terms of Medical Device Software refers to 1115 erroneous results leading to negative impact (whether direct or indirect) 1116 on patient health or/and introduction of bias in clinical decision-making 1117 to the extent that it may negatively impact the health of user. 1118 [Examples: malfunction of an implanted pulse generator because of 1119 erroneous control/influence by the respective software; erroneous 1120 calculations in radiation therapy planning leading to exposure to incorrect 1121 radiation intensities, etc.].
1122  The manufacturer/importer shall ensure availability of sufficient 1123 infrastructure/mechanisms and resources for receiving continuous 1124

Page 44 of 44

customer/user feedback for the Medical Device Software in terms of its 1125 performance, safety and efficacy. 1126  The manufacturer/importer may recall a Medical Device Software from 1127 the market, subject to the conditions laid down in the MDR-2017, 1128 wherein product recall in the case of Medical Device Software may refer 1129 to a complete or partial halt in distribution of the medical device 1130 software from some or all channels/domains, 1131 uninstalling/decommissioning the Medical Device Software from some 1132 or all available networks and hardware devices. 1133  Medical Device Software that are approved for marketing after clinical 1134 investigation(s) (such as medical devices that do not have a predicate 1135 device), shall be closely monitored for their clinical safety once they are 1136 marketed. The manufacturer/importer(s) shall furnish Periodic Safety 1137 Update Reports (PSURs) as per the conditions laid out in the MDR- 1138 2017, in order to — 1139 a) Report all the relevant new information from appropriate sources; 1140 b) Relate these data to patient exposure; 1141 c) Summarize the market authorization status in different countries, if 1142 applicable, and any significant variations related to safety; and 1143 d) Indicate whether changes will be made to product information in 1144 order to optimize the use of the product. 1145

1146

Annexure A: Document Checklists

NOTE:

In case any document in the given checklists is not applicable, a detailed justification with rationale for non-applicability needs to be submitted by the applicant.
In case of Class A (non-sterile and non-measuring) medical device, the applicant may obtain the registration number from the CDSCO MD Online portal to fulfill the regulatory requirements for marketing in the country.
Documents pertaining to cybersecurity verification, human factor validation, etc., may be added as a part of ‘Verification and validation of medical device’ checklist section.

iii

(A) Checklist for the grant of Test Licence to manufacture medical devices for the purposes of clinical investigations or test or evaluation or demonstration or training under the Medical Devices Rules, 2017

Form Type: Test license application in Form MD-12 (MD) Section no. Checklist Name Reference Section 1.0 Covering Letter mentioning the objective of test license 4.9

2.0 Brief description of applied medical device including the Intended use, etc. 3.0 Manufacturing Flow chart, Test specification and test protocol for the applied medical device(s) 4.0 Proposed package insert/ IFU, literature, user manual, pack size and other additional document (if any) 5.0 List of equipment, instruments for manufacturing and testing of applied Medical Devices 6.0 List of qualified personnel for manufacturing and testing of applied Medical Devices 7.0 Justification of quantity proposed to be manufactured. 8.0 Undertaking stating that the required facilities including equipment, instruments, and personnel have been provided to manufacture such medical devices. 9.0 Copy of manufacturing licence of the premises where the development/testing activity is to be carried out, under these rules (if any) 10.0 Approval letter authorizing to undertake research and development activities issued by any government organization (if any) 11.0 Fee Challan 12.0 Legal Form

(B) Checklist for the grant of Test Licence to manufacture IVD medical devices for the purposes of clinical investigations or test or evaluation or demonstration or training under the Medical Devices Rules, 2017

Form Type: Test license application in Form MD-12 (IVD) Section No. Checklist Name Reference Section 1.0 Covering Letter 4.9 2.0 Brief description of the medical device including intended use, material of construction, design 3.0 Undertaking stating that the required facilities including equipment, instruments, and personnel have been provided to manufacture such medical devices. 4.0 List of equipment, instruments 5.0 List of qualified personnel 6.0 Justification of quantity proposed to be manufactured 7.0 Test protocol, if any 8.0 Quality certificates like QMS etc., of the manufacturer from where the raw material is procured, if any 9.0 Copy of Manufacturing licence issued under these rules, if any 10.0 Approval letter authorizing to undertake research and development activities issued by any government organization, if any 11.0 Other documents, if any 12.0 Schematic plan of premises 13.0 Certification of site with detailed raw component 14.0 Detailed description of how the raw material will be procured so as the entire process is scrutinized 15.0 Fee Challan 16.0 Legal Form

(C) Checklist for the grant of Test Licence to import medical devices (other than Class A (non- sterile and non-measuring) medical devices) for the purposes of clinical investigations or test or evaluation or demonstration or training under the Medical Devices Rules, 2017

Form Type: Test license application in Form MD-16 (MD) Section No. Checklist Name Reference Section 1.0 Covering Letter mentioning the objective of test license 4.9 2.0 Brief description of the applied medical device
3.0 Proposed package insert/ IFU, literature, user manual, pack size, Quality certificates and other additional document (if any) 4.0 Justification of quantity proposed to be imported. 5.0 Test specification and test protocol for the applied medical device 6.0 An undertaking stating that the medical device proposed to be imported to be used exclusively for purpose specified at serial number 7 of Form MD-16 and shall not be used for commercial purpose. 7.0 An undertaking stating that required facilities including equipment, instruments, and personnel will be provided to test or evaluate medical devices 8.0 Fee Challan 9.0 Legal Form

(D) Checklist for the grant of Test Licence to import IVD medical devices for the purposes of clinical investigations or test or evaluation or demonstration or training under the Medical Devices Rules, 2017

Form Type: Test Licence application in Form MD-16 (IVD) Section No. Checklist Name Reference Section 1.0 Covering Letter mentioning the objective of test license 4.9 2.0 Brief description of the applied medical device
3.0 Justification of quantity proposed to be imported along with its utilization break-up 4.0 Test specification and protocol along with applicable standards 5.0 Quality certificates like QMS etc., of the manufacturer, if any 6.0 Labels and IFU, as per Rule 48 7.0 Other document, if any 8.0 An undertaking stating that the medical device proposed to be imported to be used exclusively for purpose specified at serial number 7 of Form-16 and shall not be used for commercial purpose. 9.0 An undertaking from the testing laboratory, stating that required facilities including equipment, instruments, and personnel will be provided to test or evaluate medical devices 10.0 Fee Challan 11.0 Legal Form

vii

(E) Checklist for the grant of permission to conduct clinical investigation on investigational medical device(s) (other than Class A (non-sterile and non-measuring) medical devices)
under the Medical Devices Rules, 2017

Form Type Application in Form MD-22 Sectio n No. Checklist Name Reference Section 1.0 Cover Letter mentioning whether the Study is Pilot/Pivotal/ Postmarketing clinical study along with its objective 4.10 2.0 Application (Form MD-22) 3.0 Fees Challan 4.0 Justification for the proposed class of device along with supporting documents 5.0 Regulatory status of the device if approved by any National regulatory authority (if any) along with the copy of approval letter 6.0 Design analysis data of the Investigational medical device 6.1 Design input, design output and design control documents, etc. along with design verification and validation report 6.2 Essential Principles checklist for demonstrating conformity to the Safety and Performance of the Medical Device 6.3 Device specification including the test parameters and its reference protocol to be carried out on the finished device along with the test report 6.4 Mechanical test, electrical tests, Reliability tests, software verification & validation, any performance test, Ex vivo tests, etc.(wherever applicable) 7.0 Stability Study data generated (if any) 8.0 Risk Management Report on the Investigational medical device 9.0 Biocompatibility and Animal performance study data for Investigational medical device (as applicable) 10.0 Proposed Labelling information 11.0 The agreement between the Sponsor and Principal investigator 12.0 Appropriate Insurance certificate, if any 13.0 Forms for reporting any adverse event and serious adverse event, 14.0 Investigators Brochure as per Seventh Schedule of MDR-2017 15.0 Clinical Investigational Plan as per Seventh Schedule of MDR-2017 16.0 Case Report Form as per Seventh Schedule of MDR-2017 17.0 Informed Consent Form as per Seventh Schedule of MDR-2017 18.0 Undertaking by the Investigator as per Seventh Schedule of MDR-2017 19.0 Published technical documents/literature (if any)

viii

20.0 Clinical Investigation data generated on the applied device (if any) 21.0 Ethics Committee Approval letter 22.0 Other information (if any)

(F) Checklist for the grant of permission to conduct clinical performance evaluation on new IVD medical devices under the Medical Devices Rules, 2017

Form Type: Application in Form MD-24 Section No. Checklist Name Reference Section 1.0 Covering Letter 4.10 2.0 Constitution of the Firm 3.0 Device description including specification of raw material and finished product, data allowing identification of the device in question, proposed instruction for use, labels and regulatory status in other countries, if any 4.0 In house performance evaluation data used to establish stability, specificity, sensitivity, repeatability and reproducibility 5.0 Approval from an Ethics Committee 6.0 Clinical performance evaluation plan 7.0 Case Report Form (CRF) 8.0 Undertaking by investigators 9.0 An undertaking that the device in question conforms to the requirements of these rules, apart from aspects covered by evaluation and apart from those specifically itemised in the undertaking, and that every precaution has been taken to protect the health and safety of the patient, user and other persons 10.0 Performance evaluation report from a laboratory designated under sub- rule (1) of rule 19 11.0 Fee Challan 12.0 Legal Form

(G) Checklist for the grant of permission to import or manufacture for sale or for distribution of medical device (other than Class A (non-sterile and non-measuring) medical devices) which does not have predicate medical device under Medical Devices Rules, 2017 Form Type Application in Form MD-26
Section No. Checklist Name Reference Section 1.0 Cover Letter 4.11 2.0 Application (Form MD-26) 3.0 Fees Challan 4.0 Justification for the proposed class of device along with supporting documents 5.0 Regulatory status of the device if approved by any National regulatory authority of the countries viz. United Kingdom, United States of America, Australia, Canada, Japan, etc. along with the notarized copy of approval letter. 6.0 Design analysis data of the Investigational medical device 6.1 Design input, design output and design control documents, etc. along with design verification and validation report 6.2 Essential Principles checklist for demonstrating conformity to the Safety and Performance of the Medical Device 6.3 Device specification including the test parameters and its reference protocol to be carried out on the finished device along with the test report 6.4 Mechanical test, electrical tests, Reliability tests, software verification & validation, any performance test, Ex vivo tests, etc.(wherever applicable) 7.0 Stability Study data generated (if any) 8.0 Risk Management Report on the applied medical device 9.0 Biocompatibility and Animal performance study data for applied medical device (as applicable) 10.0 Proposed Labelling information 11.0 In case if the device contains drug, whether the drug is approved in India, If yes, then details of approval no. and company name and validity of approval etc., 12.0 If the drug is not approved in India, the following documents are required to be submitted: Data on animal toxicology, Reproduction studies, Teratogenic studies, Perinatal studies, Mutagenicity, Carcinogenicity, Chemical and Pharmaceutical information, etc. 13.0 Clinical Investigation data including that carried out in India or other countries (if any)

14.0 Details of countries where the investigational medical device is being sold/marketed from last two year (in case of import) 15.0 Post marketing surveillance data of the investigational medical device if marketed in the countries viz. United Kingdom, United States of America, Australia, Canada, Japan, etc., from last two years. 16.0 Details on evidence that there is no theoretical possibility of any difference in the behavior and performance in Indian population 17.0 Undertaking in writing to conduct post marketing clinical investigation with the objective of safety and performance of such investigational medical device as per protocol approved by the Central Licensing Authority 18.0 Notarized copy of overseas manufacturing site or establishment or plant registration, in the country of origin issued by the competent authority (in case of import) 19.0 Constitution details of domestic manufacturer or authorized agent 20.0 Other information (if any)

xii

(H) Checklist for the grant of permission to import or manufacture for sale or for distribution of IVD medical device which does not have predicate medical device under Medical Devices Rules, 2017

Form Type: Application in Form MD-28 Section No. Checklist Name Reference Section 1.0 Covering Letter 4.11 2.0 Power of Attorney (Original) authenticated in India either by a Magistrate of First Class or by Indian Embassy in the country of origin or by an equivalent authority through apostille along with under taking from the authorized agent as specified in Part I of Forth Schedule 3.0 Constitution details of authorized agent 4.0 Self-attested copy of valid Whole sale licence or manufacturing licence 5.0 Regulatory Certificates 5.1 Notarized and valid copy of overseas manufacturing site or establishment or plant registration, by whatever name called, in the country of origin issued by the competent authority 5.2 Notarized and valid copy of Free Sale Certificate issued by the National Regulatory Authority or equivalent competent authority of the country of origin (if any) 5.3 Notarized and valid copy of Free Sale Certificate issued by the National Regulatory Authority or equivalent competent authority of the any of the countries namely United States of America, Australia, Canada, Japan, and European Union Countries 5.4 Copy of latest inspection or audit report carried out by Notified bodies or National Regulatory Authority or Competent Authority within last 3 years, if any 5.5 Copy of NOC from Department of Animal Husbandry, Ministry of Agriculture, In Case of Veterinary IVD Kits 5.6 Copy of NOC from Bhabha Atomic Research Centre (BARC), Mumbai, In case Radio Immuno Assay Kits 6.0 Quality Management System certificate in respect of legal and actual manufacturing sites(s) (Wherever applicable) 6.1 Notarized and valid copy of Quality Management System certificate (ISO 13485) certificate issued by the competent authority 6.2 Notarized and valid copy of Production Quality Assurance certificate or Full quality Assurance certificate issued by the competent authority (if any) 6.3 Notarized and valid copy of CE design certificate issued by the competent authority (if any) 7.0 Undertaking signed by the manufacturer stating that the manufacturing site is in compliance with the provisions of the Fifth Schedule of MDR- 2017 8.0 Site or plant master file as specified in Appendix I of Fourth Schedule of MDR-2017 9.0 Device master file as specified in Appendix III of Fourth Schedule of MDR-2017 10.0 Device data including, (whichever is applicable) 10.1 Design input, Design output documents, Stability data 10.2 Device specification including specificity, Sensitivity, Reproducibility and Reputability 10.3 Product validation and Software validation relating to the function of the Device (if any)

xiii

11.0 Risk Management Data 12.0 Clinical Performance Evaluation data carried out in India and in other countries (if any) 13.0 Regulatory status and Restriction on use in other countries (if any) where marketed or approved 14.0 Essential principles checklist for demonstrating conformity to the essential principles of safety and performance of the in vitro medical device 15.0 Product Insert 16.0 Labelling and Pack Size 17.0 Fee Challan 18.0 Legal Form 19.0 Copy of performance evaluation report issued by the central medical device testing laboratory or medical device testing laboratory registered under sub-rule (3) of rule 83 of MDR 2017 for three batches 20.0 Stability 20.1 Claimed Shelf life - stability study report for at least 3 lots including the protocol, acceptance criteria, testing intervals and conclusion 20.2 In use stability study report for 1 lot including the protocol, acceptance criteria, testing intervals and conclusion 20.3 Shipping stability study report for 1 lot including the protocol, acceptance criteria, simulated conditions, conclusion and recommended shipping conditions 21.0 Specific evaluation report, if done by any laboratory in India, showing the sensitivity and specificity of the in vitro diagnostic medical device(if available), 22.0 Specimen batch test report for at least consecutive 3 batches showing specification of each testing parameter 23.0 Correlation chart with respect to products list mentioned in MD-28 and FSC submitted 24.0 Testing method preferably in Video (if available)

xiv

(I) Checklist for the grant of manufacturing license for Class A (other than Class A (non-sterile and non-measuring) medical devices) Medical Devices under Medical Devices Rules, 2017

Form Type: Fresh Application (Form MD-3) Section no. Checklist Name Reference Section 1.0 Covering Letter 4.12.1 2.0 Legal Form (MD-3) 4.12.1 3.0 Fee Challan 4.12.1 4.0 Details of the constitution of the firm along with the relevant documents 4.12.1 5.0 The Establishment /Site ownership/Tenancy Agreement 4.12.1 6.0 Plant Master file as per Appendix I of Fourth Schedule of MDR, 2017 4.12.1 6.1 General Information of the facility 6.2 Personnel- Organisation chart 6.3 Personnel -Qualification, Experience and responsibilities 6.4 Premises and Facilities 6.5 Plant Layout of premise with indication of scale
6.6 List of equipment and instruments used for manufacturing and testing 6.7 Sanitation 6.8 Production 6.9 Quality Assurance 6.10 Storage 6.11 Documentation 7 Quality Management System Requirements 4.6 7.1 Undertaking from the manufacturer stating that the manufacturing site is in compliance with the provisions of the Fifth Schedule of MDR, 2017 7.2 Quality Manual 7.3 Control of Documents 7.4 Control of Records 7.5 Management Responsibility 7.6 Resource management 7.7 Control of production and service provision 7.8 Internal Audit System 7.9 Control of non-conforming product 7.10 Corrective Action and Preventive Action 7.11 Table the areas showing the environmental requirement for Medical Devices as per Annexure A of Fifth Schedule of MDR, 2017. 8.0 Copy of approval obtained from DAHD in case of devices intended for veterinary use

9.0 Any other additional documents (if any)

10.0 Test License obtained in Form MD-13 for the applied devices (if any) 4.9

11.0 Copy of Permission in Form MD-27 (in case of Medical device which does not have Predicate medical device) 4.11 12.0 Device description including Intended use of the device, Material of construction (if applicable), Working principle, specification including variants and accessories etc., 4.12.2 13.0 Labelling information (Labels, Instruction for Use, etc.) 4.12.2 14.0 Essential Principles checklist for demonstrating conformity to the Safety and Performance of the applied device Medical Device 4.12.2

xvi

(J) Checklist for the grant of manufacturing licence for Class B Medical Devices under Medical Devices Rules, 2017

Form Type: Fresh (Form MD-3) common checklist Section no. Checklist Name Reference Section 1.0 Covering Letter 4.12.1 2.0 Application (Form MD-3/MD-4) 4.12.1 3.0 Fee Challan 4.12.1 4.0 Details of the constitution of the firm along with the relevant documents 4.12.1 5.0 The Establishment /Site ownership/Tenancy Agreement 4.12.1 6.0 Plant Master file as per Appendix I of Fourth Schedule of MDR, 2017 4.12.1 6.1 General Information of the facility 6.2 Personnel- Organisation chart 6.3 Personnel -Qualification, Experience and responsibilities 6.4 Premises and Facilities 6.5 Plant Layout of premise with indication of scale
6.6 List of equipment and instruments used for manufacturing and testing 6.7 Sanitation 6.8 Production 6.9 Quality Assurance 6.10 Storage 6.11 Documentation 7 Quality Management System Requirements 4.6 7.1 Undertaking from the manufacturer stating that the manufacturing site is in compliance with the provisions of the Fifth Schedule of MDR, 2017 7.2 Quality Manual 7.3 Control of Documents 7.4 Control of Records 7.5 Management Responsibility 7.6 Resource management 7.7 Control of production and service provision 7.8 Internal Audit System 7.9 Control of non-conforming product 7.10 Corrective Action and Preventive Action 7.11 Table the areas showing the environmental requirement for Medical Devices as per Annexure A of Fifth Schedule of MDR, 2017. 8.0 Copy of approval obtained from DAHD in case of devices intended for veterinary use

9.0 Any other additional documents (if any)

xvii

10.0 Test License obtained in Form MD-13 for the applied devices (if any) 4.9 11.0 Copy of Permission in Form MD-27 (in case of Medical device which does not have Predicate medical device) 4.11 12.0 Device Master file in the line of Appendix II of Forth Schedule of Medical Devices Rules, 2017 4.12.2 12.1 Executive Summary 12.2 Descriptive information of the device 12.3 Justification for the Medical Device Grouping 12.4 Product Specification, including variants and accessories 12.5 Substantial equivalence with reference to the predicate device or previous generations of the device 12.6 Labelling information (Labels, Instruction for Use, etc.) 12.7 Device Design and Manufacturing Information 12.8 Essential Principles checklist for demonstrating conformity to the Safety and Performance of the Medical Device 12.9 Risk analysis and control summary 12.10 Verification and validation of the medical device 12.11 Biocompatibility validation data (if applicable) 12.12 Medicinal substances data (if device contains Drug) 12.13 Biological Safety (if applicable) 12.14 Sterilization Validation data (if applicable) 12.15 Software verification and validation (if software used) 12.16 Animal studies – Preclinical data (if any) 12.17 Stability study data (Real-time and Accelerated conditions) 12.18 Clinical evidence (if any) 12.19 Post Marketing Surveillance data (Vigilance reporting) duly authenticated by the manufacturer 12.20 Batch Release Certificates or Certificate of Analysis for minimum 3 consecutive batches/ Software version release certificate/Software version release note/Software release report

xviii

(K) Checklist for the grant of manufacturing licence for Class A and Class B IVD Medical Devices under Medical Devices Rules, 2017

Form Type: Fresh Application (Form MD-3) Section No. Checklist Name Reference Section 1.0 Covering Letter 4.12.1 2.0 Constitution Details of Manufacturer 4.12.1 3.0 Site or plant master file as specified in Appendix I of Fourth Schedule of MDR 2017 4.12.1 4.0 Device master file as specified in Appendix III of Fourth Schedule of MDR 2017 4.12.2 5.0 Essential principles checklist for demonstrating conformity to the essential principles of safety and performance of the in vitro medical device 4.12.2 6.0 Undertaking signed by the manufacturer stating that the manufacturing site is in compliance with the provisions of the Fifth Schedule of MDR 2017 4.6 7.0 Labelling and Pack Size 4.12.2 8.0 Regulatory Certificates 4.12.1 8.1 Copy of latest inspection or audit report carried out by Notified bodies or National Regulatory Authority or Competent Authority within last 3 years, if any

8.2 Valid copy of Quality Management System certificate (ISO:13485) certificate issued by the competent authority (if any)

8.3 Copy of NOC from Department of Animal Husbandry, Ministry of Agriculture, In Case of Veterinary IVD Kits (if available)

8.4 copy of NOC from Bhabha Atomic Research Centre (BARC), Mumbai, In case Radio Immuno Assay Kits (if available)

8.5 Copy of Test licence obtained for testing and generation of quality control data, if any 4.9 8.6 Self-attested copy of valid Whole sale licence or manufacturing licence if any

9.0 Specific evaluation report, if done by any laboratory in India, showing the sensitivity and specificity of the in vitro diagnostic medical device (For class B medical devices) (if available) 4.12.2

10.0 Specimen batch test report for at least consecutive 3 batches showing specification of each testing parameter (For class B medical devices) 11.0 Copy of performance evaluation report issued by the central medical device testing laboratory or medical device testing laboratory registered under sub-rule (3) of rule 83 of MDR 2017 for three batches (For class B medical devices)

xix

12.0 A summary of analytical technology, relevant analytes and test procedure (For class A medical devices)

13.0 Working principle and use of a novel technology (For class A medical devices) (if any) 4.12.2 14.0 Stability

14.1 Claimed Shelf life - stability study report for at least 3 lots including the protocol, acceptance criteria, testing intervals and conclusion. 14.2 In use stability study report for 1 lot including the protocol, acceptance criteria, testing intervals and conclusion, 14.3 Shipping stability study report for 1 lot including the protocol, acceptance criteria, simulated conditions, conclusion and recommended shipping conditions 15.0 Product Insert
4.12.1 16.0 Fees Challan 4.12.1 17.0 Legal Form 4.12.1

(L) Checklist for the grant of manufacturing license for Class C and Class D Medical Devices under Medical Devices Rules, 2017

Form Type: Fresh application in Form MD-7 Section No. Checklist Name Reference Section 1.0 Covering Letter 4.12.1 2.0 Application form 4.12.1 3.0 Fee Challan 4.12.1 4.0 Details of the constitution of the firm along with the relevant documents 4.12.1 5.0 The Establishment /Site ownership /Tenancy Agreement 4.12.1 6.0 Plant Master file as per Appendix I of Fourth Schedule of MDR, 2017 4.12.1 6.1 General Information of the facility 6.2 Personnel- Organisation chart 6.3 Personnel -Qualification, Experience and responsibilities 6.4 Premises and Facilities 6.5 Plant Layout of premise with indication of scale
6.6 List of equipment and instruments used for manufacturing and testing 6.7 Sanitation 6.8 Production 6.9 Quality Assurance 6.10. Storage 6.11 Documentation 7.0 Quality Management System Requirements 4.6 7.1 Undertaking from the manufacturer stating that the manufacturing site is in compliance with the provisions of the Fifth Schedule of MDR, 2017 7.2 Quality Manual 7.3 Control of Documents 7.4 Control of Records 7.5 Management Responsibility 7.6 Resource management 7.7 Control of production and service provision 7.8 Internal Audit System 7.9 Control of nonconforming product 7.10 Corrective Action and Preventive Action 7.11 Table the areas showing the environmental requirement for Medical Devices as per Annexure A of Fifth Schedule of MDR, 2017. 8.0 Device Master file in the line of Appendix II of Fourth Schedule of MDR, 2017 4.12.2 8.1 Executive Summary

xxi

8.2 Descriptive information of the device 8.3 Justification for the Medical Device Grouping 8.4 Product Specification, including variants and accessories 8.5 Substantial equivalence with reference to the predicate device or previous generations of the device 8.6 Labelling information (Labels, Instruction for Use, etc) 8.7 Device Design and Manufacturing Information 8.8 Essential Principles checklist for demonstrating conformity to the Safety and Performance of the Medical Device 8.9 Risk analysis and control summary 8.1 Verification and validation of the medical device 8.11 Biocompatibility validation data (if applicable) 8.12 Medicinal substances data (if device contains Drug) 8.13 Biological Safety (if applicable) 8.14 Sterilization Validation data (if applicable) 8.15 Software verification and validation (if software used) 8.16 Animal studies – Preclinical data (if any) 8.17 Stability study data (Real-time and Accelerated conditions) 8.18 Clinical evidence (if any) 8.19 Post Marketing Surveillance data (Vigilance reporting) 8.20 Batch Release Certificates or Certificate of Analysis for minimum 3 consecutive batches/ Software version release certificate/Software version release note/Software release report 9.0 Copy of approval obtained from DAHD in case of devices intended for veterinary use

10.0 Any other additional documents (if any)

11.0 Test License obtained in Form MD-13 for the applied devices (if any) 4.9 12.0 Copy of Permission in Form MD-27 (in case of Medical device which does not have Predicate medical device) 4.11

xxii

(M) Checklist for the grant of manufacturing license for Class C and Class D IVD under Medical Devices Rules, 2017

Form Type: Fresh application in Form MD-7 Section No. Checklist Name Reference Section 1.0 Covering Letter 4.12.1 2.0 Constitution Details of Manufacturer, 4.12.1 3.0 Site or plant master file as specified in Appendix I of Fourth Schedule of MDR 2017 4.12.1 3.1 Part–1 Plant Layout of premise with indication of scale 3.2 Part-2 Organization chart showing the arrangements for key personnel 3.3 Part-3 Qualification, Experience and responsibilities of key Technical Persons 3.4 Part-4 List of Equipment and Instruments 3.5 Part-5 Contract Activities if any 4.0 Quality Management System 4.6 4.1 Part – 1 Quality Management System as per Fifth Schedule of Medical devices Rules, 2017 4.2 Part – 2 Quality Manual 4.3 Part – 3 Quality Policy 4.4 Part – 4 Control of Documents 4.5 Part – 5 Control of Records 4.6 Part – 6 Management Responsibility 4.7 Part – 7 Internal Audit System 4.8 Part – 8 Preventive and Corrective Action 4.9 Part – 9 Procedure for identifying training needs and ensure that all persons are trained to adequately perform their assigned responsibilities. 4.10 Part – 10 Table the areas showing the environmental requirement for Medical Devices as per Annexure A of Fifth Schedule of Medical devices Rules, 2017 5.0 Undertaking signed by the manufacturer stating that the manufacturing site is in compliance with the provisions of the Fifth Schedule of MDR 2017 4.6 6.0 Regulatory certificates 4.6, 4.9

xxiii

6.1 Copy of latest inspection or audit report carried out by Notified bodies or National Regulatory Authority or Competent Authority within last 3 years 6.2 Copy of NOC from Department of Animal Husbandry, Ministry of Agriculture, In Case of Veterinary IVD Kits (if available) 6.3 Copy of NOC from Bhabha Atomic Research Centre (BARC), Mumbai, In case Radio Immuno Assay Kits (if available) 6.4 Valid copy of Quality Management System certificate (ISO:13485) certificate issued by the competent authority .(if any) 6.5 Copy of Test licence obtained for testing and generation of quality control data, if any 6.6 Self attested copy of valid Whole sale licence or manufacturing licence, if any 7.0 Device Master File for In Vitro Diagnostic Medical Devices as per Appendix–III of Part III of Fourth Schedule of Medical devices Rules, 2017 4.12.2 7.1 Part – 1 Executive Summary 7.2 Part-2 Regulatory status of the similar device in India (approved or new in vitro diagnostic medical device). 7.3 Part-3 Description and specification, including variants and accessories of the in vitro diagnostic medical device 7.4 Part – 4 Essential principles checklist for demonstrating conformity to the essential principles of safety and performance of the in vitro medical device 7.5 Part – 5 Risk analysis and control summary 7.6 Part–6 Device Design and Manufacturing Information 7.7 Part-7 Product validation and verification 7.8 Part-8 Analytical studies, Specimen type, Analytical performance characteristics, Analytical sensitivity, Analytical Specificity, Metrological traceability of calibrator and control material values, Measuring range of assay, Definition of assay 7.9 Part – 9 Claimed Shelf life - stability study Report for at least 3 lots including the protocol, acceptance criteria, testing intervals and conclusion. 7.10 Part-10 In use stability study report for 1 lot including the protocol, acceptance criteria, testing intervals and conclusion for 7.11 Part-11 Shipping stability study report for 1 lot including the protocol, acceptance criteria, testing intervals and conclusion for Part-11Shippingstabilitystudyreportfor1 lot including the protocol, acceptance criteria, testing intervals and conclusion for 7.12 Part-12 Clinical Evidence 7.13 Part-13 Product Insert, Pack size, Label 7.14 Part-14 Specimen batch test report format least consecutive 3 batches showing specification of each testing parameter

xxiv

7.15 Part-15 Specific evaluation report, if done by any laboratory in India, showing the sensitivity and specificity of the invitro diagnostic medical device 7.16 Part-16 Copy of performance evaluation report issued by the central medical device testing laboratory or medical device testing Laboratory registered under sub-rule(3)of rule 83 of MDR 2017 for three batches 7.17 Part-17 Post Market Surveillance Data 7.18 Part-18-Others 8.0 Fee Challan 4.12.1 9.0 Legal Form 4.12.1

xxv

(N) Checklist for the grant of Import license for Medical Device under Medical Devices Rules, 2017

Form Type: Fresh application in Form MD-14 Section no. Checklist Name Reference Section 1 Covering Letter 4.12.1 2 Application (Form MD-14) 4.12.1 3 Fee Challan 4.12.1

4 Power of Attorney along with undertaking from the authorized agent as per Part I of Fourth Schedule of MDR, 2017 (duly authenticated in India either by a Magistrate of First Class or by Indian Embassy in the country of origin or by an equivalent authority through apostille) 4.12.1 5 Copy of Whole Sale licence / Manufacturing licence/ Registration Certificate in Form MD-42 of the Authorized agent 4.12.1 6 Constitution details of the authorized agent 4.12.1 7 Regulatory Certificate 4.12.1

7.1 Copy of Free Sale Certificate/Marketing Authorization of the product issued by the National Regulatory Authority of country of origin (if any) (duly notarized)

7.2 Copy of Free Sale Certificate Marketing Authorization of the product issued from National Regulatory Authority of any of the following countries viz., USA, UK, EU, Canada, Japan or Australia (duly notarized)

7.3 Copy of overseas manufacturing site / establishment / plant registration, by whatever name called, in the country of origin issued by the competent authority (duly notarized) 7.4 Copy of latest inspection or audit report carried out by the Competent Authority within last 3 years, if any. 8 Quality Certificate in respect of the actual manufacturing site, as applicable 4.6 8.1 Copy of Certificate supporting Quality Management System (duly notarized)

8.2 Copy of Full Quality Assurance Certificate/ CE type examination Certificate/ CE product quality assurance certificate, CE design Certificate, etc. as applicable (duly notarized) 8.3 Declaration of conformity issued by the manufacturer 9 Plant Master file from the Manufacturer as per Appendix I of Fourth Schedule of Medical Devices Rules, 2017 4.12.1

10 Device Master file from the Manufacturer as per Appendix II of Fourth Schedule of Medical Devices Rules, 2017 4.12.2 10.1 Executive Summary

xxvi

10.2 Descriptive information of the device 10.3 Justification for the Medical Device Grouping 10.4 Product Specification, including variants, accessories, etc. 10.5 Substantial equivalence with reference to the predicate device or previous generations of the device 10.6 Labelling information (Labels, Instruction for Use, etc.) 10.7 Device Design and Manufacturing Information 10.8 Essential Principles checklist for demonstrating conformity to the Safety and Performance of the Medical Device 10.9 Risk analysis and control summary 10.10 Verification and validation of the medical device 10.11 Biocompatibility validation data (if applicable) 10.12 Medicinal substances data (if device contains Drug) 10.13 Biological Safety (TSE/BSE), if applicable 10.14 Sterilization Validation data (if applicable) 10.15 Software verification and validation (if software used) 10.16 Animal studies – Preclinical data (if any) 10.17 Stability study data (Real-time and Accelerated conditions) for the claimed shelf life (if applicable) 10.18 Clinical evidence (if any) 10.19 Post Marketing Surveillance data (Vigilance reporting)

10.20 Batch Release Certificates or Certificate of Analysis for minimum 3 consecutive batches/ Software version release certificate/Software version release note/Software release report 11 Any other additional documents

12 Copy of Permission in Form MD-27 (in case of Investigational Medical Device ) 4.11

xxvii

(O) Checklist for the grant of Import license for IVD under Medical Devices Rules, 2017

Form Type: Fresh Application in Form MD-14 Section No. Checklist Name Reference Section 1.0 Covering Letter 4.12.1 2.0 Power of Attorney (Original) authenticated in India either by a Magistrate of First Class or by Indian Embassy in the country of origin or by an equivalent authority through apostille along with undertaking from the authorized agent as specified in Part I of Fourth Schedule 4.12.1 3.0 Self-attested copy of valid Wholesale licence or manufacturing licence, if any 4.12.1 4.0 Regulatory Certificates along with previous import license (if any) 4.12.1 4.1 Notarized copy of overseas manufacturing Site or establishment or plant registration, by whatever name called, in the country of origin issued by the competent authority

4.2 Notarized and valid copy of Free Sale Certificate issued by the National Regulatory Authority or equivalent competent authority of the country of origin (if any)

4.3 Notarized and valid copy of Free Sale Certificate issued by the National Regulatory Authority or equivalent competent authority of the any of the countries namely United States of America, Australia, Canada, Japan, and European Union Countries

4.4 Copy of latest inspection or audit report Carried out by Notified bodies or National Regulatory Authority or Competent Authority within last 3 years, if any.

4.5 Copy of NOC from Department of Animal Husbandry, Ministry of Agriculture, In Case of Veterinary IVD Kits,

4.6 Copy of NOC from Bhabha Atomic Research Centre (BARC), Mumbai, In case Radio Immuno Assay Kits

5.0 Quality Management System certificate in respect of legal and actual manufacturing sites(s) (Wherever applicable) 4.6 5.1 Notarized and valid copy of Quality Management System certificate (ISO13485) certificate issued by the competent authority,

5.2 Notarized and valid copy of Production Quality Assurance certificate or Full quality Assurance certificate issued by the competent authority.(if any)

5.3 Notarized and valid copy of CE design certificate issued by the competent authority.(if any),

6.0 Site or plant master file as specified in Appendix I of Fourth Schedule of MDR-2017 4.12.1 7.0 Device Master File for In Vitro Diagnostic Medical Devices as per Appendix–III of Part III of Fourth Schedule of Medical devices Rules, 2017 4.12.2

xxviii

7.1 Part-1 Executive Summary, Description and specification, including variants and accessories and Design & manufacturing information of the in-vitro diagnostic medical device 7.2 Part-2 Regulatory status of the similar device in India (approved or new in vitro diagnostic medical device). 7.3 Part–3 Essential principles checklist 7.4 Part–4 Risk analysis and control summary, Product validation and verification and Clinical Evidences 7.5 Part-5 Analytical studies, Specimen type, Analytical performance characteristics, Analytical sensitivity, Analytical Specificity, Metrological traceability of calibrator and control material values, Measuring range of assay, Definition of assay 7.6 Part – 6 Claimed Shelf life – stability study report for at least 3 lots including the protocol, acceptance criteria, testing intervals and conclusion, In use stability study report for 1 lot including the protocol, acceptance criteria, testing intervals and conclusion & Shipping stability study report for 1 lot including the protocol, acceptance criteria, testing intervals and conclusion. 7.7 Part-7 Product Insert, Pack size, Label 7.8 Part-8 Specimen batch test report for at least consecutive 3 batches showing specification of each testing parameter 7.9 Part-9 Copy of performance evaluation Report issued by the central medical device testing laboratory o r medical device testing laboratory registered under sub-rule (3) of rule 83 of MDR 2017 for three batches/ Specific evaluation report, if done by any laboratory in India, showing the sensitivity and specificity of the in-vitro diagnostic medical device 7.10 Part-10 Post Market Surveillance Data and any other information of the product 8.0 Correlation chart with respect to products list mentioned in MD- 14 and FSC submitted

9.0 Testing method preferably in Video (if available)

10.0 Fee Challan 4.12.1 11.0 Legal Form 4.12.1

Verbatim extracted text (OCR/PDF). Older scans and tables may show extraction artifacts — verify against the original for anything you act on.

Analysis

No analysis has been generated for this document yet.