Login
Inicio de Chatbot
Conversación con Chatbot
Resultados y ubicación
Conversación con Doctor
Pestaña Agendar cita
Tooltip
Index Doctor
Conversación con Paciente
Calendario
Editar Clínica
Seleccionar tu Clínica
Landing Page

MedConnect

Inspiration

El 43% de los mexicanos que tienen síntomas de enfermedad no van al médico. No porque no quieran sino porque no saben a dónde ir, las citas tardan semanas, o simplemente no saben si lo que sienten es urgente o puede esperar. El mexicano promedio visita al médico solo 2.8 veces al año, uno de los índices más bajos de toda la OCDE.

Herramientas como Doctoralia o Zocdoc existen, pero asumen algo que casi nunca es cierto: que el paciente ya sabe qué especialista necesita. La realidad es diferente. La gente llega a Google con síntomas, recibe resultados confusos, llama a clínicas preguntando si tienen al especialista correcto, y muchas veces termina en urgencias cuando no era necesario o esperando cuando sí lo era.

El 23% de los afiliados al IMSS y el 32% de los del ISSSTE terminan atendidos en el sector privado pagando de su bolsillo, aunque tienen seguro. No porque prefieran hacerlo, sino porque el sistema no les orienta correctamente desde el primer momento.

Eso nos inspiró a construir MedConnect: una plataforma que parte del síntoma, no de la especialidad.

What it does

MedConnect es una plataforma médica inteligente que conecta pacientes con médicos y clínicas a través de un pipeline de tres agentes de IA especializados.

El paciente describe cómo se siente en lenguaje natural, selecciona su seguro médico (IMSS, ISSSTE, Seguro Popular o ninguno) y su nivel de gasto ($, $$, $$$). A partir de ahí, el sistema toma el control:

Agente de Triaje: Procesa los síntomas con Gemini Pro y clasifica la urgencia en tres niveles (low, medium, critical), determina el tipo de unidad médica requerida (urgencias, general o especialista) y la especialidad necesaria. Detecta automáticamente señales de alarma como dolor torácico con disnea, pérdida de conciencia o dificultad respiratoria severa.
Agente de Ruteo : Vectoriza la especialidad requerida con Gemini Embeddings y ejecuta búsqueda semántica sobre la base de datos CLUES (Clave Única de Establecimientos de Salud del gobierno mexicano), vectorizada en MongoDB Atlas. Filtra por seguro médico y presupuesto, y calcula tiempos reales de traslado con Google Maps Distance Matrix API.
Agente de Recomendación: Genera justificaciones empáticas en español para las tres mejores opciones, diferenciando entre médicos dentro de la red (con chat directo y agenda integrada) y fuera de la red (con información de contacto). Adapta el tono según el nivel de urgencia detectado.

El resultado es un mapa interactivo con las opciones rankeadas, tarjetas con justificación en lenguaje natural y, para médicos dentro de la red, la posibilidad de contacto directo y agenda organizada.

How we built it

Stack técnico:

Backend: FastAPI (Python) con arquitectura de agentes en pipeline secuencial
IA: Gemini Pro para triaje y recomendación, Gemini Flash para el chat en tiempo real, Gemini Embeddings para la vectorización de clínicas en el RAG
Base de datos: MongoDB Atlas con Vector Search nativo para la búsqueda semántica de establecimientos
Datos: Dataset abierto CLUES del gobierno mexicano, vectorizado por especialidad y servicios
Mapas: Geocoding API, Places API (new), Routes API, Maps JavaScript API
Tiempo real: WebSockets para el messenger entre paciente y médico.
Calendarios: Agenda creada.
Infraestructura: Vultr VPS, Nginx, Systemd, Docker y Docker Compose

Decisión de arquitectura RAG vs LLM Wiki:

Una de las decisiones más importantes fue elegir el mecanismo de conocimiento correcto para cada agente. El Agente de Triaje y el de Recomendación usan LLM Wiki (un markdown estructurado inyectado en el system prompt de Gemini) porque el conocimiento médico para clasificar síntomas y urgencia es estático, curado y no puede tolerar fallos de recuperación. El Agente de Ruteo usa RAG con MongoDB Vector Search porque opera sobre miles de registros de CLUES que necesitan búsqueda semántica a escala.

Diferenciación de red:

Los médicos se registran en la plataforma y activan su perfil. Cuando un paciente los selecciona, reciben el perfil clínico completo generado por el Agente de Triaje antes de que el paciente escriba su primer mensaje, lo que elimina el tiempo perdido en anamnesis básica y permite una atención mucho más eficiente.

Challenges we ran into

Disponibilidad de datos en tiempo real. Los datos de camas disponibles y tiempos de espera en tiempo real no existen como API pública en México. Resolvimos esto con el dataset CLUES del gobierno (que sí contiene especialidades, servicios y ubicación de todos los establecimientos del país) y siendo transparentes con el jurado sobre esta limitación.

La decisión RAG vs LLM Wiki. No es trivial elegir el mecanismo de conocimiento correcto para cada parte del sistema. Investigamos la literatura reciente sobre ambos enfoques en aplicaciones biomédicas y concluimos que no son alternativas excluyentes: son herramientas para contextos distintos dentro del mismo pipeline.

Calidad del triaje sin diagnóstico. El agente de triaje tiene que ser útil sin cruzar la línea del diagnóstico médico. Definir con precisión qué clasifica (urgencia, tipo de unidad, especialidad requerida) versus qué no hace (diagnóstico, prescripción) fue un trabajo cuidadoso de diseño de prompts y del LLM Wiki.

El chat con contexto clínico previo. Hacer que el perfil clínico generado por el triaje llegue al médico como primer mensaje del sistema, antes de que el paciente intervenga, requirió coordinación precisa entre el pipeline de agentes y MongoDB.

Accomplishments that we're proud of

Diseñar e implementar un pipeline de cuatro agentes especializados (triaje, enrutamiento, recomendación y chat) que se pasan contexto estructurado entre sí, con validación Pydantic en los endpoints de la API.
Vectorizar el dataset CLUES completo con Gemini Embeddings y construir un índice de búsqueda semántica en MongoDB Atlas que permite encontrar establecimientos por descripción de síntomas, no solo por nombre de especialidad.
Construir el mecanismo de red de médicos con perfil clínico previo al chat, un diferenciador que no existe en ninguna plataforma de telemedicina o directorio médico actual en México.
Tomar una decisión de arquitectura fundamentada (RAG vs LLM Wiki) con base en literatura académica real sobre aplicaciones de IA en salud, y no por intuición o conveniencia técnica.

What we learned

Aprendimos que en salud, la confiabilidad supera a la sofisticación. Un triaje que falla silenciosamente es más peligroso que uno que no existe. Eso nos llevó a preferir el LLM Wiki sobre RAG en los agentes que clasifican urgencia, no porque sea más complejo, sino porque garantiza que el modelo siempre razona sobre el contexto completo sin depender de que la recuperación encuentre el chunk correcto.

Aprendimos también que el problema de acceso a la salud en México no es solo de infraestructura sino de orientación. Los datos del ENSANUT 2022 muestran que millones de personas con seguro médico terminan pagando servicios privados porque el sistema no las guía correctamente desde el primer síntoma. Eso convierte a MedConnect en un problema de diseño de información tanto como de tecnología.

Por último, aprendimos que construir para el paciente y para el médico al mismo tiempo requiere respetar las necesidades de ambos: el paciente necesita claridad y velocidad, el médico necesita contexto clínico y control de su agenda. Un sistema que sirva a uno a expensas del otro no funciona.

What's next for MedConnect

App móvil nativa : iOS y Android para que la experiencia sea accesible en cualquier momento, especialmente en urgencias.
Agente de seguimiento post-consulta: Un cuarto agente que monitorea al paciente después de la consulta, detecta señales de alerta y recomienda seguimiento si es necesario.
Disponibilidad en tiempo real: Integración con los HIS (Hospital Information Systems) de clínicas aliadas para mostrar disponibilidad real de camas y tiempos de espera, no solo datos estáticos de CLUES.
Historial clínico del paciente: Persistencia del historial entre sesiones para que el triaje mejore con el tiempo y el médico tenga contexto longitudinal.
Telemedicina integrada: Videoconsulta desde la plataforma para casos donde la atención presencial no es necesaria.
Expansión a Latinoamérica: El modelo de agentes es agnóstico al dataset de establecimientos. Con el equivalente de CLUES en otros países (Colombia, Argentina, Chile), la plataforma puede replicarse con mínima reconfiguración.
Análisis predictivo de demanda: Identificar patrones de consulta por zona, temporada y tipo de síntoma para ayudar a las clínicas a optimizar su capacidad.