Plataforma de automatización sanitaria

Contexto

Un equipo de facturación sanitaria reunía información de visitas y autorizaciones, comprobaba que coincidiera y la trasladaba entre herramientas hasta completar la facturación y registrar los pagos. Las hojas de cálculo y el correo servían para coordinar lo que los sistemas no resolvían. Una corrección podía obligar a revisar trabajo que parecía terminado.

El volumen crecía y cada nuevo centro añadía tareas al equipo. Necesitábamos automatizar las operaciones repetitivas y conservar una forma clara de revisar las excepciones. El servicio debía seguir funcionando durante el desarrollo, con las restricciones de acceso y los formatos de información que ya existían.

Mi papel y liderazgo técnico

Preparé la propuesta técnica, incluyendo la arquitectura y las necesidades de infraestructura, y definí cómo organizar el desarrollo y las pruebas. Lideré el diseño de la aplicación y trabajé con el equipo en su implementación y puesta en producción. Mi responsabilidad incluía traducir las necesidades de facturación a reglas y estados que el software pudiera manejar.

También intervine en la coordinación de la entrega y en las conversaciones sobre alcance. A medida que avanzábamos aparecían casos que los requisitos iniciales no cubrían. Incorporé a las personas que conocían la operación diaria a esas conversaciones para resolver dudas con ejemplos reales y decidir qué necesitaba entrar en cada entrega.

Ese cambio redujo las interpretaciones entre negocio y desarrollo. Pudimos poner límites a peticiones nuevas y anticipar mejor su efecto sobre el trabajo previsto. Las decisiones de presupuesto y producto seguían siendo compartidas; yo aportaba el criterio técnico y explicaba las consecuencias de cada opción.

Desafíos y trade-offs

Aprovechamos una base de aplicación existente para reducir el tiempo de la primera entrega. Propuse separar la interfaz de operación, pero se decidió ampliar el panel disponible para contener el coste. Eso permitió avanzar antes, a cambio de adaptar una herramienta general a un flujo cada vez más específico. Mantener esas personalizaciones terminó exigiendo más esfuerzo del previsto.

Las integraciones tampoco permitían el mismo grado de automatización. Parte de la información requería acceso humano a un sistema externo. Integramos una obtención semiautomática dentro del flujo general, respetando esa restricción. El trabajo posterior podía automatizarse una vez que los datos estaban disponibles.

Había que decidir, además, cuándo detener el flujo. Una autorización incompleta o una discrepancia entre registros requerían revisión. Las alertas convertían esos casos en trabajo visible para el equipo de facturación, con información para decidir cómo continuar.

Cómo diseñamos el flujo

Organicé la aplicación alrededor de estados persistidos: el progreso quedaba guardado y podía consultarse después de cada ejecución. Los trabajos programados recogían cambios de las fuentes y ejecutaban las operaciones de facturación. Los puntos de control registraban hasta dónde había llegado la sincronización y ayudaban a localizar trabajo pendiente o interrumpido.

Trabajé con el equipo en el modelo de datos y las integraciones. Una visita, su autorización y el resultado de la facturación tenían que poder relacionarse aunque llegaran en momentos distintos. Guardábamos referencias a los registros externos y comprobábamos su existencia antes de repetir determinadas operaciones. También tratábamos las respuestas que indicaban que una operación ya se había realizado, para evitar duplicados en un flujo con consecuencias económicas.

Parte de las autorizaciones llegaba como texto. Construimos reglas de extracción que reconocían patrones en los formatos habituales y convertían la información en datos utilizables por la aplicación. La precisión de extracción se situó en ≈85 a 90 %. Los casos que requerían corrección seguían teniendo una vía de revisión humana.

La interfaz permitía supervisar el avance y atender alertas. El conocimiento del equipo de operaciones nos ayudó a ajustar qué información debía acompañar cada excepción. De poco servía detectar una diferencia si después había que reconstruir todo el caso para resolverla.

Rendimiento y crecimiento

La sincronización se hizo más costosa al crecer el volumen y cambiar un requisito: algunos registros podían corregirse después de su primera importación. Había que volver a consultar periodos anteriores. El trabajo acumulado empezó a solaparse con el uso diario de la aplicación y a degradar su respuesta.

Investigué los registros de ejecución para localizar las operaciones costosas. Encontramos llamadas demasiado pequeñas y consultas repetidas para obtener datos relacionados. Era un patrón de tipo N+1: después de recuperar una lista, se hacía otra consulta por cada elemento. Con más registros, el número de accesos crecía rápidamente.

El equipo agrupó operaciones por lotes, paginó la obtención de datos y sustituyó algunos accesos genéricos por consultas específicas. Así redujimos las llamadas necesarias y mejoramos la sincronización. La separación del procesamiento intensivo y la atención a usuarios quedó pendiente: propuse aislar esa carga, pero el cambio estructural no llegó a completarse durante mi etapa.

Resultados

El trabajo manual se redujo en ≈90 %. La operación comenzó con 200 centros y llegó a atender a más de 1.000 sobre la plataforma. El equipo pasó de ejecutar el flujo entre herramientas a supervisar excepciones y resolver los casos que necesitaban criterio humano.

La participación directa de operaciones también mejoró la previsibilidad de las entregas y la comunicación con desarrollo. La plataforma llegó a producción, entró en mantenimiento y siguió ampliándose después de mi etapa en el proyecto.

La intervención humana se concentra en los casos que necesitan criterio.

Qué aprendí y qué cambiaría

Habría involucrado antes a las personas que realizaban la facturación y probado las integraciones más inciertas antes de cerrar el alcance. Varias restricciones aparecieron cuando ya condicionaban decisiones de diseño y plazos de entrega.

También habría reservado desde el inicio trabajo para separar las tareas intensivas del uso interactivo y probar con volúmenes representativos. Las correcciones sobre datos antiguos debían formar parte de esas pruebas. Hoy documentaría antes qué ocurre al repetir una operación, cómo se recupera una ejecución interrumpida y qué comprobaciones permiten dar una sincronización por terminada.

En las decisiones compartidas dejaría por escrito el coste de las alternativas y sus límites. Habría facilitado revisar, con evidencia del uso, compromisos que tenían sentido para empezar pero que resultaban cada vez más caros de mantener.