Brasil puede liderar la salud digital. El camino empieza por los datos.
Estados Unidos estandarizó cómo los sistemas intercambian un conjunto mínimo de datos. Brasil tiene la oportunidad de ir más allá: registrar cada observación clínica de forma estructurada, con la regla de la que proviene, y formar la base de datos que necesita la inteligencia artificial en salud.
Hable con nuestro equipo Vea los protocolos en la historia clínicaPor qué Brasil, y por qué ahora
Un sistema público para más de 200 millones de personas
El SUS es el mayor sistema público universal de salud del mundo, con atención primaria, especialidades, hospitales, vacunas y vigilancia bajo las mismas reglas nacionales.
FHIR para intercambiar, un estándar brasileño para registrar
La RNDS ya adopta el estándar abierto HL7 FHIR para el intercambio de datos, con perfiles definidos por Brasil. Lo que todavía falta es un estándar brasileño para el contenido clínico: lo que registra cada atención. En Estados Unidos, esa decisión es del gobierno estadounidense, mediante el USCDI. Brasil puede definir el suyo, con los protocolos del SUS y más profundidad.
Hay recursos y una estrategia
El Plan Brasileño de Inteligencia Artificial prevé hasta R$ 23 mil millones hasta 2028, con acciones para el SUS. Lo que falta son datos clínicos estructurados y confiables para que esos proyectos funcionen fuera del laboratorio.
Lo que construyó Estados Unidos
Desde la ley 21st Century Cures de 2016, Estados Unidos obliga a los sistemas de historia clínica certificados a abrir sus datos por una API estandarizada. El resultado es la mayor experiencia de intercambio de datos de salud del mundo, y enseña mucho.
Criterio (g)(10) de la ONC
Para certificarse, un sistema debe ofrecer una API FHIR R4 con el perfil US Core, acceso de aplicaciones mediante SMART on FHIR y exportación masiva de datos de grupos de pacientes.
USCDI: el conjunto mínimo
El USCDI define qué clases de datos debe exponer la API, como alergias, problemas, medicamentos, signos vitales y resultados de exámenes. La versión 3 entró en vigor el 1 de enero de 2026.
Inferno y la CHPL
Inferno es la herramienta oficial para probar la API. Los productos aprobados entran en la lista pública de sistemas certificados (CHPL), que hospitales y gobiernos consultan antes de comprar.
TEFCA: la red nacional
Una red de redes conecta los sistemas certificados. En 2026, el gobierno estadounidense informó más de mil millones de registros de salud intercambiados por ella.
La lección: Estados Unidos decidió qué se registra en todo el país, y esa decisión se quedó en el conjunto mínimo. Brasil debe decidir el suyo, y puede hacerlo con más profundidad: qué preguntas responde el médico, por qué y con qué regla.
El mínimo para intercambiar datos, y el registro completo para cuidar
AENTE entrega los datos en FHIR, como pide el estándar. La diferencia está en lo que existe antes del intercambio: cómo nace cada dato dentro de la atención.
| Tema | Estándar (g)(10) y USCDI | AENTE |
|---|---|---|
| Formato del intercambio | API FHIR R4, US Core, SMART on FHIR y exportación masiva. | Una API FHIR R4 certificada en el programa de la ONC a través de Drummond Group, y documentos del CMD generados en los perfiles brasileños de la RNDS. |
| Modelo de gestión | Fuera del estándar: cada sistema organiza unidades, profesionales y pacientes a su manera. | Una cuenta por organización, unidades creadas desde el CNES, una identidad para cada paciente y profesional en cualquier unidad, y reglas que siguen a la unidad y al país. Tecnología con patente en trámite. |
| Profundidad | Un conjunto mínimo de clases de datos, igual para todos. | Cada pregunta de la historia clínica es un ítem estructurado, con tipo de respuesta y opciones definidos, para cada procedimiento. |
| Origen de la pregunta | No forma parte del estándar. | Cada pregunta indica la norma, protocolo o guía de la que proviene, y los médicos revisan el formulario antes de usarlo. |
| Contexto de la atención | Depende de cómo registra cada sistema. | El dato queda vinculado al procedimiento, al diagnóstico (CIE-10), al profesional, a la unidad (CNES) y a quien paga. |
| Completitud | El estándar no exige campos clínicos más allá del mínimo. | Las preguntas obligatorias deben responderse antes de finalizar la atención. |
| Reglas nacionales | Terminologías estadounidenses. | CIE-10, SIGTAP, TUSS, CNES y los protocolos del Ministerio de Salud (PCDT) dentro del flujo de atención. |
Formularios que se convierten en un diccionario nacional
En la historia clínica de AENTE, el registro se arma con dos piezas. Los ítems de formulario son las preguntas y medidas, como la presión arterial, el uso de anticoagulantes o la escala de preparación intestinal. Las categorías de formulario agrupan esos ítems en pestañas y secciones y vinculan el conjunto a procedimientos y diagnósticos.
- Cada ítem se crea una vez y se reutiliza en todos los formularios que lo necesitan. La misma pregunta significa lo mismo en cualquier unidad.
- Cada ítem tiene un tipo de respuesta definido, como número, fecha, opción única o múltiple, y opciones cerradas cuando el protocolo lo exige.
- Las categorías están vinculadas al procedimiento y al diagnóstico. Al registrar el CIE-10, el formulario del protocolo del Ministerio aparece listo.
- Todo se configura sin programar, por el equipo clínico, y los cambios quedan registrados.
Por qué esto importa para la inteligencia artificial
Los modelos de IA en salud dependen menos de algoritmos nuevos y más de datos bien definidos. El texto libre cambia de médico a médico y de hospital a hospital. Los ítems estructurados crean un vocabulario común.
Un diccionario de observaciones
Cada ítem de formulario es una variable con nombre, tipo y valores posibles. Sumados a escala nacional, forman un diccionario de observaciones clínicas que los modelos pueden leer sin adivinar lo que quiso decir el médico.
Observación vinculada al tratamiento
Como el registro queda vinculado al diagnóstico, al procedimiento y a lo que se hizo después, es posible estudiar qué conductas acompañan qué hallazgos, y con qué resultados a lo largo del tiempo.
Rastro del origen
Saber de qué protocolo vino cada pregunta ayuda a explicar lo que aprendió un modelo, y a corregirlo cuando un protocolo cambia.
Datos completos desde el origen
Las preguntas obligatorias reducen los vacíos que hoy vuelven inútil buena parte de los datos clínicos para investigación y entrenamiento.
Entrenar modelos con datos de salud exige base legal, anonimización y gobernanza, como manda la ley brasileña de protección de datos (LGPD). La propuesta es que esto ocurra bajo reglas públicas, con datos anonimizados y con el Estado coordinando. AENTE no vende datos de pacientes.
Lo que ya está construido
- Una API FHIR R4 certificada en el programa de certificación de la ONC de Estados Unidos, con pruebas de Drummond Group: perfil US Core, SMART on FHIR, permisos detallados y exportación masiva.
- Documentos del Conjunto Mínimo de Datos (CMD) generados en los perfiles FHIR de la RNDS para cada atención finalizada. El envío a la RNDS depende de la acreditación.
- Formularios de protocolo (PCDT) que aparecen a partir del CIE-10, con el término de consentimiento del paciente listo.
- Un catálogo nacional con más de 300 modelos de servicio, con códigos SIGTAP y TUSS, y registro de las unidades desde el CNES.
- Facturación del SUS y de planes de salud a partir del mismo registro clínico.
- Tecnología con patente en trámite para la gestión de salud con flujos configurables y reglas por país.
Cómo puede participar el gobierno
La propuesta es tratar el diccionario de formularios como infraestructura pública, y probar el modelo a escala real antes de ampliarlo.
1. Un piloto en una red estatal o municipal
Una secretaría usa AENTE en un conjunto de unidades, con metas de completitud de los registros y de generación del CMD definidas antes del inicio.
2. Un estándar brasileño de contenido clínico
El Ministerio, las sociedades médicas y las universidades revisan los ítems de formulario de los protocolos prioritarios. El resultado es un estándar brasileño de contenido clínico, construido a partir del modelo de AENTE y abierto a cualquier sistema.
3. Datos para la IA del SUS
Los datos anonimizados del piloto alimentan proyectos de IA del propio SUS, dentro de la LGPD y de la gobernanza definida por el gobierno.
El contenido de los protocolos públicos queda abierto como bien público. La plataforma que transforma ese contenido en atención, facturación y datos estructurados es de AENTE, y los datos siempre salen en el estándar FHIR de la RNDS, sin dependencia de proveedor. Para el piloto, los instrumentos que la ley prevé para soluciones innovadoras son el Contrato Público para Solución Innovadora (Ley Complementaria 182/2021) y la encomienda tecnológica (Ley 10.973/2004), además de convocatorias de fomento vinculadas al Plan Brasileño de Inteligencia Artificial. La elección corresponde a cada órgano.
Preguntas frecuentes
¿AENTE reemplaza al e-SUS o a la RNDS?
No. AENTE genera los documentos en el estándar de la RNDS y alimenta la red nacional. El objetivo es que lleguen más datos de calidad al Ministerio, no crear un sistema paralelo.
¿AENTE está certificada en Estados Unidos? ¿Y en la RNDS?
Sí, en Estados Unidos: la API FHIR de AENTE recibió la certificación del programa de la ONC, con pruebas realizadas por Drummond Group. En la RNDS, AENTE ya genera los documentos del CMD en los perfiles oficiales, y el envío depende de la acreditación y de un certificado digital de la empresa, etapas que forman parte del piloto.
¿De quién es el diccionario de formularios?
La propuesta es que los ítems de los protocolos públicos sean un bien público, revisado por el Ministerio y por especialistas y disponible para cualquier sistema.
¿AENTE entrena IA con datos de pacientes?
No. Cualquier uso de datos para entrenar modelos debe seguir la LGPD, con anonimización y con reglas definidas por el poder público.
¿Dónde quedan los datos?
En servidores de AENTE, con acceso por perfil y registro de auditoría de los cambios. En un piloto público, el lugar de alojamiento se define con el órgano.
Construyamos juntos este estándar.
Presentamos la plataforma a su equipo técnico, con los formularios de protocolo, la API FHIR y los documentos del CMD funcionando, y diseñamos un piloto con metas claras.