The line, and which side each component sits on
SAHI and BODH sit alongside an existing regulatory framework: the Central Drugs Standard Control Organisation and the Medical Devices Rules 2017. Software intended for diagnosis, prevention, monitoring or treatment of disease can constitute a medical device, and where it does, the obligations are statutory rather than recommendatory.
Most of the platform is coordination and record-keeping infrastructure and falls outside that definition. Some of it does not, and the programme's position is to classify conservatively rather than to argue the boundary.
| Component | Assessment |
|---|---|
| Coordination, communication, resource tracking, aid management, audit | Not a medical device. Administrative and logistical function with no diagnostic or treatment intent. |
| Clinical record management and exchange (BAEMS) | Health information system. Not a device in itself; subject to ABDM and DPDP obligations. |
| Clinical triage support | Assessed as potentially within scope as software as a medical device, depending on final claim and intended use. Treated as in scope for the purpose of controls, and the claim wording is constrained accordingly. |
| Demand and progression forecasting | Population-level planning tools, not patient-specific diagnostic or treatment software. Outside the device definition on current assessment. |
| Air ambulance dispatch recommendation | Logistics function. Clinical transportability assessment within it is made by a clinician, not by the platform. |
Intended-use wording determines regulatory classification. Marketing language that implies diagnostic capability can pull a component into device scope regardless of what it actually does. Claim wording across all RISE material is governed by CMP-09.