Desarrollar software para el sector sanitario — requisitos, costes y errores a evitar

Encargar el desarrollo de software a medida para el sector sanitario es fundamentalmente diferente a una tienda online o un panel de control interno. Eso no se debe solo a la técnica —sino al sistema de requisitos, responsabilidades y supervisión que rodea al sector sanitario. Quien subestima eso paga el precio más adelante: en retrasos, trabajo de corrección, o peor aún, en un producto que no puede entrar en uso.

Este artículo está dirigido a instituciones sanitarias, empresarios del sector y responsables de decisiones que están pensando en desarrollar un producto digital —desde un portal de pacientes hasta un sistema de informes o un EHR propio. Ofrece una imagen honesta de lo que implica este proceso, cuánto cuesta y cuáles son los errores más frecuentes.

La normativa que no puede ignorar

NEN 7510 — seguridad de la información en la sanidad

NEN 7510 es la norma neerlandesa para la seguridad de la información en el sector sanitario. Comparable a ISO 27001, pero específicamente orientada a la protección de datos médicos. Para muchas organizaciones sanitarias, la certificación NEN 7510 es obligatoria o requerida contractualmente por las aseguradoras y organizaciones paraguas.

Lo que esto significa en la práctica para un proceso de software: el proveedor debe poder demostrar que el sistema cumple con los requisitos de seguridad de la norma. Eso requiere control de acceso por roles, registro de quién ha consultado qué datos y cuándo, cifrado de datos en tránsito y en reposo, y un proceso de respuesta a incidentes documentado. Estos no son elementos que se incorporan después —deben estar en el diseño desde el primer día.

RGPD y datos médicos

Los datos médicos entran en la categoría de datos personales especiales en el RGPD. Su tratamiento está en principio prohibido, salvo que exista una base legal explícita. En la sanidad, esa base suele ser la relación terapéutica (artículo 9, párrafo 2h del RGPD), pero eso no le exime de otras obligaciones.

Una agencia de software que construye software sanitario actúa jurídicamente como encargado del tratamiento. Eso significa que un acuerdo de encargado del tratamiento es obligatorio, la minimización de datos debe incorporarse en el diseño, y las brechas de datos deben poder notificarse en un plazo de 72 horas a la Autoridad de Protección de Datos. Las organizaciones sanitarias que delegan esto a una agencia sin acuerdo de encargado del tratamiento son ellas mismas responsables.

Tarjetas UZI y autenticación

Para sistemas que dan acceso al Punt de Commutació Nacional (LSP) o que trabajan con el registro BIG, la autenticación mediante tarjetas UZI (Identificación Única del Proveedor de Atención) es obligatoria. Son tarjetas con chip que registran la identidad de un profesional sanitario. No todas las agencias tienen experiencia con las integraciones UZI —y no es una tarea técnica trivial.

Los sistemas que no necesitan una conexión directa con el LSP pueden también trabajar con DigiD (para pacientes) u otros medios de autenticación certificados, dependiendo del nivel de riesgo.

SMART on FHIR e interoperabilidad

Uno de los requisitos más subestimados en el software sanitario es la interoperabilidad: el requisito de que los sistemas puedan comunicarse entre sí. En los Países Bajos, FHIR (Fast Healthcare Interoperability Resources) es el estándar para el intercambio de datos médicos. SMART on FHIR es un marco de autorización que se sitúa sobre él y permite la conexión segura con sistemas externos.

Si su nuevo sistema necesita en absoluto comunicarse con un EPD (Historia Clínica Electrónica), un sistema de médico de cabecera o el LSP, el soporte de FHIR no es un lujo —es una condición previa. Muchos software estándar no lo soportan o lo hacen de forma incompleta. El software a medida puede incorporarlo, pero aumenta la complejidad y los costes.

Pregunte siempre explícitamente en una conversación con una agencia: ¿han construido antes integraciones FHIR? ¿Tienen referencias en el sector sanitario? Una agencia que es vaga al respecto probablemente no lo ha hecho.

Casos de uso habituales

No todo el software sanitario es igual de complejo. Algunos casos de uso habituales, ordenados por complejidad:

Portal de pacientes — Un entorno seguro donde los pacientes pueden ver citas, rellenar cuestionarios o enviar mensajes. Relativamente manejable en alcance, pero requiere cumplimiento del RGPD, integración con DigiD y una buena UX para un grupo de usuarios diverso.

Sistema de planificación para profesionales sanitarios — Horarios, citas, disponibilidad. El desafío está en la lógica de planificación compleja (contratos a tiempo parcial, especialidades, ubicaciones) y la integración con sistemas de RRHH o EHR existentes.

Historia clínica o EHR — El tipo más complejo. Registro estructurado de planes de cuidado, datos de tratamiento, medicación. Requiere estandarización mediante FHIR, auditoría sólida, y a menudo integración con sistemas externos como software de farmacia o el LSP.

Informes a las autoridades sanitarias — Muchas organizaciones sanitarias deben informar periódicamente a la Autoridad Sanitaria Neerlandesa (NZa) o a las aseguradoras. El software que automatiza esto debe ajustarse exactamente a los códigos DBC requeridos y los formatos de declaración.

Por qué el software sanitario es más caro

La diferencia de precio entre una aplicación web normal y el software sanitario tiene tres causas.

Sobrecarga de cumplimiento — Documentación, auditoría de seguridad, prueba de penetración y el cumplimiento demostrable de NEN 7510 cuestan tiempo adicional. Este es un trabajo que no es visible en la interfaz del usuario final, pero que es necesario para poder poner en uso el sistema.

Complejidad de integración — Las conexiones con sistemas EPD, infraestructura UZI, LSP o endpoints FHIR son técnicamente exigentes. No son conexiones API estándar —requieren certificados, protocolos específicos y pruebas exhaustivas.

Requisitos de prueba — En la sanidad, los errores pueden tener consecuencias directas para la seguridad del paciente. Eso requiere una estrategia de pruebas más extensa, incluidas pruebas de aceptación funcional con usuarios finales (profesionales sanitarios), y a veces la certificación como dispositivo médico bajo el MDR (Medical Device Regulation).

Indicaciones presupuestarias realistas

Para el software sanitario se aplican normas presupuestarias diferentes a las del desarrollo estándar a medida:

• Portal de pacientes (básico): €40.000 – €70.000. Incluye DigiD, mensajería segura, resumen de citas y cumplimiento del RGPD. Sin integración con EPD.
• Portal de pacientes con integración EPD: €80.000 – €140.000. Dependiendo del EPD y las interfaces de conexión disponibles.
• Sistema de planificación: €60.000 – €120.000. Muy dependiente de la complejidad de la planificación y el número de integraciones.
• EHR o EPD completo: €150.000 – €400.000+. Esto es desarrollo a medida en la categoría más exigente. Espere un proceso de 9 a 18 meses con un equipo multidisciplinar.

Sobre los costes de construcción se añaden los costes continuos: hosting (preferiblemente en los Países Bajos o la UE, en infraestructura certificada), mantenimiento, revisiones anuales de seguridad y posible recertificación.

Los errores que más sufren las instituciones sanitarias

Elegir una agencia sin referencias sanitarias. Técnicamente muchas agencias pueden construir una aplicación. Pero una agencia que nunca ha trabajado en el sector sanitario no conoce los requisitos de cumplimiento desde dentro. El resultado: paga por un proceso de aprendizaje que el proveedor hace a su cargo.

Aplazar el cumplimiento hasta después de la construcción. La seguridad y el cumplimiento del RGPD no son una capa de pintura que se aplica después. Quien lo incorpora tras la primera versión, efectivamente reconstruye el sistema. Planifique el cumplimiento como un requisito de primera clase, no como un proceso posterior.

No tener en cuenta los cambios en la normativa. El sector sanitario se digitaliza rápidamente, y la regulación evoluciona con él. Los sistemas que hoy cumplen pueden necesitar adaptarse en dos años. Asegúrese de que haya un contrato de mantenimiento y que la agencia esté disponible también a largo plazo.

Olvidar al usuario. Los profesionales sanitarios están ocupados. Un sistema que no funciona de forma intuitiva no se usa —independientemente de lo que haya costado. Invierta en investigación de usuarios y pruebe pronto con profesionales sanitarios y pacientes reales.

Encontrar la agencia correcta

Pregunte en las conversaciones con las agencias por referencias concretas en el sector sanitario. No solo "hemos hecho algo en sanidad antes", sino: ¿qué sistema, para qué organización, con qué integraciones, y cuáles eran los requisitos de cumplimiento? Pregunte también por el acuerdo de encargado del tratamiento —una agencia que no puede hablar directamente de esto tiene poca experiencia con el RGPD en la sanidad.

Verifique si la agencia está familiarizada con NEN 7510, FHIR y la infraestructura sanitaria neerlandesa. Estos no son puntos adicionales —son cualificaciones básicas para este tipo de trabajo.

Construir software sanitario es complejo, pero es manejable si sabe lo que está comprando. Las organizaciones que digitalizan con éxito no son las que tienen el mayor presupuesto —son las organizaciones que encuentran el partner correcto y hacen las preguntas correctas.