- 22/03/2026
- Juan Carlos Abaunza
El RDA ya llegó. Y tu proveedor tecnológico puede no estar listo
Desde el 15 de octubre de 2025, el reloj de la interoperabilidad en salud colombiana está corriendo. La Resolución 1888 de ese año puso en marcha un cambio de paradigma sin precedentes: cada prestador de servicios de salud en el país tiene la obligación legal de generar, enviar y consultar el Resumen Digital de Atención en Salud — el RDA — a través de la plataforma nacional del Ministerio de Salud.
La fecha límite es el 15 de abril de 2026. No es una aspiración. No es una recomendación. Es un mandato con consecuencias regulatorias concretas. Y sin embargo, en decenas de conversaciones con directores médicos, gerentes de TI y administradores de IPS a lo largo del país, emerge la misma respuesta tranquilizadora: “mi proveedor de software me dijo que ya lo tiene resuelto.”
Esa respuesta, aunque comprensible, puede ser la trampa más costosa que una institución de salud cometa en 2026.
Qué es el RDA y por qué transforma el sistema de salud colombiano
El Resumen Digital de Atención en Salud es mucho más que un nuevo formulario electrónico. Es la materialización de años de política pública orientada a resolver uno de los problemas más persistentes del sistema colombiano: la fragmentación de la información clínica.
Marco normativo vigente: Ley 2015 de 2020 (Historia Clínica Electrónica Interoperable como bien público digital) → Resolución 866 de 2021 (conjunto mínimo de datos clínicos) → Resolución 1888 de 2025 (adopción obligatoria del RDA y mecanismo de implementación nacional). El RDA se construye sobre el estándar internacional HL7 FHIR R4.
Hoy, cuando un paciente que ha sido atendido en una IPS de Medellín llega a urgencias en Bogotá, su historia clínica no viaja con él. El médico en guardia toma decisiones con información incompleta, repite exámenes ya realizados y asume riesgos clínicos innecesarios. Según cifras del propio Ministerio, el 73% de los hospitales del país operan entre 10 y 15 sistemas de información que no se comunican entre sí.
El RDA cambia eso estructuralmente. Una vez implementado, cada atención genera automáticamente un documento electrónico estandarizado bajo FHIR R4 que se transmite a la plataforma nacional (IHCE). Cualquier profesional autorizado puede consultarlo en tiempo real desde cualquier punto del país. La información clínica del paciente deja de estar “atrapada” en el sistema de cada institución.
La Resolución 1888 define cuatro tipos de RDA en su primera fase: el RDA de consulta externa, el RDA de urgencias, el RDA de hospitalización y el RDA de paciente — un consolidado del historial individual. Cada uno tiene su estructura técnica específica en FHIR, su conjunto mínimo de datos obligatorios y sus requisitos de validación ante el Ministerio.
Por qué confiarse del proveedor tecnológico es un riesgo institucional
Aquí está el punto que más incomoda escuchar, pero que debe decirse con claridad: la responsabilidad del cumplimiento del RDA recae sobre el prestador de servicios de salud, no sobre su proveedor de software.
“Si el RDA que genera su software no cumple con la estructura exigida, su institución incumple la norma.”
Resolución 1888 de 2025 — Ministerio de Salud y Protección SocialEl Ministerio certifica al prestador y al software de forma conjunta. En el proceso de homologación, es la IPS quien debe demostrar que su sistema genera, valida, firma digitalmente y transmite correctamente los RDA a la plataforma IHCE. Si el software falla en esa validación, el incumplimiento es institucional.
Esto crea una asimetría de información peligrosa. Muchos proveedores de HIS (Sistemas de Historia Clínica) han respondido al cambio regulatorio de tres formas distintas — y solo una de ellas protege a la institución de salud:
| Tipo de respuesta del proveedor | Lo que dicen | Riesgo real |
|---|---|---|
| Proveedor preparado | Certificación activa ante MinSalud, sandbox funcional, cronograma de pruebas | Bajo |
| Proveedor en desarrollo | “Estamos trabajando en ello, estará listo a tiempo” | Medio-Alto |
| Proveedor desconectado | “Nuestro sistema ya cumple” (sin evidencia técnica) | Crítico |
El problema es que, desde la perspectiva del gerente o director médico, las tres respuestas suenan igual: tranquilizadoras. La diferencia solo se hace visible cuando ya es demasiado tarde para actuar.
Lo que está en juego cuando una institución no verifica
01
Incumplimiento normativo directo
02
Bloqueo operativo post-abril
03
Datos estructurados incorrectamente
04
Dependencia tecnológica sin salida
05
Riesgo de auditoría aumentado
06
Pérdida de datos bajo custodia
Las 8 preguntas que debe hacerle a su proveedor antes del 15 de abril
La buena noticia: todavía hay tiempo para actuar. Pero ese tiempo se mide en días, no en semanas. Estas son las preguntas concretas que toda institución de salud debe hacerle a su proveedor tecnológico hoy mismo — y qué respuestas aceptar o rechazar:
- ¿Puede generar los cuatro tipos de RDA (consulta externa, urgencias, hospitalización, paciente) en formato HL7 FHIR R4?
Solicite una demostración técnica en ambiente de sandbox, no una promesa verbal o un PDF. - ¿Los diagnósticos se registran con CIE-10/CIE-11 estructurado, no como texto libre?
El texto libre no genera un RDA válido. Si su sistema acepta diagnósticos sin código, fallará la validación del Ministerio. - ¿Los medicamentos usan código IUM y nombre genérico estandarizado?
Requerimiento técnico explícito de la Res. 1888. Sin IUM, el RDA de farmacoterapia es inválido. - ¿Los procedimientos tienen código CUPS asignado de forma obligatoria?
Misma lógica: sin CUPS estructurado, el RDA no pasa validación semántica. - ¿El sistema puede conectarse vía API con la plataforma IHCE del Ministerio (Hércules)?
Solicite evidencia de pruebas exitosas de conectividad, no una descripción de arquitectura. - ¿El RDA se firma digitalmente antes de ser transmitido?
La firma digital garantiza autenticidad y no repudio — es requisito técnico obligatorio, no opcional. - ¿Qué pasa con mis datos históricos si el sistema no cumple y debo cambiar de proveedor?
Conozca el plan de extracción, portabilidad y custodia de sus datos antes de que sea una emergencia.
Señal de alerta crítica: Si su proveedor no puede responder estas preguntas con evidencia técnica demostrable — no con presentaciones ni promesas — está frente a un riesgo institucional real. El plazo del Ministerio no distingue entre instituciones que “no sabían” y las que “eligieron no actuar”.
Por qué el problema va más allá del software
Incluso cuando el proveedor de HIS esté genuinamente preparado, muchas instituciones enfrentan un problema estructural que ningún software resuelve por sí solo: la calidad de los datos que alimentan el sistema.
El RDA es tan bueno como los datos que lo componen. Si los médicos registran diagnósticos en texto libre, si los procedimientos no tienen código CUPS, si los medicamentos se ingresan con nombre comercial sin IUM, el sistema puede estar perfectamente integrado con FHIR y aún así generar RDA rechazados o clínicamente inútiles.
Esto requiere un cambio de proceso interno que va mucho más allá de una actualización de software. Requiere capacitación del equipo clínico, rediseño de plantillas de registro, gobernanza de datos activa y auditoría continua de calidad. Es la parte del cumplimiento que ningún proveedor puede hacer por la institución.
Existe un patrón que se repite en las instituciones de salud latinoamericanas: el área clínica delega todo lo tecnológico al área de TI, el área de TI delega la responsabilidad normativa al proveedor de software, y el proveedor, en el mejor de los casos, implementa la norma técnica pero no acompaña el cambio de procesos. El resultado es un vacío en el que nadie es dueño real del cumplimiento.
La Resolución 1888 rompe ese patrón porque hace que el cumplimiento sea verificable y público: la plataforma IHCE sabrá exactamente qué instituciones están generando RDA válidos y cuáles no. No hay forma de aparentar cumplimiento.
Tres niveles de respuesta según el estado actual de su institución
No todas las instituciones están en el mismo punto de partida. La respuesta correcta depende del diagnóstico real del sistema actual:
Verifique que el proceso de certificación incluya su instancia específica del software (no solo la versión genérica del proveedor). Solicite el cronograma de pruebas de conectividad con IHCE. Implemente un plan de capacitación para registro estructurado de datos clínicos. Designe un responsable interno de interoperabilidad.
Exija un compromiso contractual con fecha de entrega y penalidades. Evalúe si es técnicamente viable implementar una capa de interoperabilidad externa (middleware FHIR) que actúe sobre su sistema existente mientras el proveedor completa su desarrollo. Esta es la ruta que instituciones con plazos urgentes están tomando con mayor frecuencia en 2026.
Es un escenario más común de lo que se reconoce públicamente, especialmente con proveedores de software de menor escala. En este caso, el proceso de selección y migración debe comenzar de inmediato, priorizando la portabilidad de los datos históricos y un cronograma de transición que no interrumpa la operación clínica.
El RDA como punto de partida, no como punto de llegada
Desde Whatoko Health llevamos más de tres años implementando capas de interoperabilidad sobre sistemas de salud en Colombia y Latinoamérica. En ese tiempo hemos aprendido algo que va más allá de la discusión técnica: las instituciones que sobreviven los cambios regulatorios no son las que tienen el mejor software. Son las que tienen claridad sobre dónde está su información, quién es responsable de su calidad y qué pasa si el proveedor actual falla.
El RDA es una oportunidad real. No solo de cumplir una norma, sino de sentar las bases de una gobernanza de datos que le permita a la institución acceder a interoperabilidad real, análisis clínico avanzado, telemedicina integrada y, en el mediano plazo, entrenamiento de modelos de IA sobre datos propios anonimizados. Todo eso parte del mismo fundamento: datos clínicos bien estructurados, estandarizados bajo FHIR y bajo control institucional.
Pero ese futuro solo es posible si la institución toma el control hoy. No en mayo. No cuando el proveedor diga que está listo. Hoy.
¿No sabe si su institución cumplirá el 15 de abril?
En Whatoko Health ofrecemos un diagnóstico técnico de interoperabilidad sin costo — evaluamos su sistema actual, identificamos brechas frente a la Res. 1888 y le entregamos un plan de acción concreto en 48 horas.