Un HIS nuevo puede fallar de tres maneras que no tienen que ver con sus funciones: que deje de estar disponible, que se vea comprometido o que la gente no lo use como estaba previsto. Las dos primeras tienen marco legal: el Esquema Nacional de Seguridad, el RGPD y las cláusulas que exige la LCSP. La tercera depende de cómo se gestione el cambio. Esta lección las trata como riesgos del proyecto y cierra el caso del consorcio.

Los riesgos de cambiar de HIS

Las lecciones anteriores ya han tratado riesgos concretos: la dependencia del proveedor (en El mercado de sistemas: suites, best-of-breed, ERP y compra pública), las integraciones de red que fallan en silencio y la migración que altera la historia. Quedan cuatro, que la tabla resume como pauta de trabajo:

Continuidad: atender sin el sistema

Un hospital no cierra cuando su sistema cae. El Esquema Nacional de Seguridad pide que los sistemas de su ámbito tengan copias de seguridad y mecanismos para garantizar la continuidad de las operaciones si se pierden los medios habituales (art. 26) ¹. Su anexo II lo concreta en cuatro medidas de continuidad del servicio, que se exigen según el nivel de disponibilidad del sistema ¹:

En términos de un HIS, eso se traduce en un modo degradado diseñado antes del arranque: qué se consulta si el sistema cae (por ejemplo, una copia de solo lectura con la medicación y las alergias de los ingresados), qué se registra en papel o en un sistema de contingencia, quién lo transcribe después y cómo se evita duplicar o perder registros. El plan del ENS pide además que todos los medios alternativos estén materializados en acuerdos o contratos con los proveedores ¹: el contrato del HIS debe incluir los suyos.

Ciberseguridad desde el contrato

El ENS se aplica al sector público y también a las entidades privadas que, por contrato, le prestan servicios o le proveen soluciones (art. 2.3) ¹. Los pliegos de esas entidades públicas deben contemplar los requisitos para asegurar la conformidad con el ENS de los sistemas del contratista, como sus declaraciones o certificaciones de conformidad, y extender esa cautela a la cadena de suministro según el análisis de riesgos (art. 2.3) ¹.

Para un HIS, la pauta es pedir en el pliego lo que el centro necesita poder demostrar: la categoría de seguridad del sistema y la conformidad del proveedor, quién gestiona los parches y las vulnerabilidades, cómo se registran los accesos y cómo se notifica un incidente. El marco completo, con la Directiva NIS2 y los equipos de respuesta, está en Ciberseguridad sanitaria: ENS, NIS2 y quién responde a un incidente.

El proveedor como encargado del tratamiento

Un proveedor que aloja, mantiene o da soporte a un HIS accede a datos de salud por cuenta del centro. La LCSP le da la condición de encargado del tratamiento cuando accede a datos de los que es responsable la entidad contratante, y exige que al terminar el contrato los datos se destruyan o se devuelvan (disposición adicional vigésima quinta) ². Esa disposición cita todavía la antigua Ley Orgánica 15/1999; el contrato de encargo se escribe hoy con el artículo 28 del RGPD, que exige, entre otras cosas, que el encargado ³:

• trate los datos solo siguiendo instrucciones documentadas del responsable;
• garantice la confidencialidad de las personas autorizadas;
• aplique las medidas de seguridad del artículo 32;
• no recurra a otro encargado sin autorización previa por escrito del responsable;
• ayude al responsable a atender los derechos de los interesados y a cumplir sus obligaciones de seguridad y evaluación de impacto.

Si el contratante es una entidad pública, la LCSP añade cláusulas que el pliego debe recoger: la finalidad de la cesión de datos, la obligación de cumplir la normativa de protección de datos, la declaración de dónde estarán los servidores y desde dónde se prestarán los servicios, la comunicación de cualquier cambio en esa declaración y la indicación de si se subcontratan los servidores (art. 122.2) ². Esas obligaciones se califican como esenciales, y además debe haber una condición especial de ejecución sobre protección de datos (art. 202.1) ². El expediente, por su parte, debe especificar la finalidad del tratamiento (art. 116.1) ².

La devolución de los datos al final enlaza con la conservación de la historia: si el HIS está alojado por el proveedor, el centro sigue siendo responsable de conservarla íntegra y reproducible (art. 12) ⁴. El formato y el plazo de la devolución deben estar en el contrato. La evaluación de impacto y el papel de la autoridad de control se explican en Datos de salud: el RGPD y la LOPDGDD en un centro sanitario.

Otras obligaciones: producto sanitario y NIS2

Dos marcos más pueden afectar a un HIS y se trataron en el módulo de derechos y seguridad:

• Software como producto sanitario. Según su finalidad, un programa puede ser producto sanitario y necesitar marcado CE; la lección Software como producto sanitario y Espacio Europeo de Datos de Salud explica cuándo. La pauta es preguntar en el pliego qué módulos del sistema ofertado tienen esa condición.
• NIS2 y el EEDS. La directiva NIS2 y el Espacio Europeo de Datos de Salud traen obligaciones que se explican en el mismo módulo, con su estado de aplicación. Un contrato de varios años debe prever cómo se adaptará el sistema a las que entren en vigor durante su vigencia.

Gestión del cambio: el riesgo humano

Un HIS cambia cómo trabajan cientos de personas a la vez: médicos, enfermería, admisión, farmacia, codificación, facturación. No hay una norma que diga cómo gestionar ese cambio; lo que sigue es una pauta habitual en proyectos de sistemas clínicos, sin cifras, porque dependen de cada centro:

• Liderazgo clínico. El proyecto lo patrocina la dirección, pero lo defienden profesionales asistenciales con tiempo asignado para ello.
• Usuarios clave por servicio. Participan en el diseño y en las pruebas, se forman antes y acompañan a sus compañeros en el arranque.
• Formación por perfil y sobre casos reales, cerca del arranque, para que no se olvide, y con acceso a un entorno de práctica.
• Apoyo presencial en el arranque en cada unidad y a todas horas, también de noche y en fin de semana.
• Canal de incidencias con respuesta visible. Lo que no funciona se corrige o se explica pronto; si no, los profesionales crean circuitos paralelos en papel o en hojas de cálculo.
• Medir la adopción: qué se registra estructurado, qué se sigue escribiendo en texto libre, qué circuitos se esquivan.

El último punto conecta el riesgo humano con todo lo anterior. Un sistema que se esquiva produce un CMBD incompleto, una facturación que no cuadra y una HC3 sin información, aunque técnicamente funcione.

Caso práctico

El caso del consorcio, de principio a fin. Un consorcio sanitario público con un hospital de agudos, un centro de atenció intermèdia y una residencia asistida debe sustituir su HIS.

Decidir. El equipo separa los requisitos de red de los propios de cada centro y concluye que la residencia necesita un programa social integrado con primaria, no el HIS hospitalario (lección 1). Convierte la red en una matriz de integraciones: RCA, MPI, HC3, SIRE, CMBD, facturación e IS3 (lección 2).

Comprar. Licita en dos lotes por procedimiento abierto, con prescripciones funcionales, criterios mayoritariamente automáticos y una demostración guionizada. El pliego administrativo incluye las cláusulas de datos y la ubicación de servidores ², la conformidad con el ENS ¹ y la cesión de derechos de los desarrollos a medida (lección 3).

Migrar y arrancar. Depura el índice de pacientes, construye las tablas de equivalencias, ensaya la migración hasta que las conciliaciones cuadran y arranca con un plan de vuelta atrás. Lo no migrado queda en un archivo de consulta, conforme a un protocolo aprobado por la dirección ⁴ (lección 4).

Gestionar los riesgos. Antes del arranque, el equipo hace el análisis de impacto y escribe el plan de continuidad ¹. En urgencias, el modo degradado consiste en una copia de solo lectura actualizada periódicamente y un circuito en papel con transcripción posterior. Lo prueba en un simulacro. El contrato de encargo sigue el artículo 28 del RGPD ³ y fija el formato de devolución de los datos al final ².

Los primeros meses. Los usuarios clave de cada servicio detectan que enfermería del centro intermedio sigue anotando las valoraciones en texto libre. El equipo ajusta el formulario y lo explica en cada turno. Al cabo de unos meses, los informes de validación del CMBD-RSS y la facturación mensual son los indicadores de que el sistema se usa como estaba previsto.

Qué implica para los sistemas

Riesgo	Artefacto que lo controla	Base	Quién lo mantiene
Continuidad	Análisis de impacto, plan de continuidad, modo degradado, pruebas	ENS, art. 26 y op.cont 1	Responsable de seguridad, dirección asistencial, proveedor
Ciberseguridad	Conformidad con el ENS del proveedor y su cadena de suministro	ENS, art. 2.3 1	Responsable de seguridad
Datos personales	Contrato de encargo, declaración de servidores, plan de devolución	RGPD, art. 28 3; LCSP 2	Delegado de protección de datos y órgano de contratación
Conservación	Historia íntegra y reproducible, también al final del contrato	Ley 21/2000, art. 12 4	Dirección del centro
Personas	Red de usuarios clave, formación, canal de incidencias, indicadores de adopción	Pauta de proyecto, sin norma	Dirección del proyecto y mandos de cada servicio