Cómo exportar tus datos de Clinic Cloud: formatos, plazos y lo que no sale solo

1. El punto de partida: qué guarda Clinic Cloud y dónde

1.1. Una plataforma en la nube: los datos no están en tu ordenador

Clinic Cloud es un software de gestión clínica en la nube. Los datos —pacientes, historiales, citas, documentos, facturación— residen en los servidores de Clinic Cloud, no en un ordenador de la clínica. Eso significa que la exportación pasa siempre por lo que la plataforma ofrece como descarga o por lo que el soporte técnico pueda extraer bajo petición. No hay un fichero de base de datos en una carpeta local que se pueda copiar directamente.

1.2. Datos clínicos, datos administrativos y documentos adjuntos

Los datos de una clínica en Clinic Cloud se dividen en tres grandes bloques: los clínicos (historiales, antecedentes, diagnósticos, evoluciones), los administrativos (pacientes, citas, facturación, cobros) y los documentos adjuntos (PDF, imágenes, consentimientos escaneados). Cada bloque puede tener un canal de exportación distinto, y no todos salen con el mismo nivel de detalle ni en el mismo formato.

2. Qué se puede exportar desde la propia interfaz

2.1. Listados de pacientes y datos demográficos

La mayoría de los software de gestión, incluido Clinic Cloud, permiten exportar el listado de pacientes con datos demográficos básicos: nombre, apellidos, fecha de nacimiento, teléfono, email, dirección. Esa exportación suele salir en formato CSV o Excel, y es el dato más fácil de obtener. Lo que no suele incluir es la relación del paciente con sus citas, sus historiales ni sus documentos: solo los datos de la ficha.

2.2. Informes y estadísticas en formato descargable

Clinic Cloud ofrece informes de actividad, facturación y ocupación que se pueden descargar como PDF o como hoja de cálculo. Esos informes sirven para el análisis pero no para la migración: son datos agregados, no datos de registro. Un informe de facturación del trimestre no es lo mismo que el detalle de cada factura con su paciente, su servicio y su forma de pago. Para la migración hacen falta los datos de registro, no los resúmenes.

2.3. Documentos adjuntos: lo que se puede descargar uno a uno

Los documentos adjuntos al historial del paciente —consentimientos firmados, informes de otros centros, resultados de pruebas— pueden descargarse individualmente desde la ficha del paciente. Para una clínica con pocos pacientes, eso puede ser viable; para una con miles de historiales y documentos, descargarlos uno a uno es impracticable. La exportación masiva de documentos adjuntos suele requerir una solicitud al soporte, y el formato de entrega puede ser una carpeta comprimida con los archivos organizados por identificador de paciente o sin ninguna organización que permita la importación automática.

3. Qué hay que solicitar al soporte de Clinic Cloud

3.1. La exportación completa del historial clínico

Los datos que no están disponibles como descarga directa —historiales clínicos completos, evoluciones, plantillas rellenadas, campos personalizados— requieren una solicitud al soporte técnico de Clinic Cloud. El soporte puede generar una extracción más completa que la que ofrece la interfaz, pero el formato, el plazo y el coste de esa extracción dependen de las condiciones del contrato y de la política de la empresa en el momento de la solicitud.

3.2. Plazos y condiciones que conviene conocer antes de pedir la baja

Si la exportación se pide después de comunicar la baja del servicio, la clínica puede encontrarse con que el acceso se cierra antes de que la exportación esté lista, o con que la extracción completa tiene un coste adicional que no estaba en el contrato inicial. Pedir la exportación antes de comunicar la baja —mientras el servicio está activo y el acceso es completo— da más margen de maniobra y permite verificar que lo exportado es correcto antes de perder el acceso al sistema.

4. El derecho de portabilidad según el RGPD

4.1. Qué dice la norma y qué cubre realmente

El artículo 20 del RGPD reconoce el derecho del interesado a recibir sus datos personales en un formato estructurado, de uso común y lectura mecánica. Eso incluye los datos que el paciente ha proporcionado al responsable del tratamiento. En la práctica, la clínica ejerce este derecho en nombre de sus pacientes cuando migra a otro sistema, y el proveedor está obligado a entregar esos datos en un formato que permita su reutilización.

4.2. Lo que el RGPD no obliga a entregar

El derecho de portabilidad cubre los datos proporcionados por el interesado, pero no todos los datos que genera el sistema. Las configuraciones, las plantillas creadas por la clínica, los informes personalizados y las automatizaciones no son datos del paciente y no están cubiertos por la portabilidad. Eso significa que una parte del trabajo que la clínica ha invertido en personalizar el sistema puede no ser exportable por esta vía.

5. Formatos habituales de exportación y sus limitaciones

5.1. CSV y Excel: datos tabulares sin estructura relacional

Un archivo CSV o Excel contiene filas y columnas: un paciente por fila, un campo por columna. Sirve para datos planos como el listado de pacientes, pero no para datos con estructura relacional —un paciente con varias citas, cada cita con varios actos, cada acto con su diagnóstico—. Importar un CSV a otro sistema obliga a reconstruir esas relaciones, y eso es trabajo manual o un script de transformación que alguien tiene que escribir.

5.2. PDF: el formato que preserva la apariencia y pierde la estructura

Un historial clínico exportado como PDF se puede leer y archivar, pero no se puede importar a otro sistema de forma automática. El PDF es un formato de presentación, no de intercambio: los datos están dibujados en la página, no estructurados en campos. Una migración basada en PDF requiere que alguien —o un sistema de OCR— extraiga cada dato y lo coloque en el campo correspondiente del sistema nuevo, con el coste y el margen de error que eso implica.

5.3. XML y JSON: más estructura, menos compatibilidad directa

Algunos proveedores entregan la exportación en XML o JSON, formatos que sí preservan relaciones jerárquicas —un paciente con sus citas dentro, cada cita con sus actos—. Son mejores que un CSV para la migración, pero cada proveedor define su propia estructura: los campos se llaman distinto, las fechas van en otro formato y los catálogos de diagnósticos pueden no coincidir. Una implementación bien planificada incluye la transformación de esos archivos como parte del proyecto, no como un imprevisto que aparece al final.

6. Lo que suele quedarse fuera de la exportación estándar

6.1. Plantillas y formularios personalizados

Si la clínica ha creado plantillas de anamnesis, formularios de consentimiento o protocolos de exploración dentro de Clinic Cloud, esas plantillas pueden no ser exportables. El contenido rellenado sí —es dato del paciente—, pero la estructura de la plantilla es una configuración del sistema que cada proveedor implementa de forma diferente. Recrear esas plantillas en el sistema nuevo es un coste adicional de la migración que suele olvidarse.

6.2. El historial de comunicaciones y las notas internas

Los mensajes enviados al paciente por email o WhatsApp, las notas internas entre profesionales y el registro de llamadas telefónicas pueden no formar parte de la exportación estándar. Son datos que existen en el sistema pero que no siempre se consideran parte del expediente clínico. Si la clínica necesita conservar ese historial, debe solicitarlo explícitamente y verificar que aparece en la exportación.

7. Cómo preparar la exportación antes de pedirla

7.1. Inventariar qué datos tiene la clínica en el sistema

Antes de pedir la exportación, conviene saber qué hay dentro: cuántos pacientes activos, cuántos historiales tienen adjuntos, si hay plantillas personalizadas, si se usa la facturación integrada o externa, si hay datos de equipos médicos vinculados. Ese inventario permite comparar lo que se recibe en la exportación con lo que debería haber, y detectar lo que falta antes de perder el acceso al sistema.

7.2. Verificar la exportación mientras se tiene acceso

Lo que se exporta se verifica mientras el sistema está abierto: abrir el archivo, contar los registros, comparar un historial exportado con el que se ve en pantalla, comprobar que los documentos adjuntos están y que se abren. Si la verificación se deja para después de la baja, las discrepancias no se pueden resolver porque ya no hay acceso al sistema original. La obligación de retención del historial recae en la clínica, y eso incluye verificar que la copia exportada es completa antes de soltar la fuente.

8. Qué hacer con los datos una vez exportados

8.1. Custodia: los datos exportados siguen siendo datos de salud

Un archivo con historiales clínicos exportados tiene las mismas obligaciones legales que la base de datos original: cifrado, control de acceso, registro de quién lo abre y retención durante el plazo legal. Dejar un CSV con los datos de todos los pacientes en una carpeta compartida del escritorio es un incumplimiento del RGPD, aunque la intención sea temporal.

8.2. Transformación: adaptar el formato al sistema de destino

El formato que sale de Clinic Cloud rara vez coincide exactamente con el que necesita el sistema de destino. Los campos se llaman diferente, las fechas pueden estar en otro formato, los diagnósticos pueden usar otra codificación. La guía de migración de historiales detalla los pasos habituales de transformación y los errores que conviene evitar.

8.3. Validación cruzada: comprobar que lo importado coincide con lo exportado

Después de importar los datos al nuevo sistema, la única forma de saber si la migración ha funcionado es comparar ambos lados: abrir el mismo paciente en el sistema antiguo —mientras el acceso siga activo— y en el nuevo, y comprobar que los campos principales coinciden. Las discrepancias más habituales son fechas que cambian de formato, acentos y caracteres especiales que se pierden, y documentos adjuntos que se importan pero no se asocian al paciente correcto. Calcular el retorno de la inversión incluye la reducción del tiempo que la clínica dedica a verificar y corregir datos tras una migración mal preparada.

9. Cómo facilita obeliOmed la importación desde Clinic Cloud

9.1. Servicio de migración asistida con verificación conjunta

obeliOmed ofrece un servicio de migración asistida para clínicas que vienen de Clinic Cloud. El equipo analiza el fichero de exportación, mapea los campos, importa los datos y verifica el resultado con la clínica antes de dar la migración por terminada. El presupuesto es cerrado y se acuerda antes de empezar.

9.2. Sin atadura de salida: exportación incluida y documentada

Si en algún momento la clínica decide irse de obeliOmed, los datos se exportan en formato estándar y documentado, sin tarifa de salida. Los datos se alojan en servidores en España, con cifrado AES-256-GCM. La portabilidad no es un derecho que haya que ejercer: es una funcionalidad del sistema que está disponible en cualquier momento.