Choose quality software for Indian medical-device and IVD operations

A drug-manufacturing template may miss the device lifecycle

A company evaluates a quality platform using a pharmaceutical batch demonstration. The system handles deviations and approvals, but the team has not seen how it connects an installed analyser's serial number, service history and software configuration to a complaint.

Searching for medical device quality management software in India should begin with the products and operating decisions the system must support. A shared platform may be appropriate, but its records and workflows must represent medical-device and in vitro diagnostic (IVD) operations accurately. Familiar terminology is not evidence of that fit.

Use the applicable Medical Devices Rules, amendments and product-specific regulatory assessment as the starting point. The CDSCO Medical Devices Rules index should be read with the current Gazette notifications, not treated as a permanently complete consolidated checklist.

Establish product and market scope

List the products, intended uses, manufacturing activities, sites and markets in scope. Identify the responsible regulatory owner and the current classification and authorisation basis. Do not assume that all products sold by one company share the same requirements or traceability model.

Distinguish finished devices, IVD reagents, accessories, components and relevant software functions. The exact relationships require product knowledge. A purchasing code or generic product family may be too broad to support quality impact assessment.

Record which activities the organisation performs and which are outsourced. The software needs to represent the associated evidence and oversight responsibilities, including supplier or service-provider handovers. Outsourcing an activity does not make its records irrelevant to the manufacturer's quality workflow.

Keep the quality platform's intended use explicit

Describe what the proposed software does: control documents, manage nonconformances, coordinate changes, maintain training evidence, support traceability or another defined function. Then identify which outputs users rely on to make decisions.

Separate this assessment from the regulatory status of software that is itself a medical-device function. A quality management system (QMS) tool and software used for a medical purpose can require different analyses. The intended function and claims need specialist assessment; the product's name or use by a healthcare company is insufficient.

CDSCO's 2026 medical-device-software guidance provides awareness material on this distinction and expressly directs readers to statutory provisions for professional use. Use it as context, not as a replacement for the applicable rules. CDSCO medical-device-software guidance.

Model the records before comparing modules

Identify the objects the business needs to connect: product and revision, design evidence where applicable, manufacturing lot, component lot, individual serial, installation, service event, complaint and corrective action. Not every product needs every object, but the chosen relationships should be deliberate.

Avoid forcing all these relationships into a free-text batch field. Structured identity makes targeted retrieval possible; free-text narratives can then explain the context rather than carry the entire traceability model.

Worked example: reagent lot and analyser serial

Consider an illustrative IVD operation supplying reagent lot R240 and analyser serial A118. The reagent lot has manufacturing, test and distribution records. The analyser has an individual installation, configuration and service history.

A complaint references both the reagent and the analyser. The quality team needs to inspect their relationship at the relevant time without assuming that the complaint proves a problem with either one. A useful system retrieves the lot evidence and serial-specific history together while preserving their separate identities.

Suppose A118 received a software configuration change after the reported event. The investigation needs the configuration that applied when the event occurred, not only the current value. Overwriting the serial record would make that reconstruction difficult.

Suppose R240 was supplied to several locations. The team may need an authorised distribution-impact assessment, while a serial-specific service action may concern only A118. The system should support the relevant scope instead of treating every linked object as automatically affected.

The example does not diagnose an analyser or establish a product defect. It demonstrates the record relationships needed for qualified investigation and subsequent decisions.

Connect nonconformance, investigation and change

A shared quality platform can support several related processes, but each should retain its own purpose and decision. A nonconformance records a problem; an investigation assesses evidence; a corrective action addresses an established cause; a change controls an alteration to an approved state.

Define how these records link and which conditions govern their closure. Completing a change implementation should not automatically establish that the corrective action was effective. Conversely, closing an administrative task should not close a product-impact assessment.

Ask the supplier to demonstrate a problem spanning manufacturing and service. Inspect ownership, evidence requests, escalation and the handling of conflicting information. The platform should make the authorised decisions visible without substituting a generic workflow state for a technical conclusion.

Preserve revision and configuration history

For products with relevant design or configuration records, define how versions become effective and how the organisation identifies the version used for a particular unit or lot. A current master document alone may not explain historical production or servicing.

Test a change that applies prospectively, a correction to an earlier record and a field update to selected serials. Those events have different meanings. The system should preserve applicability, authorisation and actual implementation evidence for each.

Connect the controlled change to affected instructions, training, suppliers, tests and service arrangements as applicable. The quality owner should be able to distinguish an assessed non-impact from a dependency nobody reviewed.

Maintain current regulatory applicability

The software requirements should reference a dated, reviewed applicability assessment. For example, G.S.R. 744(E), dated 14 August 2026, adds QMS wording to specified provisions in rules 19H and 19J. It should not be reduced to a broad claim that one software package satisfies every Class A obligation. G.S.R. 744(E).

G.S.R. 743(E) addresses, among other matters, labelling for outsourced sterilisation. Where relevant, the regulatory owner should assess the resulting supplier, label and record dependencies. G.S.R. 743(E).

These are examples of why current applicability matters. They are not a complete legal checklist or a substitute for assessing the actual product, activity and market.

Use traceability standards with their proper meaning

Product identification, serialisation and event standards can support interoperability, but they do not independently establish the organisation's regulatory obligations. Define the identifiers and relationships required for the actual workflow, then assess the appropriate technical standard.

The serialisation and aggregation guide explains related event concepts. For devices, assess the applicable product-identification requirements separately rather than copying a drug export implementation unchanged.

Test a partial shipment, a returned unit and a service replacement. Confirm that the platform can distinguish the original item, replacement and their histories. Aggregate counts may reconcile while the individual serial relationship remains wrong.

Assess software assurance within scope

FDA's February 2026 computer software assurance guidance addresses software used in medical-device production and quality management systems. It is US guidance for that stated scope, not a universal waiver of validation or an Indian product approval. FDA computer software assurance guidance.

The organisation should define intended use, assess consequences of failure and select suitable assurance activities under its applicable requirements. Supplier evidence can contribute, but the implemented configuration, integrations and user decisions still need an appropriate assessment.

The computer-system validation guide provides a practical starting point for that lifecycle work. Include meaningful failure scenarios rather than testing only whether forms save successfully.

Demonstrate the difficult paths

Give suppliers the reagent-and-analyser scenario, then add an incorrect serial entry, a delayed service update and a reopened quality issue. Ask an authorised reviewer to reconstruct the history and identify the current outstanding decisions.

Test permissions for manufacturing, service, quality, regulatory and external partners. Review exports, attachments and administrator access as well as screen-level controls. A supplier technician may need a service task without needing unrestricted access to the entire quality record.

Inspect reporting denominators. A dashboard showing closed actions can be misleading if it excludes reopened items or treats every task as equivalent. Reports should explain their scope, cut-off and included states.

Add an affected-population exercise to the demonstration. Give the team one component lot used across several production orders and ask it to identify the associated finished units and distribution records. Then introduce an incorrect relationship and verify how the team detects and corrects it. The result should include both the proposed affected population and the evidence supporting that scope, ready for the authorised quality assessment.

Plan integration and migration deliberately

Assign authoritative ownership for products, lots, serials, quality decisions and service events. The ERP, MES, LIMS and QMS architecture guide explains how to divide record responsibilities across platforms without creating competing status authorities.

For migration, map historical identities, revisions and relationships before loading records. Verify representative histories, including retired products and replaced serials. Matching file or row counts cannot prove that the resulting traceability remains useful.

Define recovery when an interface fails. A delayed status should be visible with its source and age, and replay should preserve order and identity. The quality system should not silently replace a later restriction with an older status update.

Compare the operating model as well as the software

Estimate configuration, migration, assurance, integration, training and recurring administration alongside licence costs. Include the effort needed to assess supplier releases and maintain product or market requirements. A highly customised workflow may carry substantial ongoing maintenance.

Agree export and retention arrangements before implementation. Test whether an authorised reviewer can use retained records outside the active workflow, including attachments and relationships. Supplier exit should be a planned lifecycle event, not a future emergency.

Choose a pilot covering a manageable product family with both routine and exceptional work. Scale when users can perform their tasks, reviewers can reconstruct decisions and the team can maintain the configuration responsibly.

Summary and next actions

Device and IVD quality software should reflect the product lifecycle and the actual regulatory and operating scope. Lot, serial, configuration and quality relationships provide the evidence needed for useful decisions.

• Establish product classification, markets, activities and software intended use with the responsible owners.
• Map one reagent lot and analyser serial through manufacturing, distribution, service and quality records.
• Test changes, incorrect identities, restricted access and interface recovery in supplier demonstrations.
• Approve a bounded pilot with assurance, migration, lifecycle cost and exit requirements included.