Healthcare analytics platform

From risk models to a care-management operating system

A 0-to-1 analytics product scaled across nine healthcare programs, connecting risk models, delivery pipelines, dashboards, and care-manager workflows.

Problem: Risk models and dashboards were fragmented across programs and disconnected from a repeatable path into care-team action.
Decision: Build reusable data and model-delivery services while preserving each program’s population, thresholds, and review workflow.
Business / proof change: Scaled across nine programs, supporting $500K in new revenue and approximately $3M in client performance-based payouts.
Ownership: Lead data scientist and product partner across modeling, platform delivery, reporting, and workflow adoption
Scale / team: Cross-functional product delivery across nine healthcare programs
Evidence: 3 source notes · 3 explicit limits

Professional work2020–2023

Context0-to-1 healthcare analytics product

ScaleAdopted across nine healthcare programs

Product result$500K new revenue supported

Program result≈$3M client P4P impact supported

Result

$500K in new revenue supported and approximately $3M in client performance-based payouts across the broader program.

PROGRAM MAP / SANITIZED

Nine programs. One reusable delivery spine.

Select a program context to see what stayed shared and what remained specific.

SHARED SPINEData → models → delivery → workflow

All program-specific layers

Risk stratification: Shared feature and delivery services support a program-specific cohort, calibrated risk band, threshold policy, and reviewer capacity.

Readmission: The index event, exclusion rules, 30-day horizon, transition context, and post-discharge action path remain specific to readmission.

ED utilization: Near-term utilization patterns, visit cadence, access signals, and outreach capacity change both the feature window and operating threshold.

Quality gaps: Measure eligibility, evidence freshness, closure rules, and chart-review queues matter more than a generic risk rank.

Care management: Program enrollment, caseload capacity, contactability, and feedback capture shape how a score becomes a work queue.

SDoH: Proxy risk, missingness, resource availability, and consent require explicit review before a social-risk signal can inform action.

Utilization review: Length-of-stay and service patterns arrive with different timing, review authority, and escalation costs than care-management models.

Provider analytics: Provider identity, attribution, network context, and data-quality rules sit on the shared platform but require their own validation contract.

Performance reporting: Metric definitions, refresh cadence, lineage, and owner sign-off become the program-specific layer over reusable data delivery.

Context and stakes

Risk models were only one layer of the product. The harder problem was turning several healthcare programs into a repeatable operating system for data, model delivery, reporting, and care-team action.

A model that never reaches a workflow is not a product. A dashboard without a governed delivery path does not create durable adoption.

My role

I led data science and product work across risk modeling, reusable delivery patterns, program reporting, and care-manager workflows. The role required translating between model development, client priorities, operational adoption, and measurable program outcomes.

Product architecture

Shared data products and deployment patterns supported program-specific models rather than forcing every use case through one score. A composite Health Index provided a common orientation while each program kept its own population, intervention, and review logic.

The platform connected model outputs to dashboards, outreach priorities, and care-manager workflows, then fed operational feedback into later releases.

The decision that mattered

I treated delivery and adoption as part of the model system. Reusable pipelines shortened release cycles, but program-specific review and workflow design stayed explicit so scale did not erase local context.

What failed or was unreliable

A universal score was tempting but too blunt for nine different program goals. Reporting that did not match care-team work created friction even when the underlying model performed well. Data refresh and definition drift also needed product ownership, not one-time cleanup.

Validation and operations

Validation combined model quality with delivery checks, cohort review, workflow adoption, and program outcomes. Release patterns reduced repeated engineering work while leaving room for program-specific thresholds, interventions, and monitoring.

Outcome

The platform supported $500K in new revenue and approximately $3M in client performance-based payouts across the broader program. Reusable delivery patterns reduced model deployment cycles by approximately 50%. These are scoped career-record outcomes, not single-model claims.

What I would improve next

I would formalize a shared model-card and workflow-card release contract, add adoption telemetry by program, and make change-impact reviews part of every data or model release.

Source notes

What you can inspect—and what remains private.

Career record

Role, nine-program scale, revenue, P4P impact, and faster delivery are supported by the current career record.

Portfolio reconstruction

The product map and Health Index visual are authored here from approved facts without private data.

Private implementation

Client dashboards, datasets, model features, contracts, and operational rules are intentionally not published.

Limits

Outcomes belong to the broader product and program context, not one model.
The public visual is a reconstruction, not a private dashboard.
No clinical effectiveness claim is made.

The product map is an authored reconstruction. No client data, private dashboard, model feature, clinical metric, contract term, or employer artifact is reproduced.

Illustrative product map

health_index:
  inputs: [risk, utilization, quality]
  programs: 9
  delivery: reusable_pipeline
  users: care_management
  review: program_specific