MedicHub AI
Several separate imaging models behind one FastAPI service — an integration problem more than a modelling one.
The product interfaces on this page are compositions built from each platform’s real module structure. They are not screenshots of production systems — these are private client and commercial platforms.
- Role
- Backend engineer
- Year
- 2025
- Status
- Experimental · Not a medical device
- Category
- AI
A FastAPI backend that unifies several deep-learning pipelines for medical image analysis behind one service interface, with local model weights and a consistent request contract across imaging types.
The problem
Each imaging model arrives with its own input assumptions, preprocessing and output shape. Consuming four of them from one application means writing four integrations, unless something normalises them first.
The outcome
One service contract over multiple model pipelines, so a client integrates once rather than per model.
Stack
- Python
- FastAPI
- PyTorch
- Uvicorn
- REST API
Honest scope first
The interesting engineering here has nothing to do with medicine. It is the question of how you put several independently-built inference pipelines behind one interface without the differences between them leaking to every client.
One contract, several pipelines
Service
One request contract
- FastAPI
- Uvicorn
Adapters
Per-pipeline preprocessing and output normalisation
- Input normalisation
- Output shaping
Inference
Independently trained pipelines
- PyTorch
- Local weights
- Segmentation + classification
What it taught
Model weights are the operational problem nobody warns you about. Some load from local files, some download on first use, and the service has to start predictably regardless — including when a weight file is simply missing.
Next case study
Building something in this space?
I am available for a limited number of projects. Tell me what you are working on.