VMRI Desk is an AI-assisted brain MRI screening workspace built for clinical-style review. It combines MRI upload, doctor login, structured reporting, saved case history, side-by-side case comparison, doctor impressions, printable export, and a report-aware assistant inside one application.
The project is designed to feel like a compact neuroimaging command center rather than a basic ML demo. A doctor can log in, upload a .nii or .nii.gz scan, review a structured report, save their own impression, reopen earlier cases, compare two studies, and use an assistant to summarize or explain report context.
- End-to-end workflow instead of a standalone model script
- Real medical imaging input with NIfTI MRI support
- Hybrid prediction pipeline using reference similarity, an ensemble classifier, and optional GNN inference
- Structured report generation tailored to doctor review
- Case archive, report status workflow, comparison mode, and doctor impression capture
- Backend-driven clinical assistant with report-aware answers
- Model validation surfaced in the product, not hidden in notebooks
- Doctor and hospital registration/login
- Patient intake before scan submission
- MRI upload for
.niiand.nii.gz - AI-assisted classification into:
- Healthy
- Alzheimer
- Parkinson
- Differential probability display
- Scan preview from a representative MRI slice
- Key observations and recommendations
- Doctor impression editing and saved report status
- Filterable report history
- Side-by-side patient comparison
- Export to print/PDF and JSON
- Workspace analytics and validation summary
- Context-aware clinical assistant endpoint
Path: frontend/brain
The frontend is a React-based clinical workspace with:
- login/register flow
- patient intake form
- upload panel
- structured report view
- report archive and filters
- comparison view
- settings/operations summary
- assistant drawer
Main file:
frontend/brain/src/App.js
Path: backend
Main backend files:
backend/app.py: Flask API, auth routes, prediction route, report routes, assistant route, metrics routebackend/vg.py: MRI preprocessing, feature extraction, ensemble inference, validation metrics, preview generationbackend/auth_db.py: SQLite auth and report storagebackend/assistant_engine.py: report-aware assistant logicbackend/train_model.py: rebuilds reference and classifier bundles
The backend accepts .nii and .nii.gz files and loads them with nibabel.
Each MRI is:
- loaded as a 3D volume
- resized to
16 x 16 x 16 - normalized with z-score scaling
Formula:
x' = (x - mean) / (std + 1e-5)
The volume is converted into a 49-feature vector:
- 16 means across one axis
- 16 means across the second axis
- 16 means across the third axis
- 1 global standard deviation
The prediction system combines three sources:
- reference similarity against stored MRI feature vectors
- an
ExtraTreesClassifierensemble - an optional GNN path if the saved GNN bundle loads cleanly
Final probabilities are blended into a single output distribution.
If the healthy class barely wins against a disease class, the pipeline slightly favors the disease class to reduce false reassurance in near-tie cases.
The project now exposes model validation metrics directly from the backend.
Available metrics include:
- mean cross-validation accuracy
- fold-by-fold cross-validation accuracy
- confusion matrix
- per-class classification report
- feature importance ranking
- sample count
- GNN availability flag
Endpoint:
GET /model/metrics
This makes the model story much stronger for demos, viva, and technical review because the app can now explain how the classifier was evaluated.
The assistant is backend-driven and report-aware.
Endpoint:
POST /assistant
It answers narrow, practical workflow questions such as:
- summarize this case for handoff
- explain the confidence level
- what should I review next
- compare my selected reports
- show model validation metrics
The assistant is intentionally constrained to the report context and validation data so it behaves more like a clinical workflow helper than a free-form hallucinating chatbot.
The backend uses SQLite:
backend/vmri.db
Stored data includes:
- hospital/doctor accounts
- saved analysis reports
- patient metadata
- doctor impressions
- workflow status
- model insights
GET /GET /healthPOST /auth/registerPOST /auth/loginPOST /predictGET /reportsPATCH /reports/<report_id>GET /model/metricsPOST /assistant
cd C:\Users\srivi\OneDrive\Pictures\Desktop\vmri\backend
python app.pyBackend runs at:
cd C:\Users\srivi\OneDrive\Pictures\Desktop\vmri\frontend\brain
npm install
npm startFrontend runs at:
If you retrain or refresh the reference data:
cd C:\Users\srivi\OneDrive\Pictures\Desktop\vmri\backend
python train_model.pyThis rebuilds:
reference_bundle.joblibclassifier_bundle.joblib
- Log in as a doctor
- Fill patient intake fields
- Upload a
.niiMRI scan - Run analysis
- Review differential probabilities and scan preview
- Add doctor impression and set report status
- Open report history
- Compare two saved reports
- Ask the assistant for a handoff summary and confidence explanation
- Open workspace summary to show validation metrics
- The current GNN uses a simplified graph structure and is not the main strength of the model
- The MRI representation is compact and may lose anatomical detail due to aggressive resizing
- SQLite is fine for demo use but should be replaced with Postgres for production
- The assistant is context-aware and backend-driven, but still rule-based rather than LLM-powered
- This is a screening support tool, not a diagnostic system
- replace SQLite with Postgres
- move the assistant to an LLM endpoint with guardrails
- train on a larger and more balanced dataset
- add stronger calibration and uncertainty estimation
- use a richer imaging model such as a 3D CNN or a real region-based brain graph
- add PDF export templates and admin-level validation dashboards
This project is intended for academic demonstration, prototyping, and workflow exploration. It should not be used as a standalone clinical diagnosis system without proper validation, approvals, and specialist oversight.