La respuesta corta

Nadie va a modificar el sistema de información del hospital por tu app. Ese es el punto de partida, y aceptarlo pronto es lo que separa un proyecto que llega a producción de uno que se queda en piloto.

La integración no consiste en conectarse al core: consiste en construir una capa que traduzca entre tu producto y lo que el hospital ya expone, con la premisa de que lo que hay al otro lado cambia poco, cambia despacio y cambia sin avisarte.

Y una regla que ahorra la mitad de los problemas: tu app no debe hablar directamente con el sistema hospitalario. Habla con tu backend, y es tu backend el que se entiende con el hospital. Cualquier otra cosa acopla la versión publicada en la tienda al calendario de sistemas de un tercero.

Lo primero: qué expone realmente el hospital

Antes de diseñar nada, hay que averiguar en qué escenario estás. Suele ser uno de estos cuatro, y el coste varía mucho entre ellos:

  1. API moderna documentada, normalmente FHIR. El mejor caso, y aun así hay que saber la versión y el perfil — está en HL7 FHIR en una app móvil.
  2. Motor de integración en medio, que traduce mensajería clásica a algo consumible. Muy habitual, y el interlocutor pasa a ser el equipo que lo mantiene.
  3. Mensajería heredada: intercambio de mensajes y ficheros, con su formato propio y sus horarios de proceso.
  4. Nada. Extracciones periódicas, o acceso a una réplica de lectura. Sucede más de lo que se cuenta.

La pregunta que revela el escenario real no es «¿tenéis API?». Es: «¿qué integraciones tenéis hoy en producción con proveedores externos, y cómo funcionan?». Lo que ya funciona marca el camino que la organización sabe recorrer.

Patrones que funcionan

Capa anticorrupción. Tu modelo de datos es tuyo; el del hospital es suyo. En medio, un traductor explícito. Sin esa capa, cualquier particularidad del sistema hospitalario se filtra hasta las pantallas de la app y ya no se puede quitar.

Réplica de lectura. Si el hospital no puede soportar tus consultas contra el sistema vivo —y muchas veces no puede, ni quiere—, se trabaja contra una copia sincronizada. Cambia la frescura del dato, y eso hay que llevarlo al diseño de producto: una app que promete «en tiempo real» sobre una réplica de anoche miente.

Escritura acotada y trazada. Leer es negociable; escribir en la historia clínica es otra conversación, con otro comité. Empieza el proyecto asumiendo solo lectura y trata la escritura como una fase aparte, con su aprobación.

Modo degradado. El sistema hospitalario tendrá ventanas de mantenimiento y caídas. Tu app tiene que distinguir «no hay datos» de «no hemos podido consultar», y seguir siendo útil en el segundo caso.

Idempotencia. En cuanto hay reintentos —y los habrá— cada operación tiene que poder repetirse sin duplicar. Es lo primero que se olvida y lo que genera los tickets más difíciles de diagnosticar.

Identidad: el problema que no parece un problema

Tu usuario y el paciente del hospital son dos entidades distintas y hay que unirlas. Eso implica decidir:

  • Cómo se relacionan los identificadores, y quién mantiene esa correspondencia.
  • Quién autoriza el acceso a los datos de ese paciente, y con qué consentimiento.
  • Qué pasa con los duplicados, que existen en todos los sistemas hospitalarios del mundo.
  • Qué ve un profesional frente a qué ve un paciente. Son dos productos con dos modelos de permisos, aunque compartan backend.

Resolver esto mal se paga en incidentes de privacidad, que es la peor moneda posible en este sector.

Lo que se subestima al planificar

  • Los entornos de pruebas. Conseguir uno con datos representativos puede llevar semanas y depende de gente que no está en tu proyecto. Se pide el primer día, no cuando hace falta.
  • Los comités. Seguridad, protección de datos y a menudo un comité clínico. Cada uno tiene su calendario de reuniones, y ese calendario es el camino crítico del proyecto, no el desarrollo.
  • Las ventanas de despliegue. En hospital no se despliega cuando tú quieres.
  • El interlocutor técnico. Suele tener el sistema entero encima y tu proyecto es una prioridad entre veinte. Las estimaciones que asumen respuesta en el día se incumplen todas.

Es habitual que la parte móvil sea la mitad del esfuerzo y una fracción mucho menor del calendario. Decirlo en la propuesta, con las dependencias nombradas, evita la conversación incómoda del mes cuatro.

Antes de estimar

  1. ¿Qué integraciones con terceros tenéis hoy en producción y cómo funcionan?
  2. ¿Hay entorno de pruebas con datos representativos, y cuánto tarda en concederse?
  3. ¿Solo lectura, o también escritura? Si hay escritura, ¿qué comité la aprueba?
  4. ¿Quién mantiene la correspondencia de identidad del paciente?
  5. ¿Qué ventanas de mantenimiento y qué disponibilidad real tiene el sistema?

Las cinco son del hospital. Las cinco determinan el calendario más que cualquier decisión que tomes tú.

Es el trabajo previo de cualquier proyecto de apps para el sector salud: entender el sistema que ya está, antes de diseñar el que va encima.