LUMIRIS — Light-based Measurement & Research Insight System

A quality-aware research platform combining camera-based PPG with anthropometric, health, and contextual data for traceable longitudinal analysis of physiological signals.

Comment

Inspiration

LUMIRIS grew from my work as a medical science researcher studying autonomic physiology, heart-rate variability, brain–heart interaction, and disorders of consciousness. Camera-based photoplethysmography has the potential to make physiological monitoring available far beyond specialized laboratories, using devices that people already own. However, accessibility alone does not make a measurement reliable. PPG signals are sensitive to movement, ambient illumination, exposure, focus, effective frame rate, finger placement, camera-to-finger geometry, region-of-interest selection, filtering, pulse detection, and artifact correction. If these factors remain hidden, an apparently precise result may be difficult to interpret or reproduce. Many applications reduce this complex measurement chain to a single heart-rate or variability value. LUMIRIS was created around a different principle: Physiological data should remain connected to their quality, context, coverage, and provenance. The long-term vision is to combine scientific rigor with broad accessibility: first developing and validating a transparent research workflow, and then making reliable physiological acquisition and longitudinal monitoring available to a wider population at very low cost. LUMIRIS is therefore designed to connect the signal, the participant’s anthropometric and health characteristics, the circumstances of each recording, and the resulting longitudinal trends without hiding uncertainty, missing information, or methodological limitations.

What it does

LUMIRIS is a Flutter-based research and development platform for camera-based PPG acquisition, signal-quality assessment, pulse-interval analysis, artifact review, and longitudinal exploration of physiological, anthropometric, health, and contextual data. Its acquisition and analysis workflow includes:

  • camera and region-of-interest configuration;
  • monitoring of frame rate, illumination, saturation, and signal stability;
  • inspection of red, green, and averaged color channels;
  • PPG filtering and signal-polarity handling;
  • robust pulse detection;
  • pulse-to-pulse interval construction;
  • residual-outlier identification;
  • automatic and manual artifact correction;
  • signal-quality and measurement-validity assessment;
  • time-domain, frequency-domain, and nonlinear variability analysis. LUMIRIS is not limited to pulse-variability metrics. Each recording can be associated with a structured participant profile and with observations relevant to longitudinal research, including:
  • height, weight, waist circumference, and BMI;
  • body-composition information;
  • physical-activity dose, MET-related information, and activity level;
  • sleep and lifestyle characteristics;
  • blood pressure and other entered health observations;
  • participant-reported clinical conditions and medications;
  • perceived stress;
  • recent caffeine, alcohol, or nicotine use;
  • recent intense physical activity;
  • notes and other context specific to the acquisition. These variables remain descriptive and traceable. They do not retroactively modify physiological measurements or create artificial physiological values. The Your Data workspace is organized into three areas:
  • Scores, for version-aware, coverage-aware, non-diagnostic summaries;
  • Health Data, for anthropometric, body-composition, activity, and vital-sign observations;
  • HRV, for time-, frequency-, and nonlinear-domain variability metrics. Users can explore results over time while retaining visibility into recording duration, measurement quality, coverage, aggregation, contextual information, and the specific sessions contributing to each result.

How I built it

LUMIRIS is implemented primarily in Dart and Flutter, with a portable Dart processing core and separate modules for acquisition, signal analysis, artifact correction, participant profiles, health observations, recording context, longitudinal normalization, scoring, and data visualization. Before July 13, 2026, the project already contained the scientific and engineering foundations of its camera-based PPG acquisition and analysis workflow. These included web and Android camera acquisition, configurable acquisition parameters, region-of-interest selection, live signal diagnostics, filtering, pulse detection, pulse-interval generation, artifact correction, core variability metrics, participant-profile management, and the initial Flutter and portable Dart architecture. During OpenAI Build Week, I used OpenAI Codex and GPT-5.6 to extend LUMIRIS from a session-based acquisition and analysis prototype into a normalized, versioned, and traceable longitudinal research workflow. The Build Week work included 55 scoped implementation commits and introduced:

  • a normalized longitudinal data architecture;
  • separation of persistent profile data, health observations, acquisition-specific data, derived metrics, quality, validity, revisions, and provenance;
  • a versioned recording-context model;
  • coverage-aware, non-diagnostic score snapshots;
  • the web-first Your Data workspace;
  • filters for metric, recording duration, time of day, date range, aggregation, and individual measurements;
  • contributor tracing for aggregated results;
  • direct inspection of recording quality, validity, and context;
  • shared chart-rendering and interaction behavior;
  • responsive layouts;
  • keyboard accessibility and reduced-motion support;
  • English, Italian, Spanish, and French localization;
  • a Firebase-hosted web evaluation build that can open without immediate camera discovery.

Codex was used as a continuous engineering collaborator rather than as a one-shot code generator. My workflow was:

  1. inspect the existing repository, architecture, and data contracts;
  2. separate scientific and semantic decisions from interface implementation;
  3. define a narrow, reversible development phase;
  4. implement the change across the required Dart and Flutter modules;
  5. run static analysis or focused verification;
  6. test the behavior manually in the browser;
  7. inspect unexpected results before applying corrections;
  8. commit each accepted phase independently with a defined rollback path.

The main Codex thread used GPT-5.6 Sol and GPT-5.6 Terra for architecture analysis, multi-file implementation, debugging, longitudinal data normalization, formula review, accessibility, responsive behavior, Firebase delivery, and documentation. Main Codex Session ID:
019f7ea4-0134-7c62-b25f-088c1d5ab5bf

At the documentation freeze, the thread contained:

  • 64 model-bearing working contexts;
  • 54 using GPT-5.6 Sol;
  • 10 using GPT-5.6 Terra.

All physiological definitions, methodological assumptions, quality criteria, score semantics, limitations, and final code changes remained under human scientific review.

Challenges we ran into

The hardest challenge was not calculating a final metric. It was preserving enough evidence to determine whether that metric should be displayed, compared, interpreted cautiously, or excluded. Camera-based PPG varies across devices, browsers, illumination conditions, movement, finger placement, and camera geometry. Longitudinal analysis creates an additional problem: recordings with different durations, quality levels, protocols, or missing contextual information must not be treated as equivalent.

LUMIRIS therefore preserves:

  • signal quality;
  • measurement validity;
  • recording duration;
  • data coverage;
  • contributing sessions;
  • aggregation method;
  • formula and reference versions;
  • contextual revisions;
  • missing-data behavior;
  • provenance.

Another challenge was balancing scientific depth with usability. The platform needed to expose detailed research information without turning the interface into an unreadable technical report. The web workspace therefore uses structured domains, filters, contextual cards, contributor-level inspection, responsive layouts, keyboard navigation, and reduced-motion support. A further challenge was maintaining scientific caution. Camera-derived pulse-rate variability is related to, but not automatically interchangeable with, ECG-derived heart-rate variability. LUMIRIS therefore does not claim clinical or numerical equivalence before formal validation against synchronized reference instrumentation.

Accomplishments that we're proud of

I am particularly proud that LUMIRIS now connects three levels of evidence:

  1. the acquired physiological signal;
  2. the participant’s anthropometric, health, and functional characteristics;
  3. the context in which each measurement was recorded.

The platform does not merely display longitudinal trends. It retains the information required to understand how those trends were produced, which recordings contributed to them, and whether the available evidence is sufficiently complete and valid.

I am also proud of the explicit separation between:

  • observed participant data;
  • recording-specific context;
  • signal-derived metrics;
  • quality and validity;
  • later revisions;
  • score versions;
  • provenance.

Missing values are not silently replaced with artificial zeros, and contextual information does not retroactively modify the physiological measurement. The Build Week extension also produced a web-first workspace, a Firebase-hosted evaluation build, multilingual interfaces, responsive behavior, keyboard accessibility, and a documented, reversible Git history.

What we learned

Build Week reinforced that trustworthy physiological software requires more than signal processing.

It also requires:

  • explicit data contracts;
  • quality gating;
  • versioning;
  • provenance;
  • transparent missing-data rules;
  • separation between observed and derived data;
  • interfaces that communicate uncertainty rather than conceal it.

I learned that longitudinal physiological analysis becomes misleading when duration, acquisition protocol, validity, context, or contributing sessions are hidden behind a single trend line. I also learned how effectively Codex can support a complex scientific software workflow when tasks are narrowly scoped, generated changes are inspected critically, and scientific decisions remain human-led. The most valuable use of AI in this project was not automatic scientific decision-making. It was accelerating architecture analysis, implementation, debugging, verification, documentation, and iteration while preserving human responsibility for physiological meaning and methodological limits.

What's next for LUMIRIS — Light-based Measurement & Research Insight System

The next scientific priority is validation against synchronized reference instrumentation using explicit protocols, defined populations, standardized units, and transparent error bounds.

A planned hardware extension is a compact, very-low-cost acquisition accessory designed to improve the standardization of camera-based PPG.

The accessory is intended to:

  • provide stable retro-ungual illumination;
  • reduce dependence on ambient lighting;
  • maintain a consistent camera-to-finger distance;
  • stabilize finger and camera geometry;
  • reduce variability caused by positioning and movement;
  • improve acquisition repeatability across measurements.

The objective is not to create expensive proprietary hardware, but to provide a simple and reproducible physical acquisition condition that complements the software quality-control pipeline.

This accessory is a planned development and is not part of the submitted build. A further planned extension is an AI-assisted personalized reporting layer integrating:

  • signal quality and measurement validity;
  • pulse-variability results;
  • anthropometric and body-composition data;
  • physical-activity and functional information;
  • sleep and lifestyle observations;
  • participant-reported health information;
  • longitudinal trends;
  • the context of each acquisition. Each generated report should remain linked to its underlying measurements, contributing sessions, data coverage, quality, uncertainty, and provenance.

The reporting layer will be designed as a research-support tool with explicit limitations and human review, not as an autonomous diagnostic or treatment system. It is not implemented in the submitted build.

Further work will include broader device and browser testing, research-oriented data exports, improved acquisition standardization, continued development of the mobile longitudinal interface, and validation in autonomic physiology and brain–heart interaction studies.

LUMIRIS is an active research and development prototype. It is not a medical device and does not provide diagnosis, treatment, or clinical recommendations.

Built With

Share this project:

Updates