Clinical ML deployment without enterprise MLOps overhead

A clinical research team at a mid-size hospital has spent two years validating a model that predicts which patients on a specific cardiac drug protocol are likely to develop a known side-effect within six weeks of starting. The model works. The validation paper is in review. The PI's funder has just asked the question every PI dreads: "When will this be available as a service that the cardiology department can actually use?"

The team's answer is some combination of "we'll figure it out" and "we don't really know what 'available as a service' means in this context." Their PhD student who wrote the model is graduating in four months. The model lives in a Jupyter notebook that requires a specific Python version, a specific NumPy version, and three implicit cleaning steps that only the PhD student remembers.

This is the moment most clinical research teams discover that almost everything written about MLOps was written for someone else.

Why most MLOps advice doesn't fit clinical research

The MLOps blogs, vendor pages, and conference talks you'll find on the open web are written for a different reader: a platform team running hundreds of models at scale, often inside a tech company with a dedicated infrastructure org. The recommendations make sense for that reader. They do not make sense for a four-person clinical research group with one model serving forty hospital users.

Specifically:

• Kubeflow + Seldon + a feature store + a model registry + a vector database is a reasonable stack for a team running 200 models. It is not a reasonable stack for a team running one. The operational complexity of that stack exceeds what a clinical research team should ever absorb. We have seen labs inherit this kind of architecture from a previous consultancy and then watch it slowly stop working because nobody on the team can update it.
• "Continuous retraining pipelines" assume new training data arrives daily or weekly. In clinical research, retraining typically happens infrequently — when the next cohort lands, when the protocol changes, when a new validation study completes. A manual retraining procedure executed by a human is the right answer for most clinical research teams.
• "Multi-environment deployment promotion (dev → staging → prod)" assumes a deployment cadence of multiple times per week. Most clinical research models deploy once and stay deployed for months. Two environments are usually enough.
• "A/B testing in production" is rarely appropriate when the prediction informs a clinical decision and patient-safety oversight is in scope.

The reason this matters: the standard MLOps stack is operationally heavy. Clinical research teams who adopt it inherit a maintenance burden they cannot sustain. Six months later, the deployment exists in a state of frozen-in-amber decay because no team member can read it.

What a research-team deployment actually looks like

A reasonable production deployment for a single validated clinical research model has six components. None of them require a platform team.

| Component | What it is | What it is not | |---|---|---| | Containerised inference service | FastAPI service in a Docker container, deployed to a single managed VM or a container service the institution already uses | Kubeflow + Seldon + Triton | | Type-validated input/output | Pydantic schemas for request and response, versioned alongside the model | A separate feature store | | Confidence-routing layer | Threshold-based separation of high-confidence and low-confidence predictions, with low-confidence cases routed to human review | Probabilistic routing infrastructure | | Versioned model artefacts | Model file in object storage (S3-compatible) or a simple registry, versioned alongside training-data provenance | A full MLflow + model registry deployment | | Logging | Structured logs of inputs and predictions, written to a database the institution already operates | Datadog + Prometheus + Grafana + a dedicated observability team | | Model card + runbook | One-page structured documentation: training data, preprocessing, evaluation metrics, intended use, known limitations, retraining procedure | A wiki space with 200 stale pages |

This stack fits in a single repository. A single engineer can hold it in their head. A clinical researcher with intermediate Python skills can update the model file. The runbook tells them how. The retraining procedure is documented in three pages.

This is what "sized for a research team, not a hyperscale platform org" means in practice.

The three patterns we see in clinical research labs

After delivering deployment work for clinical and life-sciences teams, three patterns appear over and over.

Pattern A: The notebook-on-someone's-laptop model. The team has a working model. It lives in a Jupyter notebook. Reproducing the model requires a specific Python version, specific package pins, and the implicit cleaning steps in cell 3. Pattern A teams have done the science; they need an engineering bridge to reproducibility before any deployment work begins.

Pattern B: The previous-consultancy-deployed-Kubeflow team. Six to twelve months ago, the team engaged a consultancy that deployed a full enterprise MLOps stack for one model. The consultancy is gone. The model is technically running. Nobody on the current team can update it, retrain it, or even confidently say what version of the model is currently serving traffic. Pattern B teams need a simpler architecture they can actually operate.

Pattern C: The "we don't know how to talk about this with the funder" team. The model is validated. The team knows what's in the notebook. They have not figured out how to describe the deployed system to the funder, the IRB, or the hospital IT department. Pattern C teams need a model card, a deployment runbook, and a one-page architecture diagram before they can have the procurement conversation.

Most clinical research labs are some mix of these three patterns. The deployment work that follows is mostly engineering and documentation; the science has already been done.

What "evaluator-ready" means for ML in regulated contexts

When a clinical research model needs to be operated under regulatory oversight (HIPAA-equivalent in the US, GDPR + MDR in the EU, IRB-supervised contexts everywhere), "evaluator-ready" means more than "the API responds." It means the deployment can survive a structured review.

The structured review typically asks five questions. A deployment is evaluator-ready when it can answer all five with documented evidence.

1. What model is currently in production, and what version of the training data was it trained on? Answered by versioned model artefacts plus a provenance record.
2. What does the model do when the input is malformed, missing, or outside the validated input distribution? Answered by type-validated input schemas plus a documented out-of-distribution handling policy.
3. When the model is wrong, what is the recovery path? Answered by confidence routing plus human review for low-confidence cases plus an audit trail of decisions.
4. How are predictions logged, and for how long? Answered by structured logging plus a documented retention policy.
5. What is the procedure for retraining the model when the training data changes? Answered by the runbook.

Notice that none of these questions require a platform team. They require documentation discipline and a small number of specific engineering choices.

A concrete deployment checklist for clinical research teams

Before declaring an ML deployment "production-ready" in a clinical research context, the team should be able to answer yes to each item.

• [ ] The model's training data is described in a model card, including the inclusion and exclusion criteria for the training cohort.
• [ ] The model file in production has a version identifier that is logged in every prediction.
• [ ] The inference service has explicit input and output schemas. Malformed inputs return a structured error, not a server crash.
• [ ] There is a documented confidence threshold below which predictions are routed to human review.
• [ ] Every prediction is logged with input hash, output, confidence, model version, and timestamp.
• [ ] There is a runbook describing how to redeploy the model from the source repository on a fresh laptop.
• [ ] There is a documented retraining procedure that a human can execute without the original model author.
• [ ] The IRB / data-protection officer / hospital IT department has reviewed the deployment architecture and signed off.
• [ ] The team has answered the five evaluator questions above in writing.

If three or more items are unchecked, the deployment is not production-ready. It is a prototype that happens to be running on the open internet.

When to stay in Jupyter

Not every validated model needs to be deployed as a service. Sometimes the right answer is "stay in Jupyter, document the analysis, publish the paper, and call it done."

Stay in Jupyter when:

• The model is a research artefact that informs the next study, not a tool that informs clinical decisions.
• The intended audience is the next research team that will run the analysis, not end-users making a decision today.
• The expected usage is a few re-runs per year, not continuous serving.
• The team does not have the operational capacity to maintain a production service.

Deploy when:

• The model produces predictions that inform a decision a human is going to make today.
• The expected usage is recurring (daily, weekly, monthly).
• A non-research user (a clinician, a programme officer, a research assistant) is the intended consumer.
• The funder, the IRB, or the institution has asked for the model to be available as a service.

The honest answer is sometimes "this model should not be deployed." A research team that recognises this saves itself months of operational burden it does not need.

How human-review routing works in practice

The most common production-readiness gap we see in clinical ML deployments is the absence of a human-review path. The model produces a prediction. The system either fully trusts the prediction (rare) or fully ignores it (also rare). The interesting case is the middle: the model is right most of the time, sometimes wrong, and the cost of a false positive or false negative is not symmetric.

A practical confidence-routing layer answers three questions:

1. What is the confidence threshold below which a prediction should not be auto-actioned? Set this conservatively at first; loosen it after observed performance justifies it.
2. Where do low-confidence cases go? A queue, a notification, a flag in the patient record — somewhere a human will actually see and act on.
3. How is the human's decision captured? As a structured override that can be analysed later. If 30% of low-confidence cases are routinely overridden in the same direction, the model has a known failure mode that should inform the next retraining round.

Most clinical research teams underestimate how much value the human-review layer creates. The model becomes useful even when its accuracy is well below human performance, because the system as a whole (model + human + audit trail) is consistently better than the human alone or the model alone.

What this kind of engagement looks like

For a clinical research team with one validated model and a research-fluent engineering partner, a typical deployment engagement runs four to eight weeks. The output is a containerised inference service, a confidence-routing layer with documented thresholds, versioned model artefacts, structured logging, a model card, and a runbook the team can execute without the original engagement team in the room.

The right shape of engagement is finite, scoped, and exits cleanly. Not a retainer. Not a continuing platform-team relationship. A team that has done the science gets an engineering bridge to a documented production deployment, and then the team owns the deployment from that point forward.

This is what MLOps for Research Teams is built around. If your team has a validated clinical model that needs to move from notebook to documented production without inheriting an enterprise stack, request a Scope Review. It's a free 60-minute written assessment with no commitment — we'll tell you whether your situation is genuinely a deployment problem, a documentation problem, or "stay in Jupyter."