Experience

The systems described here belong to my employer and its clients. I name no institutions and show no code, screenshots or data. What I can describe is the engineering problem, which is what actually matters when evaluating someone.

The full laboratory cycle

A LIS follows a sample from before it exists until after its result is archived. The pre-analytical phase covers registering the encounter, collecting and receiving the sample; the post-analytical phase covers technical review, validation and report issuing.

What makes this domain hard is not any particular screen, but keeping state consistent at every moment and making every transition traceable. A sample that shows as received without having been collected, or a result validated by someone with no attribution, is not a cosmetic bug: it is a clinical audit problem.

I also worked on financial management modules, monthly production statistics, and statutory reporting under Chilean health-ministry regulation (REM and REMASEP). That reporting is mandatory and its formats are rigid: the software has to produce exactly what the regulation asks for, not a reasonable approximation.

Quality control

The Internal Quality Control module is the most technically interesting thing I have worked on.

A laboratory runs control samples of known concentration alongside patient samples, to detect whether an instrument is drifting before that contaminates real results. That involves:

• Multi-level charting per analyte and per lot. Each analyte is controlled at several concentration levels, and control-material lots change: mixing lots on one chart produces jumps that look like drift and are not.
• Westgard rules. A set of decision rules over the control series — how many standard deviations, how many consecutive points, in which direction — that separate normal noise from real drift requiring the run to be rejected.
• Outlier detection using the Dixon and Mandel & Mandel tests, with automatic interpretation of the result.

What stayed with me is that a false positive has a cost too. If the system rejects runs that were fine, the laboratory stops trusting it and starts ignoring it — and an alerting system that gets ignored is worse than no alerting system at all.

Cytopathology LIS

I led the design of a bimodal system: one codebase processing human and veterinary samples, which share the workflow but differ in nomenclature, required fields and report format.

It included a real-time results viewer to shorten the gap between the pathologist finishing their observation and the report becoming available. It was the first step toward the company’s first cytopathology LIS.

On working in a legacy stack

Much of this is ASP.NET WebForms with VB.NET: technology nobody would choose today to start from scratch. It taught me two things a modern stack would not have.

The first is that code running in production has authority over my preferences. Rewriting for aesthetic reasons in a system with real patients on the other end is an expensive way to introduce risk.

The second is that the constraints of an old platform force you to actually understand what is happening underneath. There is no framework solving the problem for you; you have to know how state is kept, when each event fires, and why the server does what it does.

Vehicle detection and counting over live video, with a dashboard for reviewing accumulated data.

The most instructive part of a project like this is not training the model but everything around it: assembling and labelling a dataset that represents real conditions — light, angle, occlusion — deciding what counts as a valid detection, and keeping processing light enough that “real time” stays true.

It was my first serious encounter with the distance between a model that works in a notebook and a system that works on the street. That distance is most of the work.