Xirai — Sistema médico con IA
Un sistema médico con visión por computadora: lee radiografías, panorámicas dentales y lesiones de piel con YOLO, y atiende el WhatsApp de la clínica 24/7 para agendar y dar seguimiento.
- Python
- FastAPI
- YOLOv8
- OpenCV
- Gemini
- Docker
- Laravel
- PHP
- Livewire
- MySQL
- Stripe
- WhatsApp API
Restricciones
- Un diagnóstico asistido no puede inventar hallazgos que no están en la imagen.
- La mayoría de las consultas llegan cuando la clínica está cerrada. El primero en responder se lleva la cita.
- Los datos son clínicos. La lógica médica no puede mezclarse con la administración.
- El hardware no estaba garantizado, así que la inferencia tiene que correr en CPU y aprovechar GPU si existe.
- Los pesos de los modelos cambian seguido; reconstruir el contenedor en cada versión es inviable.
El problema
Un sistema médico que ve los estudios
La parte que casi nadie construye: visión por computadora aplicada a imágenes médicas reales. Xirai analiza estudios con modelos de detección entrenados —no un modelo de lenguaje adivinando sobre una foto— y devuelve hallazgos localizados.
Tres modalidades, el mismo motor:
- Panorámicas dentales YOLO detecta cada pieza y la numera con notación FDI. Sobre esa detección se redacta el diagnóstico.
- Radiografía de tórax Detección sobre placa de tórax con el mismo contrato y el mismo esquema de despliegue.
- Lesiones de piel Dermatología. El más joven de los tres servicios.
Detección local con visión por computadora · redacción generativa
Cómo analiza un estudio
- 01 Entra la imagen Una panorámica dental, una placa de tórax o una foto de lesión, por el mismo endpoint.
- 02 YOLO detecta y localiza El modelo entrenado encuentra las estructuras y las numera. En dental, cada pieza recibe su número FDI. Esto es determinista: la misma imagen da el mismo resultado.
- 03 Se redacta el diagnóstico El modelo de lenguaje trabaja sobre las detecciones, no sobre la imagen. Si no hay detección, no hay hallazgo que redactar.
La cadena completa: de los píxeles a un hallazgo rastreable
Esa separación es lo que hace el sistema auditable. Cuando un hallazgo está mal, se puede saber si falló la detección o la redacción — porque son dos etapas distintas con dos salidas distintas. Si se le pide todo al mismo modelo, no hay forma de saber dónde se rompió.
Lo que corre debajo
Los tres servicios son contenedores independientes con el mismo contrato: mismo endpoint de salud, mismo formato de respuesta. Un cliente nuevo se integra sin aprender nada nuevo, y un servicio se puede reemplazar sin tocar a los demás.
Dos decisiones que solo se aprecian cuando ya lo desplegaste:
El hardware no estaba garantizado. La inferencia corre en CPU por defecto y aprovecha GPU si el servidor la tiene. La reserva de GPU en el despliegue existe pero está comentada con la instrucción de descomentarla cuando el host la ofrezca, en lugar de exigirla para arrancar.
Los pesos se montan, no se hornean. Actualizar un modelo es cambiar un archivo de solo lectura y reiniciar, sin reconstruir la imagen. Con tres servicios y modelos que cambian seguido, hornearlos habría convertido cada iteración en un build completo. Y si falta el modelo entrenado, el servicio arranca con el genérico dejando un aviso inequívoco en el log: arrancar en silencio con el modelo equivocado produce diagnósticos malos sin que nadie se entere.
Y encima, el paciente
El modelo de detección no atiende el WhatsApp. Para eso hay un agente conversacional entrenado con la operación de la clínica, que trabaja mientras la clínica está cerrada — que es cuando llega la mayoría de las consultas.
Consulta nocturna → disponibilidad, precios → cita con estudio incluido
El precio no lo inventó: estaba en la base de conocimiento de la clínica. Y si hubieran preguntado algo que no está ahí, el agente escala en lugar de improvisar.
El panel que ve el dueño
- Conversaciones Historial completo y buscable de cada hilo con tus pacientes.
- Citas Agendadas por el agente, confirmadas y con recordatorio.
- Prospectos Contactos capturados con su intención y nivel de interés.
- Configuración Respuestas, horarios y flujos editables sin tocar código.
Lo que ve el dueño de la clínica, no el ingeniero
Para quién
- Clínicas dentales Agenda, cotizaciones, panorámicas y seguimiento de tratamiento.
- Consultorios médicos Valoraciones, horarios, preparación previa, seguros y seguimiento.
- Radiología y diagnóstico Lectura asistida de estudios con hallazgos localizados.
- Dermatología y estética Análisis de lesiones, paquetes, costos y orientación inicial.
Planes
- Esencial $2,490 MXN / mes Hasta 300 conversaciones al mes. Automatiza la primera línea de atención.
- Más popular Profesional $4,990 MXN / mes Hasta 1,000 conversaciones. Memoria por conversación, captura de prospectos y escalado a humano.
- Empresarial $9,990 MXN / mes Agentes y conversaciones ilimitadas, multicanal, integraciones y SLA de soporte bajo 2 horas.
Sobre el equipo
Xirai es mío: nació dentro de Alean. La arquitectura, el modelo de datos, las reglas del dominio, las zonas de código y el diseño del pipeline de inferencia son diseño mío; la implementación se hace con revisión por Pull Requests contra ramas de trabajo.
Decisiones
- 01
La detección es determinista y la redacción es generativa
El modelo de visión detecta y numera las piezas dentales con notación FDI; el modelo de lenguaje redacta el diagnóstico a partir de ESA detección, no de la imagen. No se le pide a un modelo general el trabajo de uno especializado: lo determinista se queda local, auditable y barato, y lo generativo se usa solo para redactar.
DescartadoMandar la radiografía a un modelo de lenguaje con visión y pedirle el diagnóstico completo. Da respuestas plausibles sin trazabilidad, y cuando el hallazgo está mal no hay forma de saber si falló la detección o la redacción.
- 02
Arrancar con el modelo genérico está permitido; hacerlo en silencio no
Si falta el modelo entrenado, el servicio arranca con los pesos genéricos y deja un aviso inequívoco en el log. Negarse a arrancar sin pesos personalizados hace el servicio inoperable en desarrollo; arrancar en silencio con el modelo equivocado produce diagnósticos malos sin que nadie se entere. La tercera opción es la que se rechazó.
- 03
Los pesos se montan, no se hornean
Los modelos viven en un volumen de solo lectura, así que actualizar un peso es cambiar un archivo y reiniciar, sin reconstruir la imagen. Con tres servicios y modelos que cambian seguido, hornearlos convertiría cada iteración en un build completo.
- 04
Los tres servicios comparten el mismo contrato HTTP
Dental, radiología y piel son tres contenedores distintos con el mismo endpoint de salud y el mismo formato de respuesta. Un cliente nuevo se integra sin aprender nada nuevo, y un servicio se puede reemplazar sin tocar a los demás.
- 05
El agente recibe contexto, no acceso
En la parte conversacional, el agente no consulta la base por su cuenta: recibe un contexto ya armado —servicios, horarios, precios, tono de marca y el hilo— y responde con eso. Si algo no está en su base de conocimiento, escala en lugar de improvisar. Es la diferencia entre un asistente entrenado y uno que alucina precios.
- 06
Las zonas de código tienen permisos distintos dentro del mismo repo
El repositorio declara tres zonas explícitas: una segura, donde trabajar libremente; una con cuidado, donde los modelos solo admiten relaciones nuevas; y una prohibida sin revisión —la lógica clínica, los endpoints que consume la automatización y los flujos externos—. La revisión de PR por sí sola no distingue "agregué una relación" de "cambié la lógica clínica", así que la distinción vive en el repositorio.
Resultado
- Tres servicios de inferencia de imagen médica —panorámicas dentales, tórax y piel— con detección por visión por computadora y contrato HTTP uniforme.
- Detección de piezas dentales con numeración FDI local, y diagnóstico redactado por un modelo de lenguaje sobre esa detección.
- Un agente de WhatsApp que atiende, agenda, califica y escala con contexto completo del paciente.
- Tres planes comerciales con volumen y alcance definidos, desde atención hasta multicanal con SLA de soporte.
- Un panel donde la clínica ve conversaciones, citas, prospectos y estudios sin conocimientos técnicos.