Caso de éxito · HealthTech · Diagnóstico
Caso de éxito Unilab: cómo lanzamos una plataforma de pacientes de diagnóstico en producción —apps nativas para iOS y Android, un área personal web y los adaptadores que conectan con los sistemas heredados de agendas y contabilidad—, creada con Symfony, con flujos de notificaciones push fiables en APNs y FCM, un catálogo de 2,500 pruebas y un enfoque de privacidad alineado con el RGPD para la Unión Europea y con la CCPA para Estados Unidos desde el primer día.
El personal administrativo de Unilab gestionaba a mano las solicitudes de citas, las llamadas entrantes, la introducción de datos de pacientes y el envío por correo de los resultados de las pruebas en una red que opera en más de cuarenta ciudades. Los sistemas de agendas y de contabilidad existentes eran robustos y fiables, pero se habían construido años antes de que el tráfico móvil fuera una clase de carga relevante y no exponían ninguna superficie de cara al cliente a la que un paciente pudiera acceder desde el teléfono. El laboratorio necesitaba una plataforma unificada para pacientes —registro y área personal, reserva de citas online, resultados digitales, un catálogo con búsqueda de más de 2,500 pruebas, un mapa interactivo de sedes y recordatorios push— que se integrara con los sistemas de agendas y contabilidad existentes en lugar de sustituirlos. La plataforma también debía resistir las expectativas de privacidad sanitaria de Estados Unidos y la Unión Europea: el RGPD para pacientes europeos, la CCPA para pacientes de California y una arquitectura apta para HIPAA para cualquier escenario futuro de lanzamiento en EE. UU. Construimos la plataforma como un backend en Symfony con servicios adaptadores hacia los sistemas heredados, acompañado de clientes nativos para pacientes en iOS (Swift) y Android (Kotlin) y un área personal web en React. El resultado es una plataforma de diagnóstico en producción que escala entre ciudades, elimina el coste administrativo manual y está posicionada para operar conforme a las expectativas de privacidad en EE. UU. y la UE.
Un resumen de lo que aportó el desarrollo de Unilab en iOS, Android, web y un backend en Symfony conectado con sistemas heredados de agendas y contabilidad.
La decisión de plataforma pesa más que cualquier otra en la fiabilidad de una app de pacientes sanitaria. Elegimos Swift (iOS) y Kotlin (Android) nativos frente a un MVP en Flutter y frente a un plugin de portal de pacientes para WordPress porque las contrapartidas encajan limpiamente con lo que realmente necesita un laboratorio con varias ciudades. Los portales de WordPress resultan atractivos en una llamada comercial, pero se vienen abajo rápido con el perfil de carga de un laboratorio —cambios en las franjas de citas, conciliaciones contables, entrega de push cuando el resultado está listo— y atan al operador a un ecosistema de plugins al que ningún auditor sanitario toma en serio. Flutter es excelente para apps con muchos formularios, pero añade un puente entre Dart y los flujos de push de la plataforma y las API biométricas, y las notificaciones de resultado listo no pueden permitirse ruido en ese punto.
El desarrollo se apoya en Apple Push Notification service en iOS, Firebase Cloud Messaging en Android y el framework Symfony en el backend: primitivas probadas que nos dan un comportamiento determinista del push, una semántica de sincronización en segundo plano predecible y una capa de backend que los operadores sanitarios de EE. UU. y la UE reconocen y en la que confían.
| Criterio | iOS + Android nativos (Unilab) | Flutter | Portal en WordPress |
|---|---|---|---|
| Fiabilidad del push | APNs / FCM directos; entrega determinista | Puente a los flujos de la plataforma; condiciones de carrera poco frecuentes | Solo push web; débil en iOS |
| Encaje con el adaptador de agendas | Superficie REST limpia desde el adaptador de Symfony | Se puede acceder al mismo backend; mismo encaje | Atado a plugins; mapeo rígido |
| Escalado multiciudad | Modelo de datos con tenants; añadir una ciudad es solo configuración | Igual; paridad de interfaz sólida | Red de sitios o WP multisitio: operativamente pesado |
| Latencia de la integración contable | El servicio adaptador cachea las lecturas; interfaz en menos de un segundo | Mismo backend; misma latencia | Llamadas síncronas de plugins; esperas visibles para el usuario |
| Biometría y Face ID | LocalAuthentication / BiometricPrompt nativos | Puente de plugin; normalmente sin problemas | No disponible fuera de un envoltorio nativo |
| Adecuación a la revisión de la App Store | De primer nivel: entitlements sanitarios sin problemas | De primer nivel; mismo camino de revisión | A menudo rechazada por ser un «envoltorio web» |
| Enfoque de auditoría (EE. UU. + UE) | Almacén de eventos propiedad del operador, inmutable | Mismas garantías de backend | Base de datos del plugin; auditoría débil |
Referencias: documentación de Apple Push Notification service, guía de Firebase Cloud Messaging, documentación del framework Symfony.
El cliente de iOS está construido en Swift con SwiftUI para la capa de interfaz y una separación MVVM limpia que mantiene legible el flujo de reserva de citas para el siguiente ingeniero que tenga que tocarlo. El flujo de reserva es la columna vertebral de la experiencia del paciente: el paciente abre la app, explora las pruebas, elige fecha, hora y sede y confirma, mientras el servicio adaptador traduce la solicitud al protocolo del sistema de agendas heredado entre bastidores. El mapa interactivo de sedes es un flujo aparte con una vista basada en MapKit y filtrado por ciudad, de modo que un paciente que vive en una ciudad no tiene que pasar por sedes de otra para encontrar un hueco sin cita.
Las notificaciones push se conectan mediante APNs y se segmentan por finalidad: los recordatorios de citas, las notificaciones de resultado listo y los push promocionales viven cada uno en su propia categoría para que los usuarios los gestionen de forma independiente. La obtención en segundo plano mantiene preparada el área personal para que un paciente que abre la app a las 7 de la mañana vea la cita de hoy sin esperar a un viaje de ida y vuelta por la red. Toda la superficie de iOS se entrega como parte de nuestra práctica de desarrollo de apps móviles, con tokens de diseño compartidos entre iOS y Android para que la experiencia del paciente se lea como un único producto en ambas tiendas.
El cliente de Android está escrito en Kotlin con Jetpack Compose para la interfaz y un servicio en primer plano para la entrega de resultados listos en las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel, donde los optimizadores de batería agresivos cierran servicios en segundo plano sin avisar. Los resultados llegan como blobs cifrados mediante una descarga HTTPS activada por el push de FCM, nunca dentro de la propia carga útil del push, y un paso con BiometricPrompt controla el acceso para que un teléfono olvidado en la mesa de una cafetería no muestre a un desconocido el análisis de sangre de un paciente. WorkManager se ocupa de las operaciones no urgentes —actualizaciones del catálogo, refrescos del mapa de sedes, vaciado de telemetría— con una semántica de reintento con espera que respeta el modo Doze entre Android 10 y Android 14.
El catálogo de 2,500 pruebas es donde el cliente de Android se gana el sueldo. La búsqueda estructurada por categorías, subcategorías y términos libres la sirve un índice de búsqueda respaldado por Symfony, con disponibilidad por ciudad para que un paciente de una ciudad nunca vea una prueba que no se ofrece allí. Los detalles de cada prueba incluyen instrucciones de preparación, plazos de entrega de resultados y precios: los mismos campos que el sistema contable heredado ya mantiene, expuestos mediante el adaptador contable para que la fuente de verdad siga siendo la base de datos contable del operador. El mismo equipo de ingeniería lleva iOS y Android en paralelo como parte de nuestra práctica de ingeniería para iOS y Android.
Los adaptadores de agendas y de contabilidad soportan el peso de la integración de la plataforma. Cada uno es un módulo de Symfony dedicado que se sitúa entre los clientes de pacientes y el sistema heredado correspondiente, traduciendo las solicitudes con forma móvil al protocolo nativo del backend heredado y absorbiendo la contrapresión cuando el sistema heredado va lento. El adaptador de agendas gestiona el pool de conexiones, cachea en Redis las lecturas que no modifican datos y escribe una pista de auditoría de cada cambio de cita para que el operador pueda reconstruir la actividad a petición del regulador. El adaptador contable hace lo equivalente con los datos de precios y facturas, manteniendo la base de datos contable como única fuente de verdad y exponiendo una superficie REST limpia a los clientes móviles sin exponer el sistema heredado a internet.
Los datos de los pacientes se encuentran tras un control de acceso basado en roles y se cifran en reposo con rotación de claves. El enfoque está construido para alinearse con las obligaciones del RGPD para pacientes de la Unión Europea y las de la CCPA / CPRA para pacientes de California y del resto de Estados Unidos, con una arquitectura apta para HIPAA lista para preparar un Business Associate Agreement cuando un escenario de lanzamiento en EE. UU. lo requiera. Cada entrega de resultados, cada cambio de cita y cada conciliación contable se escribe en un registro de auditoría inmutable que supera la siguiente auditoría del regulador como un ejercicio documental y no como una excavación arqueológica.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó a Unilab desde los problemas del operador hasta producción en iOS, Android, web y los adaptadores de integración.
Mapeo del recorrido del paciente (línea base de llamadas y papel), estudio de los protocolos de los sistemas heredados, modelo de tenencia multiciudad y revisión de privacidad sanitaria de EE. UU. y la UE (RGPD, CCPA y base apta para HIPAA).
Esqueleto del backend en Symfony, especificación del adaptador del sistema de agendas, especificación del adaptador del sistema contable, superficie REST para los clientes móviles, esquema del registro de auditoría inmutable y control de acceso basado en roles.
Cliente iOS nativo en Swift / SwiftUI, cliente Android nativo en Kotlin / Jetpack Compose, área personal web en React, catálogo de 2,500 pruebas con búsqueda estructurada y localizador de sedes con MapKit.
Flujos de push en APNs y FCM, entrega cifrada de resultados con control biométrico, pruebas del registro de auditoría, revisión de roles y permisos y prueba de carga multiciudad con el volumen de pacientes previsto.
Envío a App Store + Google Play en las tiendas de EE. UU. y la UE, coreografía de despliegue por ciudad, runbooks de guardia para los servicios adaptadores y conciliación posterior al lanzamiento con contabilidad.
El backend contable de Unilab era el caballo de batalla de la operación existente, y la plataforma de pacientes se construyó para potenciarlo y no para sustituirlo. El adaptador contable se sitúa entre los clientes de pacientes y la base de datos contable, traduciendo las solicitudes móviles al protocolo nativo del sistema contable y escribiendo cada transacción en un registro de conciliación inmutable. Los precios del catálogo de 2,500 pruebas pertenecen al sistema contable; el adaptador cachea las lecturas en Redis con un TTL corto para que la app del paciente muestre precios actualizados sin saturar la base de datos heredada. La generación de facturas se ejecuta en el lado contable; el adaptador solo expone una vista de solo lectura para que un paciente pueda descargar un recibo sin tocar nunca los registros contables del operador. El subsistema se construyó pensando en el traspaso al operador: un administrador de la clínica abre la consola del operador, ve las citas del día por ciudad y puede intervenir —reprogramar, reembolsar, contactar con el paciente— sin salir de la plataforma. Los operadores de varias ciudades pueden acotar su vista por región, que es como un único administrador cubre las operaciones de varias ciudades en turnos tranquilos sin perder la pista de auditoría por ciudad.
La plataforma Unilab se diseñó para operadores sanitarios que atienden a pacientes en Estados Unidos y la Unión Europea. La versión en inglés da servicio a pacientes de California, Nueva York, Texas, Florida y Washington en EE. UU., y de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento tienen en cuenta la región en la capa del cliente: los pacientes de la UE y del EEE reciben una pantalla de consentimiento granular al estilo del RGPD, con interruptores independientes para los canales de entrega de resultados y la analítica de producto opcional; los pacientes de California reciben, en el mismo flujo, un aviso al estilo de la CCPA: «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los pacientes europeos y con el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y Oregon CPA. La arquitectura apta para HIPAA ofrece la base para un escenario de Business Associate Agreement, aunque HIPAA solo se aplica cuando el operador es una entidad cubierta según la legislación estadounidense.
El despliegue del backend se ejecuta en paralelo en regiones de la UE y de EE. UU. —Países Bajos, Alemania, Francia, Suecia e Irlanda para la cobertura de la UE; el este y el oeste de EE. UU. para Norteamérica—, con servicios de Symfony e instancias de PostgreSQL aprovisionados de forma idéntica mediante Terraform. El almacén de datos de pacientes y el registro de auditoría pueden fijarse a regiones de EE. UU. o de la UE para futuros compromisos de residencia de datos, y los servicios adaptadores no tienen estado, por lo que pueden escalarse de forma independiente en cada región. Tanto la clasificación por edad de App Store como la clasificación de contenido de Google Play se calibraron para una app sanitaria, y la política de privacidad dentro de la app se redactó para documentar exactamente la arquitectura anterior, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería responsable del desarrollo trabaja con una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coreografía de revisión en las tiendas y la respuesta de guardia.
La hoja de ruta activa de desarrollo de software a medida de Unilab incluye un nivel de telemedicina con videoconsultas, una integración más profunda con el sistema contable del operador para el traspaso directo de reclamaciones de seguros, un portal por médico para clínicas asociadas y una capa de resultados estructurados en JSON-LD para que los resultados de los pacientes se muestren con limpieza en historiales de salud de terceros. Está prevista una versión B2B con dominio propio, gestión de equipos y SSO para programas de salud corporativos de EE. UU. y la UE. Los planes de infraestructura incluyen más particionado (sharding) por ciudad, un arnés interno de verificación continua de las invariantes del registro de auditoría y una futura evaluación de preparación independiente integrada en la hoja de ruta de cloud y DevOps.
Si está planificando una plataforma de pacientes de diagnóstico, una app sanitaria multiciudad o cualquier producto móvil en el que la integración con backends heredados de agendas y contabilidad deba resistir la revisión de un regulador para públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el calendario del desarrollo. El cliente iOS en producción está disponible en la App Store de Apple en iOS y Android, y el equipo de ingeniería responsable trabaja dentro de YuSMP Group. Trabajamos a precio cerrado para MVP bien delimitados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una ventana garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Un MVP centrado en clientes nativos para pacientes en iOS y Android, un área personal web, reserva de citas, resultados digitales de pruebas y un adaptador del sistema de agendas suele costar entre $160k y $320k. Añadir un catálogo de 2,500 pruebas con búsqueda estructurada, un mapa interactivo de sedes, notificaciones push, integración con el sistema contable, soporte multiciudad y registro sanitario listo para auditoría lleva una plataforma completa a $360k–$700k. Los principales factores de coste son el adaptador del sistema de agendas heredado, la integración contable y los flujos de push específicos de cada plataforma en Apple Push Notification service y Firebase Cloud Messaging.
Las apps de pacientes sanitarias dependen de la fiabilidad del push propia de cada plataforma, del comportamiento de la obtención en segundo plano y de primitivas de autenticación biométrica que maduran más rápido en nativo que en los wrappers de Flutter. Kotlin y Swift nativos exponen directamente APNs y FCM, Face ID y los avisos biométricos, y las primitivas de sesiones URL en segundo plano y de WorkManager, de modo que los recordatorios de citas, las notificaciones de resultado listo y las actualizaciones silenciosas llegan de forma predecible en Samsung, Xiaomi, OnePlus, Pixel e iPhone. Flutter es excelente para apps con muchos formularios, pero añade un puente entre Dart y las capas de push y biometría de la plataforma, y las apps sanitarias no pueden permitirse ruido en ese punto.
La mayoría de los sistemas de agendas de laboratorio no están expuestos a internet y no se diseñaron para tráfico móvil. La integración se sitúa tras un servicio adaptador dedicado —un módulo de Symfony que traduce las solicitudes de la app de pacientes al protocolo nativo del sistema de agendas, gestiona el pool de conexiones y absorbe la contrapresión cuando el sistema heredado va lento—. El adaptador cachea en Redis las lecturas que no modifican datos, expone una superficie REST limpia a los clientes móviles y escribe una pista de auditoría de cada cambio de cita para que el operador pueda reconstruir la actividad en las auditorías de cumplimiento de EE. UU. y la UE.
El escalado multiciudad es un problema de modelo de datos antes que de infraestructura. Las sedes, las franjas de citas, los menús de pruebas y los precios viven como tenants de primer nivel de la plataforma: cada ciudad se configura de forma independiente y la app del paciente lee únicamente el catálogo y el mapa de sedes relevantes para su ubicación. El backend ejecuta workers sin estado tras un enrutador que conoce las ciudades, de modo que añadir una ciudad nueva es un cambio de configuración en el almacén de tenants y no una publicación de código, y la capa de caché de Symfony evita que las lecturas del catálogo concentren la carga en una sola base de datos.
Un MVP centrado en clientes nativos de iOS y Android, un área personal web, reserva de citas, resultados digitales y un adaptador del sistema de agendas suele tardar entre 14 y 22 semanas. Añadir un catálogo de 2,500 pruebas, un mapa interactivo de sedes, flujos de push, integración contable y tenencia multiciudad suma entre 8 y 14 semanas. El trabajo con los adaptadores heredados suele subestimarse y conviene presupuestarlo en 4–6 semanas de esfuerzo dedicado, porque los protocolos de los sistemas de agendas varían de una red de laboratorios a otra y rara vez encajan con el modelo de datos de la app de pacientes a la primera.
Casos relacionados
App multiplataforma de dietas y planificación de comidas: Flutter, motor de calorías, pedido de la compra y nivel de suscripción conforme con EE. UU. y la UE.
Ver el caso →
App y portal web de noticias deportivas multiplataforma: CMS con bot de Telegram, flujo de Markdown, iOS + Android nativos.
Ver el caso →
App para asesores de retail con inventario de boutiques entre tiendas: búsqueda con ElasticSearch, integración con 1C y alcance multitienda.
Ver el caso →
Plataformas SaaS multi-tenant con SSO, facturación y residencia fijada por región. SOC 2 en curso.
Más información →
Plataformas empresariales con la arquitectura como punto de partida, cumplimiento listo para auditoría e integración con SAP, Salesforce, Workday y Okta.
Más información →
Plataformas a medida diseñadas para su modelo de negocio, que escalan sin problemas desde el MVP hasta millones de usuarios.
Más información →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.