Migración de historial clínico: lista de comprobación

En una migración de historial clínico electrónico trasladamos información asistencial, administrativa y, con frecuencia, financiera; pero también trasladamos responsabilidades sobre su integridad, su disponibilidad y la capacidad de demostrar quién hizo cada modificación.

El reto asistencial aparece cuando el nuevo sistema funciona, pero el profesional no encuentra una alergia, una prueba relevante, un informe antiguo o la relación correcta entre un episodio y su paciente. En la práctica diaria, un dato que no se localiza a tiempo deja de ser simplemente un problema informático: puede retrasar una decisión clínica, obligar a repetir una prueba o romper la continuidad de la atención.

Por eso, los requisitos de una migración de historial clínico electrónico deben abordarse como un proyecto clínico, tecnológico y organizativo al mismo tiempo. La tecnología facilita el traslado, pero somos nosotros, los clínicos y los responsables de la gestión sanitaria, quienes debemos decidir qué información se conserva, cómo se interpreta y qué controles permiten confiar en ella cuando el sistema antiguo ya no está operativo.

1. Clasificar los datos antes de moverlos

El primer error suele producirse antes de la extracción: comenzar a exportar información sin haber definido qué se va a migrar, con qué significado y con qué nivel de prioridad. Un historial clínico reúne datos de naturaleza muy distinta, y cada grupo puede tener reglas de conservación, validación y acceso diferentes.

En términos prácticos, conviene trabajar con cuatro grandes categorías:

• Datos clínicos: diagnósticos, antecedentes, alergias, medicación, resultados de laboratorio, informes de imagen, notas de evolución, episodios, procedimientos y documentos adjuntos.
• Datos administrativos: identificación del paciente, datos de contacto, aseguradora, centro de referencia, profesionales responsables, citas y episodios de admisión.
• Datos generados por el paciente: cuestionarios, mediciones domiciliarias, diarios de síntomas, fotografías clínicas aportadas por el paciente o información procedente de dispositivos conectados.
• Datos financieros: facturación, autorizaciones, copagos, liquidaciones, presupuestos y vínculos con compañías aseguradoras.

Esta clasificación no es un ejercicio documental. Determina la forma de transformar y comprobar la información. Un diagnóstico codificado no se valida igual que un PDF firmado; una fecha de nacimiento no se trata como una anotación clínica; y una factura no debería acabar mezclada con la documentación asistencial por el simple hecho de que ambos datos pertenecen a la misma persona.

Crear un inventario con responsable y destino

Antes de seleccionar herramientas, el equipo debe elaborar un inventario de las fuentes. No basta con identificar el programa principal. En un centro sanitario suelen coexistir el historial clínico electrónico, el sistema de citas, el laboratorio, radiología, farmacia, facturación, archivos compartidos y documentos almacenados fuera de la aplicación principal.

Para cada fuente, el inventario debería recoger:

• Qué tipo de información contiene y desde qué fecha.
• Qué pacientes aparecen y cómo se identifican.
• Qué campos están estructurados y cuáles permanecen en texto libre o documento escaneado.
• Qué sistema genera el dato y qué unidad o profesional lo utiliza.
• Qué aplicación de destino lo recibirá.
• Qué información debe conservarse por razones asistenciales, legales, administrativas o históricas.
• Quién valida el resultado desde el punto de vista clínico y quién lo hace desde el punto de vista técnico.

La propiedad del dato también necesita una definición clara. El equipo de tecnología puede saber cómo extraer una tabla, pero no necesariamente puede determinar si una etiqueta de medicación equivale a un tratamiento activo, a un tratamiento suspendido o a un antecedente. Esa interpretación pertenece al trabajo conjunto entre profesionales sanitarios, responsables funcionales y especialistas en datos.

Migrar un historial no es transportar archivos: es preservar el significado clínico de cada dato cuando cambia el sistema que lo contiene.

Separar datos estructurados y documentos

Los datos estructurados —por ejemplo, fecha de nacimiento, sexo, alergias codificadas, resultados numéricos o fechas de consulta— pueden validarse mediante reglas automáticas. Los documentos en PDF, las imágenes y las notas de texto libre requieren una estrategia distinta.

Aquí conviene distinguir entre:

1. Información que debe convertirse en un campo estructurado.

Una alergia crítica, un tratamiento activo o un diagnóstico relevante no deberían quedar ocultos en un documento si el sistema de destino permite registrarlos de forma consultable.

2. Información que debe conservarse como documento original.

Un informe firmado, una autorización o una prueba complementaria pueden necesitar mantener su formato, metadatos y relación con el episodio correspondiente.

3. Información que se puede indexar sin alterar el original.

En algunos casos, la extracción de texto permite facilitar la búsqueda, pero el documento fuente debe permanecer disponible para comprobar su contenido.

La conversión automática de documentos escaneados puede ayudar, pero no convierte por sí sola un archivo en un registro clínico fiable. Cuando el texto procede de una imagen, pueden aparecer errores en nombres de medicamentos, unidades, decimales o fechas. El dato extraído debe tratarse como una ayuda para la revisión, no como una sustitución de la validación clínica.

2. Construir un mapa de correspondencias

Una migración de datos médicos necesita un mapa que explique cómo se relaciona cada elemento del sistema antiguo con el nuevo. En tecnología se suele hablar de correspondencia entre campos, pero en sanidad el problema es más profundo: dos campos con nombres parecidos pueden tener significados diferentes, y dos campos con nombres distintos pueden representar la misma información.

Por ejemplo, un sistema puede registrar la medicación con un texto libre, mientras que el nuevo software exige principio activo, dosis, pauta, vía, fecha de inicio y estado del tratamiento. Si trasladamos únicamente el texto, la información seguirá existiendo, pero se perderán capacidades de búsqueda, alertas y conciliación terapéutica.

El mapa de correspondencias debería contemplar, como mínimo:

• Nombre del campo de origen y del campo de destino.
• Tipo de dato y formato.
• Valores permitidos y equivalencias.
• Transformaciones necesarias.
• Información que no puede convertirse automáticamente.
• Regla para los valores vacíos, desconocidos o contradictorios.
• Responsable de aprobar la transformación.
• Método de comprobación después de la carga.

No confundir ausencia con dato desconocido

Una casilla vacía puede significar varias cosas: que el profesional no preguntó, que el paciente no lo sabía, que el dato no se registró en el sistema antiguo o que el campo no era obligatorio. Si el nuevo sistema transforma todos esos casos en no, nunca, negativo o sin alergias conocidas, la migración estará fabricando información clínica.

En la práctica diaria, los valores desconocidos deben conservar su condición de desconocidos. Es preferible que el nuevo sistema muestre que un dato no está disponible a que presente como confirmado algo que nunca se verificó.

Este principio afecta especialmente a:

• Alergias e intolerancias.
• Antecedentes familiares.
• Estado de vacunación.
• Medicación activa.
• Embarazo o posibilidad de embarazo.
• Diagnósticos históricos.
• Resultados de pruebas que no incluyen una interpretación concluyente.

Revisar duplicados y pacientes con varias identidades

La identificación del paciente es uno de los puntos más delicados al migrar historias clínicas a otro software. Los duplicados pueden aparecer por cambios de apellidos, errores de transcripción, documentos provisionales, pacientes extranjeros con diferentes formatos de identificación o altas realizadas en centros distintos.

El sistema de destino debería recibir una identidad maestra, pero nunca conviene fusionar registros únicamente porque coincidan el nombre y la fecha de nacimiento. La coincidencia debe apoyarse, según el caso, en varios identificadores y en una revisión de los casos ambiguos.

Una fusión incorrecta puede unir la medicación de una persona con los informes de otra. La separación de dos historiales que en realidad pertenecen al mismo paciente también rompe la continuidad asistencial. Por eso, los registros dudosos deben entrar en una cola de revisión, con trazabilidad de la decisión y sin eliminar de forma irreversible la información de origen.

3. Aplicar el marco normativo desde el diseño

En España, el acceso y la integridad de la historia clínica se relacionan con la Ley 41/2002, de autonomía del paciente, y con la Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales, junto con el Reglamento General de Protección de Datos.

La migración no crea una excepción a estas obligaciones. Aunque el objetivo sea cambiar de proveedor o modernizar los sistemas de información hospitalaria, los datos siguen siendo sanitarios y, por tanto, especialmente sensibles.

El proyecto debe dejar documentadas varias cuestiones:

• Qué base jurídica permite tratar y trasladar los datos.
• Qué entidades intervienen como responsables y encargados del tratamiento.
• Qué proveedores tendrán acceso durante la extracción, transformación y carga.
• Dónde se alojan temporalmente los datos.
• Cuánto tiempo se conservarán las copias intermedias.
• Qué personas podrán consultar los historiales durante cada fase.
• Cómo se atenderán los derechos de acceso, rectificación y demás derechos aplicables.
• Qué procedimiento se seguirá para destruir o devolver la información cuando termine la relación con un proveedor.

La protección de datos no debería aparecer al final, cuando ya se ha elegido una herramienta y se han copiado archivos a un entorno provisional. Debe estar presente en la arquitectura del proyecto: en los permisos, en la ubicación de las copias, en el diseño de los registros de actividad y en la forma de eliminar los datos temporales.

El riesgo económico acompaña al riesgo asistencial

El incumplimiento del RGPD puede dar lugar a sanciones de hasta 20 millones de euros o el 4 % de la facturación anual global de la entidad, según cuál sea la cantidad aplicable. En el sector sanitario español se han registrado 237 sanciones con un importe acumulado cercano a 22,8 millones de euros.

Estas cifras no sustituyen al análisis del caso concreto, pero ayudan a situar el problema: proteger una migración no es una formalidad administrativa ni una partida que podamos relegar a la última semana del proyecto. Un acceso indebido, una copia sin control o una eliminación prematura pueden afectar a la asistencia y a la responsabilidad de la organización.

También conviene recordar que la documentación debe ser coherente con lo que realmente se ha hecho. Si el plan afirma que todas las cargas se validan y, en la práctica, solo se revisan algunos ficheros sin criterio definido, la organización tendrá dificultades para demostrar control sobre el proceso.

4. Priorizar la transición sin interrumpir la asistencia

No todos los historiales tienen la misma urgencia operativa. Un centro que atiende a pacientes crónicos, una clínica con actividad quirúrgica y un hospital con urgencias pueden necesitar estrategias de transición diferentes, aunque compartan el mismo software de destino.

Una estrategia habitual consiste en comenzar por los pacientes activos o nuevos e incorporar progresivamente el archivo histórico. Esto permite concentrar la validación inicial en los historiales que se consultan con mayor frecuencia, sin asumir que todo el archivo debe transformarse de una sola vez.

La priorización puede organizarse con varios criterios:

• Pacientes con citas próximas o tratamientos en curso.
• Personas con enfermedades crónicas y seguimiento continuado.
• Pacientes con alergias, alertas o medicación de alto riesgo.
• Episodios abiertos o procesos asistenciales todavía no cerrados.
• Historiales vinculados a procedimientos programados.
• Registros que el equipo necesita consultar durante el periodo de convivencia entre sistemas.
• Documentación histórica cuya conservación sea necesaria, aunque no requiera conversión completa a campos estructurados.

Definir una ventana de convivencia

Durante una transición controlada, el sistema antiguo y el nuevo pueden coexistir durante un periodo definido. Esta opción facilita la continuidad, pero introduce un riesgo conocido: que se actualice la misma información en dos lugares y después nadie sepa cuál es la versión válida.

Para evitarlo, hay que establecer reglas operativas sencillas:

1. Determinar desde qué fecha el nuevo sistema será el registro principal.

2. Definir qué información seguirá introduciéndose en la aplicación antigua.

3. Designar quién puede modificar los datos durante la convivencia.

4. Establecer cómo se incorporarán al nuevo entorno los cambios realizados en el sistema anterior.

5. Fijar una fecha de cierre o de solo lectura para el sistema antiguo.

6. Comunicar el procedimiento a admisión, enfermería, facultativos, farmacia, laboratorio y administración.

La convivencia no debe convertirse en una situación indefinida. Cuanto más tiempo permanezcan abiertos ambos sistemas, más posibilidades habrá de generar divergencias, duplicados y errores de identificación.

Empezar con un grupo piloto

Una carga piloto no sirve únicamente para comprobar si el software acepta los ficheros. Debe permitir observar si los profesionales pueden trabajar con la información resultante.

El grupo piloto debería incluir casos representativos:

• Un historial sencillo y completo.
• Un paciente con varios episodios.
• Un paciente crónico con medicación activa.
• Un caso con documentos adjuntos e informes de imagen.
• Un registro con cambios de identidad o datos administrativos incompletos.
• Un historial con información antigua y formatos heterogéneos.
• Un caso en el que sea necesario diferenciar datos confirmados de datos desconocidos.

Durante la revisión, no debemos limitarnos a preguntar si el registro se ha cargado. Hay que comprobar si el profesional encuentra el dato correcto en el lugar donde espera encontrarlo, si la fecha y el autor se conservan, si los documentos siguen vinculados al paciente y si una alerta clínica mantiene el nivel de visibilidad necesario.

Una migración está terminada cuando el equipo asistencial puede interpretar el historial sin tener que reconstruirlo a partir de pistas dispersas.

5. Validar la integridad después de la carga

La integridad de los datos en salud tiene una dimensión técnica y otra clínica. Desde el punto de vista técnico, queremos saber si los registros se han transferido sin alteraciones, pérdidas o duplicaciones. Desde el punto de vista asistencial, necesitamos confirmar que los datos siguen siendo comprensibles, completos y utilizables.

La validación debería realizarse en varias capas.

Comprobaciones automáticas

Las reglas automáticas pueden identificar:

• Pacientes sin identificador único.
• Fechas imposibles o fuera del intervalo esperado.
• Historias sin relación con un paciente válido.
• Documentos sin episodio asociado.
• Campos obligatorios vacíos.
• Valores fuera de los catálogos admitidos.
• Duplicados potenciales.
• Medicaciones sin dosis o vía cuando esos datos sean necesarios.
• Diferencias entre el número de registros extraídos y el número de registros cargados.

Para los documentos, se pueden comparar recuentos, tamaños, identificadores y huellas digitales de los archivos, siempre dentro de un procedimiento documentado. La finalidad es detectar si el fichero recibido es el mismo que se extrajo, no sustituir la revisión del contenido clínico.

Comprobaciones por muestreo y revisión clínica

La automatización no identifica todos los problemas de significado. Por eso, el equipo clínico debe revisar una muestra definida con antelación y registrar los resultados.

La revisión puede seguir una secuencia como esta:

1. Abrir el historial en el sistema de destino con el perfil profesional habitual.

2. Confirmar la identidad del paciente y la ausencia de duplicados evidentes.

3. Localizar antecedentes, alergias y alertas.

4. Revisar diagnósticos, episodios y fechas relevantes.

5. Comprobar medicación activa y tratamientos suspendidos.

6. Abrir informes, resultados y documentos adjuntos.

7. Verificar que el autor, la fecha y el contexto asistencial no se han perdido.

8. Comparar la información con el registro de origen.

9. Registrar cada incidencia y clasificarla por gravedad.

10. Repetir la carga o corregir el proceso cuando se detecte un patrón, no solo un caso aislado.

Las incidencias críticas deben tener una regla de bloqueo. Si una migración altera de forma sistemática las alergias o mezcla identidades, no se debe continuar con la siguiente fase porque el calendario del proyecto diga que ha llegado el momento.

6. Proteger la migración contra accesos y pérdidas

La seguridad en la migración de datos clínicos comienza por reducir la cantidad de información expuesta y termina por eliminar de forma controlada las copias que ya no son necesarias. Durante el proyecto aparecen exportaciones, ficheros temporales, copias de respaldo, entornos de pruebas y cuentas de proveedores, y cada elemento adicional amplía la superficie de riesgo.

El plan de seguridad debería incluir:

• Cifrado durante la transferencia y en los dispositivos o servidores de almacenamiento.
• Autenticación reforzada para los perfiles con acceso a la migración.
• Permisos mínimos, asignados según la función real de cada persona.
• Separación entre entornos de desarrollo, pruebas y producción.
• Registro de accesos, exportaciones, transformaciones, cargas y borrados.
• Control de las cuentas de proveedores y retirada cuando termine su intervención.
• Copias de seguridad verificadas antes de cualquier carga irreversible.
• Procedimiento para recuperar el servicio si el nuevo sistema falla.
• Eliminación segura de archivos temporales y soportes fuera de uso.
• Revisión de los accesos privilegiados por parte del responsable de seguridad o protección de datos.

No debemos confundir una copia de seguridad con una estrategia de recuperación. Una copia puede existir y, aun así, estar incompleta, corrupta o ser imposible de restaurar en el tiempo necesario. Las pruebas de restauración deben formar parte del proyecto, especialmente antes de cerrar el sistema antiguo.

Trazabilidad: saber qué ocurrió y quién lo hizo

La trazabilidad permite reconstruir el recorrido de los datos: qué se extrajo, cuándo, desde qué fuente, qué transformación se aplicó, quién aprobó la carga y qué incidencias se corrigieron.

Este registro no debe convertirse en una colección de capturas de pantalla sin contexto. Necesitamos una relación clara entre:

• La versión del fichero de origen.
• La transformación aplicada.
• La versión del mapa de correspondencias.
• El lote de carga.
• Los resultados de las validaciones.
• Las excepciones aceptadas.
• La persona que revisó y aprobó cada fase.

Si el proveedor utiliza una herramienta automatizada, debemos conocer qué registros genera y durante cuánto tiempo estarán disponibles. La caja negra resulta especialmente problemática cuando se transforman textos clínicos o se utilizan procesos automáticos para clasificar documentos.

7. Preparar la respuesta ante una brecha

Una migración puede sufrir una filtración por varias vías: credenciales compartidas, un fichero enviado al destinatario equivocado, un servidor temporal expuesto, un dispositivo perdido o un permiso que concede más acceso del necesario.

El equipo debe saber qué hacer antes de que ocurra un incidente. El procedimiento debería identificar a las personas que reciben el aviso, quién contiene técnicamente la brecha, quién evalúa el impacto, quién coordina la comunicación y quién mantiene la relación con el delegado de protección de datos y las autoridades.

El RGPD establece un plazo máximo de 72 horas para notificar determinadas brechas de seguridad que afecten a datos personales o sensibles. Este plazo no empieza cuando la organización termina de investigar todos los detalles, sino cuando tiene conocimiento de una brecha que puede requerir notificación. La evaluación debe ser rápida, documentada y proporcional al riesgo.

En un incidente de migración conviene conservar:

• Hora en la que se detectó el problema.
• Sistemas, ficheros y pacientes potencialmente afectados.
• Personas o entidades que pudieron acceder.
• Medidas aplicadas para contenerlo.
• Valoración del riesgo para los pacientes.
• Decisiones tomadas sobre notificación y comunicación.
• Acciones para evitar que vuelva a ocurrir.

La notificación, cuando proceda, no sustituye a la corrección técnica. Tampoco conviene esperar a tener una explicación perfecta para iniciar la contención: cortar un acceso, aislar un entorno o revocar una credencial puede ser más urgente que completar el informe.

8. Evitar los errores que más comprometen el proyecto

Hay fallos que se repiten porque parecen atajos razonables. En realidad, desplazan el problema a la fase en la que resulta más caro y peligroso resolverlo.

Migrar todo sin priorización

Trasladar el archivo completo puede parecer la opción más ordenada, pero no siempre es la más segura. Si se mezclan pacientes activos, historiales cerrados, duplicados y documentos de valor desigual, la validación se vuelve más difícil y el equipo pierde visibilidad sobre lo que necesita para continuar atendiendo.

La prioridad debe responder al uso clínico y a las obligaciones de conservación, no solo al volumen de registros que el sistema puede procesar.

Cargar los datos y validar solo el recuento

Que el sistema indique que ha recibido el mismo número de filas que el archivo de origen no demuestra que la información sea correcta. Un dato puede haberse desplazado a otro campo, haber perdido su unidad, haberse asociado a otro episodio o haberse convertido en un valor genérico.

La validación debe comprobar el significado, no únicamente la cantidad.

Tratar los documentos como si fueran datos clínicos estructurados

Guardar todos los informes como archivos puede preservar el contenido, pero también puede hacer que las alergias, medicaciones o resultados relevantes queden ocultos para las búsquedas y las alertas. La solución no es estructurarlo todo a cualquier precio, sino decidir qué información necesita una representación consultable y qué debe mantenerse como documento original.

Mantener abiertas demasiadas puertas

Durante una migración, es habitual conceder accesos temporales que después nadie revoca. También se comparten cuentas para acelerar una carga o se copian datos en herramientas que no estaban previstas en el análisis inicial.

Cada acceso debe tener una finalidad, una duración y una persona responsable. Si no podemos explicar quién accedió a un lote de datos y por qué, el control del proyecto es insuficiente.

Convertir la formación en una sesión de demostración

Los profesionales no necesitan únicamente saber dónde está cada botón. Necesitan aprender cómo actuar cuando falta un documento, cómo distinguir un dato histórico de un tratamiento activo, cómo registrar una corrección y a quién comunicar una incidencia.

La formación debe utilizar casos cercanos a la actividad del centro y permitir que los equipos practiquen antes del cambio definitivo. La adopción mejora cuando el nuevo flujo acompaña el trabajo asistencial en lugar de obligar a los usuarios a descifrarlo por su cuenta.

La lista de comprobación antes de cerrar el sistema antiguo

Antes de pasar el sistema anterior a modo de solo lectura o retirarlo, conviene reunir la aprobación de las áreas que participan en el circuito. Esta revisión final puede organizarse alrededor de las siguientes preguntas:

• ¿Se han identificado todas las fuentes de información, incluidas las aplicaciones periféricas y los archivos documentales?
• ¿Se han clasificado los datos clínicos, administrativos, generados por pacientes y financieros?
• ¿Existe un mapa aprobado de correspondencias entre origen y destino?
• ¿Se han definido los valores desconocidos, vacíos, incompatibles y duplicados?
• ¿Se han priorizado los pacientes activos y los episodios abiertos?
• ¿Se ha probado la carga con casos representativos y no solo con registros sencillos?
• ¿Los profesionales pueden localizar alergias, medicación, diagnósticos, resultados e informes?
• ¿Se conservan autoría, fechas, firmas, contexto y relación con el episodio?
• ¿Se han revisado los permisos y los accesos de proveedores?
• ¿La organización puede demostrar qué transformaciones se han aplicado?
• ¿Se han probado las copias de seguridad y la restauración?
• ¿Existe un procedimiento de continuidad si el nuevo sistema deja de estar disponible?
• ¿Está definido el tratamiento de las copias temporales y del archivo histórico?
• ¿Se ha comunicado el nuevo flujo a todos los equipos implicados?
• ¿Hay un canal para registrar y resolver incidencias después de la puesta en marcha?

Esta lista no sustituye a un plan de migración de datos médicos detallado, pero evita que la decisión final dependa de una única señal técnica, como que la carga haya terminado sin errores visibles.

Una migración segura es un proceso clínico compartido

La calidad de una migración no se mide por lo rápido que desaparece el sistema antiguo, sino por la confianza que el nuevo entorno permite recuperar. Un historial clínico útil debe ser accesible, íntegro, comprensible y trazable; además, debe conservar las diferencias entre un dato confirmado, una información histórica y una cuestión todavía pendiente de verificar.

El software puede automatizar extracciones, detectar duplicados y facilitar controles, pero no puede decidir por nosotros qué dato cambia una conducta clínica ni qué ambigüedad debe revisar un profesional. Ahí permanece el papel del facultativo y del resto del equipo asistencial: interpretar, validar y acompañar la transformación tecnológica para que no se convierta en una interrupción de la atención.

En el reto asistencial de cambiar de plataforma, la mejor estrategia suele ser menos espectacular y más disciplinada: clasificar, mapear, priorizar, probar, registrar y revisar. Cuando esas etapas se integran desde el principio con la protección de datos y la continuidad operativa, migrar el historial clínico electrónico deja de ser una mudanza de archivos y se convierte en una transición controlada de nuestra forma de cuidar.