Qué hacer cuando el proveedor de software antiguo bloquea la exportación de tus datos

1. El bloqueo no es un malentendido: es una estrategia de retención

1.1. Trabas técnicas y retrasos como forma de evitar la marcha de la clínica

La secuencia se repite con pocas variaciones: se pide la exportación completa de los historiales, y la respuesta es que «el sistema no está preparado para eso», que hace falta «una petición técnica especial», o que el responsable capaz de generarla «no está disponible esta semana». Ninguna de esas excusas resiste una segunda pregunta, y ese es precisamente el objetivo: alargar el proceso lo suficiente para que la clínica desista o acabe renovando el contrato por cansancio. Un proveedor que exporta datos hacia dentro con normalidad no tiene ningún problema técnico real para exportarlos hacia fuera; el problema aparece justo cuando el cliente anuncia que se va. Este miedo a quedarse atrapado es, de hecho, uno de los costes ocultos de seguir con un software obsoleto por no afrontar el cambio a tiempo.

1.2. Tarifas de rescate imprevistas por entregar lo que ya es tuyo

La otra variante es económica: una factura inesperada por «extracción de datos», «migración asistida» o «cierre de cuenta», con una cifra que no aparecía en ningún contrato firmado y que se presenta como condición para entregar la copia. Pagar bajo esa presión no es aceptar un servicio nuevo: es pagar un rescate por algo que ya pertenece al centro y al paciente. Antes de pagar nada, conviene revisar qué dice realmente el contrato sobre la propiedad de los datos y sobre las condiciones de salida, porque en la mayoría de los casos esa tarifa no tiene respaldo contractual y solo se sostiene mientras nadie la cuestiona por escrito.

2. El marco legal: por qué los datos no son del proveedor

2.1. RGPD: los datos de salud pertenecen al paciente y al centro, no al software

El Reglamento (UE) 2016/679 reconoce el derecho a la portabilidad de los datos personales: cuando el tratamiento se basa en un contrato, el interesado —o, en el caso de historiales clínicos, el centro que actúa como responsable del tratamiento— tiene derecho a recibir esos datos en un formato estructurado, de uso común y lectura mecánica, y a transmitirlos a otro responsable sin trabas del primero. El software es solo el medio técnico donde los datos han vivido durante un tiempo; en ningún caso se convierte en su propietario, por muy antiguo o muy integrado que esté en el día a día del centro.

2.2. Ley 41/2002: el derecho de acceso a la historia clínica no depende del proveedor

La Ley 41/2002, básica reguladora de la autonomía del paciente, reconoce el derecho de acceso a la historia clínica como parte de la documentación clínica que el centro está obligado a conservar y a poner a disposición. Ese derecho existe con independencia de qué programa informático se use para gestionarla, y un cambio de proveedor de software no lo suspende ni lo condiciona. El centro sigue siendo responsable de garantizar el acceso a esa información aunque el sistema donde estaba alojada haya dejado de usarse.

2.3. Qué está obligado a hacer el proveedor saliente

Entre ambas normas, el proveedor que sale tiene una obligación clara: facilitar una copia completa y en un formato utilizable de los datos que ha alojado, dentro de los plazos que marca la normativa de protección de datos para atender este tipo de solicitudes. No está obligado a construir una herramienta de migración a medida para el sistema nuevo, ni a dar soporte técnico ilimitado durante el proceso, pero sí a entregar los datos en un estado que permita a un tercero trabajarlos, sin condicionarlo a pagos no pactados ni a plazos que no figuran en ningún contrato.

3. Qué formato pedir, y por qué no vale cualquier entrega

3.1. Formato estructurado y de lectura mecánica, no un PDF escaneado

Una entrega que cumple la letra pero no el espíritu de la norma es tan habitual como el bloqueo directo: cientos de historiales convertidos a PDF, uno por paciente, sin ninguna estructura de datos detrás. Técnicamente es «una copia», pero no es un formato de lectura mecánica ni permite migrar la información de forma automatizada a otro sistema; obliga a volver a introducir manualmente todo lo que ya estaba digitalizado. La solicitud debe pedir explícitamente un formato estructurado —una base de datos exportable, ficheros CSV o XML con los campos identificados, no capturas de pantalla ni documentos escaneados. Cuando el programa de origen sí tiene una salida documentada, el punto de partida es esa salida y la lista de lo que hay que pedir aparte, como en cómo exportar los datos de Eholo.

3.2. Qué revisar antes de dar por buena la entrega

Antes de considerar cerrado el proceso conviene comprobar que la entrega incluye realmente todo lo pactado: el volumen total de pacientes coincide con el que maneja el centro, los campos clave —diagnósticos, tratamientos, pruebas, imagen asociada— están presentes y no solo los datos administrativos básicos, y la cronología de cada historial se conserva con sus fechas originales. Una entrega parcial, presentada como completa, es una forma más de retraso: hay que detectarla antes de dar por cerrada la solicitud, no después de haber avanzado con el cambio de sistema.

4. El requerimiento formal: cómo se redacta

Un requerimiento formal por escrito, con acuse de recibo, cambia por completo el plazo de respuesta.

4.1. Qué tiene que incluir para tener valor real

Un requerimiento formal por escrito, dirigido al proveedor, con acuse de recibo, cambia por completo la naturaleza de la conversación: deja de ser una petición informal que se puede aplazar sin coste, y pasa a ser una comunicación con plazo legal de respuesta. Debe identificar con claridad al centro solicitante, la base legal invocada —el derecho de portabilidad del RGPD y, si aplica, el derecho de acceso de la Ley 41/2002—, el formato exigido para la entrega, y un plazo razonable de respuesta. Cuanto más concreto sea el requerimiento, más difícil resulta para el proveedor responder con otra excusa genérica.

4.2. Plazos que marca la normativa para responder

El RGPD fija, con carácter general, un plazo de un mes para atender una solicitud de este tipo, ampliable en casos justificados de complejidad, siempre que el responsable lo comunique motivadamente dentro del plazo inicial. Silencio o excusas genéricas transcurrido ese plazo no son una prórroga válida: son un incumplimiento. Anotar la fecha exacta de envío del requerimiento es lo que permite, después, documentar con precisión cuánto tiempo ha pasado sin respuesta si hace falta escalar la reclamación.

5. Si el proveedor sigue sin responder: escalar la reclamación

5.1. La reclamación ante la Agencia Española de Protección de Datos

Agotado el plazo sin una respuesta satisfactoria, el centro puede presentar una reclamación ante la AEPD, que tiene potestad para investigar el incumplimiento y sancionarlo. La AEPD no resuelve conflictos comerciales, pero sí tiene competencia clara sobre el incumplimiento de un derecho reconocido por el RGPD, y la sola constancia de que existe un requerimiento formal previo, con fecha y sin respuesta, suele bastar para que muchos proveedores reaccionen antes de que la reclamación llegue a tramitarse del todo.

5.2. Cuándo conviene el apoyo de un abogado especializado

Cuando la tarifa de rescate exigida es elevada, cuando el contrato original tiene cláusulas ambiguas sobre la propiedad de los datos, o cuando el proveedor amenaza con acciones legales propias para justificar el bloqueo, conviene contar con asesoramiento legal especializado en protección de datos antes de seguir adelante. Este artículo explica el marco general y el procedimiento habitual, pero no sustituye una valoración jurídica del contrato concreto que vincula al centro con su proveedor.

6. Validar los datos recuperados antes de migrarlos

6.1. Comprobar que no faltan historiales ni episodios completos

Recuperar los datos no es el final del proceso, es el punto de partida de la validación: hay que comprobar que el número de historiales coincide con el censo real de pacientes del centro, y que dentro de cada uno están presentes los episodios, pruebas y documentos que se esperaría encontrar. Es habitual que una exportación forzada, hecha con prisa por el proveedor tras un requerimiento, tenga huecos que no aparecían en exportaciones rutinarias anteriores, precisamente porque no fue un proceso pensado ni probado de antemano. Esta fase de control es la misma que conviene aplicar de forma rutinaria a cualquier acceso a la historia clínica, como se explica en cómo auditar el acceso de empleados a la historia clínica.

6.2. Detectar campos mal exportados o truncados

Además del volumen, conviene revisar una muestra representativa de historiales campo a campo: fechas que han perdido su formato original, textos clínicos truncados por límites de longitud del formato de exportación, o campos personalizados del sistema antiguo que no tienen una etiqueta clara en el fichero entregado. El método de la muestra representativa, y qué patrones de error buscar primero, es el mismo que conviene aplicar en cualquier migración de volumen alto, descrito con más detalle en el protocolo para migrar un volumen grande de pacientes. Detectar estos problemas en esta fase, antes de cargar nada en el sistema nuevo, evita tener que volver a reclamar al proveedor una segunda entrega cuando ya ha pasado tiempo y su disposición a colaborar, si alguna vez la hubo, suele haber bajado más todavía.

7. La migración, ya con los datos en la mano

7.1. Por qué esta fase ya no depende del proveedor antiguo

Una vez los datos están fuera del sistema original y validados, el proveedor antiguo deja de ser un obstáculo: el resto del proceso —mapear campos, limpiar duplicidades, cargar por lotes, validar contra el sistema nuevo— es un proyecto de migración estándar, con el mismo método que se aplicaría si el proveedor anterior hubiera colaborado desde el primer día. El bloqueo inicial retrasa el calendario, pero no cambia la naturaleza técnica del trabajo que queda por hacer.

7.2. Mapear campos y conservar la cronología clínica

El reto técnico habitual en estos casos es que los datos llegan en un formato distinto al esperado por el nuevo sistema, así que hace falta un mapeo explícito de cada campo de origen a su equivalente de destino, y una atención especial a que las fechas de cada episodio se conserven exactamente como estaban, no como la fecha en la que se hizo la exportación forzada. El detalle de cómo se hace ese mapeo campo a campo, incluidos los campos personalizados que no tienen equivalente directo, está en cómo mapear campos personalizados en una migración. Perder la cronología real de un historial es uno de los errores más costosos de corregir después, porque afecta directamente a la trazabilidad clínica.

8. Cuánto tiempo lleva resolver un bloqueo real

8.1. Proveedores que ceden tras el requerimiento formal

En la mayoría de los casos, el requerimiento formal por escrito es suficiente: el proveedor entiende que el coste de seguir bloqueando —una reclamación ante la AEPD documentada, con fechas y sin respuesta— es mayor que el de entregar los datos, y responde dentro del plazo o poco después. Desde el envío del requerimiento hasta tener los datos en formato utilizable, este escenario suele resolverse en pocas semanas.

8.2. Proveedores que fuerzan la vía de la reclamación formal

Una minoría de casos llega hasta la reclamación ante la AEPD sin que el proveedor responda antes. Ese camino alarga el calendario, porque depende de los tiempos de tramitación del organismo, y es la razón por la que conviene empezar el proceso de reclamación en cuanto se detecta el bloqueo, en paralelo a seguir preparando el resto del proyecto de migración, en vez de esperar a tener los datos en la mano para empezar a planificar lo demás.

9. Qué aporta obeliOmed y cómo empezar

Con los datos recuperados, la migración sigue el mismo protocolo, colabore o no el proveedor anterior.

9.1. Migrar los datos recuperados, con o sin colaboración del proveedor antiguo

Una vez el centro dispone de una copia de sus datos —sea porque el proveedor la entregó sin problemas o porque hizo falta un requerimiento formal para conseguirla— el trabajo de migrarlos a obeliOmed sigue el mismo protocolo, independientemente de cómo se haya obtenido esa copia: mapeo de campos, limpieza de duplicidades, carga por lotes y validación con muestra representativa antes de dar por buena la migración completa. El detalle completo del protocolo está en migrar de software médico sin perder historiales.

9.2. Cómo dar el primer paso

Si el proceso de reclamación al proveedor antiguo todavía está en marcha, no hace falta esperar a que termine para empezar a planificar la migración: mapear el volumen de pacientes, decidir el calendario de lotes y preparar el entorno de pruebas son pasos que se pueden avanzar en paralelo. desde 29 €/⁠mes Cuando los datos estén listos, la parte técnica del cambio ya estará preparada, y el tiempo perdido por el bloqueo del proveedor anterior no se traslada también a la fase de migración.