What kind of medical AI can an ordinary hospital actually use?
I mean a hospital that needs useful tools without assuming a large, fully paired research dataset, a specialist AI engineering team, or access to every advanced assay.
My clinical background shapes the question I bring to AI research:
When samples are scarce, modalities are incomplete, and platforms differ, should we pursue more complex models—or organise evidence more explicitly and report the boundaries of what the model can support?
I don't think these are mutually exclusive choices. More complex models can be useful. But each added component should earn its place through reproducible benefit under the conditions in which it will be used.
What I mean by constrained AI
Here, “constrained” refers to the conditions around the model: limited samples, incomplete modality pairing, compact representations, platform differences, and finite computing and maintenance resources. It does not refer to restrictions on what a chatbot is allowed to say.
These constraints can occur together. A model may have little labelled data, only some of the expected inputs, and measurements produced by a platform different from the one used during development.
That changes the engineering question. We need to ask what evidence remains usable, what changes when an input disappears, and when a model's earlier validation no longer applies.
A research example from our preprint
Our preprint, Restricted Multimodal Oncology AI: Role-Aware Evidence Organisation and Cross-Domain Transfer Boundaries, explores this problem in retrospective oncology cohorts through Role-Aware Evidence Engineering (RAEE) and its BLF-Net-MUL implementation.
The design starts by assigning evidence roles before evaluating fusion:
| Input | Intended evidence role |
|---|---|
| Compact transcriptomic features | Molecular evidence |
| RNA-derived pathway features | Functional molecular context |
| Low-dimensional pathology-derived features | Phenotypic context |
| Clinical variables | Patient-level context |
The pathway features are derived from RNA; they are not an independent omic measurement. The pathology inputs are compact features, not whole-slide foundation-model embeddings.
The question is whether combining these sources helps under a specified condition—not whether more modalities must always be better. Component analyses and external transfer tests are useful precisely because they can reveal where a mechanism stops helping.
This is a research example, not a demonstration that our system is ready for routine hospital use. The linked manuscript is a preprint and has not been peer reviewed. Retrospective classification and cross-repository evaluation do not establish prospective clinical benefit or reliable deployment at a new hospital.
What I would want before ordinary hospitals rely on a system
These are the requirements I would put on a development and evaluation plan:
- Obtainable inputs. State exactly which measurements are required and whether the intended hospital can obtain them. Test missing-input scenarios explicitly; supporting incomplete data in a research protocol is not a guarantee of safe operation with any missing modality.
- Affordable operation. Measure inference, storage, integration, maintenance, and staff time. Compact inputs alone do not establish a low total cost.
- Evidence from the destination setting. Evaluate relevant equipment, laboratory platforms, patient groups, and workflows. A source-cohort score cannot stand in for local validation.
- A defined response to uncertainty. Specify when the system should flag insufficient evidence, request review, or withhold an output. These behaviours need validation too.
- Traceable outputs. Let a reviewer see which inputs were present, which model version produced the result, and which limitations apply.
- A place in clinical work. Define who reviews the output, what action it is intended to inform, and how errors, drift, and overrides will be monitored. Any necessary institutional and regulatory review belongs in that deployment process.
These are proposed requirements for usable medical AI. They are not a list of capabilities already established for BLF-Net-MUL.
Complexity should answer a concrete need
I would like to see model comparisons answer a practical question: does this additional complexity improve a relevant outcome enough to justify its data, compute, and maintenance requirements?
A simpler model still needs rigorous validation. A larger model may be the better choice when the evidence supports it. Neither model size nor an interpretable-looking report establishes safety on its own.
In our research, the intended output stops at bounded evidence preparation for expert review. It is not an autonomous diagnosis or treatment recommendation. Explicit boundaries make a claim easier to examine; they do not eliminate clinical risk.
What would you require?
If you build medical AI, maintain hospital software, or work with clinical teams, I would value your perspective:
- What would make an AI system usable in a hospital without a dedicated AI infrastructure team?
- Which failure matters most in your setting: a missing input, platform shift, poor calibration, an opaque output, or maintenance burden?
- What evidence would convince you that added model complexity is worth it?
What should a medical AI system have to demonstrate before an ordinary hospital can reasonably rely on it?
Please keep examples free of identifiable patient information.
Preprint: Hu et al. Restricted Multimodal Oncology AI: Role-Aware Evidence Organisation and Cross-Domain Transfer Boundaries. doi:10.21203/rs.3.rs-10194336/v1.
Disclosure: I am a co-author of the cited preprint. This post was prepared with AI writing assistance from our manuscript and the discussion above. It presents research questions and design priorities, not clinical advice or a claim of deployment readiness.
Top comments (0)