Cuando hablamos de un sistema de historia clínica, normalmente pensamos en la atención médica, la historia clínica, las órdenes o los resultados de laboratorio. Pero hay un módulo que muchas veces pasa desapercibido y que realmente es el que da inicio a todo el proceso: la agenda.
Antes de que exista una atención, tiene que existir una cita. Y, aunque parece algo sencillo, detrás de esa cita hay reglas de negocio, disponibilidad de profesionales, validaciones y muchas decisiones que deben tomarse para que el paciente realmente pueda acceder al servicio.
historiaenlínea
Con el tiempo fuimos evolucionando este módulo en historiaenlínea, y la idea ya no era que solo funcionara para el personal administrativo. Queríamos que pudiera ser utilizado por otros sistemas de forma segura, manteniendo siempre las mismas reglas de negocio, sin importar desde dónde se estuviera solicitando la cita.
Cómo funcionaba antes
Durante mucho tiempo, la asignación de citas se hacía desde el mismo módulo administrativo o por medio de un operador que atendía llamadas o pacientes de forma presencial.
El proceso era simple. El funcionario consultaba la agenda, revisaba qué cupos tenía disponibles el profesional y, finalmente, asignaba la cita.
El problema no era que funcionara mal, porque realmente cumplía su objetivo. El inconveniente aparecía cuando queríamos abrir nuevos canales de atención. Si cada canal manejaba su propia lógica o consultaba la disponibilidad de forma diferente, era muy fácil terminar con inconsistencias o, incluso, con una doble asignación de un mismo cupo.
Ahí fue donde vimos la necesidad de hacer que el módulo de agendas fuera interoperable.
Una agenda pensada para integrarse
La solución no fue desarrollar un nuevo sistema de agendas, sino permitir que otros sistemas pudieran utilizar el que ya existía.
Para eso se desarrollaron servicios que permiten consultar disponibilidad, reservar un cupo y asignar una cita utilizando exactamente las mismas reglas del módulo administrativo.
Uno de los consumidores de estos servicios es un chatbot desarrollado por un tercero. El chatbot no administra agendas ni toma decisiones sobre la asignación; simplemente consume los servicios que expone Historiaenlínea, y toda la lógica sigue estando centralizada en el sistema.
Eso nos permitió lograr algo muy importante: que cualquier nuevo canal pudiera utilizar el mismo módulo sin tener que volver a desarrollar toda la lógica de asignación.
Dos formas de llegar a una cita
Con esta integración empezamos a manejar dos escenarios diferentes.
Demanda espontánea
Este es el caso más común y, seguramente, el que todos conocemos.
El paciente necesita una cita y la pide desde alguno de los canales disponibles. Puede ser un operador, un portal o un chatbot integrado.
Cuando llega esa solicitud, el canal consulta la disponibilidad directamente en historiaenlínea, muestra únicamente los cupos disponibles y, cuando el paciente confirma, la cita queda registrada en el módulo de agendas.
Aunque el paciente interactúe con diferentes canales, todos terminan realizando exactamente la misma operación sobre la misma agenda.
Demanda inducida
Este escenario me parece mucho más interesante.
Aquí no es el paciente quien inicia el proceso. Es la institución la que identifica que una persona debería tener una nueva atención.
Puede tratarse de un control que está próximo a vencer, un seguimiento, una cita pendiente o cualquier otra regla que la institución haya definido.
Con esa información, plataformas externas, como el chatbot, pueden contactar al paciente y ofrecerle agendar la cita utilizando nuevamente los servicios de historiaenlínea.
Al final, el canal puede cambiar, pero la asignación siempre pasa por el mismo módulo de agendas.
El reto más importante
Desde mi punto de vista, el reto técnico más grande no fue desarrollar los servicios.
Lo realmente complejo fue asegurarnos de que todos los canales consultaran exactamente la misma información.
Si el módulo administrativo veía una disponibilidad y otro canal veía una diferente, tarde o temprano iban a aparecer problemas: dos personas intentando tomar el mismo cupo, reservas inconsistentes o citas que realmente ya no estaban disponibles.
Por eso, todas las consultas y asignaciones pasan por el mismo punto de verdad.
También fue necesario manejar reservas temporales. Mientras un paciente está confirmando una cita, ese espacio queda bloqueado durante un tiempo para evitar que alguien más lo tome. Si la confirmación no se completa, el cupo vuelve a quedar disponible automáticamente.
Son detalles que muchas veces el usuario no ve, pero hacen una gran diferencia para mantener la consistencia de la agenda.
Una arquitectura preparada para crecer
Algo que me gusta de este enfoque es que no depende de un canal específico.
Hoy uno de los consumidores es un chatbot, pero mañana podría ser una aplicación móvil, un portal para pacientes, un centro de contacto o cualquier otra plataforma que necesite consultar o asignar citas.
Mientras utilicen los servicios de Historiaenlínea, todos van a trabajar sobre la misma disponibilidad y las mismas reglas de negocio.
Eso también simplifica bastante el mantenimiento, porque cualquier cambio en la lógica se realiza una sola vez y automáticamente aplica para todos los canales integrados.
Lo que hemos visto hasta ahora
Más allá de reducir llamadas o facilitar la asignación de citas, creo que el mayor beneficio ha sido poder centralizar toda la lógica en un solo lugar.
Ahora, cuando hablamos de nuevos canales de atención, ya no pensamos en volver a implementar un proceso completo de asignación. Simplemente consumen los servicios existentes y toda la operación sigue funcionando igual.
También cambió un poco la conversación con las instituciones. Ya no hablamos solamente de cómo asignar una cita, sino de cómo aprovechar mejor la agenda, cómo hacer seguimiento a los pacientes o cómo facilitar el acceso a los servicios utilizando diferentes canales.
Conclusión
Al final, este proyecto no se trató de integrar un chatbot.
Lo realmente importante fue convertir el módulo de agendas en un componente interoperable que pudiera ser utilizado por diferentes plataformas, sin perder consistencia ni duplicar la lógica de negocio.
Creo que esa fue la parte que más valor aportó. Hoy, cualquier sistema autorizado puede consultar disponibilidad o asignar una cita utilizando exactamente las mismas reglas que utiliza el personal administrativo. Eso hace que la agenda deje de ser un módulo aislado y se convierta en un servicio que puede crecer junto con las necesidades de cada institución.
(ELECTRONICA, s.f.)
Referencias
ELECTRONICA, S. (s.f.). https://saludelectronica.com/software-historia-clinica-en-linea/.
