En qué formato salen los datos de tu clínica

No plenamente. El RGPD exige que los datos se entreguen en un formato estructurado, de uso común y lectura mecánica. Un PDF es de uso común y lo puede leer una persona, pero no es estructurado ni de lectura mecánica en el sentido de que un sistema pueda importar automáticamente los datos que contiene. Para entregar al paciente un informe que pueda leer, el PDF sirve. Para cumplir plenamente el derecho de portabilidad — que incluye la transmisión a otro responsable del tratamiento —, el formato debería ser estructurado: CSV como mínimo, XML o un formato con campos identificados y relaciones preservadas como ideal.

No hay un formato único que sea el más portátil para todos los casos. Un volcado SQL documentado es técnicamente el más completo porque preserva todas las tablas y relaciones, pero requiere conocimiento técnico para interpretarlo. Un CSV es más accesible pero pierde las relaciones entre datos. Para imágenes médicas, DICOM es el estándar. Lo que hace portátil un formato no es el tipo de fichero sino que esté documentado, que los campos estén identificados y que los datos clínicos estén codificados. Un CSV con códigos CIE-10 es más portátil que un volcado SQL sin codificación.

Sí, con matices. El RGPD establece que el responsable del tratamiento — la clínica — tiene que poder cumplir el derecho de portabilidad del paciente, y para eso necesita que su software pueda exportar los datos. Si el contrato con el proveedor incluye una cláusula de portabilidad, la obligación es contractual. Si no la incluye, la obligación legal sigue existiendo — la clínica tiene que cumplir la portabilidad — pero el mecanismo para exigírselo al proveedor es más débil. Por eso la cláusula contractual es tan importante: convierte una obligación legal genérica en un compromiso concreto del proveedor.

Si tus datos clínicos están en texto libre — diagnósticos escritos como frases, medicamentos por nombre comercial sin código ATC —, la exportación será legible por personas pero no interoperable. Un sistema receptor no puede procesar automáticamente un diagnóstico en texto libre: alguien tiene que leerlo e interpretarlo. Para cumplir el EHDS, esos datos tendrán que estar codificados. Codificar retroactivamente años de datos en texto libre es posible pero caro y lento. Lo más eficiente es empezar a codificar correctamente los datos nuevos desde hoy y retrocodificar los antiguos de forma progresiva.

Hoy no, todavía. El RGPD exige formato estructurado, de uso común y lectura mecánica, pero no especifica un estándar concreto. Un CSV, un volcado SQL documentado o un XML con esquema publicado cumplen estos requisitos. Pero el EHDS va a exigir un formato europeo de intercambio específico para las categorías prioritarias de datos sanitarios antes de 2029. Ese formato se basará en estándares internacionales. Un software que hoy trabaja con formatos estructurados y datos codificados tendrá una adaptación sencilla; uno que trabaja con texto libre y PDFs tendrá una adaptación mucho mayor.

Depende de cómo las almacene tu software. El estándar para imágenes médicas es DICOM, que incluye la imagen y sus metadatos clínicos — datos del paciente, del estudio, del equipo y de la adquisición. Si tu software almacena las imágenes en DICOM, la exportación preserva toda esa información y otro sistema compatible con DICOM puede importarlas directamente. Si las almacena en JPEG o PNG, la imagen sale pero pierde los metadatos clínicos y el sistema receptor no tiene forma de asociarla automáticamente al paciente y al estudio correspondientes.

El coste depende del volumen y del tipo de dato. Codificar diagnósticos retroactivamente con CIE-10 requiere que un profesional sanitario revise cada diagnóstico en texto libre, identifique el código CIE-10 correspondiente y lo asocie al registro. Para una clínica con diez años de historiales y miles de diagnósticos en texto libre, puede ser un proyecto de meses. Lo más eficiente es empezar a codificar bien los datos nuevos — que no tiene coste adicional significativo si el software lo permite — y retrocodificar los antiguos de forma progresiva, empezando por los pacientes activos.

No directamente. El cumplimiento fiscal — VeriFactu, TicketBAI, factura electrónica — tiene sus propios formatos y requisitos que no dependen del formato de exportación de los datos clínicos. Pero sí hay un punto de contacto: la factura electrónica de Crea y Crece exige que las facturas B2B se emitan y reciban en formato Facturae, que es un formato estructurado. Si tu software ya genera Facturae, la parte fiscal del formato está cubierta. Los datos clínicos y los fiscales viajan en formatos distintos, pero la mentalidad es la misma: datos estructurados y procesables por máquina.