Yaakov Holdowsky
Case study · EyeContactDX
Taking an eye-tracking risk model into pediatric offices
A research model is not a product. I built the two systems that turned EyeContactDX's autism risk model into something clinicians could actually use: a clinical reporting platform and a secure physician portal.
The problem
The company had a promising eye-tracking model. To use it in a clinic, three things had to exist that didn't: a way to turn raw gaze data and questionnaires into a clear clinical report, a way to get that report to the right pediatrician securely, and delivery that fits how clinics really work, including fax.
The constraint underneath all of it was handling sensitive health data carefully while moving fast enough to onboard real customers.
What I built
Two products that meet at finished PDF reports in S3.
Clinical reporting platform
For internal report writers. Picks an eye-tracking session, runs the gaze analysis, drafts the report, supports review and editing, and publishes final PDFs per clinic.
React · Flask · EC2Physician portal
For clinicians. Sign in, see only your clinic's reports, and view or download them. Every access is logged.
Vite SPA · CloudFront · API Gateway · Lambda · Cognito · DynamoDBEnd-to-end flow
Five hard problems
These are the decisions that took the most thought, and the trade-off I accepted in each.
Two coordinate systems for the same gaze
ProblemThe tracker and the annotation tool use different resolutions. Left alone, that skews calibration, hit detection and the overlays shown on reports.
ChoiceScale once, up front, then run every analysis in a single space.
Trade-offThe two spaces still exist at the edges, so changes need care and cached results have to be rebuilt.
Real gaze images on reports without storing patient images
ProblemClinicians benefit from seeing the actual screening frames, but those frames are sensitive and shouldn't be kept.
ChoiceKeep nothing durable. Frames are held in temporary memory-backed storage, and each URL carries a recipe to redraw the image on demand.
Trade-offImages expire and redrawing costs CPU, in return for not retaining sensitive data.
One report, two delivery paths
ProblemThe portal can show a rich color PDF. Fax cannot, and clinics still use fax.
ChoiceGenerate a separate black-and-white variant for fax, and send it through a dedicated serverless function.
Trade-offTwo artifacts per report that must stay in step.
Report logic that changes without a deploy
ProblemReport wording and rules were hardcoded in PDF modules, so every small clinical edit needed an engineer and a release.
ChoiceMove the logic into JSON with an editor, and keep a fallback to the older path.
Trade-offTwo code paths to maintain, and the stored configuration has to stay in sync.
Fast, private video review
ProblemServing gaze review video through the application server was too slow.
ChoiceSwitch to signed CloudFront links with pre-rendered MP4 overlays, so media stays private but streams from the edge.
Trade-offMore infrastructure and signing logic, for a much faster review experience.
Security by design
Logging in is not the same as being allowed to see a report. The portal is built on that distinction.
- Access is membership-based. After sign-in, a user sees only the clinics they are an active member of. Pending users see nothing until approved, so one clinic can never browse another's reports.
- Reports live in per-clinic folders, with uploads restricted to allowed locations and stamped with who uploaded them.
- No long-lived links. A report is opened through a short-lived link, about 15 minutes, issued for the current page only after the access check passes.
- Everything is audited. Logins, list views, report views and downloads are recorded with the user, action, clinic and time.
Shipping with confidence
- Automated tests on every pull request: over 1,300 backend tests and about 650 frontend tests, covering things like the coordinate scaling, report metadata, risk tiers and the fax workflow.
- Careful deploys: scripted releases with a near-zero-downtime swap of the frontend and a smoke test that can fail a production deploy.
- Monitoring where it matters to clinics: alerts for server health, a failing fax credential, and screenings that are overdue for a report.
The model work
Beyond the applications, I developed and benchmarked alternative machine-learning approaches for autism risk prediction against the company's flagship model, using stratified cross-validation and held-out real sessions. A key lesson was evaluation discipline: I dropped approaches that looked strong only because of data leakage, and kept the simpler, more stable design for production.
Working with AI, deliberately
I built a structured AI-assisted development workflow rather than just prompting. It has about 34 project rules, automation hooks and trigger phrases that encode the whole delivery loop: ticket, isolated working branch, implementation and tests, an adversarial review of my own diff before a human sees it, then merge and deploy.
- Every task starts with a written brief, so work is reproducible and easy to hand off.
- Rules enforce health-data hygiene (no patient data in prompts) and reuse of production code for analysis.
- Anything that writes to external tools stays a draft until I approve it.
By the numbers
How it grew
- Reporting platform. From a PDF skeleton to a production report generator, gaze review and an end-to-end path from session data to a finished report.
- Delivery. Fax delivery shipped, and the first version of the clinic portal with access logging.
- Hardening and speed. Microsoft sign-in, a clinic upload tool for ops, a configurable report editor, inline PDF preview and session search.
- Scoring. Gaze-based scoring tools in the product, near-zero-downtime deploys and clearer clinical wording.
- Screening evidence on reports, plus a new web app and a browser-based gaze collector.
Details here are generalized. No patient data, customer names or proprietary model internals are shown, and the product described is a clinician-support tool that complements standard clinical care.