Modernizing Machine Learning Deployment for Prior Authorization at Aetna

By: Abel Pech

May 21st, 2026

Prior Authorization and the Role of Machine Learning

Prior authorization is a complex, high-volume workflow that sits at the intersection of clinical policy, regulatory compliance, and operational efficiency. For patients and providers, however, it can represent delays, uncertainty, and administrative burden — making thoughtful modernization of the process especially important. Health plans rely on machine learning models to assist with tasks such as document classification, rule evaluation, and approval decision support. These models must integrate cleanly with that existing business logic, remain explainable, and evolve over time as data distributions and policies change.

From an engineering standpoint, the challenge is not simply building accurate models but reliably deploying them in production. Model lifecycle management(i.e., training, versioning, deployment, monitoring, and retirement)has become as important as model accuracy and precision themselves. Improvised deployment patterns that work well for small teams often become problematic as systems scale.

The Original Deployment Pattern: Models Inside Containers

Like many organizations, early machine learning services for prior authorization were deployed by packaging trained models directly inside application containers. These containers were orchestrated using platforms such as Kubernetes and included:

• Business logic for feature preparation
• Serialized machine learning models (for example, pickled artifacts)
• The full Python runtime, environment, and packages required to load and execute those models

At first glance, this approach offered appealing simplicity. A single container image could be built, tested, and deployed as an atomic unit. Infrastructure teams already understood how to deploy containers, and application teams could integrate quickly without introducing additional dependencies.

• Over time, however, a less obvious form of coupling emerged. Many popular Python machine learning libraries, such as pandas and scikit-learn, do not guarantee forward compatibility for serialized model artifacts. A model serialized using one version of a library often cannot be reliably deserialized using a newer version and as a result: each container became tightly bound to specific library versions
• Even minor dependency upgrades risked breaking model loading at runtime
• Running multiple models with different dependencies in the same container became impractical or impossible

This coupling was not always immediately visible in code reviews or deployment manifests, but it significantly constrained operational flexibility.

Long-Term Consequences of Version Lock-In

Once containers were locked to older versions of core libraries, upgrading the underlying runtime environment became increasingly difficult. Base images could not be updated without risking model incompatibility, resulting in:

• Use of deprecated operating system components
• Reliance on unsupported language runtimes

In regulated environments, where patching and vulnerability management are essential, this represented a growing risk.

New models, trained using more recent versions of machine learning libraries, could not be deployed alongside older models without either:

• Downgrading training environments to match legacy dependencies, or
• Creating entirely new containers with separate dependency stacks

Both options carried costs. The former limited access to newer tooling and performance improvements, while the latter increased system complexity.

Creating 2 containers(one for “legacy” models and one for “modern” models) was duplicative. Each container needed its own implementation of largely identical business logic, differing only in the model artifact and dependency versions. Over time, this duplication increased:

• Maintenance effort
• Risk of behavioral drift between services
• Cognitive load for engineers supporting production incidents

What began as a straightforward deployment strategy ultimately proved burdensome at scale.

Rethinking the Architecture: Separation of Concerns

Decoupling Models from Business Logic

The core insight behind the new approach was to treat machine learning models as independently deployable assets rather than static files embedded in application containers. Instead of bundling models and logic together, responsibilities are now clearly separated:

• Application containers handle request validation, feature preparation, orchestration, and response formatting
• Model serving infrastructure is responsible for loading, executing, and scaling individual model versions

This separation aligns with long-standing software engineering principles and reflects how many organizations now approach microservice design.

Managed Model Serving with Cloud Platforms

To support this shift, model deployment was moved to a managed machine learning serving platform, such as Vertex AI. In this model:

• Each trained model is deployed independently, with its own runtime environment
• Dependency versions are scoped to the model rather than the application
• Multiple model versions can coexist without interference

This approach complements, rather than replaces, established MLOps frameworks such as MLflow, Kubeflow, Metaflow, or Flyte. In our case, managed platform capabilities were prioritized for model serving to reduce operational overhead and security risk, while orchestration and experimentation tooling can integrate with broader MLOps ecosystems as needed.

Where applicable, managed workflow orchestration can be used to define containerized DAGs for training and evaluation steps, enabling hardware specialization and clean separation between training workflows and serving endpoints. Serving remains independently managed to preserve lifecycle decoupling.

Application containers interact with models through well-defined interfaces, treating them as external services rather than local artifacts.

Benefits of the New Deployment Model

Independent Lifecycle Management

By decoupling model serving from application containers, teams can now:

• Upgrade application runtimes without affecting models
• Retrain and redeploy models without rebuilding containers
• Retire legacy models without touching business logic

This independence significantly reduces coordination overhead between data science and platform teams.

Improved Security Posture

Containers that no longer embed models can adopt modern base images and dependency versions more aggressively. This makes it easier to:

• Apply security patches promptly
• Adopt newer language runtimes
• Reduce the attack surface associated with outdated libraries

Meanwhile, model environments can be upgraded on their own timelines, with appropriate validation.

Reduced Duplication and Cleaner Codebases

With business logic consolidated into a single container codebase, duplication across “old” and “new” model services is eliminated. This results in:

• More consistent behavior across model versions
• Simpler testing and validation
• Lower long-term maintenance costs

From an engineering productivity perspective, this is one of the most tangible benefits.

Conclusion

The evolution of machine learning deployment for prior authorization reflects a broader shift in how organizations operationalize data science at scale. By moving away from container-embedded models and toward independently managed model serving, teams gain flexibility, security, and long-term sustainability.

While the specific tools and platforms may differ across organizations, the underlying principles (e.g., separation of concerns, independent lifecycles, and proactive management of technical debt) are widely applicable. As machine learning continues to mature as a production discipline and align more closely with modern engineering best practices, architectures that embrace these principles will be better positioned to adapt and grow.

References

Google Cloud. (2023). *Vertex AI documentation*.

© 2026 CVS Health and/or one of its affiliates. All rights reserved.