El Vibe Coding está cambiando la manera en que muchas personas desarrollan software. En lugar de escribir cada línea de código, el desarrollador describe lo que necesita, conversa con un modelo de inteligencia artificial, revisa el resultado, corrige el rumbo y repite. La IA deja de ser un asistente que completa código y pasa a participar en decisiones de diseño, implementación, documentación y pruebas.
Algo similar está comenzando a ocurrir en el mundo de HL7 FHIR. Podríamos llamarlo FHIR Vibe Profiling.
El perfilador describe un caso de uso y la IA propone recursos. Le entrega un formulario y obtiene un primer StructureDefinition. Pide restricciones y recibe FSH. Pide una terminología y obtiene un ValueSet. Puede generar ejemplos, invariantes FHIRPath, un CapabilityStatement, documentación narrativa, diagramas, casos de prueba e incluso buena parte de una guía de implementación.
Hace pocos años, producir todos esos artefactos requería largos tiempos de trabajo especializado. Hoy un primer borrador se obtiene en tiempos mucho más cortos.
La pregunta interesante ya no es si utilizaremos inteligencia artificial para desarrollar guías de implementación. La pregunta es cómo cambia el trabajo del perfilador cuando construir se vuelve tan fácil.
Del Vibe Coding al Vibe Profiling
En Vibe Coding la dinámica es relativamente sencilla: describir → generar → ejecutar → observar → corregir. Si el programa no compila, falla una prueba o no hace lo esperado, existe un mecanismo inmediato para descubrirlo.
En profiling FHIR podemos empezar de manera parecida: describir → generar → validar → corregir.
Podemos pedir:
"Créame un perfil R5 de DiagnosticReport para un informe de mamografía."
Y probablemente obtendremos algo técnicamente razonable. Puede compilar perfectamente con SUSHI. Puede pasar el validator de FHIR. Puede tener cardinalidades aparentemente sensatas, bindings terminológicos, elementos Must Support y ejemplos completamente válidos.
Y aun así estar completamente equivocado.
Ese es el problema fundamental del Vibe Profiling. En software, que algo ejecute correctamente proporciona al menos evidencia de que cierta intención se materializó. En interoperabilidad, que un recurso sea válido solo demuestra que cumple un conjunto de reglas técnicas.
No demuestra que esas reglas representen correctamente el proceso clínico. No demuestra que dos organizaciones interpreten el intercambio de la misma manera. No demuestra que hayamos identificado bien a los actores. No demuestra que el perfil resuelva el caso de uso.
Y definitivamente no demuestra que la guía produzca interoperabilidad.
La IA sabe muchísimo de FHIR
Los modelos actuales pueden ser sorprendentemente buenos trabajando con FHIR. Explican recursos, proponen mappings, generan FSH, escriben FHIRPath, comparan alternativas de modelado, sugieren códigos terminológicos, construyen instancias de ejemplo y ayudan a interpretar partes complejas de la especificación.
Esto tiene un enorme valor. Una IA puede funcionar como una especie de copiloto del perfilador.
Podemos usarla para explorar alternativas:
¿Es mejor representar esto medianteObservationo mediante un componente deDiagnosticReport?
Para cuestionar nuestras decisiones:
Dame argumentos a favor y en contra de hacer este elemento obligatorio.
Para detectar inconsistencias:
Compara estos tres perfiles y dime si existen restricciones incompatibles.
O para el trabajo repetitivo:
Genera diez ejemplos válidos de este perfil que cubran distintos escenarios de identificación del paciente.
Todo esto reduce enormemente el esfuerzo mecánico del profiling. Pero precisamente porque la capacidad de generación aumenta, también cambia dónde está el verdadero valor del perfilador.
Saber FHIR ya no es suficiente
Durante mucho tiempo, buena parte del valor de un perfilador provenía de saber construir los artefactos: cómo hacer slicing, definir bindings, escribir invariantes, declarar extensiones, manejar referencias, usar FSH o estructurar un StructureDefinition.
La IA está reduciendo rápidamente el costo de ese conocimiento operativo. Eso no significa que deje de ser necesario. Significa que el perfilador puede dedicar cada vez menos tiempo a escribir el artefacto y más tiempo a decidir qué artefacto debería existir y por qué.
Y ahí aparece una transformación importante del rol. El perfilador del futuro necesitará comprender mucho más profundamente:
- los casos de uso;
- los actores participantes;
- las transacciones entre esos actores;
- los procesos clínicos;
- los escenarios normales y excepcionales;
- la semántica de la información;
- las obligaciones de productores y consumidores;
- y las consecuencias que cada decisión de profiling produce en implementaciones reales.
Paradójicamente, cuanto mejor sea la IA generando FHIR, más importante será entender todo aquello que ocurre antes de escribir FHIR.
El peligro del perfil plausible
Los modelos generativos son extraordinariamente buenos produciendo resultados plausibles. Eso puede convertirse en uno de los mayores riesgos del Vibe Profiling.
Supongamos que pedimos:
"Genera un perfil FHIR para interoperar informes de imágenes médicas."
La IA probablemente encontrará DiagnosticReport. Añadirá ImagingStudy. Tal vez incluya ServiceRequest. Recomendará Observation. Creará cardinalidades, marcará elementos Must Support y añadirá terminologías. Todo parecerá razonable.
Pero ¿quién genera el informe? ¿Quién mantiene las imágenes? ¿Quién consume la información? ¿Existe siempre una orden? ¿Puede existir el informe sin imágenes accesibles? ¿El consumidor necesita recuperar el estudio o únicamente el informe? ¿Debe recibir una representación narrativa? ¿Debe poder reconstruir el documento que vio el profesional? ¿Estamos diseñando intercambio documental, acceso a recursos clínicos o ambos?
Si estas preguntas no se resolvieron primero, la IA está haciendo algo peligroso: está tomando decisiones de arquitectura e interoperabilidad de manera implícita.
Y como el resultado parece técnicamente correcto, esas decisiones pueden pasar inadvertidas.
A eso se suma un riesgo más terrenal: la IA también puede inventar un código SNOMED CT que no existe, proponer un elemento de R5 en un perfil R4 o citar una extensión que nunca se publicó. Cada artefacto generado sigue necesitando verificación contra la especificación y los servidores terminológicos reales.
Compilar no es interoperar
Aquí hay una diferencia fundamental entre Vibe Coding y Vibe Profiling. En Vibe Coding podemos ejecutar un programa. En FHIR podemos validar una instancia contra un perfil. Pero la interoperabilidad solo aparece cuando otro actor puede utilizar esa información correctamente dentro de un escenario real.
Por eso, el equivalente a un test de software no debería ser únicamente:
¿El recurso valida contra el StructureDefinition?
También debería ser:
¿Puede el actor A ejecutar la interacción definida con el actor B utilizando estos artefactos y obtener el resultado esperado?
El cambio parece pequeño, pero transforma por completo la manera en que deberíamos usar IA durante el profiling. La unidad de trabajo deja de ser el recurso. La unidad de trabajo pasa a ser el escenario de interoperabilidad.
Prompting desde el caso de uso
Un mal patrón de Vibe Profiling sería empezar diciendo:
"Créame un perfil de Patient para Costa Rica."
La IA inmediatamente comenzará a inventar decisiones.
Un enfoque mucho más robusto sería darle contexto primero:
Tenemos un actor Registro de Pacientes y un actor Consumidor de Identidades. El consumidor necesita localizar a una persona usando determinados identificadores nacionales. Estos son los escenarios de identificación, estas son las fuentes de datos disponibles, estas son las reglas cuando existen múltiples coincidencias y estas son las transacciones utilizadas.
Y solo después preguntar:
¿Qué restricciones FHIR se derivan de estos requisitos?
La diferencia es enorme. En el primer caso, la IA está diseñando el problema. En el segundo, está ayudándonos a materializar decisiones de interoperabilidad previamente comprendidas.
Esta es probablemente una de las reglas principales del Vibe Profiling: no pedirle primero a la IA que genere perfiles; pedirle primero que comprenda el escenario.
La IA como participante de la mesa de profiling
También podemos pensar la inteligencia artificial de otra manera: no como la herramienta que produce el perfil, sino como un participante adicional de la mesa de trabajo.
Durante una sesión de profiling podría usarse para preguntar:
- ¿Qué escenario no estamos considerando?
- ¿Qué ocurre si este dato no existe?
- ¿Qué interpretación podría hacer un implementador diferente de esta regla?
- ¿Esta cardinalidad realmente se deriva del caso de uso?
- ¿Estamos confundiendo obligatoriedad del dato con obligación del actor?
- ¿Hay alguna contradicción entre este ejemplo y el texto narrativo?
- ¿Qué artefactos FHIR están involucrados en este escenario?
- ¿Qué debería probar un test de conformidad?
Ese tipo de preguntas puede resultar incluso más valioso que pedirle generar el FSH. La IA se convierte así en una especie de revisor permanente del diseño.
No sustituye a los expertos clínicos, terminólogos, arquitectos, implementadores ni perfiladores. Pero puede amplificar enormemente su capacidad para explorar el espacio de decisiones.
El perfilador pasa de constructor a director
Vibe Coding está generando una discusión interesante sobre el papel del desarrollador. Algo similar ocurrirá con los perfiladores.
Si una IA puede producir buena parte de un StructureDefinition, el trabajo humano se desplaza hacia actividades de mayor nivel. El perfilador se convierte cada vez más en el director del proceso de modelado:
- proporciona contexto y delimita el problema;
- reconoce cuándo una respuesta es plausible pero incorrecta;
- conoce los estándares lo suficiente para cuestionar a la IA;
- reconcilia necesidades clínicas con capacidades técnicas;
- decide cuándo usar un recurso existente y cuándo introducir una extensión;
- identifica cuándo el problema no se resuelve con profiling;
- y, sobre todo, mantiene la coherencia entre caso de uso, actores, transacciones, requisitos y artefactos publicados.
La IA puede construir muy rápido. Pero alguien tiene que saber qué estamos construyendo.
De prompt engineering a context engineering
Probablemente el Vibe Profiling tampoco dependerá tanto de escribir "buenos prompts". Dependerá de proporcionar buen contexto.
Una IA que solo tiene acceso al recurso base puede generar un perfil. Una IA que además tiene acceso a los casos de uso, las minutas de las mesas técnicas, las decisiones arquitectónicas, las terminologías nacionales, otros perfiles existentes, los requisitos regulatorios, los diagramas de secuencia, ejemplos reales, actores, transacciones, pruebas de conformidad y versiones anteriores de la guía, se convierte en una herramienta muchísimo más poderosa.
Por eso el futuro del profiling asistido por IA quizás no sea simplemente "generar FSH con un chatbot". Será construir entornos donde la IA tenga suficiente contexto para comprender la intención de la guía de implementación.
El humano en el ciclo no es opcional
En este escenario existe una tentación evidente. Si la IA genera el perfil, SUSHI lo compila y el validator no reporta errores, ¿por qué no publicarlo?
Porque ninguno de esos tres actores entiende por sí solo el sistema de salud que estamos tratando de representar. La IA puede ayudarnos a encontrar inconsistencias. SUSHI verifica la sintaxis. El validator verifica conformidad. Pero la decisión de que un modelo representa correctamente una realidad clínica, regulatoria y operacional sigue necesitando gobernanza humana.
Esto es particularmente importante en salud. Un error en una aplicación tradicional produce una mala experiencia de usuario. Un error semántico en interoperabilidad puede propagarse entre múltiples organizaciones y permanecer durante años como parte de un estándar nacional.
La capacidad de generar perfiles rápidamente debe venir acompañada de una capacidad igualmente fuerte para revisarlos, cuestionarlos y probarlos.
Una posible disciplina para el Vibe Profiling
Podríamos imaginar el proceso de la siguiente manera:
- Humano: define el problema y los actores.
- Humano + IA: exploran escenarios y requisitos.
- IA: propone alternativas de modelado.
- Humano: selecciona y justifica decisiones.
- IA: genera perfiles, terminología, ejemplos y documentación.
- Herramientas: compilan y validan los artefactos.
- IA: revisa inconsistencias entre artefactos.
- Implementadores: prueban los escenarios reales.
- Humano: acepta, rechaza o modifica el diseño.
Y el ciclo comienza de nuevo.
Es decir, el Vibe Profiling no debería ser prompt → perfil → publicar. Debería parecerse mucho más a:
contexto → escenarios → requisitos → propuesta → crítica → artefactos → validación → implementación → retroalimentación.
La IA participa en prácticamente todas las etapas. Pero no es propietaria de ninguna decisión.
El profiling será más rápido. Pensar seguirá siendo difícil.
La inteligencia artificial probablemente permitirá que en los próximos años produzcamos guías de implementación mucho más rápido. Generar ejemplos dejará de ser tedioso. Crear documentación será más sencillo. Mantener perfiles derivados podrá automatizarse en parte. Las pruebas podrán generarse desde los requisitos. Las inconsistencias podrán detectarse automáticamente. Podremos explorar varias alternativas de modelado antes de escoger una.
Todo eso representa una enorme oportunidad para comunidades FHIR pequeñas, proyectos nacionales y organizaciones que hoy enfrentan una barrera importante de conocimiento especializado.
Pero existe también una paradoja. Cuando construir los artefactos se vuelve fácil, las malas decisiones también se vuelven fáciles de implementar.
Podemos generar diez perfiles incorrectos en el tiempo que antes tardábamos en producir uno. Podemos documentarlos perfectamente, generar ejemplos convincentes y crear diagramas hermosos. Incluso podemos producir una guía que parezca extraordinariamente madura. Y aun así haber modelado mal el problema.
Por eso el principal conocimiento del perfilador en la era de la IA probablemente no será recordar cada elemento de cada recurso FHIR. Será saber qué preguntar. Saber qué información falta. Saber cuándo una respuesta aparentemente correcta no tiene suficiente contexto. Saber separar requisitos clínicos, funcionales, semánticos y técnicos. Saber comprender actores y transacciones. Y saber convertir decisiones humanas en contratos computables que otros puedan implementar.
Eso es FHIR Vibe Profiling
El Vibe Profiling no consiste en pedirle a una IA que cree perfiles por nosotros. Consiste en incorporar la IA profundamente al proceso de diseño de interoperabilidad: para explorar, cuestionar, generar, revisar, documentar y probar. Y, sobre todo, para reducir el tiempo que dedicamos a tareas mecánicas y aumentar el tiempo disponible para entender el problema.
La IA puede conocer prácticamente toda la especificación de FHIR. Puede generar un StructureDefinition mucho más rápido que nosotros. Puede escribir FSH, FHIRPath y ejemplos con gran rapidez. Pero todavía necesita que alguien le proporcione algo fundamental: el contexto de lo que estamos intentando interoperar.
Quizás ahí esté la verdadera definición de HL7 FHIR Vibe Profiling:
Dejar que la IA acelere la construcción de la guía, sin permitir que sustituya la comprensión que debe existir detrás de ella.
Porque en interoperabilidad, generar artefactos nunca fue realmente el problema más difícil. El problema siempre fue lograr que diferentes sistemas, organizaciones y personas entendieran lo mismo.
Y ninguna cantidad de código —generado por humanos o por inteligencia artificial— puede reemplazar esa decisión.