Software used in healthcare does not automatically become a medical device. However, software intended to diagnose, prevent, monitor, predict, prognose, treat, or alleviate disease, or perform another regulated medical function, may fall within India’s medical device framework. For businesses in West Bengal, the correct route depends first on intended use, device status, risk classification, and whether the activity involves domestic manufacture, import, distribution, or marketing. Classification should therefore precede any licence application, technical submission, or commercial launch.
When Software Becomes a Medical Device
Regulatory status follows intended medical purpose rather than the technology used. Product descriptions, instructions, promotional claims, clinical workflows, and intended users help establish that purpose. Consequently, administrative software can differ legally from software that analyses patient data and produces diagnostic or therapeutic recommendations.
A business evaluating a medical device license West Bengal should document intended purpose before choosing a regulatory pathway because later claim changes can affect classification and evidence requirements.
What Qualifies as Software as a Medical Device?
SaMD generally refers to software intended for one or more medical purposes that performs those purposes without being part of medical-device hardware. Depending on intended use, it may include software that:
- analyses medical images;
- interprets laboratory or physiological data;
- calculates patient-specific therapeutic recommendations;
- assists diagnosis or disease detection;
- supports treatment planning; or
- produces medically actionable patient-specific outputs.
However, the actual function and claims determine status; a commercial label such as “clinical software” does not establish SaMD classification.
Software That May Fall Outside SaMD
Appointment scheduling, billing, inventory control, staff rostering, generic communication, administrative record storage, and non-medical wellness tools may fall outside SaMD when they do not perform regulated medical functions. Nevertheless, disease detection, patient-specific diagnostic conclusions, treatment recommendations, or similar functions can change that position.
Electronic record systems also require functional analysis. Storage or transmission differs from processing clinical data to generate medical decisions. Therefore, developers should assess mixed platforms module by module.
Indian Regulatory Framework for Medical Software
India regulates qualifying software within the Drugs and Cosmetics Act framework and the Medical Devices Rules, 2017, together with applicable notifications and classifications. There is no separate standalone software licensing regime.
Regulatory material distinguishes SaMD from software in a medical device, or SiMD. SaMD performs its medical purpose independently of device hardware, whereas SiMD drives, controls, or forms part of hardware. Accordingly, embedded software can follow rules linked to the device it influences, while independent SaMD requires its own intended-use assessment.
Risk Classification Determines Regulatory Burden
India uses Class A, B, C, and D risk categories, progressing from lower to higher risk. Classification affects the regulatory pathway, authority, evidence, and quality-system expectations.
SaMD classification should follow intended use and applicable rules, not simply whether software uses AI or operates in a hospital. Relevant considerations may include:
- seriousness of the condition addressed;
- whether software informs or drives clinical decisions;
- consequences of incorrect output;
- patient dependence on generated information;
- intended users and population; and
- clinical environment.
Therefore, technologically similar products can receive different regulatory treatment because their medical purposes and risks differ.
Central and State Licensing Responsibilities
West Bengal businesses should not assume that every medical software application goes solely to a state authority. Jurisdiction depends on device class, manufacturing or import activity, licence category, and the Medical Devices Rules.
Manufacturing responsibility differs across classes, while import licensing falls within central administration. Certain higher-risk manufacturing applications come under central jurisdiction, whereas specified lower-risk manufacturing activities can involve the State Licensing Authority. Therefore, applicants should establish device class and regulatory role before identifying the competent authority.
Who Is the Manufacturer of SaMD?
The regulatory manufacturer is not necessarily the programmer writing source code. Relevant factors include who owns the product, defines intended purpose, controls design, approves releases, places the software on the market, and assumes regulatory responsibility. Outsourcing development does not automatically transfer those obligations.
A hospital or technology business commissioning software under its own identity may therefore need to assess manufacturer responsibility. Significant modifications or ownership changes can also affect that position.
Manufacturing Licence Considerations
A domestic SaMD developer that qualifies as manufacturer should determine the manufacturing route applicable to its device class. The applicant may need a quality system, documented development, risk management, verification, validation, technical evidence, labelling, and post-market controls.
Regulatory review can also examine whether the applicant controls design, release, and maintenance. Although software manufacture differs physically from hardware production, a virtual product does not remove manufacturing responsibilities.
Importing Foreign-Developed SaMD
Foreign-developed SaMD intended for India may require an import pathway rather than domestic manufacturing licensing, and import applications fall under central regulatory responsibility.
The Indian applicant or authorised entity may need foreign-manufacturer information, quality-system evidence, technical documentation, classification, labelling, and post-market arrangements. Cloud delivery does not automatically eliminate import considerations merely because no physical package crosses a border. Businesses should assess how the software is supplied and marketed in India before commercialisation.
Quality Management System for Medical Software
A quality management system should control development, release, maintenance, and monitoring. Certification may support compliance where applicable, but it does not replace every regulatory obligation.
Important controls include:
- design and change control;
- risk management;
- configuration and version control;
- verification and validation;
- complaint handling;
- corrective and preventive action;
- outsourced-development controls;
- cybersecurity management; and
- post-market surveillance.
Moreover, the manufacturer should retain adequate oversight when development, hosting, testing, or support is outsourced.
Software Lifecycle Documentation
Regulators may expect traceability from intended use through requirements, risks, design, testing, release, and maintenance. Documentation can cover user needs, software requirements, architecture, coding controls, verification, validation, configuration, release approval, maintenance, and bug correction.
Because defects can arise from code, data handling, interfaces, dependencies, or later changes, test evidence should connect requirements and risks with acceptance criteria and results rather than rely on general assurances.
Clinical Evidence and Performance
SaMD manufacturers may need evidence that software performs safely and achieves its intended medical purpose. Depending on risk and claims, evidence can address scientific validity, analytical or clinical performance, verification, validation, accuracy, and other relevant measures.
Datasets should match the intended population and use context. Bias, weak reference standards, or unrealistic testing can undermine claims. Manufacturers should state limitations clearly and avoid promoting functionality beyond supporting evidence.
AI and Adaptive Model SaMD
AI does not automatically place software in a higher class. Nevertheless, AI-based SaMD raises additional concerns involving training and validation data, bias, generalisability, model performance, human oversight, explainability where relevant, and performance drift.
Adaptive models require particular attention because post-deployment changes can alter validated performance. Consequently, manufacturers need controlled evaluation of significant model modifications and monitoring of real-world performance.
Cybersecurity and Data Integrity
Cybersecurity forms part of device safety when compromise could affect availability, integrity, clinical output, or patient care. Relevant controls may include authentication, access management, encryption, secure updates, vulnerability management, logging, dependency monitoring, patching, data-integrity safeguards, and incident response.
Third-party libraries and cloud services can introduce additional vulnerabilities. Accordingly, cybersecurity records should connect identified threats with mitigations, verification, residual risk, and post-market monitoring.
Data Protection Is a Separate Obligation
Medical device authorisation does not satisfy every privacy obligation. Likewise, privacy compliance does not replace device approval. Developers should therefore treat device safety and data governance as separate compliance workstreams.
Technical Documentation for a SaMD Application
The submission package depends on device class and application type. Relevant documentation can include:
- intended use;
- product description;
- classification rationale;
- software architecture;
- risk management records;
- verification and validation reports;
- clinical or performance evidence;
- cybersecurity documentation;
- quality-system records;
- version information;
- labelling and instructions;
- change-control procedures; and
- post-market plans.
Technical documents should remain consistent with software functionality and commercial claims.
Digital Labelling and Instructions for Use
Software devices may present regulatory information digitally even without physical packaging. Depending on applicable requirements, users may need device identity, manufacturer information, intended purpose, instructions, warnings, version, operating limitations, and regulatory particulars.
Version identification matters because evidence relates to controlled releases. Digital information should remain accessible and should not exceed the authorised medical purpose.
Practical Regulatory Application Sequence
A sensible pre-market process generally involves:
- Define the intended medical purpose and claims.
- Determine whether the software meets the medical device definition.
- Distinguish SaMD from embedded or non-medical software.
- Establish the applicable device classification.
- Identify the competent licensing authority.
- Determine manufacturing or import requirements.
- Establish an appropriate quality system.
- Complete software lifecycle and risk documentation.
- Perform verification and validation.
- Develop clinical or performance evidence where required.
- Prepare labelling and technical documentation.
- Submit the applicable regulatory application.
- Respond to regulatory questions, audit, or inspection requirements.
- Obtain required authorisation before regulated commercialisation.
The precise process can vary according to class, activity, and application type.
Regulatory Review and Inspection
Regulatory review may assess quality systems, classification, risk management, development controls, validation, clinical evidence, manufacturer responsibility, and post-market arrangements.
Software does not necessarily follow the same physical-site inspection model as hardware. Audit or inspection requirements depend on the licensing route and device class, while outsourced development or hosting may require suitable oversight.
Software Updates and Change Control
Not every update has equal regulatory significance. Routine bug fixes, interface changes, or security patches can differ from changes affecting clinical functionality or intended use.
Significant changes may include new diagnostic claims, patient populations, algorithms, therapeutic recommendations, or medically actionable outputs.
Therefore, each release should undergo documented regulatory impact assessment. Depending on applicable requirements, a significant modification may require notification, amendment, further evidence, or another regulatory action.
Post-Market Compliance
Regulatory duties continue after commercial release. SaMD manufacturers should monitor complaints, software defects, adverse events where reportable, cybersecurity issues, field performance, and emerging risks.
Post-market processes may include:
- complaint investigation;
- corrective and preventive action;
- adverse-event reporting where applicable;
- field safety actions;
- cybersecurity updates;
- controlled software releases;
- recall or withdrawal procedures;
- post-market surveillance; and
- retention of required records.
A serious defect can affect many users simultaneously. Consequently, manufacturers need reliable mechanisms to identify affected versions, communicate safety information, and deploy controlled corrections.
Common Compliance Mistakes
Businesses entering regulated medical software commonly create avoidable risk by:
- assuming every health application is a device;
- assuming software-only products cannot require licensing;
- classifying software without reviewing intended use;
- confusing SaMD with embedded software;
- approaching the wrong licensing authority;
- failing to identify the regulatory manufacturer;
- using weak software risk-management processes;
- relying on insufficient verification or validation;
- making clinical claims without suitable evidence;
- neglecting cybersecurity documentation;
- allowing marketing claims to exceed authorised use;
- releasing major changes without regulatory assessment; and
- treating privacy compliance as a substitute for medical device regulation.
Practical Pre-Application Checklist
Before filing or commercialising, a business should verify:
- intended medical purpose and product claims;
- whether the software meets the medical device definition;
- SaMD or embedded-software status;
- applicable risk classification;
- licensing authority and application type;
- regulatory manufacturer responsibility;
- domestic manufacturing or import status;
- quality-system readiness;
- lifecycle and configuration documentation;
- risk-management records;
- verification and validation evidence;
- clinical or performance evidence;
- cybersecurity controls;
- labelling and instructions;
- post-market processes; and
- procedures for assessing software changes.
This checklist supports preparation but does not replace the Medical Devices Rules, applicable classifications, notifications, or regulatory directions.
Conclusion
Medical software businesses in West Bengal should begin regulatory planning with intended use rather than technology labels. Software that independently performs a medical function may qualify as SaMD, while administrative or general wellness software may not. Once device status is established, risk classification, licensing jurisdiction, manufacturer or importer responsibility, quality systems, technical evidence, validation, cybersecurity, labelling, and post-market controls shape the regulatory route. Careful change management remains equally important after commercial release.
FAQs
1. Is every healthcare software application treated as a medical device?
No. Healthcare software becomes a regulatory medical device because of its intended medical purpose, functionality, and claims, not merely because clinicians or patients use it. Administrative systems, scheduling tools, billing software, or general wellness applications may remain outside SaMD where they do not independently perform a regulated medical function.
2. What makes software qualify as SaMD?
Software may qualify as SaMD when it performs one or more intended medical purposes independently of medical-device hardware. Relevant functions can include diagnosis, monitoring, treatment support, or medically actionable analysis. The manufacturer’s intended use, claims, clinical function, and applicable medical device definition determine whether the software falls within the regulated category.
3. Does SaMD require medical device approval in India?
When software meets the regulated medical device definition, it can fall under the Medical Devices Rules, 2017 and applicable licensing requirements. The precise pathway depends on device classification and whether the business manufactures or imports the product. A developer should therefore establish device status and classification before selecting an application route.
4. Who regulates SaMD for a business based in West Bengal?
Jurisdiction depends on device class and activity rather than business location alone. Certain manufacturing functions can involve the relevant State Licensing Authority, while other device classes and import applications fall within central regulatory responsibility. Applicants should identify classification, manufacturing or import status, and licence category before determining the competent authority.
5. How is SaMD classified under Indian medical device rules?
Medical devices follow Classes A, B, C, and D according to risk-based principles. For software, intended use, clinical role, patient risk, and consequences of incorrect output can influence classification. A product should not be assigned a class solely because it uses AI, handles medical information, or operates within a hospital.
6. Does AI-based medical software require a different approval?
Artificial intelligence does not automatically create a separate licence or higher device class. However, AI-based SaMD may require stronger attention to training data, validation, bias, generalisability, model changes, human oversight, cybersecurity, and performance drift. Its regulatory pathway still depends on intended use, risk classification, and applicable medical device requirements.
7. Is clinical validation required for medical software?
Relevant clinical or performance evidence may be required to show that SaMD safely achieves its intended medical purpose. The evidence needed depends on device class, claims, and risk. Manufacturers may need to address scientific validity, analytical or clinical performance, verification, validation, dataset suitability, accuracy, limitations, and intended population.
8. Does imported medical software need regulatory approval in India?
Foreign-developed SaMD can require import authorisation when it falls within regulated medical device requirements and is supplied to the Indian market. The regulatory submission may involve foreign manufacturer information, quality-system evidence, technical documentation, classification, intended use, labelling, and post-market arrangements. Import requirements differ from domestic manufacturing licensing.
9. Do software updates affect an existing medical device approval?
They can. Routine bug fixes or cybersecurity patches may differ from major changes involving intended use, algorithms, clinical claims, patient populations, or diagnostic functionality. Manufacturers should assess each release through documented change control. Significant modifications may require regulatory action, but every software update does not automatically require an entirely new licence.
10. Is cybersecurity part of medical device software compliance?
Yes, where cybersecurity weaknesses could affect device safety, performance, data integrity, availability, or clinical output. Appropriate controls can include authentication, access restriction, secure updates, vulnerability management, logging, dependency monitoring, patching, and incident response. Cybersecurity should remain integrated with risk management and post-market monitoring throughout the software lifecycle.
