PaperlayerView exact revision on arXiv

Source-linked AI summary

DR-LabStack: Design and Implementation of a Clinician-Facing Web System for Diabetic Retinopathy Prediction

Yingfan Xu, Tieming Liu, Ye Liang

arXiv:2609.10796v1cs.LGcs.SE

TL;DR

Pretrained DR models expose heterogeneous input, artifact, preprocessing, and output contracts, complicating access through a common clinical interface. DR-LabStack addresses this through a React-Flask system with shared ordered-feature interaction and model-specific adapters. Functional testing established the integrated loading, serving, and display behaviors under documented software boundaries, while clinical effectiveness and clinician usability remain unevaluated.

  • Problem

    Pretrained DR models differ in feature ordering, artifact formats, preprocessing requirements, and output semantics, creating a need for coordinated interface and inference-service integration.

  • Method

    DR-LabStack combines a shared React form with Flask model-discovery and inference endpoints, artifact-specific adapters, ensemble scaling, and a common classification response for four pretrained models.

  • Results

    Functional checks established loading, input-order, invocation, response, and browser-rendering behavior for the four integrated model contracts under documented conditions.

  • Takeaways & Limitations

    The system provides a concrete foundation for further integration engineering and clinician-facing evaluation of heterogeneous DR models.

  • Takeaways & Limitations

    The evidence covers one four-model snapshot with limited software inputs, isolated test adaptations, mocked browser transport, and no independent diagnostic validation.

Abstract

from arXiv · show

Pretrained diabetic retinopathy (DR) prediction models differ in their input fields, serialization formats, preprocessing requirements, and output semantics. Making these models accessible through a common clinical interface therefore requires explicit coordination between the user interface and the inference service. We designed and implemented DR-LabStack, a React-Flask web system integrating four externally developed pretrained models: RuleFit, Pruned RuleFit, Elaborative XGBoost, and Two-level Ensemble. A shared form retrieves ordered model features, renders model-specific numerical and categorical controls, and constructs a positional input vector. Backend adapters load heterogeneous artifacts and apply the ensemble's accompanying scaler, while a common JSON response supports binary classification display alongside method and source information. Functional evaluation on September 8, 2026 used copied application files and real model artifacts in a documented isolated environment. All four models loaded and exposed their 14-, 6-, 8-, and 25-field contracts. Sixty-two Flask test-client requests characterized service behavior; 12 limited-vector checks confirmed invocation-path and threshold consistency. Twenty-four browser-component scenarios with mocked transport verified input ordering and result rendering and characterized input-validation behavior. The resulting system demonstrates a reusable interaction and serving workflow for heterogeneous DR models. The contribution is web-system design, integration, and software functionality; clinical effectiveness and clinician usability require separate evaluation.

1 Introduction

DR-LabStack addresses the integration challenge of exposing heterogeneous pretrained DR models through a shared interface. Its contribution is application design, artifact integration, and functional evaluation rather than new model development or clinical validation.

  • 1 Introduction: DR-LabStack integrates RuleFit, Pruned RuleFit, Elaborative XGBoost, and Two-level Ensemble through shared React interaction and Flask discovery and inference endpoints.The system provides model-derived ordering, model-specific controls, heterogeneous artifact adapters, and a common classification response.
  • 1 Introduction: The paper contributes web-system design and functional integration evaluation, while algorithm design, training, feature selection, and ensemble learning remain outside its scope.The supplied predictive artifacts were developed in prior work and were neither retrained nor replaced by a new prediction algorithm.
  • 1 Introduction: Heterogeneous DR models require coordination of ordered features, artifact loading, preprocessing, and output interpretation across the interface and serving layer.The introduction identifies positional inputs, model-specific artifacts, an ensemble scaler, and differing output semantics as linked engineering concerns.
  • 1 Introduction: The evaluation establishes implemented behavior for specified inputs and interface contracts, not clinician usability, clinical utility, or clinical effectiveness.The intended audience is clinical personnel, but clinician participation and clinical utility were not evaluated.
  • 1 Introduction: DR-LabStack differs from prior DR web tools by focusing on serving multiple supplied model contracts rather than reproducing model performance across cohorts.Related systems provide context for web-based DR prediction, but this evaluation concerns integration across four externally developed models.

3 Intended Use and System Overview

DR-LabStack provides a manual-entry workflow that connects model-specific ordered inputs and inference paths to a consistent classification display. Its architecture separates the developed web application from externally supplied models and preprocessing artifacts.

  • 3 Intended Use and System Overview: DR-LabStack lets users select a DR model, enter its required clinical fields, and view a binary classification with method and source context.The workflow is intended for demonstration and assessment by clinical personnel.
  • 3 Intended Use and System Overview: The shared form discovers ordered fields, presents numerical or categorical controls, applies the supplied inference path, and returns a consistent result display.These requirements connect page-level presentation with model-specific inference.
  • 3 Intended Use and System Overview: Figure 1 separates project-developed React and Flask integration components from externally developed pretrained models and the paired scaler used by Two-level Ensemble.The arrows represent implemented metadata and inference relationships; model training is outside the online workflow.

4 System Architecture and Implementation

DR-LabStack uses a shared React–Flask workflow that discovers model-specific feature contracts, preserves positional ordering, loads heterogeneous artifacts, and returns a common classification response.

  • System architecture: The React–Flask architecture separates shared interaction, backend model discovery, feature metadata, artifact loading, inference, and result rendering.React handles routing, controls, state, requests, and rendering, while Flask maintains the model registry, exposes features, and invokes artifact-specific paths.
  • Feature-driven interaction: The shared form iterates over backend-returned feature order for state, controls, and positional request construction while separately mapping artifact keys to readable labels and hints.Numerical inputs and categorical selectors use model-specific controls, with exact artifact keys retained as state identifiers.
  • Artifact discovery: Startup discovery loads .pkl and .json artifacts into an in-memory registry, skips scaler.pkl as a standalone model, and omits artifacts that fail loading.The registry is populated at startup and does not support hot loading or online uploads.
  • Preprocessing and inference: The ensemble adapter pairs its predictor with a same-directory scaler, derives feature order from model metadata or scaler metadata, and transforms inputs before prediction.If the scaler is missing, the loader falls back to an unwrapped model and warns.
  • Request and response flow: The prediction endpoint converts the feature list to a floating-point row, invokes the adapter, thresholds the first output at 0.5, and returns an integer classification for React to display.The ensemble uses its external scaler, while other adapters use identity preprocessing; application adapters invoke pretrained objects without training.

5 Integrated Models and Interface Semantics

The integrated system serves four externally developed models with distinct input contracts and retained artifact semantics, while presenting a common binary classification interface whose labels are not calibrated probabilities.

  • Artifact semantics: RuleFit artifacts use regression mode, Elaborative XGBoost contains eight named features but is invoked through classifier predict, and the ensemble retains its supplied nested stacking structure.The retained ensemble includes inner Random Forest, Gradient Boosting, LinearSVC, and XGBoost stacks with Logistic Regression final estimators.
  • Documentation boundary: The application retains the name “Pruned RuleFit” without asserting a four-rule-only deployed predictor because the local artifact and concise method description remain unreconciled.The paper identifies this as an integration-documentation boundary rather than a conclusion about the validity of the original pruning research.
  • Interface semantics: The interface preserves exact artifact keys and positional order while mapping long or punctuated names to readable labels, units, and categorical controls.This boundary is important because field order determines construction, while interpretation depends on definitions and coding.
  • Output interpretation: The common threshold establishes a display contract for binary classification, not a shared calibrated probability scale or an individual clinical explanation.“Low Risk of DR!” and “High Risk of DR!” label the classification output rather than defining a clinical exclusion rule.

6 System Functional Evaluation

Functional evaluation combined source checks, real-artifact Flask requests, and mocked browser interaction to verify implemented model contracts, request behavior, ordering, rendering, and validation boundaries.

  • Evaluation scope: The evaluated environment used copied files and real artifacts with documented Python, import-shim, deserialization, network, and subprocess adaptations that were test-environment constraints rather than application features.Synthetic vectors had no patient identities or DR labels, and the evaluation did not establish clinical effectiveness.
  • Backend evaluation: The evaluation comprised 62 Flask test-client requests covering registry access, feature retrieval, prediction cases, invalid envelopes, boundary values, and ancillary routes.The test client operated without a running HTTP server, and the model-dependent outcomes are reported in Appendix B.3.
  • Backend integration results: All four artifacts loaded and exposed 14, 6, 8, and 25 fields, while all 12 limited-vector checks agreed on invocation paths and threshold behavior.The results characterize software invocation behavior rather than clinical accuracy.
  • Input and error behavior: Wrong-length, empty-list, and nonnumeric inputs returned 500 for all models, whereas numeric strings, nested one-row lists, negative values, and an out-of-domain neuropathy code were accepted.Unknown models and invalid feature-envelope types returned 400, while unknown-model feature retrieval returned 200 with an empty list.
  • Browser evaluation: The browser component rendered and submitted all 53 field positions in returned order, suppressed requests for required blank forms, and displayed controlled Low/High Risk responses for all four forms.These tests used mocked transport responses and therefore did not establish complete browser-to-model end-to-end operation.
  • Browser validation: Decimal submission depended on interaction state: entering 1.7 after an integer value could produce stepMismatch and block Enter submission, while blur synchronized the value and allowed button submission.A first value of −999 was submitted on every form, distinguishing browser-native behavior from enforcement of displayed medical hints.

7 Discussion

DR-LabStack makes heterogeneous model contracts explicit across the interface and serving layer, while its shared classification display does not imply shared probabilistic meaning or clinical interpretation.

  • 7.1 Separating numerical identity from presentation: The shared form preserves exact model keys for positional payloads while using separate clinical labels, making ordering explicit without rewriting model contracts.Browser results support this ordering behavior, but development time, input-error reductions, and usability improvements were not measured.
  • 7.1 Separating numerical identity from presentation: A transferable next step is a typed feature schema binding exact keys to units, categorical codes, clinical definitions, and missing-value representations.The current separation between artifact metadata and frontend hints exposes these responsibilities but does not unify them.
  • 7.1 Separating numerical identity from presentation: Figure 3 shows representative Elaborative XGBoost and Two-level Ensemble pages with complete eight- and 25-field forms in the waiting-for-input state.The screenshots illustrate shared interaction structure and are separate from executed tests.
  • 7.2 Maintaining heterogeneous model integrations: A versioned integration manifest could preserve alignment among artifact and scaler identity, metadata origin, dependencies, and page configuration.The ensemble’s composite preprocessing path makes these associations operationally important.
  • 7.3 Uniform responses and meaningful outputs: The common response standardizes final class display, but RuleFit regression scores and classifier labels retain different evidential meanings.Equation 2 standardizes the class rather than establishing a shared probability interpretation.
  • 7.3 Uniform responses and meaningful outputs: A low classification cannot establish absence of DR, and demographic or complication features require ascertainment and population context rather than causal interpretation.Future usability evaluation should test whether users understand required inputs, binary results, and intended limits of use.

8 Limitations and Future Work

The evaluation establishes tested component and service behavior for one four-model snapshot, but its software and deployment evidence remains bounded by isolated execution, mocked browser transport, and absent live full-stack testing.

  • 8 Limitations and Future Work: The study covers one four-model snapshot and limited software inputs, with browser tests using mocked transport and Flask calls omitting live full-stack HTTP deployment.Isolated execution also differed from the original Python and dependency environment through explicit test-only adaptations.
  • 8 Limitations and Future Work: The work evaluates integration and serving of externally developed models without independent diagnostic validation or complete artifact-to-publication mapping.Original-study performance estimates are therefore not attributed to the deployed artifacts.
  • 8 Limitations and Future Work: Future engineering should prioritize unified feature schemas, server-side validation, explicit model–preprocessing bindings, reproducible dependencies, clearer errors, and real frontend–backend integration tests.The observed missing-scaler fallback and browser decimal behavior provide concrete cases for these changes.
  • 8 Limitations and Future Work: The research web system still requires deployment-specific engineering because of hardcoded loopback endpoints, permissive CORS, debug startup, and limited operational controls.Deployment performance and clinical-workflow use have not been measured.

9 Conclusion

DR-LabStack provides a common web workflow for four externally developed DR models by coordinating ordered inputs, heterogeneous artifacts, preprocessing, and shared result display. Functional checks establish the reported integration behavior under documented conditions, while clinical effectiveness and usability remain unassessed.

  • 9 Conclusion: DR-LabStack connects model-derived feature order to shared React controls, adapts heterogeneous artifacts and the ensemble scaler through Flask, and presents a common classification response.The system integrates RuleFit, Pruned RuleFit, Elaborative XGBoost, and Two-level Ensemble.
  • 9 Conclusion: Real-model service checks and separate browser-component tests establish loading, ordering, invocation, and display behavior under documented conditions.These results concern software functionality rather than clinical effectiveness or clinician usability.
  • 9 Conclusion: The functional evaluation used synthetic inputs, recruited no participants, and processed no patient records.Training and clinical validation of the externally developed models were outside this study’s scope.
  • 9 Conclusion: The contribution is web-system design, implementation, integration, and software verification rather than development or training of the underlying prediction models.The underlying models were developed in separate research.

A Ordered Input Fields and Display Definitions

The appendix records ordered model keys alongside displayed meanings, units, and encodings for the integrated DR models, preserving the positional contracts used by the interface.

  • A Ordered Input Fields and Display Definitions: RuleFit exposes 14 ordered fields spanning laboratory measurements and binary neuropathy and nephropathy indicators.The listed units include %, mg/dL, g/dL, mEq/L, and U/L, with Yes=1 and No=0 encodings.
  • A Ordered Input Fields and Display Definitions: The appendix distinguishes exact model keys from their displayed clinical meanings, units, or encodings.Exact keys retain their original spelling and order, while compatibility with source-data definitions requires confirmation.
  • A Ordered Input Fields and Display Definitions: Pruned RuleFit exposes six ordered fields: creatinine, neuropathy, HbA1c, BUN, nephropathy, and anion gap.Neuropathy and nephropathy use Yes=1 and No=0 encodings.
  • A Ordered Input Fields and Display Definitions: Elaborative XGBoost exposes eight ordered fields covering laboratory measurements, age, and binary neuropathy and nephropathy indicators.The sequence begins with HbA1c, creatinine, glucose, hemoglobin, albumin, and age before the two complication indicators.

Two-level Ensemble (25)

The Two-level Ensemble uses a 25-field contract with coded demographic variables and model-specific clinical inputs, evaluated through isolated software fixtures and documented environment controls.

  • Input contract: The frontend preserves exact model keys while presenting readable labels for long punctuated ensemble feature names.This supports positional construction while retaining clinical display meanings.
  • Input contract: The ensemble input contract includes age, gender, race, laboratory measurements, and complication fields, with gender and race represented by numeric codes.Gender uses Female=0, Male=1, Unknown=2; race uses nine categorical codes.
  • Evaluation environment: The September 8, 2026 run used copied application and artifact files in a restricted Windows and Python environment with network and subprocess calls prevented.Testing used real artifacts while applying an import-only torch shim and restricted deserialization globals.
  • Fixture evaluation: The evaluation used baseline, 1.05-scaled numerical, and all-zero vectors without outcome labels, so fixtures represent software inputs rather than patients.The ensemble direct path scales before prediction, whereas the raw path calls CompositeModel.

B.3 Model-dependent API outcomes

Model-dependent API testing combined malformed and boundary inputs with retained HTTP-status fixtures, while separate checks documented ancillary application-path behavior and artifact-level qualifications.

  • Model-dependent cases: The 48 model-dependent prediction requests covered twelve input conditions for each of four models, including nonnumeric, numeric-string, nested, negative, null, and nonstandard NaN/Infinity inputs.Outcomes preserved observed acceptance and failure behavior across the four model integrations.
  • Request validation: Five malformed prediction envelopes returned HTTP 400, covering empty, unknown-model, string, missing-feature, and null-feature cases.These cases tested request-envelope validation rather than medical prediction validity.
  • Model-dependent cases: Table 4 reports HTTP statuses for model-dependent cases, where HTTP 200 denotes software acceptance rather than medical validity.The table distinguishes RuleFit, Pruned RuleFit, and Two-level Ensemble abbreviations.
  • Artifact qualification: Stored RuleFit artifacts contained 1,443 and 1,452 rule terms, qualifying the concise four-rule interface description without establishing a conclusion about pruning research.The counts refer to stored terms, not per-patient active-rule counts.
  • Ancillary paths: The legacy root returned 200, its about route returned 500, and its stylesheet returned 404, while a contact-component contract mismatch was not exercised through email sending.These supporting-path findings were separate from the four-model inference results.
Loading 2609.10796v1…