BTSO

BTSO is a B2B web application for organizing and executing an optometric screening and evaluation workflow. The domain links the patient to evaluation sessions (Treatment), anamnesis and strabismus questions, an ordered battery of tests, measurement methods, and measurable properties. The interface offers both a guided step-by-step journey and a fast sequence that concentrates the anamnesis, refraction data, and main tests into a single workspace.

Clinical tests are configured in the database and cover distance visual acuity, stereopsis, accommodation amplitude, near point of convergence, distance/near phoria, and monocular accommodative facility. Methods can change the set of properties attached to a test; the user can save their preferred method and test order, and a new evaluation can reuse baseline optometric data from the previous session.

The final evaluation aggregates much more than the raw answers. The backend computes Z-scores based on the configured formulas, the difference between distance and near phoria, and, for compatible methods, the AC/A ratio. The API builds an anamnesis profile with ok/suspicious/skipped states, prepares the series for the chart, and adds system notes for methods where the values are not treated as evidence-based. The frontend renders the result in a Chart.js chart with normative zones and in a table of measured values.

Reporting is hybrid. The frontend captures the chart visualization and sends it as a PNG, and Laravel/mPDF generates the final report on the server with the patient's data, the optometric parameters for the right and left eye, the evaluation chart, contextual documentation, the input values, and the clinician's observations.

Consent for data processing has a separate flow: the backend generates a PDF template with a QR code linked to the patient's UUID, and the signed document can be uploaded as JPG, PNG, or PDF. The file is normalized with Imagick when needed, the QR code is read and verified against the patient, and the status and the user who processed the document are persisted.

The backend uses Laravel 10 / PHP 8.2, REST controllers, Form Requests, Resources, Services, Repositories, Eloquent, and Policies. Isolation of clinical resources is done by company_id, the main model is Patient → Treatment → TreatmentTest/TreatmentQuestion → Property, and the treatment creation and method-change operations are transactional. MySQL holds the operational data, and a secondary MySQL connection periodically receives a pseudonymized dataset.

The frontend is a Vue 3 SPA in JavaScript, built with Vite, Vue Router, Vuex, Axios, and Tailwind CSS. Authentication uses Laravel Sanctum sessions and a CSRF cookie, with optional email-based 2FA at the company level. The UI includes a patient registry, a collapsible side navigation, screens dedicated to clinical stages, a fast sequence, embedded PDF documentation, user administration, settings, and localization into multiple languages.

Operationally, Laravel Scheduler starts jobs for cleaning up unfinished evaluations, notifying and deleting expired trials, and syncing the pseudonymized dataset. The sync jobs process data in chunks, but the repository's default configuration remains queue=sync unless the environment overrides it.

The Git history clearly shows that the application was not built entirely from scratch in the HthePaul2 repository: the initial commits from 2022 belong to another developer, and there are later merges and migrations from GitLab/FLZSFL. HthePaul2's verifiable contribution in 2024–2025 includes PDF branding updates, fixes in the clinical documentation flowchart, localization of the final report and of classes/methods/properties, as well as an extensive modification of TestEvaluationView aimed at the final evaluation's performance issue.

The snapshot audit also highlights hardening technical debt: legacy web routes for running and displaying anonymization data have no authentication middleware in the analyzed file, logging can capture headers, bodies, SQL queries, and authentication data, and persisted formulas are evaluated via eval. The analyzed repositories contain no GitHub Actions or Docker and only have the example Laravel tests, so securing these areas and introducing a test suite/CI are the natural next steps.