Como Exportar Historia Clinica a FHIR desde Software Medico Espanol
El problema: ningun HIS espanol exporta FHIR limpio
La realidad del mercado espanol en abril de 2026: la mayoria de los sistemas de gestion clinica exportan datos en formatos propios (CSV con columnas inventadas), JSON no estandar o PDF. Ninguno de los mas extendidos en clinicas pequenas y medianas genera hoy un Bundle FHIR R4 validable contra el Resumen del Paciente europeo (IPS) y la guia de implementacion espanola (UNICAS). Esto es un problema concreto: el EHDS va a exigir exactamente eso. Los caminos posibles son tres. Uno: esperar a que su proveedor saque soporte nativo FHIR (en algunos casos, nunca). Dos: cambiar de proveedor (caro y lento). Tres: usar una herramienta puente que convierta lo que su HCE ya exporta al formato que el EHDS va a exigir. Esta guia cubre el tercer camino, con pasos concretos para los cuatro casos mas comunes en el mercado espanol.
Exportar Clinic Cloud a FHIR
Clinic Cloud es uno de los HIS mas usados en clinicas espanolas de tamano medio. Soporta REMPe para receta electronica, pero no tiene exportacion FHIR nativa. El workflow es: (1) En Clinic Cloud, vaya a Configuracion > Exportacion de datos y genere un CSV de pacientes, diagnosticos y medicacion. El formato por defecto es UTF-8 con coma como delimitador. Si tiene datos antiguos importados desde papel, puede aparecer codificacion Windows-1252 — nuestro transformador detecta ambas. (2) Revise que las columnas incluyan al menos: nombre, apellidos, DNI/NIE, fecha de nacimiento, codigo CIE-10 de diagnostico, medicacion activa (nombre comercial o codigo AEMPS) y alergias. (3) Suba el CSV al Transformador FHIR de SaludComply (gratuito). El sistema detecta el formato, mapea los campos a recursos FHIR Patient, Condition, MedicationStatement y AllergyIntolerance, y valida DNI mod-23, OIDs espanoles y codigos AEMPS. (4) Descargue el Bundle FHIR R4 + IPS validado. Listo para enviar a un destinatario europeo via MyHealth@EU cuando el canal este abierto.
Exportar Klinikare a FHIR
Klinikare domina el mercado de clinicas pequenas en Espana (2.800+ clinicas segun su propia web) pero es uno de los casos mas complicados: su exportacion estandar es un CSV propietario sin columnas normalizadas, y la empresa no ofrece documentacion publica de su estructura. No hay exportacion REMPe nativa en el plan estandar. Workflow recomendado: (1) Desde Klinikare, exporte el listado completo de pacientes a CSV. El formato varia segun version — pida soporte si las columnas no son claras. (2) Exporte por separado el listado de consultas y medicacion prescrita. (3) Si tiene CSVs con nombres de columna inconsistentes (p.ej. "NOMBRE" en unos, "Nombre" en otros), pase un paso de limpieza previo — nuestra herramienta admite un mapeo manual de columnas para estos casos. (4) Suba los tres CSVs al Transformador FHIR. El modo batch permite combinar varios archivos en un unico Bundle. (5) Revise los errores de validacion: con Klinikare es frecuente que los campos de fecha no esten normalizados (dd/mm/yyyy vs yyyy-mm-dd) y que falten DNIs en registros antiguos. La salida de validacion le dice exactamente que registros arreglar en origen antes del siguiente ciclo.
Exportar Clinni JSON a FHIR
Clinni es uno de los HIS mas modernos del mercado espanol y, a diferencia de muchos competidores, ofrece exportacion en JSON estructurado. No es FHIR — tiene su propio esquema — pero es lo suficientemente consistente como para que el mapeo a FHIR sea directo. Workflow: (1) En Clinni, use el endpoint de exportacion de paciente (disponible en planes profesional y superior) o el export manual desde la pantalla de paciente. Obtendra un archivo JSON con estructura anidada: datos personales, encuentros clinicos, prescripciones, alergias, vacunas. (2) Suba el JSON al Transformador. El sistema reconoce el esquema Clinni automaticamente y lo convierte a Bundle FHIR R4 manteniendo los identificadores originales como identifier.system secundarios para trazabilidad. (3) La validacion IPS verifica que el Resumen del Paciente contenga las secciones obligatorias. Si falta alguna (p.ej. no hay lista de alergias registrada), el sistema lo indica como warning, no como error — el Bundle sigue siendo utilizable. (4) Descargue el Bundle y, opcionalmente, un PDF con las diferencias entre el JSON original y la salida FHIR — util para auditoria interna.
CSV generico: el resto del mercado
Si su HIS no es ninguno de los tres anteriores — DriCloud, mediQuo, Trabem, Flowww, cualquier sistema local hecho a medida — todavia hay camino. El Transformador acepta un formato CSV generico con columnas estandar espanolas: nombre, apellidos, dni, fecha_nacimiento, sexo, codigo_cie10, diagnostico_libre, medicamento, dosis, frecuencia, alergia, vacuna, fecha_vacuna. Si su HCE exporta CSV con columnas distintas, hay dos opciones: (1) Preparar el CSV manualmente con LibreOffice o Excel renombrando las columnas — viable para una clinica pequena con volumen manejable. (2) Usar el mapeador de columnas del Transformador: sube su CSV, asigna cada columna del origen a una columna estandar, y el sistema guarda el mapeo para exportaciones futuras. La segunda opcion es la recomendada si va a exportar regularmente. Una vez el CSV esta en formato estandar, el flujo es identico: validacion, Bundle FHIR, descarga.
Validacion automatica: que atrapa antes de que sea un problema
La conversion a FHIR no vale mucho si el Bundle no pasa validacion europea. El Transformador valida contra tres perfiles en paralelo. FHIR R4 base: estructura, cardinalidades, value sets, formatos de fecha. IPS (International Patient Summary): secciones obligatorias del Resumen del Paciente, declaracion de perfiles, estructura del Bundle. UNICAS (guia espanola): DNI/NIE con checksum mod-23, OIDs de identificadores espanoles, mapeo CIE-10 a SNOMED CT, codigos AEMPS de medicacion, formato de codigo postal espanol. Los errores salen bilingues (espanol e ingles) con el FHIRPath exacto del problema — no se queda en "registro invalido", le dice "Patient.identifier[0].value: DNI 12345678A falla el checksum mod-23". Esto es importante para cumplimiento pero tambien para calidad de datos: la validacion revela fallos en los datos de origen que, sin ella, nunca se detectarian.