API FHIR para Proveedores de Software Medico en Espana: Integracion EHDS en una Tarde
Por que un HIS espanol necesita esta API
Construir un generador FHIR R4 + IPS + UNICAS desde cero es un proyecto de 6-12 meses para un equipo con experiencia en salud digital y estandares HL7. La mayoria de proveedores de HIS espanoles no tiene ese equipo. El problema: el EHDS va a exigir exactamente eso a marzo de 2029. Los clientes (clinicas) estan empezando a preguntar por el roadmap FHIR en cada renovacion de contrato. La alternativa: integrar una API externa que haga el trabajo pesado. Su HIS se queda haciendo lo que ya hace bien — interfaz, flujo clinico, facturacion, gestion de citas — y delega la capa de interoperabilidad europea a una API especializada. El resultado: puede anunciar "compatible con EHDS" a sus clientes en semanas, no en 18 meses, y sin construir internamente conocimiento de SNOMED CT, LOINC, AEMPS y validacion de perfiles FHIR.
Que hace la API y que no hace
Honestidad primero. Que hace: (1) recibe datos clinicos en formato CSV, JSON propietario o FHIR parcial, (2) los convierte a Bundle FHIR R4 conforme IPS + UNICAS, (3) valida contra los tres perfiles con checks especificos espanoles (DNI mod-23, AEMPS, OIDs), (4) devuelve el Bundle validado y el informe de validacion en menos de un segundo. Que no hace: (a) no guarda sus datos clinicos — la transformacion es sin estado, una vez devuelta la respuesta, los datos se eliminan. (b) No es un servidor FHIR completo — no tiene endpoints GET por recurso, no gestiona suscripciones ni versiones; es un transformador y validador. (c) No emite credenciales ni asume el rol de un sistema clinico de fuente. (d) No substituye su cumplimiento RGPD ni su obligacion de proteccion de datos — los datos viajan cifrados pero su responsabilidad sobre ellos sigue siendo suya.
Formatos de entrada y salida
Entrada aceptada: CSV con columnas estandar espanolas (nombre, apellidos, dni, fecha_nacimiento, codigo_cie10, medicamento, alergia, vacuna) en UTF-8 o Windows-1252 (detectado automaticamente). JSON con esquema Clinni o JSON propio mapeado via plantilla de columnas. FHIR R4 parcial: si su sistema ya genera algunos recursos FHIR pero no cumple IPS, la API completa, reestructura y valida. Salida por defecto: Bundle FHIR R4 en JSON conforme a las reglas IPS y UNICAS. Opcional: salida XML (FHIR soporta ambos formatos; algunos sistemas legados lo prefieren). Junto al Bundle, informe de validacion en tres niveles: errores (impiden el uso del Bundle), warnings (lo permiten pero conviene arreglar) e info (sugerencias de calidad de datos). Todo bilingue espanol/ingles con FHIRPath exacto del problema. Rate limit estandar: 100 llamadas por clave por hora en plan gratuito, 10.000 por hora en plan profesional.
Autenticacion y empezar en diez lineas
La autenticacion es por clave API enviada en el header x-api-key. Las claves se generan desde el dashboard (saludcomply.com/dashboard/settings), formato sc_live_... para produccion y sc_test_... para pruebas. Ejemplo minimo en Node.js: const response = await fetch("https://api.saludcomply.com/api/v1/transform", { method: "POST", headers: { "x-api-key": "sc_live_xxx", "Content-Type": "application/json" }, body: JSON.stringify({ format: "csv_generic_es", data: csvContent }) }); const { bundle, validation } = await response.json();. En Python con requests: r = requests.post("https://api.saludcomply.com/api/v1/transform", headers={"x-api-key": "sc_live_xxx"}, json={"format": "csv_generic_es", "data": csv_content}); bundle = r.json()["bundle"]. La documentacion completa con todos los formatos, ejemplos en cURL y manejo de errores esta en saludcomply.com/documentacion/api. Soporte tecnico en espanol para integradores por email.
Casos de uso reales de integracion
Tres patrones que ya estamos viendo en el mercado espanol. (1) HIS con exportacion bajo demanda: clinica solicita "exportar para intercambio europeo" desde la interfaz, el HIS llama al endpoint /api/v1/transform con los datos del paciente, recibe Bundle FHIR y lo entrega al paciente como descarga o lo envia por correo cifrado. Integracion en 2-4 semanas de desarrollo. (2) Portal de paciente con derecho de portabilidad: el portal llama a la API cuando el paciente pulsa "descargar mis datos" bajo derechos EHDS/RGPD, genera Bundle en formato europeo y lo ofrece al paciente. Cumple el derecho de portabilidad del Capitulo II del EHDS. Integracion en 1-2 semanas. (3) Integrador con mutuas: la mutua exige recibir datos en FHIR; el proveedor de software clinico usa la API como puente sin rediseniar su exportador de datos. Integracion en dias si el CSV ya existe. En los tres casos, el HIS/portal/integrador manda, la API solo transforma y valida — control sobre los datos queda en su stack.
Empezar: cuenta gratuita y clave de prueba en 5 minutos
El plan gratuito basta para evaluacion tecnica y pilotos con un par de clinicas. Lo que hace falta: (1) Crear cuenta en saludcomply.com/dashboard (email + contrasena, o magic link). (2) Ir a Settings > API Keys y generar una clave de prueba sc_test_.... La clave se muestra una vez — copiela. (3) Hacer una primera llamada al endpoint con un archivo de ejemplo (hay un payload de muestra en la documentacion). En 30 segundos deberia ver un Bundle FHIR devuelto. (4) Revisar el dashboard: cada llamada se registra con timestamp, tamano, perfiles validados y resultado. Si algo falla, el historial le dice que y cuando. (5) Cuando este listo para produccion, generar una clave sc_live_ y hablar con nosotros si necesita limites superiores al plan profesional o despliegue on-premises. Sin comercial agresivo — si su caso encaja, seguimos; si no, lo decimos.