Built for the conditions Indian public hospitals actually run in — radiologist shortages, ageing equipment, connectivity that comes and goes, and patient data whose every movement has to be accounted for.
Project HealthX is TrioMav Tech's healthcare research programme. Its first system, Vaidya-RAD, is radiology infrastructure being built for Indian public hospitals — designed to draft reports and prioritise worklists under a radiologist's supervision, on equipment and connectivity that most commercial AI refuses to support. Nothing is built yet. We are at Phase 0, and both models are still being trained.
Assistive, not diagnostic — the radiologist always decides.
India does not have a radiology software problem. It has a radiologist problem — and most AI products are built for a country that doesn't have one.
Approximate radiologist-to-population ratio in India
Source: Radiological & Imaging Association of India (RIAI)
District hospitals can acquire images far faster than they can report them. Studies wait days for a radiologist who may be covering several facilities at once. The bottleneck is interpretation capacity, not machines.
Public hospitals run ageing CR and DR units that emit non-conformant DICOM — missing tags, inconsistent pixel spacing, malformed headers. Most commercial AI simply refuses these studies, which excludes exactly the hospitals that need help most.
Cloud-first tools assume a stable link to a data centre. In a district hospital, the internet and the power are both variables. Software that stops working during an outage is software that will not be trusted.
Radiology AI is largely trained, validated, and priced for well-resourced Western hospitals with clean data pipelines and sub-specialist readers. Dropped into an Indian public hospital, the assumptions break before the model does.
What we are building is a drafting pipeline, not a verdict machine. Every stage is designed to produce something a radiologist can inspect, correct, or overrule, with their corrections coming back as training signal. None of it is running in a hospital yet.
A study arrives from the modality or PACS. Headers are parsed, the body part and modality identified, and non-conformant DICOM repaired rather than rejected. This layer is the furthest along — it is the part that does not depend on a finished model.
Our own vision model, in training rather than finished. A radiology-pretrained backbone produces an image representation, and per-pathology heads we are training on it are designed to return calibrated findings with confidence — never a single yes/no verdict. Intended to run on hospital hardware.
Structured findings with per-item confidence, plus attention heatmaps showing which regions drove each finding. Where the model cannot see enough to be useful it should say so rather than guess — a design requirement we intend to hold ourselves to, and one worth judging us on later.
Our own language model, also still being built. It is designed to turn structured findings into readable prose in standard reporting format, composing only from what the vision stage produced rather than introducing observations of its own. It will run on our inference server rather than the imaging workstation, which makes this the one stage that needs a network path.
A structured draft report, waiting in the radiologist's worklist before they begin reading. A starting point, explicitly marked as unverified AI output.
The radiologist reads the study, edits the draft, and signs. Nothing will reach a patient record without that signature. The clinical decision never leaves the clinician — that constraint is fixed regardless of how good the models eventually get.
Every edit a radiologist makes is signal: what the model missed, what it over-called, what it phrased wrongly. Those corrections become training data for the next iteration — which is why the data foundation, not the model, is the hard part, and why it is the part we are doing first.
Assistive, not diagnostic — the radiologist always decides.
Plenty of teams can train a detector. What decides whether radiology AI survives contact with a district hospital is everything around it — the ingest, the degradation behaviour, the data path, the integration surface. We would rather own that than rent it, which is why we are building the models as well as the plumbing.
Ageing CR and DR equipment emits DICOM that violates the standard in small, consistent ways. Rather than reject those studies, the ingest layer repairs headers, infers missing attributes, and normalises pixel data, so a twenty-year-old machine becomes a supported input instead of an error message.
The system is designed to adapt to the hardware and network it finds. Image analysis is meant to run locally — full precision on a GPU, quantised on a plain CPU box. When the network or the report server is unreachable it should keep analysing and prioritising studies, drop the drafted narrative, and queue records to reconcile on recovery. A tool that stops working during an outage gets abandoned after the first one.
We are building our own models rather than renting someone else's, so no general-purpose commercial AI provider will sit in the clinical path and the deployment can be shaped to the institution. A hospital with its own server capacity would run the whole pipeline in-house; one without can lean on ours; one that wants custody without the hardware cost gets a dedicated quantised instance. De-identification is applied at ingest in every case — DPDP Act 2023 by design, not retrofitted once a procurement review asks the question.
Designed to fit public hospital reality: existing PACS and HIS, ABDM and FHIR interoperability, district-level administration, and procurement that must justify every rupee. The integration surface is the product.
Where the model will run is a deployment decision, not a fixed property of the product. It depends on what the hospital already has — and we would rather fit the institution than make it buy hardware to fit us. These are the three shapes we are designing for; none is deployed anywhere yet.
If the hospital already has server capacity, the whole pipeline would run inside their network — vision and drafting both. Nothing crosses the boundary, and the institution keeps physical custody of everything.
Most public hospitals have no spare GPU capacity and no budget line to create it. Image analysis would still run on their hardware; the drafting model on ours, receiving de-identified findings and study data for that case only. No capital expenditure on the hospital's side.
Where a hospital wants its own deployment but not the cost of full-precision hardware, we would provision a dedicated instance running quantised models sized to their case volume. Lower hardware requirement, and the trade-off that makes will be stated rather than hidden.
We are at the beginning, and we would rather say so. Radiology AI has a long history of impressive benchmark numbers that dissolve on contact with a real hospital. We are building the data foundation first.
De-identified imaging cohorts from Indian hospitals, radiologist-labelled to a controlled vocabulary, with leakage-free patient-level splits and an annotation tool built for clinician time. This is the current work.
Models trained and validated on Indian data, reported against external datasets from institutions that contributed nothing to training. Numbers published only when they survive that test.
Worklist prioritisation and draft reporting inside a real radiology department, under supervision, measured against the department's existing standard of care.
Regulatory filing, multi-site deployment across a district or state health system, and post-market performance monitoring.
Nothing is built yet. There is no deployed product, no running pilot, no clinical validation — and the models themselves are still being trained. What exists today are research prototypes on public benchmark datasets, which say nothing about Indian patients on Indian equipment. We therefore publish no accuracy figures at all. When we have numbers that survive validation on data from institutions that contributed nothing to training, we will publish those instead.
White papers, technical notes, and validation protocols. We publish method and reasoning before results, and results only once they survive external validation.
Phase 0 output publishes here first: the dataset governance and de-identification protocol, the validation protocol we intend to be held to, and a technical note on DICOM conformance in Indian public hospital equipment.
We would rather publish the protocol before the results, so the standard we are judged against is on the record in advance.
For a government health system, this is the first question, not the last one.
Patient-identifying DICOM attributes are removed following the PS3.15 Annex E confidentiality profile before any processing, storage, or embedding — applied at the earliest pipeline stage, not as a post-processing pass.
Image analysis is designed to run on hospital hardware. Report drafting is the only stage that can transmit, and whether it does at all depends on the deployment — on a hospital-hosted install it would never leave the building. Where it does transmit, what is sent are de-identified findings and image data for that study, to a named endpoint fixed in the deployment agreement, never to a general-purpose commercial AI provider.
Health data is a special category under India's Digital Personal Data Protection Act 2023. Purpose limitation, privacy by design, and breach notification obligations were design inputs rather than compliance paperwork added later.
The de-identification process is documented and open to audit by the contributing institution, with written certification of de-identification for any data shared under a research agreement.
Project HealthX is TrioMav Tech's healthcare research effort. TrioMav is structured as a research lab with a services business attached: the services engine funds the research, which means the research does not have to reach a demo before it is ready. We are building systems intended to run for decades inside public institutions, and that timescale is only affordable because we are not dependent on this product to make payroll.
triomavtech.comIf you run a radiology department, work in a state health system, or are a radiologist willing to shape how this is built — we want the conversation now, while the design is still open. We are not selling anything yet.