Models are easy to announce. They are harder to find, harder to reuse, and much harder to trust.
That is the uncomfortable starting point for radiology AI. The field is not suffering from a shortage of algorithms. It has models for lesion detection, segmentation, image reconstruction, report generation, modality-specific classification, and increasingly fashionable foundation-style systems. The difficulty begins one step later, when someone asks a boring but lethal operational question: Where is the model, what does it actually do, and can we use it without conducting an archaeological expedition through GitHub, supplementary PDFs, broken links, and optimistic abstracts?
OpenRad, introduced in the paper “OpenRad: a Curated Repository of Open-access AI models for Radiology,” is an answer to that unglamorous problem.1 It aggregates 1,694 open-access radiology AI models, standardizes their metadata using RSNA AI Roadmap and RadLex-style fields, verifies linked repositories for code, pretrained weights, and demos, and then exposes the result through a searchable web interface.
That description sounds like “a database.” It is not wrong. It is just too small.
The more useful reading is that OpenRad is a mechanism for turning scattered research artifacts into a model-intelligence layer. It does not prove that a radiology AI model is clinically safe. It does not remove the need for validation, regulation, local workflow testing, or procurement judgment. What it does is more basic and, in practice, more often missing: it makes the model landscape legible.
And legibility, unlike another 0.3-point improvement on a benchmark, can actually change how organizations make decisions.
A GitHub Link Is Not a Deployment Plan
A common misconception deserves to be killed early: “open access” does not mean “ready to use.”
In software-heavy AI research, a paper may include a repository link, but that link can point to incomplete training scripts, missing weights, undocumented dependencies, old environments, partial notebooks, or code that worked on one graduate student’s machine under a full moon. Healthcare adds another layer of difficulty. Even if the model runs, a hospital or vendor still needs to know modality, clinical task, intended use, dataset context, validation strategy, performance metrics, limitations, and whether the model has been evaluated beyond the training population.
OpenRad starts from this gap. The authors searched PubMed, arXiv, and Scopus for radiology and imaging AI papers up to December 2025. The initial search retrieved 5,239 records. After removing 985 duplicate records by DOI and excluding papers that were not focused on radiology AI, lacked open-access code or model availability, or were dataset-only entries, the final repository contained 1,694 unique articles.
That funnel matters because it defines the object being curated. OpenRad is not merely cataloguing radiology AI publications. It is trying to catalogue radiology AI models with some public route to use.
The difference is operationally important:
| Item | What it gives you | Why it is insufficient alone |
|---|---|---|
| A paper title | Topic and claimed contribution | Not enough to judge usability |
| A benchmark score | Performance in a reported setting | Often not portable to local data |
| A repository link | Possible implementation path | May lack weights, demos, or documentation |
| A model record | Structured comparison fields | Still needs validation and clinical review |
| A curated repository | Searchable decision layer | Useful for discovery, not a substitute for deployment assurance |
OpenRad’s value begins when it refuses to treat these as the same thing. A paper is a claim. A repository is an artifact. A model record is a structured object. A deployment candidate is something else again. Confusing these categories is how organizations end up calling literature review “AI strategy,” which is a charming way to burn time.
OpenRad’s Real Contribution Is the Assembly Line
The paper’s most important contribution is not the number 1,694, although the scale is useful. The real contribution is the pipeline that turns unstructured research into structured model records.
The workflow has several layers.
First, the authors construct the literature corpus from PubMed, arXiv, and Scopus. That gives coverage across medical literature, preprints, computer science venues, and conference proceedings. This matters because radiology AI does not live neatly inside one publishing ecosystem. Some clinically oriented systems appear in medical journals; many model-centric contributions circulate through computer science channels before clinical adoption is even imaginable.
Second, the authors map model information into the RSNA AI Roadmap reference schema, using RadLex-style standardization for imaging modality and clinical subspecialty. The extracted fields include modality, clinical subspecialty, intended use, architecture, performance metrics, dataset details, validation strategy, and repository-related information.
Third, they use a locally hosted open-source LLM, gpt-oss:120b via Ollama, with Python and the instructor library to populate structured JSON records. When full-text PDFs are available, the system uses them; otherwise, it relies on abstracts. This is a practical design choice, not a philosophical manifesto about LLMs. Large-scale curation needs automation, and schema-constrained extraction is one of the less silly ways to use language models.
Fourth, the system interrogates linked repositories. It checks for the presence of pretrained weights or ready-to-use implementations such as demos. This is where OpenRad moves beyond bibliographic indexing. It asks whether the research artifact contains something closer to usable material.
Fifth, ten expert reviewers manually verify the generated records. The reviewers include AI researchers at PhD, MSc, and faculty levels. They correct errors and classify corrections as minor or major. Manual review is not decorative here. It is the quality-control layer that prevents “LLM-generated database” from becoming a polite synonym for “confident spreadsheet of possible nonsense.”
The mechanism can be summarized like this:
| Pipeline layer | Paper’s implementation | Operational consequence |
|---|---|---|
| Corpus construction | PubMed, arXiv, and Scopus search through Dec. 2025 | Reduces platform fragmentation |
| Eligibility filtering | Excludes non-radiology AI, no-code/no-model, and dataset-only records | Keeps the repository focused on reusable models |
| Schema standardization | RSNA AI Roadmap and RadLex-aligned fields | Makes records comparable and machine-readable |
| LLM extraction | Locally hosted gpt-oss:120b with structured prompts | Scales curation beyond manual entry |
| Repository inspection | Checks repositories for weights and demos | Separates publication claims from usable artifacts |
| Expert review | Ten reviewers verify and correct records | Anchors automation in domain oversight |
| Web interface | Search, filters, badges, detail pages, live statistics | Converts metadata into discovery infrastructure |
This is why a mechanism-first reading is better than a normal paper summary. The business lesson is not “someone built a website.” It is that AI adoption often depends on boring intermediate infrastructure: the conversion of scattered model claims into structured, inspectable, reusable records.
The Model Record Is the Product
OpenRad’s web interface exposes models through keyword search and filters for resource availability, imaging modality, radiology subspecialty, use case, and demo availability. Each model appears with badges showing verification status, modality, subspecialty, and saved-weight availability. A detailed model page provides architecture, dataset information, performance metrics, known limitations, external links to code and papers, and links to demos where available. For the subset of 27 models with existing RSNA ATLAS model cards that met inclusion criteria, OpenRad includes links to those cards.
This is a subtle but important shift. The product is not only the repository. The product is the record.
A good model record compresses due diligence. It gives a researcher, clinician, vendor, or evaluator a structured starting point:
- What task does this model claim to perform?
- Which modality and subspecialty does it address?
- What architecture family does it use?
- What dataset and validation strategy are reported?
- Are weights available?
- Is there a demo?
- What limitations did the authors report?
- Has the entry been verified?
None of those answers, alone, certifies clinical usefulness. Together, they reduce search cost.
For business readers, this is the part worth noticing. In many AI-heavy industries, the next layer of value may not come from training yet another model. It may come from maintaining structured inventories of models, datasets, workflows, validation evidence, licenses, deployment constraints, and real-world performance signals. Radiology is simply a sharp example because the stakes are high and the artifacts are scattered.
OpenRad also includes a community submission and curation mechanism. Users can submit new models, suggest corrections through a “Verify & Edit” mode, and flag problematic records. The authors state that community submissions and suggested corrections are subject to expert verification before inclusion.
That governance loop is not a side feature. Static AI repositories decay. Links break. Dependencies rot. New papers appear. Models are superseded. If the maintenance layer is weak, today’s useful catalogue becomes tomorrow’s haunted archive. Very academic, very open, very dead.
The Stability Test Checks Extraction Reliability, Not Clinical Truth
The paper includes an intra-LLM stability assessment on 225 randomly selected papers. The authors repeatedly process records and compare later generations against the first generation using lexical similarity metrics: difflib sequence matching, Levenshtein ratio, and Jaccard similarity.
This is not an ablation. It is not a clinical validation test. It is a reliability check on the automated extraction pipeline.
The results are intuitive and useful. Structured fields are more stable. Free-text fields vary more.
| Field | Levenshtein ratio | Interpretation |
|---|---|---|
| Title | 100.0% ± 0.0% | Fully stable |
| Authors | 91.3% ± 27.7% | High stability, but with variance |
| Repository link | 90.5% ± 25.2% | Mostly stable |
| Affiliation list | 88.8% ± 29.3% | Fairly stable |
| Sustainability: training time / hardware | 88.6% ± 27.0% | Fairly stable |
| Architecture | 66.6% ± 36.2% | Moderate lexical instability |
| Limitations | 50.4% ± 42.2% | High rephrasing variance |
| Regulatory | 75.4% ± 27.0% | Moderate stability |
The authors also report that human review found technical descriptions to be semantically consistent despite lexical variation, and that 78.5% of edits across the 1,694 included models were classified as minor.
The correct interpretation is not “LLMs can now curate medical AI repositories by themselves.” That would be the usual overexcited conclusion, and therefore probably wrong.
The better interpretation is narrower: schema-constrained LLM extraction appears practical for scaling the first pass of metadata generation, especially for structured fields, when paired with human review. For fields like architecture, limitations, and regulatory details, lexical instability is expected because those sections are more narrative and context-dependent. Variation there does not automatically mean factual error, but it does mean these fields deserve more review attention.
This gives organizations a useful design rule:
| Extraction target | Automation suitability | Review priority |
|---|---|---|
| Title, authors, repository links | High | Low to moderate |
| Modality, task, subspecialty | Moderate to high, if schema is clear | Moderate |
| Architecture | Moderate | Higher |
| Limitations | Lower lexical stability | High |
| Regulatory or deployment claims | Sensitive and context-dependent | Very high |
The paper’s workflow is therefore not “replace curators.” It is “spend curator time where ambiguity is highest.” Less glamorous. More useful.
The Landscape Data Shows Crowding, Fashion, and Missing Validation
Once OpenRad has structured records, the authors use the repository as an analytics layer over the radiology AI field. These analyses are descriptive and exploratory, not causal claims. They do not tell us which model should be purchased, deployed, or trusted. They tell us what the open-access model ecosystem looks like.
Several patterns stand out.
Architecture distribution shows transformer-based models and CNN variants nearly tied at the top: transformers account for 33.4%, CNN variants for 33.3%, followed by diffusion models at 12.1%, U-Net variants at 10.1%, GANs at 8.1%, and smaller shares for YOLO and LSTM. The immediate lesson is not “transformers won.” The lesson is that radiology AI now contains overlapping architectural generations. Classical convolutional methods remain deeply present, while transformer and diffusion systems have become structurally important.
Geographically, the repository data show publication concentration in China and the United States, with approximately 400 and 300 papers respectively. A secondary tier of European, Indian, and East Asian contributors ranges from about 50 to 150 papers, while many countries contribute only a small number. This is not surprising, but it matters for business interpretation. Model availability reflects research capacity, data access, funding, institutional incentives, and publication ecosystems. A global model catalogue does not mean globally balanced evidence.
The modality-specialty heatmap is even more revealing. MRI dominates neuroradiology applications, with 621 studies. Chest imaging follows, especially X-ray and CT models for chest radiology, with 233 and 188 entries respectively. Oncologic imaging relies heavily on MRI and CT, with 179 and 165 entries. Nuclear medicine and PET applications are comparatively scarce.
This tells us where the field is crowded and where discovery may be thin. Crowding can be good: more models, more methods, more comparison possibilities. It can also create noise. A hospital evaluating chest X-ray AI faces a different problem from an organization looking for open PET-based AI tools. One has too many claims to sort. The other may have too few mature candidates.
The evaluation metrics also show task-specific habits. Classification models most often report accuracy, AUC, F1-score, and specificity. Segmentation models rely heavily on Dice Similarity Coefficient, with 308 mentions, roughly 68% of total DSC mentions. Generative applications often use SSIM and PSNR.
These metrics are not wrong. They are just incomplete as business evidence. A segmentation Dice score does not answer whether integration into a radiologist’s workflow improves throughput. AUC does not answer whether the system is calibrated across scanners, hospitals, and patient demographics. SSIM does not decide whether generated or reconstructed images are safe for clinical interpretation.
Finally, the limitations analysis points toward the familiar translation gap. Frequent limitation terms include “limited,” “data,” “model,” “dataset,” “training,” “performance,” “image,” and “evaluated,” with lower-frequency but clinically important terms such as “small,” “sample size,” “external validation,” “generalization,” and “single center.” The discussion highlights the problem directly: many studies remain confined to single-center retrospective settings, limiting generalizability across patient populations and imaging protocols.
So the repository reveals a field that is productive, technically diverse, and unevenly validated. In other words, AI is behaving exactly like AI.
What the Evidence Supports, and What It Does Not
Because OpenRad mixes platform construction, extraction reliability testing, and descriptive analytics, it is useful to separate the paper’s evidence types.
| Evidence item | Likely purpose | What it supports | What it does not prove |
|---|---|---|---|
| Literature selection flowchart | Implementation evidence | The repository is built from a defined search and filtering process | Complete coverage of every relevant model |
| RSNA/RadLex schema use | Implementation detail and standardization mechanism | Records are designed for comparability and interoperability | That all fields are complete or clinically sufficient |
| GitHub repository interrogation | Repository-health evidence | OpenRad checks for weights and demos beyond paper metadata | That available code is production-ready |
| 225-paper intra-LLM stability test | Reliability check | Structured extraction is relatively stable; narrative fields vary more | Clinical correctness or regulatory adequacy |
| Expert review and 78.5% minor edits | Quality-control evidence | Human curation improves trust in generated records | Absence of remaining omissions |
| Architecture/geography/modality figures | Descriptive landscape analysis | OpenRad can map ecosystem patterns | Causal explanation for those patterns |
| Word cloud of limitation terms | Exploratory limitation synthesis | Generalization and validation concerns recur | Quantified clinical risk |
This distinction prevents a common reading error. The paper does not claim to solve radiology AI deployment. It claims to reduce fragmentation and create a searchable, standardized, curated layer that can support discovery, reproducibility, and future benchmarking.
That is already enough. Not every paper needs to cure medicine before breakfast.
For Businesses, OpenRad Looks Like Model Intelligence Infrastructure
The most practical implication is not limited to radiology. OpenRad demonstrates a pattern that many AI-intensive sectors will need: model intelligence infrastructure.
A model intelligence layer is not just a list of models. It maintains structured knowledge about what models exist, what tasks they address, what data they were trained or evaluated on, what artifacts are available, what limitations are known, and how trustworthy the surrounding evidence appears.
For radiology vendors, hospitals, insurers, research groups, and AI governance teams, this has several possible uses.
First, it reduces discovery cost. Instead of manually searching across papers and repositories, teams can filter by modality, subspecialty, task, weight availability, demo availability, and verification status.
Second, it supports due diligence. A structured record does not replace expert review, but it creates a first-pass comparison layer. Procurement teams and technical evaluators can quickly separate models with public artifacts from papers that remain difficult to reproduce.
Third, it improves benchmarking design. If a field has many open models for chest X-ray classification but fewer for PET applications, benchmarking priorities can be chosen more rationally. Crowded areas may need comparative evaluations. Sparse areas may need investment in data and model development.
Fourth, it creates pressure for better reporting. If repository health, weights, demos, and validation strategies are visible, authors and labs have more incentive to publish usable artifacts rather than symbolic code drops.
Fifth, it suggests a repeatable architecture for other domains: pathology, drug discovery, surgical robotics, genomics, industrial inspection, legal AI, financial risk models. Anywhere model claims are abundant and operational trust is scarce, structured curation becomes valuable.
The business inference is therefore:
| Paper directly shows | Cognaptus business inference | Remaining uncertainty |
|---|---|---|
| OpenRad curates 1,694 open-access radiology AI models | Domain-specific model registries can reduce search and due-diligence friction | Actual ROI depends on adoption, maintenance, and integration workflows |
| LLM extraction is stable for structured fields and weaker for narrative fields | Hybrid LLM-human curation can scale metadata operations | Review cost and error tolerance vary by domain |
| Repository checks identify weights and demos | Artifact-health metadata is commercially useful | Code availability does not mean deployment readiness |
| Landscape analytics reveal concentration by architecture, geography, modality, and task | Model repositories can become strategic market maps | Descriptive distributions do not prove model quality |
| Limitations often relate to validation and generalization | Discovery tools should integrate validation maturity scoring | Clinical evidence remains uneven and locally dependent |
The stronger business lesson is not “build a repository.” It is “turn fragmented AI assets into decision-grade metadata.” That is a different product.
The Boundary: Discovery Is Not Validation
OpenRad improves discoverability and reproducibility. It does not certify clinical safety.
The authors are clear about several limitations. Model records are generated automatically and, despite stability assessment and expert review, can still contain omissions or minor inaccuracies, especially where publications are paywalled or full text is inaccessible. The literature search is limited to PubMed, arXiv, and Scopus using defined queries, which improves reproducibility but may miss some models. The first extraction did not populate every RSNA Roadmap field because of computational constraints, focusing more on indexing and access to manuscripts and code.
There is also a practical boundary that sits beyond the paper. A model with available code and weights may still fail local validation. It may not handle a hospital’s scanner mix, patient population, image acquisition protocol, annotation conventions, integration environment, latency requirements, liability constraints, or regulatory context. OpenRad can help teams find and compare candidates. It cannot decide whether a model belongs in a clinical workflow.
That boundary should not be treated as a weakness. It defines the role of the infrastructure.
Discovery tools answer: What exists, where is it, what does it claim, and what artifacts are available?
Validation programs answer: Does it work here, safely, reliably, and under the constraints of our environment?
Procurement and governance answer: Should we adopt it, monitor it, pay for it, regulate it, or reject it?
The value of OpenRad is that it strengthens the first layer, making the second and third layers less blind.
The Unfashionable Layer That Makes AI Reusable
Radiology AI’s next bottleneck is not only algorithmic performance. It is organizational memory.
A field can produce thousands of models and still remain inefficient if no one can reliably find, compare, verify, and reuse them. OpenRad is interesting because it treats model curation as infrastructure rather than clerical work. It combines search, schema standardization, repository-health checks, LLM-assisted extraction, expert review, community correction, and live descriptive analytics.
The result is not clinical translation by itself. It is the preparation layer that makes translation less chaotic.
That may sound less exciting than another model launch. Good. Excitement has done its part. The harder work now is building systems that remember what has already been built, distinguish usable artifacts from decorative links, and expose where evidence remains thin.
OpenRad does not clean up all of radiology AI’s mess. It shows what cleaning would look like.
And in a field full of models waiting to be discovered, reproduced, compared, and validated, that is not a small contribution. It is the kind of boring infrastructure that decides whether innovation compounds—or just piles up.
Cognaptus: Automate the Present, Incubate the Future.
-
Konstantinos Vrettos, Galini Papadaki, Emmanouil Brilakis, Matthaios Triantafyllou, Dimitrios Leventis, Despina Staraki, Maria Mavroforou, Eleftherios Tzanis, Konstantina Giouroukou, and Michail E. Klontzas, “OpenRad: a Curated Repository of Open-access AI models for Radiology,” arXiv:2603.02062, 2026, https://arxiv.org/pdf/2603.02062. ↩︎