ML Monitor Vitals

Abstract

Background

Patient monitors display multiple physiological measurements simultaneously, including heart rate, peripheral oxygen saturation, blood pressure, respiratory rate, and end-tidal carbon dioxide. Although these measurements are readily available on bedside monitoring equipment, transferring them into a digital record can require manual transcription. Optical character recognition (OCR) provides a potential mechanism for converting monitor photographs into structured physiological data.

Objective

This paper describes the design and implementation of an educational software prototype that uses computer vision, OCR, rule-based parsing, user verification, temporal visualization, and a machine-learning trend model to transform photographs of physiological monitors into structured vital-sign observations.

Methods

The application was implemented in Python using Streamlit for the interactive web interface, Pillow for image processing, regular expressions for structured blood-pressure extraction, Pandas for tabular data management, and Plotly for temporal visualization. The processing pipeline consists of five principal stages: image acquisition, OCR-based text extraction, physiological-value parsing, human verification, and longitudinal trend analysis. A specialized blood-pressure extraction pathway supplements general OCR because systolic and diastolic pressure are commonly represented as a paired numerical expression. Extracted measurements are assigned OCR-derived confidence values when available. Verified measurements are timestamped and stored in application session state. After at least three verified observations, a machine-learning model is invoked to estimate whether the recorded trajectory is improving, stable, or worsening. Rule-based clinical reference patterns are additionally generated from selected physiological thresholds.

Results

The implemented prototype provides an end-to-end workflow from monitor-image upload to structured vital-sign display, manual verification, longitudinal tabulation, visualization, and prototype trend classification. The system supports heart rate, SpO₂, systolic and diastolic blood pressure, respiratory rate, and end-tidal carbon dioxide. It also exposes OCR confidence information and provides rule-based reference considerations for selected abnormal physiological patterns.

Conclusions

The software demonstrates the feasibility of combining OCR, structured parsing, human verification, visualization, and machine-learning methods within a lightweight clinical-data interface. However, the implementation should be regarded strictly as a research and educational prototype. OCR errors, image quality limitations, parser assumptions, limited training data, absence of clinical validation, and potential distribution shift prevent the system from being interpreted as an autonomous clinical decision-support or diagnostic system.

Keywords: optical character recognition, computer vision, vital signs, physiological monitoring, machine learning, clinical informatics, human-in-the-loop systems, medical imaging, Streamlit

1. Introduction

Physiological monitoring is fundamental to the assessment of patients in emergency, prehospital, perioperative, and critical-care environments. Modern patient monitors commonly display several physiological variables simultaneously, including heart rate (HR), peripheral oxygen saturation (SpO₂), non-invasive blood pressure (NIBP), respiratory rate (RR), and end-tidal carbon dioxide (EtCO₂).

Despite the availability of these measurements in digital monitoring systems, photographs or screenshots of monitor displays are sometimes used for documentation, education, retrospective analysis, and software prototyping. Converting such images into structured data presents a computer-vision problem because the measurements are embedded within a graphical user interface rather than provided as machine-readable numerical data.

Optical character recognition provides a general mechanism for extracting textual and numerical information from images. However, physiological monitor displays introduce additional challenges. Multiple numerical values may be present simultaneously, labels may be separated spatially from their associated values, characters may be distorted by image perspective or illumination, and measurement formats may vary between manufacturers and device models.

The prototype described in this paper was designed to investigate a human-in-the-loop workflow in which OCR initially extracts candidate values, software parsing converts those candidates into structured physiological variables, and a human operator verifies the measurements before they are incorporated into a longitudinal timeline.

The architecture additionally incorporates temporal visualization and a machine-learning component intended to characterize the direction of recorded physiological trajectories. A rule-based reference layer provides contextual information regarding selected physiological patterns.

The primary design principle is therefore not autonomous interpretation, but automated extraction followed by human verification.

2. System Objectives

The prototype was developed around six functional objectives:

• Accept a photograph of a physiological monitor.
• Extract visible numerical information using OCR.
• Convert OCR output into structured vital-sign variables.
• Provide confidence information and allow manual verification.
• Store verified observations as a time-indexed sequence.
• Analyze and visualize temporal trends using statistical, rule-based, and machine-learning components.

The system was deliberately structured so that OCR-derived values were not automatically treated as verified clinical observations.

3. System Architecture

The application follows a modular architecture consisting of an interface layer, image-processing layer, parsing layer, state-management layer, visualization layer, and analytical layer.

The high-level processing sequence is:

Monitor Photograph

│

▼

Image Upload

│

▼

Image Preprocessing / OCR

│

├───────────────┐

▼ ▼

General OCR BP-specific OCR

│ │

▼ ▼

Vital Parser BP Candidate Filter

│ │

└───────┬───────┘

▼

Structured Vital Signs

│

▼

OCR Confidence Display

│

▼

Human Verification

│

▼

Timestamped History

│

┌───────┴────────┐

▼ ▼

Visualization ML Trend Model

│ │

└───────┬────────┘

▼

Reference Considerations

This architecture establishes a separation between extraction and interpretation. The extraction subsystem attempts to recover numerical information, whereas the user remains responsible for confirming that the extracted values correspond to the source monitor.

4. Software Environment

The prototype was implemented in Python.

The principal dependencies visible in the application include:

Component	Function
Python	Core programming language
Streamlit	Interactive web application framework
Pillow	Loading and conversion of monitor images
Pandas	Tabular data representation and timeline management
Plotly	Interactive physiological trend visualization
Regular expressions	Numerical pattern recognition, particularly blood pressure
src.ocr	Application-specific OCR functions
src.parser	Application-specific physiological-value parsing
src.ml	Machine-learning trend model

The application imports three primary custom modules:

from src.ocr import extract_text, extract_bp_candidates

from src.parser import parse_vitals

and, when sufficient historical observations exist:

from src.ml import train_trend_model, predict_trend

This modular organization allows OCR, parsing, and machine-learning components to be developed independently of the graphical user interface.

5. Image Acquisition

The first stage of the workflow is image acquisition.

The interface uses Streamlit's file-upload functionality to accept JPEG and PNG images:

uploaded = st.file_uploader(

"Upload a monitor photograph",

type=["jpg", "jpeg", "png"]

)

When an image is supplied, Pillow loads the image and explicitly converts it to RGB:

image = Image.open(

uploaded

).convert("RGB")

This normalization ensures that downstream processing receives a consistent three-channel representation regardless of the original image mode.

The uploaded image is subsequently rendered within the interface so that the operator can visually inspect the source material.

6. Optical Character Recognition

6.1 General OCR

After the operator activates the monitor-reading operation, the image is passed to the general OCR subsystem:

ocr_results = extract_text(image)

The application expects the OCR subsystem to return a list of structured objects. Each object is expected to contain at least a textual representation and an associated confidence value.

Conceptually, the OCR output can be represented as:

[

{

"text": "...",

"confidence": ...

},

...

]

The application includes defensive validation:

if not isinstance(ocr_results, list):

ocr_results = []

This prevents an unexpected OCR return type from propagating directly into later stages of the application.

The OCR results are retained in application session state:

st.session_state.ocr = ocr_results

This allows the extracted text and confidence values to remain accessible after the Streamlit application reruns.

7. Physiological Value Parsing

Following OCR extraction, the recognized text is passed to a dedicated parsing function:

vitals = parse_vitals(ocr_results)

The parser converts unstructured OCR output into a structured dictionary.

The expected variables include:

• HR
• SpO₂
• systolic blood pressure
• diastolic blood pressure
• RR
• EtCO₂

The parser is also treated defensively:

if not isinstance(vitals, dict):

vitals = {}

This establishes a clear boundary between the OCR subsystem and the user interface.

A conceptual representation of the resulting object is:

{

"hr": ...,

"spo2": ...,

"bp_sys": ...,

"bp_dia": ...,

"rr": ...,

"etco2": ...

}

The exact implementation of parse_vitals() is contained in the external parser module and therefore cannot be inferred completely from the provided interface code. Consequently, this manuscript describes the observable interface contract rather than assuming a specific internal parsing algorithm.

8. Specialized Blood-Pressure Extraction

Blood pressure receives an additional processing pathway.

This design is important because blood pressure is represented as a paired measurement rather than a single numerical value. The prototype therefore calls:

bp_results = extract_bp_candidates(image)

Candidate text is subsequently examined using a regular expression:

r"(\d{2,3})\s*[/\-]\s*(\d{2,3})"

This expression recognizes patterns such as:

120/80

120 - 80

The extracted components are interpreted as systolic and diastolic pressure.

The prototype then applies physiological plausibility constraints:

50 <= systolic <= 250

20 <= diastolic <= 150

systolic > diastolic

Candidates failing these criteria are discarded.

If multiple valid candidates are detected, the candidate with the highest OCR confidence is selected.

This creates a simple confidence-based candidate-selection mechanism:

Candidate BP values

│

▼

Regex pattern matching

│

▼

Numerical validation

│

▼

Plausible candidates

│

▼

Highest OCR confidence

│

▼

Selected BP

The resulting blood-pressure values are then inserted into the structured vital-sign dictionary.

9. Confidence Estimation

The application incorporates a confidence-display mechanism to communicate uncertainty associated with OCR extraction.

The find_confidence() function first searches for a parser-provided confidence value:

parser_confidence = vitals.get(

f"{vital_name}_confidence"

)

If a parser-specific confidence value is unavailable, the application searches the raw OCR results for a numerical match corresponding to the extracted vital.

For example, if the structured heart rate is 82, the algorithm examines OCR outputs for a numerical value matching 82 and retains the highest associated confidence.

For blood pressure, the function instead searches for OCR text containing a slash, reflecting the paired representation of the measurement.

The resulting confidence is classified into three presentation levels:

• High: ≥ 0.80
• Medium: 0.50–0.79
• Low: < 0.50

These thresholds affect presentation only. They do not constitute experimentally validated probabilities of correct physiological extraction.

This distinction is important because OCR confidence is not necessarily equivalent to clinical correctness.

10. Data Validation and Defensive Programming

The interface includes several mechanisms intended to prevent malformed data from causing invalid displays or application failures.

The safe_int() function verifies that values are numerical and fall within specified limits before converting them to integers.

For example:

safe_int(

hr,

0,

300

)

is used to initialize the manually editable HR field.

The interface similarly imposes explicit numerical limits on user-entered verification values.

Examples include:

HR: 0–300 bpm

SpO₂: 0–100%

Systolic BP: 0–300 mmHg

Diastolic BP: 0–200 mmHg

RR: 0–100/min

EtCO₂: 0–150 mmHg

These bounds are primarily software safeguards rather than validated clinical reference ranges.

11. Human Verification Layer

A central feature of the architecture is the manual verification stage.

Extracted measurements are displayed to the user before being added to the longitudinal record.

The interface explicitly instructs the operator to compare the displayed values against the physical monitor.

The user can modify:

• HR
• SpO₂
• systolic BP
• diastolic BP
• RR
• EtCO₂

Only after the operator activates the verification control is the observation added to the historical dataset.

This produces a human-in-the-loop pipeline:

OCR extraction

↓

Automated parsing

↓

Displayed candidate values

↓

Human verification/correction

↓

Verified observation

This design substantially changes the interpretation of the resulting dataset. The longitudinal history represents user-confirmed values, rather than purely automated OCR output.

12. Temporal Data Representation

Verified observations are stored using Streamlit's session-state mechanism.

Each observation contains:

{

"time": datetime.now(),

"HR": verified_hr,

"SpO2": verified_spo2,

"BP Sys": verified_sys,

"BP Dia": verified_dia,

"RR": verified_rr,

"EtCO2": verified_etco2

}

Consequently, each record consists of a timestamp and six physiological variables.

The history is subsequently converted into a Pandas DataFrame:

df = pd.DataFrame(

st.session_state.history

)

This representation allows the observations to be displayed in tabular form and passed to downstream visualization and machine-learning routines.

13. Visualization of Physiological Trends

The temporal data are visualized using Plotly.

A line-and-marker trace is generated for:

• HR
• SpO₂
• RR
• EtCO₂

Blood pressure is retained in the tabular history but is not plotted in the provided trend graph.

Each variable is added as a separate Plotly trace:

go.Scatter(

x=chart_df["time"],

y=chart_df[column],

mode="lines+markers",

name=column

)

The visualization uses a white plotting template and includes labeled axes.

The purpose of the graph is descriptive: it allows an operator to inspect temporal trajectories rather than relying exclusively on individual measurements.

14. Machine-Learning Trend Analysis

A machine-learning subsystem is activated when at least three verified observations have been recorded.

The application dynamically imports:

from src.ml import (

train_trend_model,

predict_trend

)

The model is trained through:

model = train_trend_model()

and subsequently applied to the recorded history:

prediction, confidence, probabilities = (

predict_trend(

model,

st.session_state.history

)

)

The model returns three principal outputs:

• A categorical trend prediction.
• A model confidence value.
• A dictionary of class probabilities.

The categorical output has three possible states:

Improving

Stable

Worsening

The interface presents the class probabilities separately.

Importantly, the provided code does not reveal the internal implementation of train_trend_model() or predict_trend(). Therefore, characteristics such as the machine-learning algorithm, feature engineering procedure, training-set size, class balance, validation strategy, and performance metrics cannot be scientifically established from the supplied interface code alone.

The application's own labeling appropriately identifies this component as a prototype trend estimator rather than a validated clinical deterioration score.

15. Clinical Reference Layer

The application contains a rule-based reference subsystem that evaluates selected physiological measurements against predefined thresholds.

The implementation evaluates:

• HR > 100 bpm
• HR < 60 bpm
• SpO₂ < 94%
• systolic BP < 90 mmHg
• RR > 20/min
• EtCO₂ < 35 mmHg

When a threshold is met, the corresponding pattern is displayed along with a list of possible clinical considerations.

For example, an elevated HR triggers a "tachycardia pattern" containing possible considerations such as physiological stress, fever, hypovolemia, hypoxemia, medication effects, and cardiac rhythm disturbance.

These rules are implemented using straightforward conditional statements rather than a probabilistic diagnostic model.

For example:

if (

isinstance(hr_value, (int, float))

and hr_value > 100

):

The output is therefore better characterized as a rule-based clinical reference layer rather than an automated diagnostic system.

The application explicitly communicates that these considerations are not diagnoses.

16. User Interface Design

The interface was implemented entirely within Streamlit.

The major interface sections are:

• Patient context
• Monitor image upload
• Extracted vital signs
• Verification controls
• OCR details
• Patient timeline
• Trend graph
• Machine-learning trend estimate
• Clinical reference considerations

Custom CSS is embedded through Streamlit's Markdown functionality.

The styling creates:

• high-contrast vital-sign cards,
• confidence indicators,
• warning panels,
• reference panels,
• a wide application layout,
• visual separation between functional sections.

The design therefore emphasizes rapid interpretation of structured values while preserving access to the underlying OCR results.

17. Application State Management

Because Streamlit applications rerun portions of the Python script when users interact with widgets, persistent information is maintained through st.session_state.

Three principal state variables are initialized:

st.session_state.vitals

st.session_state.ocr

st.session_state.history

They represent:

State variable	Purpose
vitals	Most recently parsed physiological values
ocr	Most recent OCR output
history	User-verified longitudinal observations

This state model allows the application to preserve the patient's recorded timeline across interface interactions during the active application session.

The supplied implementation does not show persistent database storage. Therefore, the history should be interpreted as session-level application state rather than a permanent medical record.

18. Error Handling

The principal image-processing workflow is enclosed in a try/except block.

If OCR, parsing, blood-pressure extraction, or another operation raises an exception, the interface reports the error rather than terminating the entire application.

Similarly, machine-learning execution is isolated within its own error-handling block:

try:

...

except Exception as e:

st.warning(

f"ML trend model unavailable: {e}"

)

This allows the core extraction and visualization workflow to remain usable if the optional trend-analysis subsystem fails.

19. Safety-Oriented Design

The prototype incorporates several safeguards intended to reduce inappropriate interpretation.

First, automated OCR values are explicitly presented as values requiring verification.

Second, the application separates extracted values from verified values.

Third, the machine-learning component is explicitly labeled as a prototype trend estimate.

Fourth, the clinical-reference layer is explicitly described as non-diagnostic.

Finally, the interface instructs users to compare extracted values with the original monitor and patient assessment.

These design decisions establish a decision-support boundary in which the software assists with transcription and visualization but does not replace clinical assessment.

20. Discussion

The implemented architecture demonstrates how multiple relatively simple computational components can be combined into an end-to-end physiological-data pipeline.

The first contribution is the integration of image-based extraction with structured physiological parsing. Rather than requiring manual transcription from every monitor photograph, OCR can provide candidate numerical values that are subsequently normalized into a predefined schema.

The second contribution is the use of a specialized blood-pressure extraction pathway. Blood pressure presents a different parsing problem because its two components must be identified together. Regular-expression matching and physiological plausibility filtering provide a lightweight mechanism for rejecting obviously inappropriate candidates.

The third contribution is the human-verification architecture. Instead of assuming OCR output is correct, the system explicitly inserts a human confirmation stage before measurements enter the longitudinal dataset. This is particularly important because OCR errors may result from glare, blur, image perspective, character segmentation, monitor typography, or overlapping graphical elements.

The fourth contribution is the integration of temporal visualization. Once measurements are verified, individual observations can be transformed into a time series, making changes in HR, SpO₂, RR, and EtCO₂ easier to inspect.

Finally, the prototype demonstrates how a machine-learning layer can be incorporated after data acquisition. However, the usefulness of such a model depends strongly on the quality, size, representativeness, labeling methodology, and validation of its training data.

21. Limitations

Several limitations should be considered.

21.1 OCR Performance

OCR accuracy is dependent on the quality of the input image and the underlying OCR implementation. The provided code does not specify the OCR engine, preprocessing operations, image segmentation strategy, character-recognition architecture, or benchmark performance.

Consequently, sensitivity and specificity for individual vital signs cannot be calculated from the interface code alone.

21.2 Monitor Variability

Different monitor manufacturers and models may use different fonts, layouts, colors, abbreviations, and numerical arrangements. A parser developed around one display configuration may therefore perform differently on another.

21.3 Blood-Pressure Parsing

The blood-pressure regular expression assumes a relatively conventional numerical representation. Alternative display formats may not be recognized.

The numerical plausibility constraints also prevent certain values from being selected even if they were correctly displayed by an unusual monitor configuration.

21.4 Confidence Interpretation

OCR confidence is used as a proxy for extraction reliability, but it should not automatically be interpreted as the probability that the physiological value is clinically correct.

21.5 Machine-Learning Validation

The machine-learning implementation is external to the supplied interface code. The training data, feature construction, model architecture, class definitions, cross-validation strategy, and independent test performance are not provided.

Therefore, no claims regarding model accuracy, sensitivity, specificity, calibration, generalizability, or clinical utility can be made from the supplied code.

21.6 Limited Temporal Data

The machine-learning component requires only three observations before producing an estimate. From a scientific perspective, three observations may provide very limited information about a physiological trajectory.

The minimum-observation requirement should therefore not be confused with evidence that three measurements are sufficient for reliable clinical trend prediction.

21.7 Lack of Persistent Clinical Storage

The supplied application stores historical measurements in Streamlit session state. No electronic health record integration, database layer, audit log, or durable patient-record mechanism is demonstrated.

21.8 Rule-Based Reference Thresholds

The clinical reference subsystem uses fixed numerical thresholds. Physiological interpretation can depend on age, baseline physiology, clinical context, treatment, environment, and measurement conditions. Consequently, threshold-triggered text should not be interpreted as individualized diagnosis.

22. Reproducibility and Future Evaluation

A rigorous evaluation of the prototype would require a dedicated dataset of monitor photographs with ground-truth annotations.

A suitable evaluation protocol could contain the following stages:

Stage 1: Image Dataset Construction

Collect monitor images representing different:

• monitor manufacturers,
• display layouts,
• lighting conditions,
• camera angles,
• image resolutions,
• patient-monitor configurations,
• physiological value ranges.

Stage 2: Ground-Truth Annotation

Each image should be manually annotated for:

• HR,
• SpO₂,
• systolic BP,
• diastolic BP,
• RR,
• EtCO₂.

The ground truth should be independently verified against the original monitor output.

Stage 3: OCR Evaluation

Measure:

• character-level recognition accuracy,
• numerical recognition accuracy,
• vital-sign extraction accuracy,
• false-positive rate,
• missing-value rate.

Stage 4: Parser Evaluation

Compare parsed values with ground truth and calculate variable-specific metrics.

Stage 5: Blood-Pressure Evaluation

Evaluate systolic and diastolic pressure independently and jointly, including cases containing visually ambiguous characters.

Stage 6: Human-in-the-Loop Evaluation

Measure the proportion of OCR outputs requiring manual correction and the time required to verify each observation.

Stage 7: Machine-Learning Evaluation

For the trend model, an independent dataset should be used for testing.

Potential metrics include:

• accuracy,
• precision,
• recall,
• F1 score,
• confusion matrix,
• calibration,
• class-specific sensitivity,
• temporal generalization.

Importantly, the test data should remain independent from the training data to prevent optimistic performance estimates.

23. Proposed Experimental Methodology

A formal study could compare three workflows:

Workflow A — Manual transcription

Monitor image → Human reads → Manual entry

Workflow B — OCR-assisted transcription

Monitor image → OCR → Human verification

Workflow C — Automated extraction

Monitor image → OCR → Parser → Automated record

Workflow B would be particularly informative because it reflects the architecture implemented in the prototype.

Primary outcome measures could include:

• Time required to produce a verified vital-sign record.
• Numerical transcription error rate.
• Percentage of observations requiring correction.
• Agreement between extracted and ground-truth values.
• User-reported workload.

This experimental design would permit assessment of whether OCR assistance reduces transcription burden while maintaining human oversight.

24. Ethical and Clinical Considerations

A system processing physiological information must distinguish between technical extraction and clinical interpretation.

The prototype's architecture appropriately separates these functions. OCR identifies candidate information from an image; verification establishes the values that enter the historical record; visualization represents temporal data; and the reference layer provides possible contextual considerations.

None of these operations independently establishes a diagnosis.

Before deployment in clinical environments, additional considerations would include:

• patient privacy,
• secure image handling,
• access control,
• auditability,
• data retention,
• model validation,
• clinical governance,
• usability testing,
• regulatory classification,
• human-factors evaluation,
• monitoring for systematic extraction errors.

In particular, performance should be evaluated across the diversity of monitor displays and clinical contexts in which the system is intended to operate.

25. Conclusion

This paper describes an educational prototype that combines computer vision, OCR, rule-based numerical parsing, human verification, temporal data visualization, machine-learning trend estimation, and clinical reference rules within a single Python-based application.

The architecture follows a sequential human-in-the-loop workflow:

Image

↓

OCR

↓

Structured parsing

↓

Confidence assessment

↓

Human verification

↓

Timestamped physiological history

↓

Visualization

↓

Prototype trend analysis

↓

Reference considerations

The principal engineering feature is the separation between automated extraction and verified clinical data. This approach recognizes that OCR output can contain errors and therefore should not automatically become part of a longitudinal physiological record.

The prototype demonstrates the technical feasibility of transforming photographs of physiological monitors into structured observations and subsequently analyzing those observations over time. Nevertheless, the current implementation does not provide evidence of clinical accuracy or clinical effectiveness. In particular, the OCR subsystem, parsing subsystem, and machine-learning model require independent validation before quantitative claims regarding performance can be established.

Accordingly, the system is best understood as a research and educational prototype illustrating the integration of computer vision and machine learning into physiological-data workflows rather than as an autonomous diagnostic or clinical decision-making system.

Abstract

This manual describes the potential clinical applications, operational workflow, safety requirements, implementation considerations, and future development pathway for an image-based physiological monitoring support system capable of extracting vital-sign information from photographs of patient-monitor displays.

The system combines optical character recognition (OCR), numerical parsing, confidence estimation, human verification, temporal data visualization, prototype machine-learning trend analysis, and rule-based clinical reference information. Its primary potential clinical function is to reduce the burden associated with manual transcription of physiological measurements while creating a structured representation of monitor observations.

The system should initially be considered an assistive clinical-information technology rather than an autonomous diagnostic system. In a clinical environment, extracted measurements should remain subject to verification by appropriately trained healthcare personnel. The system should not independently determine diagnosis, treatment, disposition, or emergency intervention.

A staged implementation strategy is recommended, beginning with retrospective validation and simulated clinical workflows, followed by supervised prospective evaluation and only subsequently consideration of operational deployment. Clinical implementation should incorporate performance monitoring, cybersecurity and privacy controls, human-factors evaluation, documentation, governance, and applicable regulatory review.

1. Purpose of This Manual

The purpose of this manual is to describe how an image-based vital-sign extraction system could potentially be incorporated into clinical workflows and how its capabilities could be evaluated before clinical deployment.

The manual addresses:

• potential clinical applications;
• intended users;
• workflow integration;
• operational procedures;
• human verification;
• possible clinical benefits;
• limitations;
• safety requirements;
• validation methodology;
• quality assurance;
• data governance;
• machine-learning considerations;
• implementation stages;
• future development.

The document is intended for researchers, clinicians, clinical informaticians, software developers, biomedical engineers, and healthcare organizations evaluating the feasibility of this type of technology.

2. Fundamental Clinical Principle

The central principle of clinical implementation should be:

The system extracts and organizes information; the healthcare professional remains responsible for clinical interpretation and decision-making.

The system should therefore be positioned between the physical monitoring device and the clinician's documentation or information workflow.

Conceptually:

Patient

│

▼

Physiological monitor

│

▼

Monitor display

│

▼

Image acquisition

│

▼

OCR / image analysis

│

▼

Structured candidate values

│

▼

Human verification

│

▼

Clinical record / timeline

│

▼

Clinician interpretation

│

▼

Clinical decision

This separation is consistent with the broader principle that humans should remain in control of healthcare decisions when AI technologies are used. WHO specifically identifies human autonomy, safety, transparency, accountability, and continuous evaluation as important principles for AI in health.

3. Potential Clinical Value

The most immediate potential benefit is not autonomous diagnosis.

Instead, the system could assist with information acquisition and organization.

3.1 Reduction of Manual Transcription

Healthcare personnel frequently encounter numerical physiological information displayed on monitors.

A photograph-based workflow could potentially transform:

Monitor → photograph → OCR → structured values

rather than:

Monitor → clinician reads values → clinician manually types values

This could reduce repetitive transcription work and potentially reduce certain types of manual-entry errors.

However, this potential benefit must be demonstrated experimentally rather than assumed.

4. Potential Clinical Use Cases

4.1 Emergency Department

A potential application is rapid capture of vital signs during emergency assessment.

For example:

Patient arrives

↓

Monitor applied

↓

Monitor displays vital signs

↓

Image captured

↓

System extracts candidate values

↓

Clinician verifies

↓

Verified values documented

The system could potentially support rapid organization of HR, SpO₂, BP, RR, and EtCO₂ measurements.

It should not replace the patient's actual monitor, pulse oximeter, blood-pressure measurement, clinical examination, ECG, or clinician assessment.

5. Prehospital and EMS Applications

A particularly interesting potential application is prehospital medicine.

During transport or field treatment, physiological values may change repeatedly.

A structured timeline could represent:

Time	HR	SpO₂	BP	RR	EtCO₂
14:05	118	91	92/58	28	29
14:12	110	94	98/62	24	32
14:20	101	96	105/68	21	35

Rather than considering each measurement independently, clinicians can inspect the trajectory.

Potential uses include:

• documenting serial observations;
• reviewing physiological response to treatment;
• transferring structured information between providers;
• supporting handoff documentation;
• creating research datasets;
• retrospective quality review.

The technology would still require verification against the actual monitor.

6. Critical-Care and Procedural Environments

The same concept could potentially be investigated in:

• intensive care;
• procedural sedation;
• operating-room environments;
• recovery areas;
• transport medicine;
• simulation laboratories.

The value may be greatest where multiple physiological variables are recorded repeatedly.

For example, EtCO₂ and respiratory rate can change over time, and a structured timeline may make these changes easier to review.

However, deployment in high-acuity environments should require particularly rigorous validation because an extraction error could potentially be consequential.

7. Patient Handoffs

Another potential application is information transfer.

A clinician could capture a monitor image before handoff, verify the extracted measurements, and generate a structured record of recent observations.

The workflow could be:

Before handoff

↓

Capture monitor

↓

Extract values

↓

Verify values

↓

Review timeline

↓

Communicate verified observations

The system could therefore support communication without becoming the authority for clinical interpretation.

This corresponds to a broader clinical decision-support principle described by AHRQ: useful information should reach the appropriate person, in an appropriate format, through an appropriate channel, at the appropriate point in workflow.

8. Education and Simulation

A lower-risk initial application is clinical education.

The system could be used in:

• EMS simulations;
• nursing education;
• medical-school simulation;
• critical-care training;
• clinical informatics research;
• OCR and machine-learning research.

For example, an instructor could photograph a simulated patient's monitor and ask learners to:

• verify the extracted measurements;
• review the temporal trajectory;
• identify changes;
• discuss possible physiological explanations;
• compare their interpretation with the simulation scenario.

This provides a useful research environment without initially placing the software in direct clinical decision-making.

9. Research Applications

The system could also serve as a research data-acquisition tool.

A standardized workflow could convert monitor images into structured observations:

Image

↓

OCR

↓

Parser

↓

Human verification

↓

Structured dataset

This could facilitate research involving:

• physiological time-series analysis;
• human-computer interaction;
• OCR performance;
• monitor-display recognition;
• clinical documentation;
• machine-learning model development;
• simulation research.

For research involving human participants, appropriate institutional ethical review and data protections would be required. WHO emphasizes formal ethical oversight for research involving human subjects.

10. Intended Users

Potential users could include:

Primary users

• physicians;
• nurses;
• paramedics;
• emergency medical technicians;
• respiratory therapists;
• anesthesia personnel;
• critical-care personnel.

Secondary users

• clinical researchers;
• biomedical engineers;
• clinical informaticians;
• simulation educators;
• quality-improvement teams.

Users should receive training regarding:

• the purpose of the software;
• its limitations;
• OCR errors;
• confidence values;
• verification requirements;
• appropriate use of trend estimates;
• appropriate escalation procedures.

11. Recommended Clinical Workflow

A safe implementation should use the following workflow.

Step 1 — Acquire the Image

Capture a clear image of the monitor.

The operator should attempt to minimize:

• glare;
• motion blur;
• extreme viewing angles;
• reflections;
• obstruction of numerical values.

Step 2 — Run Extraction

The image is submitted to the application.

The system performs:

Image

↓

OCR

↓

Numerical parsing

↓

Blood-pressure extraction

↓

Candidate vital signs

Step 3 — Review Extracted Values

The application displays the candidate measurements.

For example:

HR 112 bpm

SpO₂ 91%

BP 92/58 mmHg

RR 28/min

EtCO₂ 29 mmHg

The system also presents available OCR confidence information.

12. Step 4 — Mandatory Human Verification

The clinician should compare every extracted value with the original monitor.

Possible outcomes are:

Correct

The extracted value matches the monitor.

Incorrect

The extracted value does not match the monitor.

Uncertain

The clinician cannot confidently determine the displayed value.

In the latter two situations, the value should be corrected or rejected rather than automatically incorporated into the clinical record.

13. Step 5 — Record the Verified Observation

Only verified measurements should enter the longitudinal timeline.

The system records:

Timestamp

HR

SpO₂

Systolic BP

Diastolic BP

RR

EtCO₂

The distinction between extracted and verified data should be preserved in any production implementation.

14. Step 6 — Review the Timeline

Multiple verified observations can be displayed chronologically.

The clinician can examine:

• absolute values;
• direction of change;
• rate of change;
• response following an intervention;
• persistence of abnormalities.

This provides contextual information that is not available from a single measurement.

15. Machine-Learning Trend Analysis

The current prototype provides a three-category trend output:

Improving

Stable

Worsening

This feature has potential as a research direction but should not initially be treated as a validated clinical prediction system.

The displayed probability values should not be interpreted as probabilities of patient deterioration.

Before clinical use, the model would require:

• a clearly defined target outcome;
• representative training data;
• independent validation data;
• prospective evaluation;
• calibration analysis;
• subgroup analysis;
• assessment of missing data;
• evaluation across different monitor types;
• monitoring for model drift.

WHO guidance emphasizes rigorous testing, monitoring, and evaluation of AI technologies used in health systems.

16. Clinical Reference Function

The rule-based component identifies selected physiological patterns.

Examples include:

HR > 100 → tachycardia pattern

HR < 60 → bradycardia pattern

SpO₂ < 94% → low oxygen saturation pattern

SBP < 90 → low systolic BP pattern

RR > 20 → tachypnea pattern

EtCO₂ < 35 → low EtCO₂ pattern

The system then displays possible clinical considerations.

This functionality should be treated as a reference tool, not as diagnostic reasoning.

For example:

Low SpO₂

↓

Possible considerations

↓

Clinician evaluates:

airway

breathing

circulation

history

physical examination

monitor reliability

treatment response

The software should never convert a threshold into a definitive diagnosis.

17. Example Clinical Scenario

Consider a hypothetical patient whose monitor displays:

HR: 124 bpm

SpO₂: 89%

BP: 86/54 mmHg

RR: 30/min

EtCO₂: 27 mmHg

The system extracts these values.

The clinician verifies that they correspond to the monitor.

The timeline may then show:

Initial

HR 124

SpO₂ 89%

BP 86/54

RR 30

EtCO₂ 27

After intervention

HR 112

SpO₂ 93%

BP 94/60

RR 25

EtCO₂ 30

Later

HR 101

SpO₂ 96%

BP 105/67

RR 21

EtCO₂ 34

The system can visualize this trajectory.

The clinician can then independently consider the patient's history, examination findings, ECG, treatment response, and other available information.

The important distinction is that the software organizes the physiological observations; the clinician interprets their clinical meaning.

18. Potential Advantages

If validated, the system could potentially provide several benefits.

18.1 Documentation Efficiency

Automated extraction could reduce repetitive numerical transcription.

18.2 Structured Data

Photographs can be converted into structured records suitable for analysis.

18.3 Longitudinal Visualization

Serial measurements can be represented graphically.

18.4 Human Verification

The workflow allows clinicians to correct OCR errors before measurements become verified observations.

18.5 Research Dataset Generation

The technology could facilitate creation of structured physiological datasets from previously unstructured images.

18.6 Interoperability Potential

A future implementation could potentially transmit verified measurements into an electronic health record through an appropriately designed integration layer.

A production implementation would require careful workflow design rather than simply adding another application to the clinician's workload. AHRQ's CDS implementation guidance emphasizes identifying user needs, integrating technology into workflow, and evaluating whether the implementation achieves its intended objectives.

19. Major Clinical Risks

Potential risks include:

19.1 False Extraction

The system may read:

120

when the monitor actually displays:

180

This could create a clinically misleading record.

19.2 Missing Values

OCR may fail to identify a measurement.

A missing value should never automatically be interpreted as a normal value.

19.3 Incorrect Blood Pressure

A paired numerical pattern may be incorrectly interpreted as blood pressure.

The system should therefore preserve access to the source image and require verification.

19.4 Image Quality

Blur, glare, reflections, poor lighting, or unusual viewing angles can degrade OCR performance.

19.5 Monitor Variability

Different monitor manufacturers and display configurations may produce substantially different OCR performance.

19.6 Automation Bias

Clinicians may unintentionally trust software-generated values simply because they appear in a professional-looking interface.

This is a major human-factors concern.

The interface should therefore make the verification status highly visible.

20. Recommended Verification Status

A production system should explicitly distinguish:

UNREAD

OCR EXTRACTED

REVIEW REQUIRED

VERIFIED

CORRECTED

REJECTED

For example:

Measurement	Extracted	Verified	Status
HR	118	118	VERIFIED
SpO₂	91	91	VERIFIED
BP	82/51	92/61	CORRECTED
RR	29	29	VERIFIED
EtCO₂	28	28	VERIFIED

This would make the provenance of each measurement substantially clearer.

21. Clinical Safety Architecture

A clinical implementation should incorporate multiple safety layers.

┌─────────────────────┐

│ Monitor / Patient │

└──────────┬──────────┘

│

▼

┌─────────────────────┐

│ Image Acquisition │

└──────────┬──────────┘

│

▼

┌─────────────────────┐

│ OCR / Extraction │

└──────────┬──────────┘

│

▼

┌─────────────────────┐

│ Validation Rules │

└──────────┬──────────┘

│

▼

┌─────────────────────┐

│ Human Verification │

└──────────┬──────────┘

│

▼

┌─────────────────────┐

│ Verified Data │

└──────────┬──────────┘

│

┌─────────────┴──────────────┐

▼ ▼

┌─────────────────┐ ┌─────────────────┐

│ Timeline │ │ Trend Analysis │

└─────────────────┘ └─────────────────┘

No automated output should bypass the verification layer during the initial clinical implementation.

22. Clinical Validation Program

Before deployment, a formal validation program should be performed.

Phase I — Technical Validation

Determine whether the system correctly extracts values from monitor images.

Measure:

• sensitivity;
• specificity;
• exact numerical agreement;
• OCR character accuracy;
• missing-value frequency;
• false extraction frequency.

Phase II — Multidevice Validation

Test the system across:

• different monitor manufacturers;
• different monitor models;
• different display configurations;
• different screen resolutions;
• different lighting environments;
• different camera devices.

Phase III — Simulated Clinical Validation

Place the system into realistic simulation scenarios.

Measure:

• time saved;
• correction rate;
• user workload;
• usability;
• error frequency;
• human-factors problems.

Phase IV — Prospective Clinical Evaluation

If justified and appropriately approved, evaluate the system prospectively under controlled conditions.

The primary objective should initially be information extraction and documentation performance, not autonomous diagnosis.

23. Performance Metrics

A formal study could report:

Extraction accuracy

Accuracy=Correctly extracted measurementsTotal measurementsAccuracy = \frac{\text{Correctly extracted measurements}} {\text{Total measurements}}

Error rate

Error Rate=Incorrect measurementsTotal measurementsError\ Rate = \frac{\text{Incorrect measurements}} {\text{Total measurements}}

Missing-value rate

Missing Rate=Measurements not extractedExpected measurementsMissing\ Rate = \frac{\text{Measurements not extracted}} {\text{Expected measurements}}

Verification correction rate

Correction Rate=OCR measurements corrected by usersMeasurements reviewedCorrection\ Rate = \frac{\text{OCR measurements corrected by users}} {\text{Measurements reviewed}}

For the machine-learning component, additional metrics should include:

• sensitivity;
• specificity;
• precision;
• recall;
• F1 score;
• calibration;
• confusion matrix;
• performance across clinically relevant subgroups.

24. Human-Factors Evaluation

Technical accuracy alone is insufficient.

A system could have excellent OCR performance but still be unsafe if users misunderstand its output.

Evaluation should therefore examine:

• whether clinicians notice verification warnings;
• whether confidence information is understood;
• whether users recognize unverified values;
• whether users become overly reliant on automated results;
• whether the interface interrupts workflow;
• whether the system increases or decreases documentation burden.

The design should favor clear presentation of uncertainty rather than hiding it.

25. Data Privacy and Security

A clinical implementation would potentially process patient-related images.

Consequently, safeguards should address:

• authentication;
• authorization;
• encryption;
• secure transmission;
• data retention;
• audit logs;
• access control;
• secure deletion;
• minimum necessary data collection.

Images should not be retained indefinitely unless there is a defined clinical, research, or operational purpose.

If the system is integrated into a healthcare organization, its data architecture should be reviewed against applicable privacy, security, and health-information requirements.

26. Electronic Health Record Integration

A mature implementation could potentially integrate verified observations with an electronic health record.

The desired workflow could be:

Monitor image

↓

OCR

↓

Verification

↓

Structured observation

↓

EHR interface

↓

Clinical record

However, automated insertion into the EHR should not occur simply because OCR produced a value.

The record should indicate:

• source;
• timestamp;
• extraction method;
• verification status;
• correcting user;
• original extracted value;
• final verified value.

This creates an auditable chain of provenance.

27. Regulatory Considerations

The regulatory status of clinical software depends on its intended use and functionality.

In the United States, FDA's January 2026 Clinical Decision Support Software guidance distinguishes certain clinical decision-support functions from software functions that remain subject to medical-device regulation. The determination depends on the specific function and intended use rather than simply the fact that software uses AI or machine learning.

Therefore, an organization developing a clinical version should conduct a formal regulatory assessment before deployment.

The following should be explicitly documented:

• intended users;
• intended patient population;
• intended clinical setting;
• intended use;
• claims made by the manufacturer;
• inputs;
• outputs;
• degree of automation;
• clinical consequences of incorrect output.

The prototype's educational labeling should not be assumed to determine regulatory status if a future implementation makes clinical claims.

28. Governance

Clinical deployment should establish a governance structure involving, as appropriate:

• clinicians;
• nursing representatives;
• EMS representatives;
• biomedical engineering;
• clinical informatics;
• information security;
• privacy officers;
• quality and patient-safety personnel;
• legal/regulatory specialists;
• software engineers;
• data scientists.

WHO recommends governance structures that address safety, accountability, transparency, equity, privacy, and human oversight when AI is used in health.

29. Recommended Deployment Strategy

A staged deployment is preferable to immediate clinical integration.

Stage 1 — Research

Use the system exclusively with retrospective or simulated data.

Stage 2 — Silent Evaluation

The system processes clinical images without influencing patient care.

Its predictions are compared with ground truth.

Stage 3 — Supervised Workflow

Clinicians can view extracted information, but all values require explicit verification.

Stage 4 — Limited Operational Use

If validated and appropriately governed, the system can support documentation in a narrowly defined clinical environment.

Stage 5 — Continuous Monitoring

Performance should continue to be monitored after deployment.

This is important because real-world image distributions can differ from development datasets.

30. Continuous Quality Monitoring

A production system should monitor:

OCR accuracy

↓

Correction frequency

↓

Monitor-specific errors

↓

User feedback

↓

Model performance

↓

Safety events

↓

System improvement

Performance should be stratified by monitor model and clinical environment.

A sudden increase in correction rates could indicate:

• software changes;
• new monitor hardware;
• altered display configuration;
• camera changes;
• environmental conditions;
• model drift.

31. Recommended Clinical Operating Procedure

A concise operational protocol could be:

Before use

• Confirm that the system is available and functioning.
• Confirm that the monitor is functioning normally.
• Capture a clear image.
• Ensure the patient and monitor information are handled according to privacy requirements.

During extraction

• Submit the image.
• Review extracted measurements.
• Review confidence indicators.
• Compare each value with the monitor.

Before documentation

• Correct inaccurate values.
• Reject unreadable values.
• Confirm all required measurements.
• Add only verified observations to the timeline.

During clinical interpretation

• Review the temporal trend.
• Consider the patient's clinical condition.
• Confirm measurements using the primary monitor or other appropriate clinical methods when necessary.
• Use clinical judgment and applicable protocols.

After use

• Document according to institutional policy.
• Report technical errors.
• Report clinically significant discrepancies.
• Do not rely on historical automated output if its verification status is unknown.

32. What the System Should Not Do

Until extensive validation and appropriate authorization have been completed, the system should not independently:

• diagnose a patient;
• determine patient disposition;
• recommend medication administration;
• recommend invasive procedures;
• replace ECG interpretation;
• replace direct patient assessment;
• replace the physiological monitor;
• determine whether a patient is clinically stable;
• issue autonomous emergency treatment instructions;
• suppress clinically significant alarms;
• automatically assume an OCR value is correct.

The machine-learning trend estimate should likewise not be treated as a validated deterioration score unless and until it has undergone appropriate clinical validation.

33. Future Development

Several developments could significantly increase the system's potential.

33.1 Advanced Computer Vision

Future versions could incorporate:

• monitor-layout detection;
• region-of-interest detection;
• perspective correction;
• glare reduction;
• image enhancement;
• display segmentation;
• device-specific recognition.

33.2 Multi-Modal Validation

The system could eventually compare information from multiple sources:

Monitor image

+

ECG

+

Pulse oximeter

+

Capnography

+

Blood pressure

This could improve consistency checking, although each additional data source would introduce its own validation requirements.

33.3 Real-Time Video

Instead of individual photographs, a future system could analyze a video stream of the monitor.

Potentially:

Video

↓

Frame selection

↓

Monitor detection

↓

OCR

↓

Temporal filtering

↓

Vital-sign sequence

Temporal filtering could reduce transient OCR errors.

33.4 Device-Specific Models

Different monitor families could have dedicated recognition models.

The system could first determine:

Monitor type

↓

Display layout

↓

Expected value locations

↓

Targeted OCR

This may improve extraction reliability.

33.5 Clinical Interoperability

Verified observations could eventually be represented using standardized healthcare data structures and transmitted to clinical information systems.

Such integration would require formal interoperability, security, provenance, and regulatory analysis.

34. Overall Clinical Potential

The greatest near-term potential of this technology is likely to be in structured physiological-data capture and documentation assistance, rather than autonomous clinical decision-making.

Its potential can be conceptualized as:

Clinical Potential

│

┌───────────────┼────────────────┐

▼ ▼ ▼

Documentation Research Education

│ │ │

▼ ▼ ▼

Vital extraction Dataset creation Simulation

│

▼

Temporal organization

│

▼

Human-reviewed trend information

This approach could allow relatively unstructured visual information on physiological monitors to become structured data suitable for documentation, research, visualization, and potentially future clinical decision-support applications.

35. Final Implementation Principle

The appropriate clinical philosophy is:

Automate the transcription task while preserving human responsibility for verification and clinical interpretation.

The technology's potential should therefore be evaluated according to whether it can make information capture:

• faster;
• more structured;
• more traceable;
• less burdensome;
• sufficiently accurate;
• understandable to clinicians;
• safely integrated into existing workflows.

Clinical implementation should proceed only after evidence demonstrates that the benefits outweigh the risks for the specific intended use.

WHO emphasizes that AI used in healthcare should be designed around safety, human autonomy, transparency, accountability, equity, and continuous assessment.

Accordingly, the long-term vision is not a system that replaces clinicians. It is a system that can potentially convert visual physiological information into reliable, structured, human-verified information that clinicians can incorporate into their existing workflow.

36. Summary of Recommended Clinical Pathway

Development stage	Primary objective	Human verification	Clinical decision influence
Prototype	Demonstrate technical feasibility	Yes	None
Retrospective validation	Measure extraction accuracy	Yes	None
Simulation	Evaluate workflow and usability	Yes	None
Silent prospective evaluation	Measure real-world performance	Yes	None
Supervised clinical pilot	Evaluate operational utility	Mandatory	Limited
Validated clinical deployment	Support defined clinical workflow	Defined by intended use	Subject to authorization
Continuous monitoring	Detect performance degradation	Required	Governed

The key scientific question for future work is therefore not simply “Can the system read a monitor?” but rather:

“Can the system reliably extract physiological measurements, communicate uncertainty, reduce documentation burden, and integrate safely into clinical workflow without creating new sources of clinical error?”

That question can be answered only through systematic technical validation, human-factors testing, prospective evaluation, and appropriate clinical and regulatory governance.

1. Purpose

This manual describes the operation, testing methodology, and technical principles of a prototype machine-learning system designed to classify a set of physiological measurements into one of three demonstration categories:

• Improving
• Stable
• Worsening

The system uses a Random Forest classification algorithm implemented with Python and scikit-learn.

The purpose of this prototype is to demonstrate a complete machine-learning workflow consisting of:

• physiological data input,
• feature extraction,
• model training,
• classification,
• probability estimation, and
• software testing.

Important: The model described in this manual is a demonstration prototype. Its training data and labels are synthetic and are not derived from a clinically validated dataset. Consequently, its output must not be interpreted as a clinical diagnosis, medical risk score, or validated prediction of patient deterioration.

2. System Overview

The prototype receives individual physiological readings containing up to six measurements:

Feature	Description
HR	Heart rate
SpO₂	Peripheral oxygen saturation
BP Sys	Systolic blood pressure
BP Dia	Diastolic blood pressure
RR	Respiratory rate
EtCO₂	End-tidal carbon dioxide

The measurements are converted into a standardized numerical feature vector:

[HR, SpO₂, BP Sys, BP Dia, RR, EtCO₂]

This vector is supplied to a trained Random Forest classifier.

The classifier returns:

• a predicted category,
• a confidence value, and
• probability estimates for all three categories.

3. Software Requirements

The prototype requires:

• Python 3.x
• NumPy
• scikit-learn
• pytest, if automated testing is performed

The principal libraries are:

import numpy as np

from sklearn.ensemble import RandomForestClassifier

For automated testing:

pip install pytest

4. Data Processing

4.1 Input Data

A physiological reading is represented as a Python dictionary.

For example:

reading = {

"HR": 80,

"SpO2": 97,

"BP Sys": 120,

"BP Dia": 80,

"RR": 18,

"EtCO2": 38,

}

The implementation also supports lowercase field names such as:

{

"hr": 80,

"spo2": 97,

"bp_sys": 120,

"bp_dia": 80,

"rr": 18,

"etco2": 38,

}

This allows the processing function to accommodate different naming conventions.

5. Feature Extraction

The get_features() function converts an input reading into a numerical vector.

The resulting order is always:

HR

SpO₂

BP Sys

BP Dia

RR

EtCO₂

For example:

reading = {

"HR": 80,

"SpO2": 97,

"BP Sys": 120,

"BP Dia": 80,

"RR": 18,

"EtCO2": 38,

}

produces:

[80, 97, 120, 80, 18, 38]

This standardized representation is required because the machine-learning model expects the same feature ordering during training and prediction.

6. Missing and Invalid Data

The feature extraction function attempts to convert each value to a floating-point number.

If a value is None, the implementation substitutes:

0.0

If a value cannot be converted to a number, the implementation also substitutes:

0.0

For example:

reading = {

"HR": 80,

"SpO2": None,

}

results in:

[

80,

0.0,

0.0,

0.0,

0.0,

0.0

]

Scientific consideration

Replacing missing physiological measurements with zero is convenient for demonstrating the software pipeline, but it is not necessarily an appropriate clinical data-processing strategy.

A missing oxygen-saturation measurement, for example, is fundamentally different from an actual measurement of zero.

A production or research system should therefore define a formal missing-data strategy before being evaluated on real-world data.

7. Model Architecture

The prototype uses a:

Random Forest Classifier

implemented through:

RandomForestClassifier(

n_estimators=100,

random_state=42

)

The model consists of multiple decision trees whose outputs are combined to produce a classification.

The parameter:

n_estimators = 100

specifies that 100 decision trees are used.

The fixed random seed:

random_state = 42

makes the demonstration reproducible under the same software and input conditions.

8. Training Dataset

The prototype uses nine synthetic observations.

The six input variables are:

HR

SpO₂

BP Sys

BP Dia

RR

EtCO₂

The corresponding labels are:

0 = improving

1 = stable

2 = worsening

The synthetic observations are deliberately arranged into three groups representing the three demonstration categories.

Improving examples

70, 98, 120, 80, 16, 38

72, 98, 122, 82, 16, 39

75, 97, 120, 80, 17, 38

Stable examples

80, 97, 118, 78, 18, 37

82, 96, 116, 76, 19, 36

85, 96, 115, 75, 20, 35

Worsening examples

95, 95, 110, 72, 22, 33

105, 93, 100, 68, 25, 30

115, 91, 90, 60, 28, 27

9. Important Scientific Limitation

The training dataset is extremely small.

It contains only:

9 observations

6 features

3 classes

Furthermore, the labels are demonstration labels rather than labels generated from a clinically established outcome definition.

Therefore, the model should not be evaluated as though it were a validated medical machine-learning model.

The appropriate interpretation is:

The prototype demonstrates the technical process of training a multiclass classifier and generating predictions from physiological measurements.

It does not establish that the classifier can accurately identify clinical deterioration.

10. Prediction Procedure

The prediction process begins by checking whether historical data are available.

If the history is empty:

history = []

the system returns:

Prediction: stable

Confidence: 0.0

with the probability distribution:

Improving: 0.0

Stable: 1.0

Worsening: 0.0

This is a software-defined default behavior and should not be interpreted as evidence that a person is clinically stable.

11. Prediction From a Reading

When historical data are available, the prototype selects:

latest = history[-1]

It then extracts features from that reading and supplies them to the trained model.

The model generates a numerical class:

0

1

2

The system subsequently converts those numerical values into:

0 → improving

1 → stable

2 → worsening

12. Probability Output

The Random Forest also produces probability estimates using:

model.predict_proba(features)

The results are converted into a dictionary:

{

"improving": ...,

"stable": ...,

"worsening": ...

}

The probability corresponding to the selected prediction is reported as the model's confidence value.

For example, a hypothetical result could be:

Prediction: worsening

Improving: 0.00

Stable: 0.05

Worsening: 0.95

Confidence: 0.95

The values represent the classifier's estimated class probabilities for the supplied feature vector.

They should not be interpreted as a 95% probability that a patient will deteriorate.

13. Experimental Testing Procedure

Testing should be performed using predefined inputs whose expected behavior is known.

The basic test set should contain at least:

• an improving demonstration reading,
• a stable demonstration reading,
• a worsening demonstration reading,
• a reading using lowercase field names,
• a reading containing missing values, and
• an empty history.

This tests both the machine-learning pipeline and the surrounding data-processing code.

14. Functional Tests

Test 1 — Feature Extraction

Input:

{

"HR": 80,

"SpO2": 97,

"BP Sys": 120,

"BP Dia": 80,

"RR": 18,

"EtCO2": 38,

}

Expected result:

[80, 97, 120, 80, 18, 38]

Objective

Verify that each physiological variable is extracted in the correct order.

Test 2 — Lowercase Compatibility

Input:

{

"hr": 80,

"spo2": 97,

"bp_sys": 120,

"bp_dia": 80,

"rr": 18,

"etco2": 38,

}

Expected result:

[80, 97, 120, 80, 18, 38]

Objective

Verify that alternative field naming conventions are accepted.

Test 3 — Missing Values

Input:

{

"HR": 80,

"SpO2": None,

}

Expected result:

[80, 0.0, 0.0, 0.0, 0.0, 0.0]

Objective

Verify that missing fields do not cause the program to crash.

Test 4 — Model Training

The training function should execute successfully and produce a fitted Random Forest classifier.

The classifier should contain three classes:

0

1

2

Objective

Verify that the training pipeline executes correctly.

Test 5 — Empty History

Input:

history = []

Expected prediction:

stable

Expected confidence:

0.0

Objective

Verify that the system handles an absence of measurements without generating an exception.

15. Demonstration Classification Tests

Three representative observations can be used to verify the demonstration classifier.

Improving demonstration

{

"HR": 72,

"SpO2": 98,

"BP Sys": 122,

"BP Dia": 82,

"RR": 16,

"EtCO2": 39,

}

Expected class:

improving

Stable demonstration

{

"HR": 82,

"SpO2": 96,

"BP Sys": 116,

"BP Dia": 76,

"RR": 19,

"EtCO2": 36,

}

Expected class:

stable

Worsening demonstration

{

"HR": 115,

"SpO2": 91,

"BP Sys": 90,

"BP Dia": 60,

"RR": 28,

"EtCO2": 27,

}

Expected class:

worsening

These tests demonstrate that the model can reproduce patterns represented in its synthetic training dataset.

They do not demonstrate generalization to previously unseen clinical populations.

16. Automated Testing

The test suite can be executed with:

pytest -v

A successful test run should report that the defined tests have passed.

Automated testing is useful for detecting:

• incorrect feature ordering,
• missing-value handling errors,
• model-training failures,
• invalid class mappings,
• unexpected output formats, and
• regressions following code modifications.

17. Recommended Experimental Evaluation

For a scientifically meaningful machine-learning evaluation, the synthetic dataset should eventually be replaced with a sufficiently large, appropriately collected dataset.

The dataset should have clearly defined outcome labels.

Possible evaluation methodology includes:

Training set

Used to fit the model.

Validation set

Used to select model parameters and evaluate development performance.

Independent test set

Used only for final performance evaluation.

The independent test set should not be used during model development.

18. Performance Metrics

Once an appropriate labeled dataset is available, performance can be evaluated using metrics such as:

• accuracy,
• precision,
• recall,
• F1 score,
• confusion matrix,
• sensitivity,
• specificity,
• calibration,
• receiver operating characteristic analysis where appropriate.

Because this is a three-class classification problem, class-specific metrics should be reported rather than relying exclusively on overall accuracy.

Class imbalance should also be assessed because accuracy can be misleading when one class occurs substantially more frequently than another.

19. Trend Analysis Limitation

Although the function is named:

predict_trend()

the current implementation does not mathematically calculate a temporal trend.

It uses:

latest = history[-1]

Therefore, only the most recent observation is supplied to the classifier.

For example, consider:

Reading 1: HR = 70

Reading 2: HR = 80

Reading 3: HR = 95

The current model receives only:

HR = 95

It does not explicitly calculate:

70 → 80 → 95

Consequently, the current implementation should technically be described as current-state classification, rather than a fully developed temporal trend model.

20. Future Development

A future version could incorporate temporal information such as:

• change between consecutive measurements,
• percentage change,
• rate of change,
• moving averages,
• measurement variability,
• duration of observed changes,
• slopes over time, and
• multiple consecutive observations.

For example:

Current HR

Previous HR

HR change

Current SpO₂

Previous SpO₂

SpO₂ change

Current BP

Previous BP

BP change

This would allow the model to use information about the direction and magnitude of change rather than relying solely on the latest measurement.

21. Reproducibility

To reproduce the demonstration:

• Install Python.
• Install NumPy and scikit-learn.
• Save the model implementation.
• Save the automated test file.
• Run the test suite.
• Record the Python and package versions.
• Preserve the exact training data and model parameters.

The fixed random seed:

random_state=42

also assists reproducibility.

For scientific reporting, software versions should be recorded because different library versions can occasionally produce differences in implementation behavior.

22. Interpretation of Results

A successful test indicates that the software performed according to its programmed specifications.

For example:

Test passed

means that the expected software behavior occurred.

It does not mean:

The model is clinically accurate.

Similarly, a high classifier probability does not establish clinical certainty.

The distinction between software verification and clinical validation is essential.

23. Safety and Scientific Validity

This prototype should be considered an experimental machine-learning demonstration.

Before any system of this type could be considered for clinical use, it would require substantially more work, potentially including:

• clinically appropriate datasets,
• clearly defined clinical outcomes,
• prospective or appropriately designed validation,
• external validation,
• assessment of demographic and clinical subgroup performance,
• missing-data analysis,
• calibration assessment,
• robustness testing,
• monitoring for distribution shift,
• appropriate human oversight,
• documentation of limitations, and
• applicable regulatory and ethical review.

The present prototype does not establish clinical safety or effectiveness.

24. Summary

The prototype demonstrates a basic supervised machine-learning workflow for classifying physiological measurements.

The processing pipeline is:

Physiological Reading

↓

Feature Extraction

↓

Numerical Feature Vector

↓

Random Forest Classifier

↓

Predicted Category

↓

Class Probabilities

The current implementation successfully demonstrates the mechanics of:

• converting physiological readings into numerical features,
• training a multiclass Random Forest,
• generating predictions,
• calculating class probabilities,
• handling alternative field names,
• handling missing inputs, and
• performing automated software tests.

However, the training dataset is synthetic and extremely limited, and the current prediction procedure uses only the latest reading. Therefore, the system should be regarded as a software and machine-learning prototype rather than a clinically validated predictive system.

Scientific and Technical Manual

Vital-Sign Trend Classification Prototype

Version: 1.0 Date: September 2026 System Type: Educational machine-learning prototype Classification Task: Improving / Stable / Worsening

1. Purpose

This prototype was developed to demonstrate the use of a machine-learning classification pipeline for categorizing physiological observations into three predefined trend classes:

• Improving
• Stable
• Worsening

The system uses six physiological features:

• Heart rate (HR)
• Oxygen saturation (SpO₂)
• Systolic blood pressure
• Diastolic blood pressure
• Respiratory rate (RR)
• End-tidal carbon dioxide (EtCO₂)

The prototype uses a Random Forest classifier implemented with Python and scikit-learn.

The system is intended for educational and technical demonstration purposes only. It has not been clinically validated and must not be interpreted as a clinical deterioration prediction system.

2. Experimental Objective

The objective of testing was to determine whether the implemented software correctly:

• extracted the expected numerical features,
• trained the Random Forest classifier,
• accepted physiological observations in the expected format,
• returned one of the three predefined classifications,
• generated class probabilities,
• mapped numerical class labels to their corresponding descriptions, and
• handled empty or valid input histories according to the programmed logic.

3. Model Configuration

The prototype uses:

RandomForestClassifier(

n_estimators=100,

random_state=42

)

The model therefore consists of 100 decision trees.

The random_state=42 parameter provides deterministic model initialization for reproducible testing.

4. Input Features

Each observation is converted into the following feature vector:

[HR, SpO₂, BP Sys, BP Dia, RR, EtCO₂]

For example:

[82, 96, 116, 76, 19, 36]

represents:

Feature	Example value
HR	82 bpm
SpO₂	96%
Systolic BP	116 mmHg
Diastolic BP	76 mmHg
RR	19/min
EtCO₂	36 mmHg

The feature-extraction function also supports both uppercase and lowercase field names.

5. Demonstration Training Dataset

The prototype was trained using nine synthetic observations.

The observations were divided into three demonstration classes:

Class	Label	Number of observations
Improving	0	3
Stable	1	3
Worsening	2	3
Total		9

The labels represent predefined demonstration categories rather than clinically established outcomes.

6. Testing Procedure

Testing was performed by executing the prototype using predefined physiological observations and comparing the software output with the expected classification.

For each test, the following were examined:

• successful model execution,
• predicted class,
• readable class label,
• confidence value,
• probability dictionary, and
• expected handling of the supplied input.

A test was considered successful when the software output matched the predefined expected result.

7. Test Results

All completed prototype test cases produced the expected software output.

The observed result was:

Test outcome	Result
Tests passing	100%
Tests failing	0%
Expected-output agreement	100%

Overall prototype test result

100% of the executed test cases passed according to the predefined software test criteria.

This indicates that, within the tested conditions, the implemented functions produced the expected outputs.

8. Feature Extraction Testing

The feature-extraction function was tested using physiological dictionaries containing the expected vital-sign fields.

The function successfully converted the supplied measurements into the required six-element numerical feature vector.

Result: 100% of tested feature-extraction cases passed.

The function also contains handling for:

• missing fields,
• None values,
• non-numeric values,
• uppercase field names, and
• lowercase field names.

These behaviors were tested according to the available test cases.

9. Model Training Testing

The Random Forest model was successfully initialized and trained using the demonstration dataset.

The model produced the expected three-class output structure:

0 → Improving

1 → Stable

2 → Worsening

Result: 100% of model-training test cases passed.

10. Prediction Testing

The prediction function was tested using valid physiological feature inputs.

For each tested input, the classifier returned a valid prediction corresponding to one of the predefined classes.

The output was successfully converted from the numerical class representation into the corresponding text label.

Result: 100% of prediction test cases passed.

11. Probability Testing

The prototype also generates class probabilities using:

model.predict_proba()

The resulting values are assigned to:

Improving

Stable

Worsening

The tested probability outputs were successfully returned in the expected dictionary format.

Result: 100% of tested probability-output cases passed.

It is important to distinguish these model probabilities from clinically validated probabilities. They represent outputs of the prototype classifier trained on the supplied demonstration dataset.

12. Empty-History Testing

The prediction function contains a specific condition for an empty history.

When no history is supplied, the programmed output is:

Prediction: Stable

Confidence: 0%

with the probability representation:

Improving: 0%

Stable: 100%

Worsening: 0%

This behavior represents the application's predefined fallback behavior.

It should not be interpreted as a physiological or clinical assessment.

Result: 100% of the tested empty-history cases produced the expected fallback output.

13. Label-Mapping Testing

The numerical classifier outputs were tested against the programmed label mapping:

0 → improving

1 → stable

2 → worsening

The mapping operated as intended for the tested outputs.

Result: 100% of label-mapping tests passed.

14. Error-Handling Testing

The prediction workflow was tested within the application's exception-handling structure.

Where the machine-learning component cannot be executed, the application is designed to display an informative warning rather than terminate the entire interface.

The tested error-handling behavior operated according to the programmed requirements.

Result: 100% of completed error-handling test cases passed.

15. Summary of Test Performance

The complete software-level testing produced the following summary:

Component	Test result
Feature extraction	100% passed
Model training	100% passed
Prediction	100% passed
Probability generation	100% passed
Empty-history handling	100% passed
Label mapping	100% passed
Error handling	100% passed
Overall tested prototype functionality	100% passed

16. Interpretation of the 100% Result

The 100% result should be interpreted specifically as a software test result.

It demonstrates that all executed test cases met their predefined expected outputs.

It does not establish:

• clinical accuracy,
• clinical sensitivity,
• clinical specificity,
• patient deterioration prediction accuracy,
• generalization to real patient populations,
• diagnostic accuracy,
• safety in clinical use, or
• suitability for medical decision-making.

The distinction is important because the model was trained using a small synthetic demonstration dataset rather than a clinically validated dataset.

17. Limitations of the Test Results

Although all executed tests passed, the test dataset and model remain limited.

The training dataset contains only nine synthetic observations.

Furthermore, the current prediction function uses the most recent reading as the model input. The existence of multiple historical readings does not mean that the classifier currently learns a longitudinal trajectory from the complete sequence.

Therefore, the 100% test result should not be described as:

100% clinical accuracy

or:

100% prediction accuracy in patients.

The scientifically appropriate description is:

100% of the executed prototype software test cases passed according to the predefined expected outputs.

18. Recommended Reporting Statement

For a scientific report, presentation, or project documentation, the following statement accurately summarizes the findings:

Testing of the Vital-Sign Trend Classification Prototype resulted in a 100% pass rate across the executed software test cases. All tested feature-extraction, model-training, prediction, probability-generation, label-mapping, fallback, and error-handling functions produced their predefined expected outputs. These findings demonstrate successful operation under the tested conditions but do not constitute evidence of clinical validity, clinical accuracy, or real-world predictive performance.

19. Future Validation

Further evaluation would be required before drawing conclusions about real-world performance.

Future testing should include:

• A substantially larger dataset.
• Independently collected physiological observations.
• Clinically established reference labels.
• Training/test data separation.
• An independent validation dataset.
• Cross-validation.
• Confusion-matrix analysis.
• Precision, recall, and F1-score.
• Calibration analysis.
• Testing across different patient populations and measurement conditions.
• Evaluation of temporal trends rather than only the latest observation.
• External validation using data not involved in model development.

20. Conclusion

The Vital-Sign Trend Classification Prototype successfully completed all executed software test cases, resulting in an overall 100% test pass rate.

The results demonstrate that the implemented prototype performed according to its predefined computational requirements under the conditions tested.

The findings should nevertheless be interpreted within the scope of the experiment. Because the model uses synthetic demonstration data and has not undergone clinical validation or independent real-world evaluation, the 100% result represents prototype software-test performance rather than clinical prediction accuracy.

This distinction should be maintained in all scientific, academic, technical, and presentation materials describing the system.