YACHAQ 360

The problem

A health regulator receives enquiries, complaints and reports written however each person can write them. Someone has to read each one, decide what it is about under the regulation, how urgent it is, and send it to the right team. YACHAQ 360 was built for an innovation contest run by SUSALUD, Peru's health regulator, and targets that first filter.

My role

Developer and project lead: functional definition, architecture, frontend, backend, database and automations, the AI-assisted classification and prioritisation, and the technical preparation for the contest.

What I care about most: measuring it properly

Classifying free text with a language model is easy to build and very easy to measure badly. The classic trap: the system retrieves the very case it is evaluating as a "similar example", gets it right because of that, and the score looks great while meaning nothing.

So there is an ablation study comparing four configurations on exactly the same cases, in the same order: no retrieval; real examples with text similarity (pg_trgm); real and synthetic examples; and a hybrid of pg_trgm plus embeddings.

• Fixed sampling seed, so runs can be compared with each other.
• Evaluated cases are excluded from the index by ID, not by text match, so the system cannot find itself or a near-duplicate.

Design principles

• AI suggests, it does not decide. No case is rejected automatically.
• Local model with Ollama, not an external API. Health complaints are sensitive data and never leave the infrastructure.
• Classification anchored to regulation, through versioned catalogues.
• Every state change is logged, so any decision can be reconstructed.

Limitations

• It is a contest MVP, not a production system.
• The repository contains no real cases and no embeddings derived from them.