CFM 2.454 no FHIR: onde o uso de IA cabe no prontuário - Rogério Rodrigues

A Resolução CFM nº 2.454, de 11 de fevereiro de 2026, diz no art. 4º, inciso V, que é dever do médico “registrar no prontuário do paciente o uso de sistemas de IA como apoio à decisão médica”. Ela não diz em qual campo. Em FHIR, o lugar que já existe para isso é o recurso Provenance: o resultado da IA vai em target, o modelo entra como agent do tipo author apontando para um Device com nome e versão, o médico entra como agent do tipo verifier e os dados de entrada vão em entity com papel source. O exemplo abaixo passa na validação estrutural de FHIR R4 (4.0.1) e tem uma variante R5 (5.0.0).

Isto é leitura de quem desenha sistema. Não é parecer jurídico. Se você precisa saber se o seu registro cumpre a resolução, a pergunta é para o jurídico e para a Comissão de IA da sua instituição.

O que a resolução pede, artigo por artigo

A resolução foi publicada no DOU em 27/02/2026 e o art. 23 diz que ela entra em vigor 180 dias depois da publicação. Pela conta, 26/08/2026. Fui atrás do texto procurando o campo. Não tem campo. Tem dever. Quem vai modelar o dado somos nós.

Os trechos que importam para quem desenha o prontuário:

Artigo	O que diz	Onde cabe no FHIR
Art. 4º, V	Registrar no prontuário o uso de IA como apoio à decisão	`Provenance` apontando para o resultado da IA
Art. 18, § 2º	A decisão “caberá sempre ao médico, que pode acolher ou rejeitar as sugestões da IA”	Agente humano no `Provenance`; a decisão em si vai no registro clínico do médico
Art. 5º, § 1º	Paciente informado quando a IA for “apoio relevante”	Fora do `Provenance`; é processo de atendimento
Art. 11	“Qualquer utilização de IA deverá ser comunicada e explicada aos pacientes”	Fora do `Provenance`; é processo de atendimento
Art. 5º, § 3º	Respeitar a “recusa informada” do uso de IA	Candidato natural: `Consent`
Art. 9º, § 2º	Instituições com “mecanismos de auditoria especializada e monitoramento contínuos”	`AuditEvent` para o acesso; `Provenance` consultável para o uso
Art. 13	Modelos classificados em risco baixo, médio, alto ou inaceitável	Sem campo padrão no core; fica no cadastro do `Device`

O texto do art. 13 está resumido. Os de art. 4º, 5º, 9º, 11 e 18 estão entre aspas, conferidos palavra por palavra em duas cópias do texto (links no fim).

Por que Provenance e não um parágrafo de texto livre

O jeito mais rápido de cumprir o art. 4º é o médico escrever “utilizada ferramenta de IA” na evolução. Funciona no papel. Não funciona no dia em que a instituição precisar responder ao art. 9º: quantos atendimentos usaram o modelo X na versão Y, quantas sugestões o médico revisou, em quais pacientes. Texto livre não responde isso sem outra IA lendo texto livre.

O Provenance existe para isso. A spec R5 define o recurso como o que rastreia “the activity that created, revised, deleted, or signed a version of a resource, describing the entities and agents involved”. Os campos que o art. 4º precisa já estão lá: quem fez, com qual ferramenta, a partir de quais dados, quando.

Tem um detalhe na própria spec. Na seção de fronteiras, ela diz que elementos de origem que já existem em outros recursos “should always be used in preference to the Provenance resource”. Ou seja: se o recurso alvo já tem um campo de autoria, use. O Provenance entra quando você quer um registro explícito de proveniência. É exatamente o caso.

O exemplo: risco de sepse sugerido por IA, revisado por médica

Cenário sintético. Um modelo de risco de sepse lê lactato e pressão arterial e gera um RiskAssessment. A médica revisa. O Provenance registra isso. Nada aqui é paciente real; o domínio example.org é reservado para exemplo.

Provenance (FHIR R4)

{
  "resourceType": "Provenance",
  "id": "uso-ia-sepse-001",
  "target": [
    { "reference": "RiskAssessment/risco-sepse-001" }
  ],
  "occurredDateTime": "2026-09-15T10:42:00-03:00",
  "recorded": "2026-09-15T10:47:12-03:00",
  "policy": [
    "https://hospital-ficticio.example.org/politicas/ia-clinica/v1"
  ],
  "reason": [
    {
      "coding": [
        {
          "system": "http://hl7.org/fhir/uv/aitransparency/CodeSystem/AddedProvenanceCS",
          "code": "CLINAST_AIRPT"
        }
      ]
    }
  ],
  "activity": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
        "code": "CREATE"
      }
    ]
  },
  "agent": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
            "code": "author"
          }
        ]
      },
      "who": {
        "reference": "Device/ia-sepse-v2-3-1",
        "display": "Modelo de risco de sepse (sintético) v2.3.1"
      }
    },
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
            "code": "verifier"
          }
        ]
      },
      "who": { "reference": "Practitioner/medica-ficticia-01" },
      "onBehalfOf": { "reference": "Organization/hospital-ficticio" }
    }
  ],
  "entity": [
    { "role": "source", "what": { "reference": "Observation/lactato-001" } },
    { "role": "source", "what": { "reference": "Observation/pressao-arterial-001" } }
  ]
}

Device que representa o modelo (FHIR R4)

{
  "resourceType": "Device",
  "id": "ia-sepse-v2-3-1",
  "deviceName": [
    { "name": "Modelo de risco de sepse (sintético)", "type": "model-name" }
  ],
  "modelNumber": "sepse-risk",
  "version": [ { "value": "2.3.1" } ],
  "type": { "text": "Software de IA de apoio à decisão clínica" },
  "owner": { "reference": "Organization/hospital-ficticio" }
}

As escolhas, uma por uma

IA como Device. Em R4, agent.who aceita Practitioner, PractitionerRole, RelatedPerson, Patient, Device ou Organization. Modelo não é pessoa. É software com versão. Um Device por versão deixa a pergunta “qual versão sugeriu isso?” com resposta exata.
IA como author, médica como verifier. É o padrão que o guia AI Transparency on FHIR da HL7 descreve: o sistema de IA como autor do conteúdo gerado e o humano que revisou como verificador. Casa com o art. 18: a IA sugere, o médico responde por isso.
reason com CLINAST_AIRPT. Código do mesmo guia: conteúdo reportado por IA e depois revisado e assumido por clínico. Esse guia está em ballot (v1.0.0-ballot, STU1, baseado em R4). Código de ballot pode mudar.
policy com URI da política interna. O art. 14, parágrafo único, cria a Comissão de IA e Telemedicina para instituições com sistemas próprios de IA. A política dessa comissão é o candidato natural para esse campo.
entity com papel source. Os dados que o modelo leu. Sem isso, a auditoria do art. 9º não consegue reconstruir o que a IA viu.

R4 ou R5: o que quebra

O mesmo JSON não serve nas duas versões. A tabela junta a spec e os testes negativos que foram rodados (reason no R5, patient no R4, Device R5 no R4):

Ponto	R4 (4.0.1)	R5 (5.0.0)
Maturidade do Provenance	3, Trial Use	4, Trial Use
`recorded`	1..1	0..1
`reason`	existe	não existe; o validador rejeita
`patient`, `encounter`	não existem; o validador rejeita patient	existem, 0..1
`basedOn`, `authorization`	não existem	existem, 0..*
Nome do `Device`	`deviceName`	`name`
`Device.type`	0..1	0..*

Na variante R5 tirei o reason e acrescentei patient e encounter. O patient no R5 é útil para o art. 9º: dá para buscar todo uso de IA de um paciente sem resolver o target antes. Em R4, você resolve pelo alvo.

Onde mais o registro encosta

AuditEvent. A spec separa os dois: o Provenance é preparado por quem cria ou atualiza o recurso; o AuditEvent é criado conforme os eventos acontecem. Quem abriu o prontuário vai no AuditEvent. Quem gerou a sugestão vai no Provenance.
meta.security com AIAST. O guia da HL7 recomenda marcar o recurso tocado por IA com o código AIAST do sistema v3-ObservationValue. É a marca leve. O Provenance é o detalhe.
Consent. Para a recusa informada do art. 5º, § 3º. Se o paciente recusou, o pipeline precisa saber antes de chamar o modelo, não depois.

Limites

A validação foi estrutural, com a biblioteca Python fhir.resources. Ela confere elementos, tipos e cardinalidade. Não confere invariantes FHIRPath, não confere terminologia e não confere conformidade com o perfil AI-Provenance do guia. O validador oficial da HL7 não foi rodado neste exemplo.
O Provenance não tem campo para “rejeitei a sugestão”. O agente verifier diz que houve revisão, não o resultado dela. Acolher ou rejeitar (art. 18, § 2º) precisa aparecer no registro clínico do médico, por exemplo um ClinicalImpression que referencia o RiskAssessment.
A classificação de risco do art. 13 não tem elemento padrão no Device do core. O guia da HL7 traz um perfil de Model Card via DocumentReference. Ainda é ballot.
A resolução não fala em FHIR. Tudo aqui é uma proposta de modelagem, não leitura oficial.

Quando não usar

IA puramente administrativa (agenda, faturamento). O Anexo II põe funções administrativas em risco baixo, e o art. 4º, V fala de apoio à decisão médica. Provenance por chamada ali é custo sem pergunta para responder.
Quando o recurso alvo já tem campo de autoria que resolve. RiskAssessment.performer em R4 aceita Device. Se a única pergunta é “qual modelo gerou”, a própria spec manda preferir o campo nativo.
Prontuário sem servidor FHIR e sem plano de ter. Aí o mesmo desenho vale como modelo de tabela: ferramenta, versão, entradas, revisor, data. O que não vale é texto livre.

Fonte e como reproduzir

Resolução CFM nº 2.454/2026, texto consolidado: Legismap e cópia em PDF no Observatório Hospitalar da Fiocruz. Publicação: DOU de 27/02/2026, Seção 1.
HL7 FHIR R4, Provenance: hl7.org/fhir/R4/provenance.html
HL7 FHIR R5, Provenance: hl7.org/fhir/R5/provenance.html
AI Transparency on FHIR, v1.0.0-ballot: hl7.org/fhir/uv/aitransparency/2026Jan

Para conferir o JSON acima em R4, salve como prov-r4.json e rode:

python3 -m venv r4 && r4/bin/pip install "fhir.resources==6.1.0" "pydantic==1.9.2"
r4/bin/python -c "
import json
from fhir.resources.provenance import Provenance
Provenance.parse_obj(json.load(open('prov-r4.json')))
print('OK')"

A versão 6.1.0 é a que traz FHIR 4.0.1. Para R5, a 8.3.0 traz FHIR 5.0.0 e usa Provenance.model_validate(...). Colocar o mesmo prov-r4.json no R5 falha em reason, que é o teste negativo da tabela acima.

In English

Brazil’s CFM Resolution 2,454/2026 (art. 4, V) requires physicians to record AI use in the patient record, but defines no field. In FHIR, Provenance fits: the AI model as a Device agent of type author, the physician as verifier, inputs as source entities. The synthetic example passes structural validation in R4 (4.0.1), and an R5 variant passes in R5 (5.0.0). Not legal advice.

Última revisão em 07/10/2026.