CDSCO Software as a Medical Device: A Buyer's Class Check

The February 2020 notification that brought all medical devices under the Drugs and Cosmetics Act 1940 defines a medical device broadly, and the definition reaches software intended by its manufacturer for diagnosis, prevention, monitoring, treatment or alleviation of disease. There is no carve-out for software because it runs in a browser, sits on a cloud server outside the hospital, or is described in the brochure as decision support. What matters is the purpose the manufacturer assigns to it, expressed in labelling, instructions for use and promotional material.

That last item catches a lot of products. A vendor may write a cautious intended-use statement in the manual and then market the same product as detecting a condition. Regulators treat promotional claims as evidence of intended use, and reasonably so. If the website says the tool identifies tuberculosis while the manual says it is a research aid, the mismatch is the vendor's problem until you deploy it in a screening camp, at which point a good part of it becomes yours.

Software that clearly falls outside is software that does not act on individual clinical information for a clinical purpose: rostering, billing, inventory, queue displays, dictation that only produces text for a clinician to write with. The boundary gets thin quickly, though. A discharge-summary generator that reformats what a clinician typed is a different object from one that infers a diagnosis from the chart. Write down which side of that line each tool in your estate sits on, and record why you decided that.

The Rules use a four-tier risk classification: Class A for low risk, Class B for low-moderate, Class C for moderate-high and Class D for high risk. The class drives who licenses the product and how much scrutiny it attracts. Class A and B manufacturing sits with the State Licensing Authority, while Class C and D sits with the Central Licensing Authority. Import licensing runs centrally regardless of class. The higher the class, the heavier the evidence and audit burden carried by the manufacturer.

For software, the class usually tracks two things: how serious the clinical situation is, and how much weight the output carries in the decision. A tool that reorders a radiologist's worklist without changing what eventually gets reported is a different proposition from one that returns a normal result on which no human read follows. CDSCO publishes classification lists covering device categories, and where a specific software product is not covered by a published entry, the manufacturer proposes a class and the licensing authority takes a view.

Buyers sometimes reach instead for the IMDRF risk framework, which categorises software by the seriousness of the healthcare situation and the significance of the information it provides to that situation. It is a genuinely useful way to think, and it is worth asking a vendor to place their product on it. It is not the Indian legal test, and a vendor who answers your classification question only with an IMDRF grid has not actually answered it.

A manufacturing licence in Form MD-5 covers Class A or B devices; Form MD-9 covers Class C or D. An imported product reaches the market against an import licence in Form MD-15, held by an Indian authorised agent. Each of these documents names specific products. It is a licence for a device with a stated name and a stated intended use, not a certificate awarded to a company. A vendor holding a genuine licence for one module may quite legitimately hold nothing at all for the module you are being sold.

The licence also does not certify accuracy. It attests that the manufacturer has met the applicable requirements, including the essential principles of safety and performance, and that the licensing authority accepted the evidence submitted. It is a floor, not a benchmark. Two licensed products at the same class can perform very differently on your population, which is exactly why the licence check and the clinical evaluation are separate exercises that both have to be completed.

A licence is also a live object rather than a historical fact. It has a validity position, it can be suspended, and it is tied to a named manufacturing site subject to inspection or, for Class A and B, audit by a Notified Body. A licence copy dated three years ago proves that something was true three years ago, which is a weaker statement than most procurement files assume it to be.

Ask for the licence number and check it against what CDSCO publishes rather than accepting an emailed document. A PDF is a picture of a claim. The useful discipline is to treat the regulatory document exactly as your materials department treats a drug licence: number recorded, source of verification recorded, date of verification recorded, and a diary entry to check again at renewal. If your biomedical engineer maintains an equipment file for every infusion pump, clinical software belongs in the same register.

Two verification traps are worth naming out loud. The first is the certificate that is not a licence: an ISO 13485 certificate, a CE marking, an FDA clearance letter or a registration receipt. All are meaningful documents in their own context. None of them is permission to place that device on the Indian market. The second is the group-company shuffle, where the licence sits with a related entity while the contracting party is a different company with no regulatory standing at all.

When you cannot resolve a question from documents, put it in writing to the vendor and keep the answer. A signed statement of regulatory status in the contract, with an indemnity attached, is not a substitute for a licence. It does convert an ambiguity into a liability that someone has accepted in writing, which is a materially better position than a verbal assurance in a demonstration room.

Registration and licensing were introduced in stages, with transition timelines that differed by class, and some products in the market still trade on documents from that transition rather than on a full licence. Ask which one you are looking at. A registration is not a licence, and a vendor who cannot explain the difference for their own product has told you something useful about how they run their regulatory function.

The more common problem is scope creep after purchase. You buy a tool for chest radiograph triage; eighteen months later the vendor has added three new findings, a paediatric mode and a report generator, and none of that was in the intended use you checked. The regulatory position of the product may have changed without anyone telling you. Material changes to a licensed device generally require the licence holder to go back to the licensing authority, and your contract should oblige them to notify you when that happens.

The mirror image is scope creep on your own side. A tool licensed for triage gets used as a final read on a thin night shift; a screening aid gets quoted verbatim in a discharge summary. That is not a vendor failure and no licence will prevent it. It is a governance failure, and it happens to be the one your own committee can genuinely control.

The cheapest place to run this check is before the technical evaluation, because it removes products from the shortlist at almost no cost. Build it into the tender document as a mandatory regulatory annexure asking for classification, licence details, intended use and change-notification commitments, evaluated pass or fail before anyone scores a single feature. Vendors respond to what is scored, and a regulatory annexure that carries no marks will be answered with a brochure.

Keep the evidence where an assessor will look for it. NABH assessment and any medico-legal inquiry both work from files, and a regulatory file for clinical software that lives inside somebody's email thread does not exist in any practical sense. Hold it with the same discipline as an equipment file: document, verification note, date, owner, review date. HealUDoc activity logs can carry the deployment trail alongside the clinical record, so you can show which version of a tool was live on a given date.

Finally, accept that this check tells you about permission and not about performance. A correctly licensed product can still be wrong on your patients, and an impeccable regulatory file is not clinical validation. The two questions are separate, they are answered by different people inside the vendor organisation, and a purchase decision that answers only one of them has almost always answered the easier one.