Cuando un paciente pide que su historia clínica viaje a otro centro, lo que llega rara vez es lo que debería llegar. Esta guía explica qué dice la ley, qué sale realmente del software, qué recibe el centro destino y qué puedes hacer para que la portabilidad de tus pacientes sea real.

La historia clínica viaja a otro centro: qué llega

Para directores, gestores y responsables de sistemas de clínicas privadas que necesitan saber qué ocurre cuando un paciente pide que su historia clínica se transfiera, qué formatos se usan y qué debería mejorar.

pasillo clínico con un carro y carpeta en primer plano y otro carro idéntico al fondo Lo que viaja entre centros no es «el historial»: es un subconjunto filtrado por el derecho del paciente y la capacidad técnica de cada sistema.

1. El derecho del paciente a llevarse sus datos

1.1. Lo que dice el RGPD

El artículo 20 del RGPD establece el derecho de portabilidad: el paciente tiene derecho a recibir sus datos personales en un formato estructurado, de uso común y lectura mecánica, y a transmitirlos a otro responsable del tratamiento. Para datos de salud, eso significa que la clínica tiene que entregar la historia clínica del paciente en un formato que otra clínica pueda usar — no solo leer.

1.2. Lo que dice la legislación sanitaria española

La Ley 41/2002 de autonomía del paciente establece el derecho de acceso a la historia clínica y la obligación de los centros sanitarios de conservarla durante al menos cinco años desde el alta. La ley autonómica puede ampliar ese plazo. El paciente tiene derecho a obtener copia de su historia clínica, y la clínica tiene la obligación de entregarla. Lo que la ley no especifica con detalle es el formato de esa entrega — y ahí es donde la práctica se aleja de lo que debería ser.

1.3. La brecha entre el derecho y la práctica

En la práctica, la mayoría de clínicas privadas entregan la historia clínica en PDF — a veces impreso, a veces por correo electrónico. El paciente la recibe, la lleva al nuevo centro y allí un profesional la lee y transcribe los datos relevantes al nuevo sistema. El proceso funciona, pero es manual, lento y propenso a errores. Lo que el RGPD pide — formato estructurado y lectura mecánica — casi nunca se cumple en la práctica de la portabilidad de datos sanitarios entre centros privados.

2. Lo que sale del software cuando se pide la historia

2.1. La exportación típica: un PDF

La exportación más común de la historia clínica de un paciente es un PDF — a veces un solo documento largo, a veces un ZIP con varios PDFs organizados por tipo de dato o por fecha. El PDF incluye la información clínica en formato narrativo: notas de evolución, informes de consulta, resultados de laboratorio, diagnósticos y tratamientos. Es legible por una persona pero no procesable por un sistema informático: los datos están embebidos en texto, no en campos separados.

2.2. Lo que no suele incluir

La exportación estándar en PDF suele omitir las imágenes médicas en formato original (radiografías, ecografías, fotografías clínicas), los documentos escaneados (consentimientos firmados, informes de otros centros), el historial completo de prescripciones en formato estructurado, los datos de codificación clínica (códigos CIE-10, ATC) y los metadatos de auditoría (quién registró qué y cuándo). Cada uno de estos datos puede ser necesario para la continuidad asistencial y para reconstruir el contexto clínico del paciente en el nuevo centro.

2.3. Lo que depende del software

La calidad de la exportación depende directamente de lo que el software sea capaz de hacer. Un software que almacena los datos en campos estructurados y codificados puede exportar una historia clínica rica y procesable. Un software que almacena todo en notas de texto libre solo puede exportar un documento narrativo. El formato en el que salen los datos es un indicador directo de la calidad del software como herramienta de portabilidad.

conector de red desenchufado sobre la bandeja de un carro clínico junto a carpetas apiladas La portabilidad no es solo un derecho del paciente: es un requisito técnico que el software tiene que resolver antes de que el paciente lo pida.

3. Lo que llega al centro destino

3.1. Un documento que hay que releer

Lo que llega al centro destino es, en la mayoría de los casos, un documento que un profesional sanitario tiene que leer para extraer la información relevante. Si es un PDF de cien páginas con notas de evolución de cinco años, alguien tiene que buscar los diagnósticos activos, los tratamientos vigentes, las alergias y los antecedentes relevantes. Eso lleva tiempo, requiere criterio clínico y está sujeto a que el profesional del nuevo centro interprete correctamente lo que escribió el profesional del centro anterior.

3.2. La transcripción manual

Una vez leída la historia, los datos relevantes se transcriben al nuevo sistema informático. El diagnóstico que en el centro de origen era un código CIE-10 asociado a un campo estructurado llega como un texto en un PDF, se lee, se interpreta y se vuelve a codificar en el nuevo sistema. Ese proceso introduce oportunidades de error: un diagnóstico puede transcribirse con un código diferente, una dosis puede leerse mal, una alergia puede pasarse por alto en un documento largo. La transcripción manual es el eslabón débil de la portabilidad.

3.3. Lo que se pierde en la traducción

Además de los errores de transcripción, hay información que se pierde estructuralmente. Las relaciones entre datos — qué diagnóstico motivó qué tratamiento, qué episodio se cerró y cuándo, qué consentimiento se firmó para qué procedimiento — no sobreviven a la conversión a PDF y reconversión a texto. El contexto temporal — la cronología de los eventos clínicos — se aplana en un documento narrativo. Y los metadatos — quién registró cada dato, con qué fecha exacta, con qué grado de certeza — desaparecen por completo.

Antes de elegir software, conoce las preguntas que debes hacerte

En 30 minutos de análisis gratuito identificamos qué procesos de tu clínica se pueden digitalizar hoy.

4. Lo que se pierde por el camino

4.1. La codificación

Si el centro de origen codificaba los diagnósticos con CIE-10 y los medicamentos con ATC, esa codificación se pierde cuando la historia se exporta como PDF. El centro destino recibe el nombre del diagnóstico en texto libre y tiene que recodificarlo. Si el centro de origen usaba codificación rigurosa, el trabajo se pierde. Si el centro destino no usa la misma codificación, el dato queda sin código. La codificación es la condición para que el dato viaje sin perder significado, y perderla en la transferencia anula el trabajo de codificación del centro de origen.

4.2. Las imágenes

Las imágenes médicas rara vez viajan con la historia clínica cuando se transfiere entre centros privados. Si el centro de origen tiene un sistema PACS con imágenes en DICOM, esas imágenes no suelen incluirse en la exportación estándar — o se incluyen como JPEG de baja resolución dentro del PDF, sin los metadatos DICOM que las vinculan al estudio y al paciente. El centro destino puede pedir las imágenes por separado, pero el proceso suele ser manual y no siempre funciona entre sistemas de imagen de proveedores distintos.

4.3. El contexto clínico

El contexto clínico — por qué se tomó una decisión, qué alternativas se descartaron, qué dijo el paciente en la consulta — vive en las notas de evolución del profesional y no siempre se incluye en la exportación. El informe de alta o el resumen de historia clínica capturan los hechos principales, pero no el razonamiento clínico completo. Para la continuidad asistencial, ese contexto puede ser la diferencia entre entender un caso y empezar de cero.

5. Formatos de salida: de PDF a datos estructurados

5.1. PDF: el mínimo que cumple

El PDF cumple el mínimo legal: entrega la información al paciente en un formato que puede leer. Pero no cumple el espíritu del derecho de portabilidad — que la información sea procesable por otro sistema — ni prepara para lo que el EHDS va a exigir. Es el formato de salida más cómodo para el centro de origen — porque no requiere ninguna capacidad especial del software — y el menos útil para el centro destino — porque requiere lectura y transcripción manual completa.

5.2. Formatos estructurados: CSV, XML, SQL

Un formato estructurado — CSV para datos tabulares, XML para datos jerárquicos, volcado SQL para la estructura completa — permite que el centro destino importe los datos de forma automática o semiautomática. Los diagnósticos llegan como campos con código CIE-10, los medicamentos con código ATC, las citas con fecha y hora en campos separados. El sistema receptor puede mapear los campos y cargar los datos sin transcripción manual. La pérdida de información es menor y el riesgo de error de transcripción desaparece.

5.3. El horizonte del formato europeo de intercambio

El EHDS va a definir un formato europeo de intercambio que será obligatorio para las categorías prioritarias de datos sanitarios. Ese formato será estructurado, codificado e interoperable — diseñado para que los datos pasen de un sistema a otro sin pérdida y sin intervención manual. Es el destino hacia el que converge toda la regulación de portabilidad sanitaria, y llegar a él requiere que los datos del centro de origen estén estructurados y codificados antes de exportarlos.

6. La codificación como condición de viaje

6.1. Sin código, el dato no viaja

Un diagnóstico en texto libre — «sospecha de glaucoma primario de ángulo abierto» — solo lo entiende quien lo lee. Un sistema receptor no puede asociarlo automáticamente a una categoría diagnóstica, ni buscarlo, ni agregarlo con otros diagnósticos similares. El mismo diagnóstico con código CIE-10 (H40.1) es entendido por cualquier sistema que hable CIE-10, en cualquier idioma y en cualquier país. El código es el pasaporte del dato: sin él, el dato se queda en su sistema de origen o viaja con un intérprete humano.

6.2. Qué datos deberían viajar codificados

Los datos que deberían viajar codificados en una transferencia de historia clínica son: diagnósticos (CIE-10), medicamentos (código ATC), procedimientos (sistema de clasificación nacional), alergias (codificación estándar si existe), y resultados de laboratorio con sus códigos de prueba. Cada uno de estos datos tiene un sistema de codificación estándar que permite la interpretación automática por el sistema receptor. Los datos que no tienen codificación estándar — como las notas de evolución o los planes de tratamiento narrativos — viajan inevitablemente como texto libre.

6.3. El coste de no codificar

El coste de no codificar no se paga cuando se guarda el dato sino cuando se intenta moverlo. El profesional que escribe «glaucoma» en texto libre tarda lo mismo que el que selecciona H40.1 de un desplegable — o menos si el desplegable tiene buscador. Pero cuando ese dato tiene que viajar a otro centro, el texto libre requiere lectura, interpretación y recodificación manual; el código viaja tal cual. El coste de no codificar se multiplica por cada transferencia, por cada integración y por cada obligación regulatoria que exija datos interoperables.

archivador metálico con cajón abierto mostrando carpetas ordenadas y un sobre asomando El centro de destino recibe lo que el formato permite: si exportas en PDF, llega una foto fija; si exportas en estructurado, llega un dato que se integra.

7. Lo que el EHDS va a cambiar en la portabilidad

7.1. De voluntario a obligatorio

Hoy, la portabilidad de datos sanitarios entre centros privados es un derecho del paciente que se cumple con el formato que el centro de origen tenga disponible — habitualmente PDF. El EHDS va a convertir ese derecho en una obligación con formato definido: antes de 2029, las categorías prioritarias de datos sanitarios tendrán que ser accesibles en el formato europeo de intercambio. El centro de origen no podrá elegir el formato — tendrá que usar el que establezca la normativa.

7.2. De bilateral a sistémico

Hoy, la transferencia de datos entre centros privados es bilateral: el paciente pide la historia al centro A y la lleva al centro B. No hay infraestructura común que conecte los sistemas de los centros privados. El EHDS pretende crear esa infraestructura — a nivel nacional y europeo — para que los datos circulen de forma sistémica, no caso por caso. Para la clínica privada, eso significa que su software tendrá que conectarse a esa infraestructura, no solo generar un fichero que el paciente lleve en mano.

7.3. De PDF a datos estructurados codificados

El cambio más concreto que el EHDS trae a la portabilidad es el salto del PDF al dato estructurado y codificado. Un historial de paciente que hoy viaja como un PDF de cien páginas tendrá que viajar como un conjunto de datos estructurados con diagnósticos codificados, medicamentos codificados y relaciones preservadas. El centro destino podrá importarlo en su sistema sin transcripción manual. Ese salto es el que hay que preparar, y empieza por codificar bien los datos en el centro de origen.

8. Cómo mejorar lo que sale de tu clínica

8.1. Codificar los diagnósticos

El primer paso es asegurarte de que los diagnósticos de tus pacientes están codificados con CIE-10. Si tu software lo permite — tiene un buscador de códigos CIE-10 o un desplegable — pero los profesionales no lo usan, es un problema de formación, no de software. Si tu software no lo permite, es un problema de proveedor que hay que resolver. Un diagnóstico codificado viaja mejor que uno en texto libre, y codificar bien desde hoy evita la retrocodificación masiva que el EHDS va a hacer necesaria.

8.2. Pedir una exportación estructurada al proveedor

Si tu software solo exporta la historia clínica en PDF, pide al proveedor una exportación estructurada — al menos CSV con campos identificados, idealmente XML con esquema documentado. Si el proveedor no la tiene, pregunta cuándo la tendrá. Si no tiene plan para tenerla, es una señal que hay que ponderar en la evaluación del proveedor. Las preguntas de normativa para el proveedor cubren este punto.

8.3. Incluir las imágenes en la exportación

Si tu clínica genera imágenes médicas — radiografías, ecografías, fotografías clínicas — asegúrate de que la exportación de la historia clínica las incluye en formato original. Un informe de consulta que dice «se observa lesión en fondo de ojo» sin la imagen de fondo de ojo pierde la mitad de su valor clínico. Si tu software almacena las imágenes en DICOM, la exportación debería incluir los ficheros DICOM. Si las almacena en otro formato, al menos debería incluir las imágenes asociadas a cada estudio.

9. Qué pedir cuando recibes una historia de otro centro

9.1. Los datos mínimos imprescindibles

Cuando recibes una historia clínica de otro centro, los datos mínimos que necesitas para la continuidad asistencial son: diagnósticos activos, medicación actual, alergias conocidas, antecedentes relevantes y último informe de seguimiento de cada patología activa. Si esos datos no están en lo que recibes, hay que pedirlos explícitamente. Un PDF de cien páginas puede no incluirlos de forma accesible — pueden estar dispersos en notas de evolución de distintas fechas — y localizarlos requiere una lectura completa del documento.

9.2. Pedir formato estructurado cuando sea posible

Si el centro de origen puede exportar los datos en formato estructurado — CSV, XML o cualquier formato con campos identificados — pídelo además del PDF narrativo. El PDF te da el contexto clínico legible; el formato estructurado te da los datos importables. Los dos juntos son mucho más útiles que cualquiera de los dos por separado. No todos los centros pueden hacerlo, pero si no lo pides nunca lo sabrás.

9.3. Documentar lo que falta

Si la historia que recibes tiene carencias — faltan imágenes, faltan diagnósticos codificados, faltan informes de procedimientos —, documéntalo. Esa documentación cumple dos funciones: protege a tu clínica si algún dato faltante afecta a una decisión clínica, y genera evidencia de las carencias de portabilidad que el sistema actual tiene. Cuanto más documentadas estén esas carencias, más fácil será argumentar la necesidad de formatos estructurados cuando el EHDS lo haga obligatorio.

Riesgo normativo

¿Tu infraestructura resistiría una inspección de la AEPD?

El RGPD clasifica los expedientes clínicos como datos de categoría especial. Una brecha técnica o un consentimiento mal custodiado puede acarrear sanciones muy elevadas. Solicita un análisis técnico de viabilidad normativa.

10. Preguntas frecuentes sobre la portabilidad de la historia clínica

¿Estoy obligado a entregar la historia clínica si el paciente la pide?

Sí. La Ley 41/2002 de autonomía del paciente establece el derecho de acceso a la documentación clínica, y el RGPD establece el derecho de portabilidad de los datos personales. La clínica tiene la obligación de entregar al paciente copia de su historia clínica cuando la pide. El plazo razonable es de un mes según el RGPD, aunque la práctica sanitaria suele ser más rápida. Lo que sí puede hacer la clínica es limitar el acceso a las anotaciones subjetivas del profesional sanitario, que la Ley 41/2002 excluye expresamente del derecho de acceso del paciente.

¿En qué formato tengo que entregar la historia clínica?

El RGPD dice «formato estructurado, de uso común y lectura mecánica». En la práctica, la mayoría de centros entregan en PDF porque es lo que su software permite. El PDF cumple la parte de «uso común» pero no la de «lectura mecánica» en el sentido de procesamiento automático por otro sistema. Para cumplir plenamente, el formato debería ser estructurado — CSV, XML o equivalente — con los datos en campos identificados. El EHDS va a concretar esta exigencia para datos sanitarios con un formato europeo de intercambio obligatorio antes de 2029.

¿Puedo cobrar por entregar la historia clínica?

El RGPD establece que la primera copia es gratuita. Para copias adicionales, el responsable del tratamiento puede cobrar un canon razonable basado en los costes administrativos. En la práctica, cobrar por la primera copia de la historia clínica no es aceptable y puede generar reclamaciones ante la autoridad de protección de datos. El coste de preparar la exportación es un coste operativo de la clínica, no una tasa que se pueda trasladar al paciente. Si tu software puede exportar la historia con un clic, el coste es mínimo; si requiere trabajo manual, el coste es mayor pero sigue siendo tuyo.

¿Qué pasa si mi software no puede exportar la historia en formato estructurado?

Si tu software solo exporta en PDF, estás cumpliendo el mínimo de entregar la información al paciente, pero no el espíritu del derecho de portabilidad del RGPD. En la práctica, la mayoría de clínicas privadas están en esta situación y las autoridades de protección de datos no han sancionado por entregar en PDF — todavía. Pero con el EHDS, el formato estructurado pasará de ser deseable a ser obligatorio. Lo que puedes hacer hoy es documentar la limitación de tu software, comunicarla al proveedor y exigir una hoja de ruta para la exportación estructurada.

¿Las imágenes médicas tienen que incluirse en la portabilidad?

Sí, las imágenes médicas forman parte de la historia clínica del paciente y están cubiertas por el derecho de acceso y portabilidad. Si tu clínica genera imágenes diagnósticas, tienen que incluirse cuando el paciente pide su historia. Lo ideal es entregarlas en formato DICOM, que preserva la imagen y sus metadatos clínicos. Si no es posible, al menos en el formato original en el que se almacenan. Una imagen comprimida dentro de un PDF pierde resolución, pierde metadatos y puede no ser útil para fines clínicos en el centro destino.

¿Cuánto tiempo tarda una transferencia de historia clínica entre centros?

El RGPD establece un plazo máximo de un mes para responder a una solicitud de portabilidad, ampliable a tres meses en casos complejos. En la práctica, si el software permite la exportación con unos pocos clics, la historia puede estar lista en minutos. Si requiere trabajo manual — imprimir, escanear, compilar documentos de distintas fuentes —, puede llevar días. El plazo real depende de la capacidad del software y del proceso interno de la clínica. Un software con exportación automática reduce ese plazo a lo que tarda el profesional en autorizar la entrega.

¿Puede el paciente pedir que la historia se envíe directamente al nuevo centro?

Sí, el RGPD da al paciente el derecho a que los datos se transmitan directamente de un responsable del tratamiento a otro, cuando sea técnicamente posible. En la práctica, la transmisión directa entre centros privados es poco habitual porque no hay una infraestructura común que conecte los sistemas. Lo habitual es que el paciente reciba la copia y la lleve al nuevo centro. El EHDS pretende crear esa infraestructura para que la transmisión directa sea técnicamente posible a nivel europeo, pero eso no llegará antes de 2029 como mínimo.

¿El EHDS va a obligar a entregar la historia en un formato concreto?

Sí. El EHDS establece que las categorías prioritarias de datos sanitarios — historiales de pacientes, recetas, informes de laboratorio, informes de alta, imágenes médicas — deben ser accesibles en un formato europeo de intercambio antes de 2029. Ese formato será estructurado, codificado e interoperable, definido por actos de ejecución de la Comisión Europea. El centro de origen no podrá elegir el formato de entrega para esas categorías: tendrá que usar el que la normativa establezca. Es un cambio significativo respecto a la situación actual, donde cada centro entrega en el formato que su software permite.

Más sobre lo que hay que preguntar al proveedor

Información adicional

Última actualización: septiembre de 2026.