Resolución 1888 de 2025: qué le exige de verdad a una clínica odontológica

El Ministerio de Salud y Protección Social expidió la Resolución 1888 el 15 de septiembre de 2025. Lo que adopta es el Resumen Digital de Atención en salud —el RDA— como el mecanismo con el que la información clínica se intercambia dentro de la Interoperabilidad de la Historia Clínica Electrónica (IHCE).

Conviene separar dos cosas que se confunden todo el tiempo. La historia clínica electrónica es lo que tu clínica lleva adentro. El RDA es un resumen estructurado de cada atención que sale de tu sistema hacia una plataforma nacional. No es lo mismo tener la historia digitalizada que estar interoperando: lo primero lo tienen casi todos, lo segundo es lo que la norma vino a exigir.

La resolución rige desde su publicación, y su artículo 6.º le dio a los sujetos obligados un plazo máximo de seis meses para adecuar sus sistemas de información a la estructura, el formato y los requisitos técnicos del anexo. Ese plazo se cumplió durante el primer semestre de 2026. Si tu clínica no ha empezado, no estás yendo temprano ni justo a tiempo: vas tarde, y conviene saberlo con ese nombre.

Es la primera pregunta que hace todo el mundo, y la respuesta es que sí. La obligación recae sobre los prestadores de servicios de salud, y una clínica odontológica, un consultorio de un solo profesional o un centro de especialidades lo son. No hay una excepción por tamaño: no existe el umbral de «somos muy pequeños para esto».

La norma define cuatro tipos de RDA, y para odontología ambulatoria importa uno:

Salvo que atiendas urgencias odontológicas dentro de una institución hospitalaria, el que te ocupa es el RDA de consulta externa.

El intercambio se hace bajo el estándar internacional HL7 FHIR R4. En concreto, un RDA es un Bundle de tipo «document» cuyo recurso raíz es un Composition —el perfil se llama CompositionAmbulatoryRDA para consulta externa—, acompañado del paciente, el encuentro, los recursos clínicos de cada sección y los de contexto: el profesional, la organización y el rol del profesional en ella.

Dentro del Composition son obligatorios el tipo, el estado, el sujeto (el paciente), el encuentro, el autor y las secciones. Y las secciones definidas son nueve:

• Pagadores — la EAPB, o el régimen particular
• Otros datos demográficos
• Incapacidad
• Medicamentos
• Alergias e intolerancias
• Diagnósticos
• Factores de riesgo
• Órdenes de servicio
• Documentos soporte

Un detalle que cuesta caro descubrir tarde: que una sección sea obligatoria no significa que tenga que llevar contenido, significa que tiene que estar. Una consulta odontológica normal no tiene incapacidad ni medicamentos, y aun así esas secciones van en el documento, declarando por qué están vacías. No es lo mismo «no se preguntó» que «se preguntó y no hay»: son motivos distintos y el documento los distingue.

Este es el punto que cambia el plan de trabajo de cualquiera, y no aparece en casi ningún artículo sobre la 1888: puedes leer la resolución entera, y el anexo entero, y seguir sin saber qué valida el Ministerio.

El propio Anexo Técnico lo dice: las reglas de validación obligatorias viven en la guía de implementación, publicada aparte, en vulcano.ihcecol.gov.co/guia/. El anexo entrega el diccionario de datos —qué significa cada elemento y cuáles son opcionales— pero la cardinalidad completa, es decir qué campo es realmente obligatorio y cuántas veces puede aparecer, la define la guía.

La consecuencia práctica es incómoda pero simple: el cumplimiento es contra un documento técnico vivo, no contra un texto normativo estable. Un proveedor que te diga «ya cumplimos la 1888» y no pueda decirte contra qué versión de la guía validó, no te está respondiendo la pregunta.

Cuando un RDA pasa todas las reglas de validación obligatorias, la plataforma devuelve el VIDA: el Validador Individual de Atención, una cadena alfanumérica cifrada que certifica la recepción y la validación de ese registro. El mecanismo lo incluye en la respuesta de los RDA de hospitalización, urgencias y consulta ambulatoria aceptados.

Si tu sistema no guarda el VIDA, tu clínica no puede demostrar que cumplió con esa atención. Enviar y no conservar el acuse es, a efectos de prueba, casi lo mismo que no haber enviado.

Es una pregunta concreta y muy buena para hacerle a cualquier proveedor: ¿dónde queda guardado el VIDA de cada atención, y cómo lo consulto dentro de tres años?

Acá es donde se cae la mayoría de los proyectos, y no por razones técnicas. La estructura de un RDA se programa; los datos que la llenan los tiene que tener la clínica, y casi nunca están completos:

1. 1El código REPS de cada sede habilitada. Va en el documento como identificación del prestador; sin él, el envío no identifica quién atendió.
2. 2El registro profesional de cada odontólogo, con su número RETHUS y su número de la Seguridad Social. Un profesional sin registro cargado deja sin autor todas sus atenciones.
3. 3CUPS vigente para los procedimientos. Es un catálogo dinámico: la versión oficial para 2026 es la Resolución 2706 de 2025, y un sistema serio guarda de qué resolución salió, desde cuándo rige y de dónde se descargó.
4. 4CIE-10 real para los diagnósticos. Y una advertencia concreta acá abajo.
5. 5Datos del paciente completos: tipo y número de documento, fecha de nacimiento, sexo, y su pagador o su condición de particular.

Sobre el CIE-10: la lista que viene publicada dentro de la propia guía de implementación no sirve para odontología. Son unos 395 códigos, todos del capítulo A —enfermedades infecciosas— y no trae un solo código K, que es donde viven las enfermedades de la cavidad oral. Es coherente con que esa compilación esté en estado de borrador, pero si alguien la siembra tal cual en tu software, no vas a poder codificar ni una caries. La fuente que sirve es la tabla de referencia básica del Ministerio en SISPRO.

Hay además una consecuencia que conviene decirle a la clínica antes y no después: las atenciones que se cerraron cuando la sede todavía no tenía su código REPS cargado, o el profesional su registro, no se pueden exportar al RDA más tarde. No es un problema de software. El documento tiene que decir quién atendió y dónde, y ese dato no existía cuando se cerró la historia.

El anexo fija lineamientos técnicos obligatorios de seguridad para todo el intercambio, en cumplimiento de la Ley Estatutaria 1581 de 2012. El más concreto y el más fácil de verificar: todas las comunicaciones van sobre HTTPS con cifrado TLS versión 1.3 o superior.

Vale la pena leerlo junto con el resto de tus obligaciones de habeas data. Un RDA mueve datos sensibles de salud, y la autorización del paciente, la política de tratamiento y —si tu software guarda en el exterior— la autorización de transferencia internacional no dejan de aplicar porque el envío sea a una plataforma del Estado.

La 1888 no quedó congelada. La Resolución 1799 de 2026 la modificó en lo relativo a la dispensación de medicamentos, y el mecanismo nacional entró en operación durante 2026. Para una clínica odontológica el cambio de fondo es poco, pero sirve para dimensionar el asunto: esto es una norma con cronograma y con ajustes, no un documento que se lee una vez.

El Ministerio publica el cronograma de implementación y los recursos técnicos en su micrositio de IHCE, y tiene mesa de ayuda con un buzón distinto según el tema. Si algo no aparece publicado, ese es el camino: escribir, no suponer.

1. 1Verifica que cada sede tenga su código REPS a la mano y cargado en tu sistema, no en un PDF en una carpeta.
2. 2Pídele a cada odontólogo su número RETHUS y el de la Seguridad Social, y cárgalos en su ficha.
3. 3Revisa si tus servicios están asociados a un código CUPS o si son texto libre. Si son texto libre, ese es tu trabajo más largo.
4. 4Revisa si tus diagnósticos guardan el sistema y el código, o solo una descripción escrita a mano.
5. 5Pregúntale a tu proveedor de software tres cosas concretas: contra qué versión de la guía de implementación valida, dónde guarda el VIDA, y si hoy transmite de verdad o solo prepara el documento.

Los primeros cuatro puntos son trabajo de la clínica y no dependen de ningún software. Se pueden empezar hoy, y son los que más tiempo toman.

HIZCAO es el sistema odontológico que construimos en Zcalaris, así que es justo decir dónde está parado, sobre todo porque casi toda la información disponible sobre la 1888 la publican proveedores que cierran diciendo que ya cumplen.

Hoy HIZCAO compone el RDA de consulta externa en FHIR R4 a partir de la historia real, y lo valida antes de dejarlo salir: revisa el sobre, que cada referencia resuelva, los perfiles, las nueve secciones y los recursos. La transmisión al mecanismo nacional no está activa: hay una consulta radicada ante el Ministerio sobre el esquema de firma exigido, y no vamos a adivinar esa respuesta para poder decir antes que cumplimos.

Preferimos que esto se lea así, con la fecha encima, a escribir «cumple la Resolución 1888» y que un cliente lo descubra el día que lo necesite. Cuando la transmisión esté en producción, se va a decir acá mismo.

Si estás montando esto en tu clínica y quieres una segunda opinión sobre por dónde empezar —aunque termines con otro software— escríbenos y te decimos qué haríamos en tu caso.