Deploying Prediction Models Without a Data Engineering Team

The deployment gap

A trained model exists as code: coefficients, a preprocessing pipeline, and a prediction function. To make it usable, someone needs to build an interface, handle input validation, compute the output in real time, and present the result in a way that makes sense to someone who is not a data scientist.

In well-resourced organisations, a data engineering team handles this. They containerise the model, build an API, connect it to a front end, and set up monitoring. In most clinical research settings, especially in Africa, that team does not exist. The model stays in a notebook, gets presented at a conference, and never reaches the people it was meant to help.

The scale of this problem is significant. A review of clinical prediction models published in African health journals between 2015 and 2023 found that fewer than 5% had been deployed as tools accessible to clinicians. The remaining 95% exist as equations in journal articles or code in supplementary materials. They represent substantial research investment that produced no practical impact because the last step, deployment, was never completed.

The gap is not about technical difficulty. The computations involved in most clinical prediction models are straightforward. The gap is about engineering infrastructure: building a reliable interface, validating inputs so the model does not produce nonsensical outputs from invalid data, presenting results with appropriate context, and keeping the whole system running over months and years without dedicated maintenance staff.

What we do differently

Our platform takes the model (the coefficients, the standardisation parameters, the input variables) and packages it into a live, interactive application. The researcher provides the model. We provide the deployment infrastructure, the interface, and the governance layer.

The diabetes, breast cancer, and osteoporosis demos on this platform were built exactly this way. Each one started as a set of regression coefficients from a published study. We turned them into live tools with validated inputs, real-time computation, interpretation text, and reference citations. No data engineering was required from the research team.

The process works like this: the research team provides the model specification (variable names, coefficients, intercept, standardisation parameters, and outcome definition) along with the published reference. We implement the model as a workbench application with input validation that matches the variable ranges from the training data, real-time computation that mirrors the original model exactly, and output presentation that includes the probability score, risk band classification, key driver analysis, and interpretation text. The research team then validates the deployed tool against known test cases to confirm the implementation matches the original model.

Input validation is a critical part that researchers often underestimate. A model trained on patients with BMI between 18 and 45 should not accept a BMI of 150. A model trained on adults should not accept an age of 3. Without input validation, the model will produce a prediction for any input, including clinically impossible values, and the output will look just as confident as a prediction from valid inputs. Our workbench tools enforce the valid input range for every variable and display a clear message when an input falls outside the training data range.

Sustainability matters

A deployed model needs to stay deployed. It needs to keep working when browsers update, when dependencies change, and when the next paper is published with updated coefficients. We maintain the deployment infrastructure so the research team can focus on the research.

This is not glamorous work. But it is the work that determines whether a model actually gets used.

Sustainability also means keeping the model current. When a new study publishes updated coefficients or extends the model to a new population, the deployed tool needs to be updated to reflect the latest evidence. Our platform supports versioning: the old model remains accessible for reproducibility, while the new model becomes the default. Users who ran the old version can see how their results would change with updated coefficients.

Long-term maintenance includes monitoring how the tool is actually being used. If users consistently enter values at the extreme ends of a variable's range, it may indicate that the training data does not cover the population being served. If the distribution of predicted probabilities shifts over time, it may indicate that the patient population has changed and the model needs recalibration. These signals are only visible if the deployment infrastructure includes basic usage monitoring, which most ad hoc deployments lack.

The economics of shared infrastructure

Building deployment infrastructure for a single model is expensive relative to the model's impact. Building it once and reusing it across dozens of models changes the economics entirely. The engineering cost is amortised across every model deployed on the platform, which makes it viable to deploy models that would never justify the cost of a standalone deployment.

This is particularly relevant for models developed by small research teams at African universities. A research group that published a validated prediction model for preeclampsia risk in Nigerian pregnant women has no budget for a software engineering team to deploy it. On our platform, deployment requires the model specification and a validation dataset, not a development team.

The shared infrastructure also enforces quality standards. Every model deployed on the platform gets the same input validation, the same output presentation, the same reference citations, and the same governance layer. A model from a small university department gets the same deployment quality as one from a large research consortium. That consistency is part of the value proposition for institutional partners who need to trust every tool on the platform, not just the ones from well-known research groups.