Las pruebas IHCE permiten verificar que el sistema de una IPS construya, valide y transmita correctamente los Resúmenes Digitales de Atención mediante HL7 FHIR antes de operar con información real. El proceso debe probar credenciales, seguridad, recursos clínicos, terminologías, referencias, respuestas de la API y trazabilidad. No basta con obtener una respuesta exitosa: la institución debe demostrar coherencia semántica, manejo de errores y control del paso a producción.
El Ministerio de Salud mantiene durante septiembre de 2026 sesiones de asistencia técnica sobre la Guía de Implementación HL7 FHIR, los RDA de paciente, consulta, urgencias y hospitalización, el Manual de Operaciones, el visor y la seguridad de la información. La continuidad del calendario confirma que la integración no termina con la primera conexión.
La Interoperabilidad de la Historia Clínica Electrónica (IHCE) busca que los prestadores intercambien información clínica estandarizada y segura. El Resumen Digital de Atención (RDA) es el documento electrónico que transporta la información mínima relevante de una atención.
Las pruebas IHCE deben entenderse como una validación clínica, semántica, técnica y de seguridad. Una prueba que solo comprueba disponibilidad de red deja sin evaluar los riesgos más importantes: paciente equivocado, recursos incompletos, catálogos inválidos, referencias rotas o exposición de credenciales.
¿Por qué las pruebas IHCE requieren un enfoque institucional?
El Manual de Operaciones IHCE versión 1.3 aplica a hospitales, clínicas, IPS, centros de urgencias y sistemas de información hospitalaria. Su alcance abarca credenciales, autenticación, envío, consulta, validación, monitoreo, seguridad y soporte técnico. Consulte el Manual de Operaciones IHCE.
Esto significa que la integración involucra más que al proveedor del HIS. Las áreas clínicas definen el significado de los datos; seguridad controla identidades y secretos; tecnología implementa servicios; calidad evalúa integridad; y gerencia autoriza riesgos y recursos.
La Resolución 1888 de 2025 adoptó el RDA y estableció el mecanismo de implementación nacional. El micrositio de normatividad del Ministerio también reúne la Ley 2015 de 2020, la Resolución 866 de 2021 y las disposiciones complementarias. Revise el marco oficial de la IHCE.
¿Qué debe demostrar una prueba completa?
Una prueba completa debe responder cinco preguntas:
- ¿El sistema identifica correctamente al prestador, al profesional, al paciente y a la sede?
- ¿El RDA cumple la estructura exigida por los perfiles colombianos?
- ¿Los códigos y terminologías expresan el significado clínico correcto?
- ¿La transmisión utiliza credenciales y canales protegidos?
- ¿La IPS puede reconstruir qué ocurrió cuando una operación falla?
Si una de estas preguntas queda sin evidencia, la integración puede ser técnicamente visible pero operativamente frágil.
| Dimensión | Qué debe probarse | Riesgo si se omite | Evidencia mínima |
|---|---|---|---|
| Identidad | Paciente, profesional, organización y sede | Asociación con sujeto o institución incorrectos | Casos de prueba e identificadores |
| Sintaxis | Bundle, Composition, cardinalidades y tipos | Rechazo estructural | Resultado del validador |
| Semántica | Diagnósticos, procedimientos y medicamentos | Intercambio de información ambigua | Catálogos y casos clínicos revisados |
| Seguridad | OAuth2, TLS, secretos y permisos | Acceso indebido o exposición de datos | Registros protegidos y matriz de acceso |
| Transporte | API, tiempos, reintentos y disponibilidad | Pérdida o duplicación de mensajes | Logs y correlación |
| Operación | Consulta, envío, error y recuperación | Dependencia de acciones improvisadas | Procedimiento probado |
| Trazabilidad | Usuario, versión, fecha y respuesta | Imposibilidad de auditar incidentes | Bitácora con identificador |
| Continuidad | Contingencia y retorno al servicio | Interrupción asistencial | Simulación documentada |
¿Cómo se estructura un RDA para la IHCE?
El documento maestro del Ministerio indica que el RDA se construye como un Bundle FHIR de tipo document. La primera entrada corresponde a Composition, que organiza el documento y referencia recursos como Patient, Encounter, Condition, Procedure, Medication, Practitioner y Organization.
FHIR, sigla de Fast Healthcare Interoperability Resources, es el estándar empleado para representar e intercambiar recursos clínicos mediante servicios interoperables. No convierte automáticamente cualquier dato en información interoperable: cada recurso debe respetar perfiles, identificadores, cardinalidades y terminologías.
El RDA no es una copia indiscriminada de toda la historia clínica. Es un conjunto estructurado de información relevante para el escenario definido. La institución conserva su historia clínica y genera el resumen conforme al marco aplicable.
¿Qué escenarios deberían probarse por separado?
Las pruebas IHCE deben diferenciar al menos:
- RDA de paciente;
- consulta externa;
- atención de urgencias;
- hospitalización;
- prescripción o información farmacéutica cuando aplique;
- consulta de documentos anteriores;
- resumen longitudinal;
- validación de profesionales, organizaciones y sedes.
Cada escenario utiliza recursos y relaciones diferentes. Aprobar una consulta externa no demuestra que la hospitalización, los egresos o los medicamentos estén correctamente implementados.
La guía interna sobre historia clínica interoperable ofrece contexto funcional. Para programar perfiles y validaciones deben utilizarse siempre la guía y los manuales oficiales vigentes.
¿Qué debe validarse antes de transmitir un Bundle?
La validación local evita enviar errores previsibles al mecanismo nacional. El Documento Maestro señala que el prestador debe validar la conformidad sintáctica y semántica antes del envío.
¿Qué comprende la validación sintáctica?
La sintaxis verifica que el documento pueda interpretarse conforme al estándar y al perfil:
- JSON correctamente formado;
- recurso Bundle del tipo esperado;
- Composition en la posición definida;
- elementos obligatorios presentes;
- cardinalidades respetadas;
- formatos de fecha y hora válidos;
- referencias resolubles;
- identificadores con el patrón requerido;
- perfiles declarados correctamente.
Una sintaxis válida no garantiza que el contenido sea clínicamente correcto. Solo confirma que la estructura es procesable.
¿Qué comprende la validación semántica?
La semántica revisa el significado y la coherencia del contenido:
- diagnóstico compatible con el catálogo aplicable;
- procedimiento codificado de manera válida;
- medicamento identificado mediante la terminología prevista;
- profesional relacionado con la atención;
- fechas consistentes entre ingreso, atención y egreso;
- referencias al mismo paciente;
- unidad, cantidad o vía representadas adecuadamente;
- correspondencia entre el escenario clínico y los recursos incluidos.
Esta capa necesita participación asistencial. Un desarrollador puede confirmar que un campo contiene un código, pero un referente clínico debe ayudar a determinar si ese código expresa correctamente lo documentado.
¿Cómo se prueban la autenticación y la seguridad?
El Manual de Operaciones establece autenticación mediante el flujo OAuth2 Client Credentials. Cada prestador recibe client_id, client_secret y llaves para consumir la API. El manual versión 1.3 indica TLS 1.3 o superior para el transporte.
Las pruebas no deben incluir secretos de producción en capturas, correos o documentos compartidos. Tampoco deberían insertar credenciales directamente en el código fuente.
Una matriz de seguridad debe comprobar:
- quién solicita y administra credenciales;
- dónde se almacenan los secretos;
- qué sistemas pueden leerlos;
- cómo se separan pruebas y producción;
- qué ocurre cuando expiran o se rotan;
- cómo se revoca una credencial comprometida;
- qué información se registra sin exponer datos sensibles;
- quién revisa los accesos y las anomalías.
El Ministerio mantiene un manual específico de gestión de llaves y sesiones de seguridad y privacidad. El portal de recursos de apoyo IHCE debe revisarse antes de configurar ambientes o distribuir credenciales.
¿Qué casos positivos, negativos y de frontera necesita la IPS?
Probar solamente el “camino feliz” produce una falsa sensación de preparación. Las pruebas IHCE deben cubrir resultados esperados y fallas deliberadas.
¿Cuáles son los casos positivos esenciales?
- paciente y profesional válidos;
- RDA completo para cada escenario;
- token vigente;
- envío aceptado;
- consulta posterior del documento;
- recuperación del resumen longitudinal;
- correlación entre solicitud y respuesta;
- visualización autorizada en el flujo clínico.
¿Cuáles son los casos negativos prioritarios?
- token ausente, vencido o inválido;
- perfil FHIR incorrecto;
- recurso obligatorio ausente;
- referencia a paciente inexistente;
- identificador de sede inválido;
- terminología no admitida;
- Composition fuera de la primera entrada;
- contenido clínico incoherente;
- tamaño o formato no aceptado;
- intento de acceso sin autorización.
¿Qué casos de frontera suelen olvidarse?
- paciente con más de un tipo de identificación;
- cambio de documento;
- profesional asociado a varias sedes;
- atención que cruza medianoche;
- reenvío después de un tiempo de espera;
- respuesta tardía de la API;
- solicitud duplicada;
- interrupción durante la transmisión;
- corrección posterior del registro;
- rotación de secretos durante una ventana operativa.
Cada caso debe indicar entrada, resultado esperado, resultado real, evidencia, responsable y decisión. “Funcionó” no es un criterio de aceptación suficientemente verificable.
¿Cómo evitar duplicados durante los reintentos?
Las redes y servicios pueden fallar después de enviar una solicitud, antes de que el sistema local reciba la respuesta. En ese escenario, un reintento automático mal diseñado puede duplicar el evento.
La IPS necesita identificadores de correlación y una política de idempotencia compatible con las operaciones oficiales. Antes de reenviar, el sistema debe determinar si la solicitud anterior fue procesada, permanece pendiente o realmente falló.
Un patrón operativo prudente incluye:
- asignar un identificador único a la transacción;
- conservar la hora, versión y huella del contenido;
- registrar el resultado HTTP y la respuesta funcional;
- consultar el estado cuando sea posible;
- limitar los reintentos automáticos;
- enviar a revisión las fallas persistentes;
- impedir que el usuario genere copias manuales sin control.
La política exacta debe ajustarse al manual y a la operación específica de la API. No debe suponerse que cualquier solicitud puede repetirse de forma indefinida.
¿Qué evidencias deben conservarse?
Una certificación técnica interna necesita evidencias suficientes para reproducir el resultado, sin conservar datos sensibles innecesarios.
El expediente de pruebas puede contener:
- versión del HIS y del componente de integración;
- versión de la guía y los perfiles;
- ambiente utilizado;
- identificadores ficticios o anonimizados;
- caso ejecutado;
- solicitud protegida;
- respuesta técnica y funcional;
- fecha, responsable y aprobador;
- defectos encontrados;
- corrección aplicada;
- evidencia de regresión;
- autorización para promover la versión.
Los registros no deben convertirse en una segunda base de historias clínicas. La IPS debe aplicar controles de acceso, minimización y conservación compatibles con su política de seguridad.
¿Cómo se aprovecha el ambiente de pruebas?
El Ministerio ofrece recursos de apoyo, colecciones y actividades para recorrer operaciones sin afectar datos reales. Una publicación de gestión farmacéutica explica que el sandbox utiliza credenciales exclusivas de pruebas y que la información allí enviada no afecta la operación ni historias clínicas reales.
El ambiente de pruebas debe parecerse funcionalmente a producción, pero mantenerse aislado. No deben cargarse pacientes reales para compensar una falta de datos de ensayo.
Una IPS puede construir conjuntos sintéticos que cubran sus servicios habituales y los escenarios menos frecuentes. El valor del sandbox está en detectar errores antes de que afecten la atención o la continuidad del intercambio.
¿Qué asistencia técnica está disponible en septiembre de 2026?
El plan oficial de implementación IHCE publica las siguientes actividades para el segundo semestre de 2026:
- socialización, credenciales, RDA y metodología de validación el 7 y 21 de septiembre;
- asistencia técnica sobre la Guía HL7 FHIR, gestión farmacéutica, manual y visor el 9 y 23 de septiembre;
- seguridad y privacidad de la información el 2, 16 y 30 de septiembre.
El calendario también contempla sesiones posteriores hasta diciembre. Las fechas deben comprobarse en el portal antes de participar, pues una actualización institucional puede modificar accesos o programación.
La asistencia técnica no sustituye las pruebas internas. Debe emplearse para aclarar requisitos, contrastar interpretaciones y fortalecer la capacidad del equipo.
¿Cómo se decide el paso a producción?
El paso a producción requiere una decisión documentada. No debería depender únicamente de que el proveedor comunique que “la integración está lista”.
Un comité institucional debe confirmar:
- casos críticos aprobados;
- defectos de alta severidad cerrados;
- credenciales de producción protegidas;
- monitoreo activo;
- mesa de ayuda informada;
- respaldo y reversión preparados;
- usuarios capacitados;
- contingencia ensayada;
- responsables disponibles durante el despliegue;
- criterios de suspensión definidos.
La primera ventana productiva debe limitar el riesgo. Es preferible comenzar con monitoreo reforzado y capacidad de respuesta antes de ampliar el volumen.
¿Qué debe vigilarse después de la salida?
Durante las primeras semanas deben revisarse:
- porcentaje de RDA aceptados;
- errores por perfil o terminología;
- tiempos de respuesta;
- tokens fallidos;
- reintentos y duplicados;
- consultas no autorizadas;
- diferencias entre escenarios clínicos;
- incidencias por sede;
- tiempos de resolución;
- quejas del personal asistencial.
El monitoreo debe conducir a acciones. Un tablero que acumula alertas sin responsable no constituye control.
¿Cómo se distribuyen las responsabilidades?
| Rol | Responsabilidad en las pruebas IHCE |
|---|---|
| Gerencia | Aprobar recursos, riesgos y salida a producción |
| Dirección médica | Validar significado y utilidad clínica |
| Tecnología | Implementar API, FHIR, seguridad y monitoreo |
| Seguridad de la información | Controlar secretos, accesos e incidentes |
| Calidad | Diseñar criterios y conservar evidencias |
| Proveedor del HIS | Corregir desarrollos y documentar versiones |
| Usuarios clínicos | Ejecutar escenarios reales y evaluar usabilidad |
| Auditoría | Verificar trazabilidad y cumplimiento del procedimiento |
La página de Software Médico interoperable permite evaluar el alcance funcional disponible para una IPS. La institución debe confirmar mediante pruebas su configuración concreta, integraciones, perfiles y responsabilidades contractuales.
¿Qué plan de validación puede aplicar una IPS?
Un plan práctico puede organizarse en cuatro ciclos.
¿Qué ocurre en el ciclo de preparación?
Se inventarían servicios, sistemas, interfaces, catálogos, perfiles y responsables. El equipo define criterios, ambientes y datos sintéticos.
¿Qué ocurre en el ciclo técnico?
Se prueban autenticación, conectividad, recursos FHIR, validación local, envío, consulta, errores y reintentos.
¿Qué ocurre en el ciclo clínico-operativo?
Los usuarios verifican que el RDA represente fielmente la atención y que el visor aporte información comprensible al flujo asistencial.
¿Qué ocurre en el ciclo de producción controlada?
Se habilita la versión aprobada, se monitorean transacciones y se activa la contingencia cuando se supera un umbral de riesgo previamente definido.
Las pruebas IHCE deben repetirse ante cambios en perfiles, catálogos, API, HIS, infraestructura, credenciales o procesos clínicos. La aprobación inicial no cubre modificaciones futuras.
¿Cuál es la conclusión sobre las pruebas IHCE?
Las pruebas IHCE son el mecanismo que convierte una integración técnica en una capacidad institucional confiable. Deben demostrar estructura FHIR, significado clínico, identidad correcta, seguridad, recuperación ante fallas y trazabilidad.
El próximo paso es crear un plan de validación compartido. Tecnología debe liderar la integración; dirección médica, la semántica; seguridad, las credenciales; calidad, los criterios; el proveedor, las correcciones; y gerencia, la decisión de producción. La IPS debe consultar los recursos oficiales antes de cada cambio y validar con el Ministerio cualquier requisito que resulte ambiguo o tenga impacto normativo.
Preguntas frecuentes
No. El proveedor desarrolla y corrige componentes, pero la IPS debe validar procesos, datos, seguridad, significado clínico y criterios de aceptación.
No. La estructura puede ser válida y contener información clínicamente incoherente. Por eso se requieren validaciones sintácticas y semánticas.
La práctica institucional debe usar datos sintéticos o debidamente protegidos. El recurso oficial de pruebas indica que el sandbox no contiene historias reales y está diseñado para ensayar sin afectar la operación.
Deben verificarse obtención del token, almacenamiento seguro, revocación de la credencial anterior, consumo autorizado y comportamiento ante errores.
Cuando cambien perfiles FHIR, catálogos, servicios de la API, versiones del HIS, infraestructura, credenciales o flujos clínicos relevantes.
Software Médico puede apoyar la estructuración y transmisión del RDA desde el sistema clínico institucional. Una IPS puede solicitar una demo para revisar escenarios, perfiles e integraciones, manteniendo la validación técnica y normativa como responsabilidad compartida entre la institución y su proveedor.
Fuentes oficiales consultadas
- Ministerio de Salud y Protección Social. Manual de Operaciones para la Interoperabilidad de la Historia Clínica Electrónica, versión 1.3. Publicado en 2026.
- Ministerio de Salud y Protección Social. Documento Maestro IHCE. Publicado en 2026.
- Ministerio de Salud y Protección Social. Plan de implementación de la IHCE. Calendario consultado el 11 de septiembre de 2026.
- Ministerio de Salud y Protección Social. Recursos de apoyo para la IHCE. Consultado el 11 de septiembre de 2026.
- Ministerio de Salud y Protección Social. Gestión farmacéutica IHCE para no técnicos. Consultado el 11 de septiembre de 2026.
- Ministerio de Salud y Protección Social. Normatividad de la IHCE. Consultado el 11 de septiembre de 2026.