SAKSHAM सक्षम

SAKSHAM expands to Soldier Acclimatisation, Kinetic Stress, Health Analytics and Monitoring. The Sanskrit word सक्षम means capable, competent and able to perform - which is precisely the judgement the platform supports: does this person appear physiologically capable of performing the assigned task safely.

No. SAKSHAM is explicitly a software layer. We own the canonical data model, the adapter contract, the intelligence engine and the decision-support workflows. Any hardware whose data can be lawfully accessed becomes a supported source by writing one adapter, and nothing downstream changes when the hardware changes.

Any device family for which an adapter exists. Supported ingestion modes include real-time BLE to an edge gateway, store-and-forward overnight sync, vendor REST APIs, MQTT field gateways, file imports such as CSV, JSON and EDF, database imports from existing medical or research systems, and manual medic entry. The adapter SDK ships with schemas, interfaces, fixtures and a conformance suite so a partner OEM can write a conformant adapter without our involvement.

No. SAKSHAM is human-in-the-loop decision support. It surfaces earlier awareness and better prioritisation with explainable evidence. The clinical decision stays with the medic and the medical officer, and every consequential action requires a human.

At altitude, two people at the same height respond very differently depending on acclimatisation history, fitness, sleep, ascent rate, infection, hydration, workload and peripheral perfusion. A platform that only alerts below a fixed number will miss progressive decline above that number and will fire constantly on sensor artefacts. SAKSHAM learns each person's own normal per context - altitude band, sleep or wake, rest or exertion - and judges the trend against it.

A signal-quality gate runs before anything is interpreted, grading every observation as Valid, Valid with caution, Low confidence, Invalid or Missing. A rule that requires Valid data does not fire on Low confidence data - it raises a device-check advisory instead. This is the control that keeps medics reading the alerts in month six rather than uninstalling the platform in week one.

Yes. Core runs in two shapes from one codebase. An edge node at the unit handles local device connectivity, at least 24 hours of buffering, locally evaluated urgent rules and a local medic dashboard with encrypted storage and store-and-forward sync. Urgent alerting never depends on the central node. If the link is down, the medic dashboard at the edge keeps working, and reconnect is lossless.

Baseline confidence is a visible, first-class output, not a hidden variable. With no history the platform applies population thresholds and states that plainly. Historical backfill collapses this cold start: prior device exports, medical examination records, previous altitude induction data or digitised paper logs are imported through the same adapters and seed the baselines immediately.

No. The command view shows aggregate readiness - Green, Amber, Red and Grey counts, personnel under medical management, data coverage and unit trend. It does not show diagnoses, medical notes or raw vital signs unless policy explicitly authorises a named role. Command can see readiness; only medical authority can change it, and every override is attributed with a reason recorded.

Punitive and unrelated use is explicitly prohibited and enforced as a product requirement, not a policy footnote. Analytical pipelines use pseudonymous identifiers by default, re-identification requires separate authorisation and is itself audited, and access is evaluated per read against organisational role and medical need-to-know. If personnel believe the platform is surveillance, wear compliance collapses and the data disappears - trust is an input to data quality.