Cuando el call center de un hospital sigue recibiendo llamadas para agendar citas meses después de lanzar el agendamiento en línea, la lectura más común es que el paciente no confía en lo digital. La respuesta habitual es rediseñar el formulario, simplificar los pasos y lanzar una campaña para que la gente use el portal.
La desconfianza del paciente casi nunca explica las llamadas. El paciente llama porque el agente del call center resuelve cosas que el portal no tiene cómo saber. Cada llamada que entra por un trámite que el portal dice resolver es un síntoma, y el síntoma señala una capa concreta de la arquitectura.
¿Por qué el agente del call center resuelve lo que el portal no?
El agente del call center resuelve lo que el portal no porque tiene acceso a cuatro fuentes de información: la agenda real del día, los derechos del paciente con su aseguradora, las reglas de cada tipo de cita y el estado de la cita después de reservada. Si el portal no tiene acceso a alguna de esas cuatro fuentes, el flujo en línea termina en una llamada.
La ventaja del agente es la información: tiene abiertas cuatro pantallas y años de práctica sobre reglas que no están escritas en ninguna parte. Un portal de pacientes que solo muestra un calendario y un formulario está compitiendo contra esa persona con menos información.
El diagnóstico general de por qué falla la integración entre un portal de salud y el sistema clínico, con los estándares de interoperabilidad y los riesgos de seguridad, lo desarrollamos en Por qué la integración con el sistema de información clínica sigue fallando. Esta pieza se concentra en un solo flujo, agendar una cita médica, y lo recorre de punta a punta.
¿Dónde se rompe el agendamiento en línea de un hospital?
El agendamiento en línea de un hospital depende de cuatro capas que tienen que funcionar juntas: disponibilidad, identidad y cobertura, reglas de la cita y ciclo posterior a la reserva. Basta con que una falle para que el paciente vuelva al teléfono, y cada capa deja señales distintas en la operación.
Las cuatro capas son, en conjunto, un problema de interoperabilidad en salud. La interoperabilidad en salud es la capacidad de que el portal, la agenda, el sistema de convenios y las herramientas de comunicación intercambien datos y los usen con el mismo significado. El agendamiento en línea es el flujo donde esa interoperabilidad se pone a prueba frente al paciente todos los días.
| Capa | Qué consulta el agente en cada llamada | Síntoma en el call center | De quién depende resolverla |
| 01. Disponibilidad | La agenda del día en el HIS | Citas en línea reprogramadas por cupo ocupado | Proveedor del HIS y equipo de integración |
| 02. Identidad y cobertura | Datos del paciente, convenio y autorización | Pacientes que no pueden agendar con su aseguradora | Sistema de facturación y convenios |
| 03. Reglas de la cita | Preparación, sede, profesional y secuencia de citas | Servicios que no aparecen en el portal | Área asistencial y equipo del portal |
| 04. Ciclo posterior | Estado de la cita y recordatorios enviados | Llamadas para cancelar, reprogramar o confirmar | HIS y herramientas de comunicación |
01. ¿El portal consulta la agenda real o una copia de anoche?
En muchos hospitales, el portal muestra una copia de la agenda que se sincroniza con el sistema de información hospitalaria (HIS) una o varias veces al día. Mientras tanto, el call center y la recepción asignan cupos en tiempo real sobre la agenda original. El resultado es predecible: el paciente reserva en línea un cupo que ya estaba ocupado, recibe una llamada para reprogramar y la próxima vez prefiere llamar directamente.
La señal en la operación es clara. Si una parte importante de las citas agendadas en línea se reprograma por "cupo no disponible", o si el call center recibe llamadas de pacientes que quieren confirmar una cita que ya agendaron en el portal, la capa de disponibilidad no está resuelta.
La solución técnica es consultar la agenda en el momento de la reserva y bloquear el cupo mientras el paciente completa el proceso. Cuando el HIS expone una API, el portal la consume directamente. Cuando no la expone, una capa intermedia de integración puede hacer la consulta y mantener la reserva temporal. El estándar FHIR define recursos específicos para esto (Schedule, Slot y Appointment), y vale la pena preguntarle al proveedor del HIS si los soporta antes de diseñar una integración a la medida.
| Criterio | Copia sincronizada por lotes | Consulta en tiempo real |
| Qué ve el paciente | La agenda de la última sincronización | La agenda del momento |
| Riesgo de cupo duplicado | Alto en las horas de mayor demanda | Bajo, con bloqueo temporal del cupo |
| Requisito técnico | Exportación periódica desde el HIS | API del HIS o capa intermedia de integración |
| Esfuerzo de arranque | Menor | Mayor, depende del proveedor del HIS |
02. ¿El portal sabe quién es el paciente y qué cubre su aseguradora?
En muchos portales, no. Antes de asignar una cita, el agente del call center verifica quién es el paciente, si está afiliado a un convenio vigente y si el servicio que pide necesita autorización u orden médica. En Colombia eso pasa por la EPS, la medicina prepagada o la póliza; en Chile, por Fonasa o la Isapre del paciente. Esa verificación ocurre en el sistema de facturación o de convenios, que casi nunca es el mismo que guarda la agenda.
Cuando el portal no tiene acceso a esa información, le quedan dos caminos y ambos generan llamadas. Puede dejar agendar sin verificar, y entonces la cita se cancela después porque el convenio no la cubre. O puede limitarse a los servicios particulares y mandar al teléfono todo lo que pasa por aseguradora, que en muchas instituciones es la mayor parte del volumen.
La identidad del paciente es la otra mitad de esta capa. El mismo paciente puede estar registrado con documentos distintos o con datos duplicados entre sistemas, y el portal necesita saber con certeza a qué historia clínica electrónica corresponde la persona que está agendando. Resolver esta capa exige consultar elegibilidad en el momento de la reserva y tener un identificador de paciente confiable entre el portal, la agenda y la facturación.
03. ¿Las reglas que el agente sabe de memoria están escritas en algún sistema?
En muchos hospitales, no: las reglas de cada tipo de cita viven en la memoria del equipo, y es la capa que más se subestima. Una cita de control con un especialista exige que antes haya existido una cita de primera vez. Algunos exámenes requieren ayuno o suspender un medicamento. Ciertos procedimientos ocupan dos bloques de agenda, solo se hacen en la sede que tiene el equipo, o los atiende un profesional específico según la edad del paciente.
Un agente con experiencia aplica estas reglas sin pensarlo. Cuando las reglas están en un manual interno o en una hoja de cálculo, el portal no tiene de dónde leerlas. Por eso tantos portales de salud solo permiten agendar medicina general y mandan al teléfono todo lo demás.
Resolver esta capa es en buena parte un trabajo de modelado de contenido. El catálogo de tipos de cita, especialidades, sedes, preparación previa y restricciones se estructura como datos administrables, con dueños claros en el área asistencial. En un portal construido sobre Drupal, ese catálogo se modela con tipos de contenido y taxonomías que el equipo del hospital actualiza sin depender del desarrollador, y el flujo de agendamiento lee las reglas desde ahí. Cualquier CMS enterprise con modelado estructurado puede hacer lo mismo, siempre que las reglas vivan dentro del sistema.
04. ¿Qué pasa después de que el paciente reserva?
Después de la reserva vienen la confirmación, los recordatorios, la reprogramación, la cancelación y, en algunos servicios, la lista de espera para cupos liberados. Si el portal permite reservar pero no cancelar ni reprogramar, el paciente igual va a llamar, solo que unos días más tarde.
El otro síntoma de esta capa son los mensajes que se contradicen. El recordatorio sale de una herramienta de mensajería, la confirmación de otra, y ninguna de las dos se entera de que el paciente reprogramó por teléfono. El paciente recibe un recordatorio de una cita que ya no existe y llama para entender qué pasó. Es el mismo problema de cada sistema guardando su propia versión de la persona, que analizamos para marketing en Dropsolid integra tu stack de marketing y tu CMS en una sola capa de datos.
La regla de arquitectura para esta capa es que el estado de la cita viva en un solo lugar, normalmente el HIS, y que el portal y las herramientas de comunicación lo lean de ahí. Cada cambio hecho por cualquier canal, sea el portal, el call center o la recepción, se escribe de vuelta en esa fuente única.
¿Cómo saber en qué capa está tu problema?
La forma más rápida de ubicar la capa que falla es clasificar los motivos de llamada al call center durante una semana. No hace falta un proyecto: basta con que los agentes registren por qué llamó cada paciente que podía haber agendado en línea, y que cada motivo se asigne a una capa.
| Motivo de la llamada | Capa | Primera conversación |
| El cupo que vio en el portal ya no estaba disponible | 01. Disponibilidad | Con el proveedor del HIS: qué API de agenda expone |
| El portal no le permitió agendar con su aseguradora o no supo cargar la autorización | 02. Identidad y cobertura | Con facturación y convenios: cómo se consulta la elegibilidad |
| El servicio que necesitaba no aparecía o no sabía cuál elegir | 03. Reglas de la cita | Con el área asistencial: quién es dueño de cada regla |
| Quería cancelar, reprogramar o confirmar una cita que ya tenía | 04. Ciclo posterior | Con el HIS y las herramientas de comunicación: dónde vive el estado de la cita |
Al final de la semana, la distribución de llamadas te dice dónde invertir. En muchos casos aparece una capa que concentra la mayoría de los motivos, y esa es la conversación que hay que tener con el área asistencial, con el proveedor del HIS o con el equipo del portal.
¿Qué capa conviene resolver primero?
Conviene empezar por la capa que concentra más llamadas y que menos depende de terceros. La capa 03 suele ser la de arranque más rápido, porque modelar el catálogo de citas y sus reglas depende sobre todo del hospital y del equipo del portal. Las capas 01 y 02 dependen de lo que exponga el HIS y el sistema de convenios, y su plazo lo marca la conversación con esos proveedores.
Mientras las cuatro capas no estén resueltas, hay una alternativa honesta: ofrecer agendamiento en línea solo para los tipos de cita en los que las cuatro capas funcionan, y decirle claramente al paciente cuáles requieren llamada. Un portal que agenda bien tres especialidades genera más confianza que uno que promete todas y falla en la mitad.
esinergia acompaña la operación digital de instituciones de salud como la Fundación Santa Fe de Bogotá, RedSalud Chile, Clínica La Sabana y Comfandi, cliente de esinergia desde hace ocho años. De ese trabajo sale el criterio para ordenar las capas: en organizaciones de este tamaño, el portal de pacientes convive con sistemas clínicos, de facturación y de comunicación que tienen sus propios dueños y ritmos, y la integración se diseña alrededor de esa realidad.
Preguntas frecuentes sobre agendamiento en línea en salud
¿Qué estándar se usa para conectar la agenda del hospital con el portal?
Los dos estándares de referencia son HL7 v2 y FHIR, ambos publicados por HL7 International, la organización que desarrolla los estándares de interoperabilidad en salud. HL7 v2 es un estándar de mensajería clínica muy extendido en los sistemas hospitalarios instalados, e incluye mensajes de agendamiento (la familia SIU). FHIR (Fast Healthcare Interoperability Resources) es el estándar de HL7 International para intercambiar datos de salud mediante API web, y define los recursos Schedule, Slot y Appointment, que permiten consultar disponibilidad y crear citas mediante una API moderna. La elección depende de lo que soporte el HIS de cada institución, y conocerla es el primer paso de cualquier proyecto de interoperabilidad en salud. El papel de estos estándares en la integración clínica completa está en Por qué la integración con el sistema de información clínica sigue fallando.
| Criterio | HL7 v2 | FHIR |
| Cómo intercambia datos | Mensajes entre sistemas, disparados por eventos | API web sobre recursos, en JSON o XML |
| Elementos de agenda | Mensajes de la familia SIU | Recursos Schedule, Slot y Appointment |
| Presencia en hospitales | Muy extendido en sistemas ya instalados | Creciente en sistemas y versiones recientes |
| Uso típico en agendamiento | Avisarle al portal los cambios de agenda | Consultar disponibilidad y crear citas desde el portal |
¿El portal de pacientes reemplaza al sistema de información hospitalaria?
El portal de pacientes es la capa de experiencia y el HIS sigue siendo la fuente de verdad de la agenda, la historia clínica y la facturación. El portal consulta y escribe en el HIS a través de integraciones, y la lógica clínica se queda en el HIS. Esa separación permite cambiar el portal sin tocar el sistema clínico, y actualizar el HIS sin rehacer la experiencia del paciente.
¿Qué papel cumple un DXP en el portal de un hospital?
Un DXP, o plataforma de experiencia digital, es la capa que gestiona el contenido, la experiencia del paciente y las integraciones con los sistemas internos en todos los canales digitales del hospital. En agendamiento, el DXP aloja el catálogo de servicios y sus reglas, presenta el flujo al paciente y orquesta las llamadas al HIS y al sistema de convenios. Drupal es un CMS open source que sirve como base de un DXP en muchas instituciones de salud y educación, y proveedores del ecosistema como Acquia y Dropsolid suman sobre Drupal capas de nube, datos y gobierno de contenido. El marco completo está en ¿Qué es un DXP y su empresa realmente necesita uno?, y la forma en que esinergia trabaja la plataforma, en la página de Drupal.
¿Hacia dónde va el agendamiento en salud?
En los próximos tres a cinco años, una parte creciente de los pacientes va a pedirle a un asistente de IA que le busque y le agende una cita, en lugar de entrar al portal. Ese asistente va a necesitar exactamente lo mismo que hoy necesita el portal: agenda en tiempo real, verificación de cobertura, reglas legibles por una máquina y un estado de la cita confiable. Los hospitales que resuelvan las cuatro capas para su propio portal van a tener lista la base para ese canal.
esinergia es Drupal Certified Partner Platinum y acompaña a organizaciones enterprise en LATAM desde 2009. Si quieres seguir la serie sobre integración y experiencia del paciente en portales de salud, suscríbete a Insights y te llegará el próximo análisis.