HL7 FHIR Vibe Profiling: quando a IA entra no design de guias de implementação

O Vibe Coding está mudando a forma como muitas pessoas desenvolvem software. Em vez de escrever cada linha de código, o desenvolvedor descreve o que precisa, conversa com um modelo de inteligência artificial, revisa o resultado, corrige o rumo e repete. A IA deixa de ser uma assistente que completa código e passa a participar de decisões de design, implementação, documentação e testes.

Algo parecido está começando a acontecer no mundo do HL7 FHIR. Poderíamos chamá-lo de FHIR Vibe Profiling.

O perfilador descreve um caso de uso e a IA propõe recursos. Entrega um formulário e obtém um primeiro StructureDefinition. Pede restrições e recebe FSH. Pede uma terminologia e obtém um ValueSet. Ela pode gerar exemplos, invariantes FHIRPath, um CapabilityStatement, documentação narrativa, diagramas, casos de teste e até boa parte de um guia de implementação.

Há poucos anos, produzir todos esses artefatos exigia longos tempos de trabalho especializado. Hoje um primeiro rascunho sai em tempos muito mais curtos.

A pergunta interessante já não é se usaremos inteligência artificial para desenvolver guias de implementação. A pergunta é como muda o trabalho do perfilador quando construir se torna tão fácil.

Do Vibe Coding ao Vibe Profiling

No Vibe Coding a dinâmica é relativamente simples: descrever → gerar → executar → observar → corrigir. Se o programa não compila, um teste falha ou ele não faz o esperado, existe um mecanismo imediato para descobrir.

No profiling FHIR podemos começar de forma parecida: descrever → gerar → validar → corrigir.

Podemos pedir:

"Crie um perfil R5 de DiagnosticReport para um laudo de mamografia."

E provavelmente obteremos algo tecnicamente razoável. Pode compilar perfeitamente com o SUSHI. Pode passar no validator do FHIR. Pode ter cardinalidades aparentemente sensatas, bindings terminológicos, elementos Must Support e exemplos totalmente válidos.

E ainda assim estar completamente errado.

Esse é o problema fundamental do Vibe Profiling. Em software, o fato de algo executar corretamente fornece ao menos evidência de que certa intenção se materializou. Em interoperabilidade, um recurso ser válido só demonstra que ele cumpre um conjunto de regras técnicas.

Não demonstra que essas regras representem corretamente o processo clínico. Não demonstra que duas organizações interpretem a troca da mesma maneira. Não demonstra que identificamos bem os atores. Não demonstra que o perfil resolva o caso de uso.

E definitivamente não demonstra que o guia produza interoperabilidade.

A IA sabe muito sobre FHIR

Os modelos atuais podem ser surpreendentemente bons trabalhando com FHIR. Explicam recursos, propõem mapeamentos, geram FSH, escrevem FHIRPath, comparam alternativas de modelagem, sugerem códigos terminológicos, constroem instâncias de exemplo e ajudam a interpretar partes complexas da especificação.

Isso tem um valor enorme. Uma IA pode funcionar como uma espécie de copiloto do perfilador.

Podemos usá-la para explorar alternativas:

É melhor representar isto com uma Observation ou com um componente de DiagnosticReport?

Para questionar nossas decisões:

Dê-me argumentos a favor e contra tornar este elemento obrigatório.

Para detectar inconsistências:

Compare estes três perfis e diga se existem restrições incompatíveis.

Ou para o trabalho repetitivo:

Gere dez exemplos válidos deste perfil que cubram diferentes cenários de identificação do paciente.

Tudo isso reduz enormemente o esforço mecânico do profiling. Mas justamente porque a capacidade de geração aumenta, também muda onde está o verdadeiro valor do perfilador.

Saber FHIR já não basta

Durante muito tempo, boa parte do valor de um perfilador vinha de saber construir os artefatos: como fazer slicing, definir bindings, escrever invariantes, declarar extensões, lidar com referências, usar FSH ou estruturar um StructureDefinition.

A IA está reduzindo rapidamente o custo desse conhecimento operacional. Isso não significa que ele deixe de ser necessário. Significa que o perfilador pode dedicar cada vez menos tempo a escrever o artefato e mais tempo a decidir qual artefato deveria existir e por quê.

E aí surge uma transformação importante do papel. O perfilador do futuro precisará compreender muito mais profundamente:

• os casos de uso;
• os atores participantes;
• as transações entre esses atores;
• os processos clínicos;
• os cenários normais e excepcionais;
• a semântica da informação;
• as obrigações de produtores e consumidores;
• e as consequências que cada decisão de profiling produz em implementações reais.

Paradoxalmente, quanto melhor a IA for gerando FHIR, mais importante será entender tudo o que acontece antes de escrever FHIR.

O perigo do perfil plausível

Os modelos generativos são extraordinariamente bons em produzir resultados plausíveis. Isso pode se tornar um dos maiores riscos do Vibe Profiling.

Suponhamos que pedimos:

"Gere um perfil FHIR para interoperar laudos de imagens médicas."

A IA provavelmente encontrará DiagnosticReport. Adicionará ImagingStudy. Talvez inclua ServiceRequest. Recomendará Observation. Criará cardinalidades, marcará elementos Must Support e adicionará terminologias. Tudo parecerá razoável.

Mas quem gera o laudo? Quem mantém as imagens? Quem consome a informação? Sempre existe um pedido? O laudo pode existir sem imagens acessíveis? O consumidor precisa recuperar o estudo ou apenas o laudo? Deve receber uma representação narrativa? Deve poder reconstruir o documento que o profissional viu? Estamos projetando troca de documentos, acesso a recursos clínicos ou ambos?

Se essas perguntas não foram respondidas antes, a IA está fazendo algo perigoso: está tomando decisões de arquitetura e interoperabilidade de forma implícita.

E como o resultado parece tecnicamente correto, essas decisões podem passar despercebidas.

A isso se soma um risco mais terreno: a IA também pode inventar um código SNOMED CT que não existe, propor um elemento do R5 em um perfil R4 ou citar uma extensão que nunca foi publicada. Cada artefato gerado continua precisando ser verificado contra a especificação e os servidores de terminologia reais.

Compilar não é interoperar

Aqui há uma diferença fundamental entre Vibe Coding e Vibe Profiling. No Vibe Coding podemos executar um programa. No FHIR podemos validar uma instância contra um perfil. Mas a interoperabilidade só aparece quando outro ator consegue usar essa informação corretamente dentro de um cenário real.

Por isso, o equivalente a um teste de software não deveria ser apenas:

O recurso é válido contra o StructureDefinition?

Também deveria ser:

O ator A consegue executar a interação definida com o ator B usando estes artefatos e obter o resultado esperado?

A mudança parece pequena, mas transforma por completo a forma como deveríamos usar IA durante o profiling. A unidade de trabalho deixa de ser o recurso. A unidade de trabalho passa a ser o cenário de interoperabilidade.

Prompting a partir do caso de uso

Um mau padrão de Vibe Profiling seria começar dizendo:

"Crie um perfil de Patient para a Costa Rica."

A IA imediatamente começará a inventar decisões.

Uma abordagem muito mais robusta seria dar contexto primeiro:

Temos um ator Registro de Pacientes e um ator Consumidor de Identidades. O consumidor precisa localizar uma pessoa usando determinados identificadores nacionais. Estes são os cenários de identificação, estas são as fontes de dados disponíveis, estas são as regras quando existem múltiplas correspondências e estas são as transações utilizadas.

E só depois perguntar:

Quais restrições FHIR decorrem destes requisitos?

A diferença é enorme. No primeiro caso, a IA está projetando o problema. No segundo, está nos ajudando a materializar decisões de interoperabilidade previamente compreendidas.

Esta é provavelmente uma das regras principais do Vibe Profiling: não pedir primeiro à IA que gere perfis; pedir primeiro que ela compreenda o cenário.

A IA como participante da mesa de profiling

Também podemos pensar a inteligência artificial de outra forma: não como a ferramenta que produz o perfil, mas como um participante adicional da mesa de trabalho.

Durante uma sessão de profiling ela poderia ser usada para perguntar:

• Que cenário não estamos considerando?
• O que acontece se este dado não existir?
• Que interpretação um implementador diferente poderia fazer desta regra?
• Esta cardinalidade realmente decorre do caso de uso?
• Estamos confundindo obrigatoriedade do dado com obrigação do ator?
• Há alguma contradição entre este exemplo e o texto narrativo?
• Quais artefatos FHIR estão envolvidos neste cenário?
• O que um teste de conformidade deveria verificar?

Esse tipo de pergunta pode ser ainda mais valioso do que pedir que ela gere o FSH. A IA se torna assim uma espécie de revisora permanente do design.

Ela não substitui especialistas clínicos, terminólogos, arquitetos, implementadores nem perfiladores. Mas pode ampliar enormemente a capacidade deles de explorar o espaço de decisões.

O perfilador passa de construtor a diretor

O Vibe Coding está gerando uma discussão interessante sobre o papel do desenvolvedor. Algo parecido acontecerá com os perfiladores.

Se uma IA pode produzir boa parte de um StructureDefinition, o trabalho humano se desloca para atividades de nível mais alto. O perfilador se torna cada vez mais o diretor do processo de modelagem:

• fornece contexto e delimita o problema;
• reconhece quando uma resposta é plausível, mas incorreta;
• conhece os padrões o suficiente para questionar a IA;
• concilia necessidades clínicas com capacidades técnicas;
• decide quando usar um recurso existente e quando introduzir uma extensão;
• identifica quando o problema não se resolve com profiling;
• e, sobretudo, mantém a coerência entre caso de uso, atores, transações, requisitos e artefatos publicados.

A IA pode construir muito rápido. Mas alguém precisa saber o que estamos construindo.

De prompt engineering a context engineering

Provavelmente o Vibe Profiling também não dependerá tanto de escrever "bons prompts". Dependerá de fornecer bom contexto.

Uma IA que só tem acesso ao recurso base pode gerar um perfil. Uma IA que além disso tem acesso aos casos de uso, às atas das mesas técnicas, às decisões de arquitetura, às terminologias nacionais, a outros perfis existentes, aos requisitos regulatórios, aos diagramas de sequência, a exemplos reais, atores, transações, testes de conformidade e versões anteriores do guia se torna uma ferramenta muito mais poderosa.

Por isso o futuro do profiling assistido por IA talvez não seja simplesmente "gerar FSH com um chatbot". Será construir ambientes onde a IA tenha contexto suficiente para compreender a intenção do guia de implementação.

O humano no ciclo não é opcional

Nesse cenário existe uma tentação evidente. Se a IA gera o perfil, o SUSHI o compila e o validator não reporta erros, por que não publicá-lo?

Porque nenhum desses três atores entende sozinho o sistema de saúde que estamos tentando representar. A IA pode nos ajudar a encontrar inconsistências. O SUSHI verifica a sintaxe. O validator verifica a conformidade. Mas a decisão de que um modelo representa corretamente uma realidade clínica, regulatória e operacional continua exigindo governança humana.

Isso é particularmente importante na saúde. Um erro em uma aplicação tradicional produz uma má experiência de usuário. Um erro semântico em interoperabilidade pode se propagar entre múltiplas organizações e permanecer durante anos como parte de um padrão nacional.

A capacidade de gerar perfis rapidamente deve vir acompanhada de uma capacidade igualmente forte de revisá-los, questioná-los e testá-los.

Uma possível disciplina para o Vibe Profiling

Poderíamos imaginar o processo da seguinte forma:

1. Humano: define o problema e os atores.
2. Humano + IA: exploram cenários e requisitos.
3. IA: propõe alternativas de modelagem.
4. Humano: seleciona e justifica decisões.
5. IA: gera perfis, terminologia, exemplos e documentação.
6. Ferramentas: compilam e validam os artefatos.
7. IA: revisa inconsistências entre artefatos.
8. Implementadores: testam os cenários reais.
9. Humano: aceita, rejeita ou modifica o design.

E o ciclo recomeça.

Ou seja, o Vibe Profiling não deveria ser prompt → perfil → publicar. Deveria se parecer muito mais com:

contexto → cenários → requisitos → proposta → crítica → artefatos → validação → implementação → retroalimentação.

A IA participa de praticamente todas as etapas. Mas não é dona de nenhuma decisão.

O profiling será mais rápido. Pensar continuará sendo difícil.

A inteligência artificial provavelmente permitirá que, nos próximos anos, produzamos guias de implementação muito mais rápido. Gerar exemplos deixará de ser tedioso. Criar documentação será mais simples. Manter perfis derivados poderá ser parcialmente automatizado. Os testes poderão ser gerados a partir dos requisitos. As inconsistências poderão ser detectadas automaticamente. Poderemos explorar várias alternativas de modelagem antes de escolher uma.

Tudo isso representa uma enorme oportunidade para comunidades FHIR pequenas, projetos nacionais e organizações que hoje enfrentam uma barreira importante de conhecimento especializado.

Mas existe também um paradoxo. Quando construir os artefatos se torna fácil, as más decisões também se tornam fáceis de implementar.

Podemos gerar dez perfis incorretos no tempo que antes levávamos para produzir um. Podemos documentá-los perfeitamente, gerar exemplos convincentes e criar diagramas lindos. Podemos até produzir um guia que pareça extraordinariamente maduro. E ainda assim ter modelado mal o problema.

Por isso o principal conhecimento do perfilador na era da IA provavelmente não será lembrar cada elemento de cada recurso FHIR. Será saber o que perguntar. Saber que informação falta. Saber quando uma resposta aparentemente correta não tem contexto suficiente. Saber separar requisitos clínicos, funcionais, semânticos e técnicos. Saber compreender atores e transações. E saber converter decisões humanas em contratos computáveis que outros possam implementar.

Isso é FHIR Vibe Profiling

O Vibe Profiling não consiste em pedir a uma IA que crie perfis por nós. Consiste em incorporar a IA profundamente ao processo de design de interoperabilidade: para explorar, questionar, gerar, revisar, documentar e testar. E, sobretudo, para reduzir o tempo que dedicamos a tarefas mecânicas e aumentar o tempo disponível para entender o problema.

A IA pode conhecer praticamente toda a especificação do FHIR. Pode gerar um StructureDefinition muito mais rápido do que nós. Pode escrever FSH, FHIRPath e exemplos com grande rapidez. Mas ainda precisa que alguém lhe forneça algo fundamental: o contexto do que estamos tentando interoperar.

Talvez aí esteja a verdadeira definição de HL7 FHIR Vibe Profiling:

Deixar que a IA acelere a construção do guia, sem permitir que ela substitua a compreensão que deve existir por trás dele.

Porque em interoperabilidade, gerar artefatos nunca foi realmente o problema mais difícil. O problema sempre foi fazer com que diferentes sistemas, organizações e pessoas entendessem a mesma coisa.

E nenhuma quantidade de código —gerado por humanos ou por inteligência artificial— pode substituir essa decisão.