Síntese de prontuários médicos

#O problema: prontuários precisos, mas ilegíveis

Um profissional de saúde que assume o acompanhamento de um paciente precisa examinar relatórios, resultados de exames laboratoriais, prescrições e correspondências, muitas vezes produzidos por vários softwares. Um modelo local pode preparar, em uma página, uma síntese do prontuário para a retomada do acompanhamento. O método que funciona no contexto médico é sempre o mesmo: extrair os dados estruturados por meio de código determinístico, fazer o modelo redigir a síntese com base apenas nesses fatos, fazê-lo citar em cada linha o identificador do fato de origem, verificar a síntese por meio de um programa e depois submetê-la à validação de um médico.

Um esclarecimento de vocabulário evita uma confusão frequente. Na França, os documentos de saúde trocados e compartilhados, especialmente por meio do Dossier Médical Partagé, seguem o marco de interoperabilidade dos sistemas de informação em saúde (CI-SIS) da Agence du numérique en santé, cujos componentes descrevem documentos no formato CDA R2, um padrão HL7 baseado em XML. O HL7 versão 2 é outro padrão, baseado em mensagens de texto delimitadas por barras verticais, usado para transporte. Por fim, o FHIR, em JSON, é o padrão de intercâmbio mais recente e mais simples de processar, encontrado sobretudo nas trocas entre aplicações. Sua primeira tarefa é, portanto, saber o que seu software fornece.

#Contexto: sigilo médico, hospedagem e responsabilidade

Três questões se colocam antes de escrever qualquer código. A primeira é o sigilo médico e a proteção dos dados de saúde, que exigem o tratamento desses dados em uma infraestrutura controlada: a execução local é a aplicação prática disso, mas também é necessário criptografar os discos, restringir os acessos e registrar as atividades em logs. A segunda é a hospedagem de dados de saúde. O artigo L. 1111-8 do Código de Saúde Pública prevê que qualquer pessoa que hospede dados pessoais de saúde em suporte digital deve ser certificada para esse fim, quando o fizer em nome de um responsável pelo tratamento ou do paciente.

Essa obrigação nem sempre se aplica como se imagina. De acordo com a Agence du numérique en santé, citada por uma seguradora especializada, a certificação de provedor de hospedagem não é uma obrigação regulamentar quando todos os sistemas de uma instituição armazenam apenas dados de seus próprios pacientes, exceto se ela prestar serviços de hospedagem para terceiros. Ou seja, um consultório que executa a ferramenta em suas próprias instalações, para seus pacientes, não se enquadra na mesma situação que uma empresa de software que oferece esse serviço a outros consultórios. Peça à sua assessoria ou ao seu encarregado de proteção de dados que confirme como essa regra se aplica à sua situação.

A terceira questão é a finalidade. Um software que produz informações destinadas a subsidiar uma decisão médica pode estar sujeito à regulamentação de dispositivos médicos, conforme a finalidade declarada. Uma síntese para retomar a análise de um prontuário, apresentada como auxílio à leitura e validada pelo médico, não tem o mesmo alcance que uma ferramenta que sugere um tratamento. Este guia se mantém dentro da primeira formulação.

#Pilha local

Três componentes são suficientes. Python para ler os documentos: o módulo json para um lote FHIR, lxml para um documento CDA e a biblioteca hl7 para eventuais mensagens da versão 2; essa biblioteca se apresenta como um analisador de mensagens HL7 v2.x. Ollama para servir o modelo: Qwen 3.5 com 9 bilhões de parâmetros pesa 6,6 GB, com 256.000 tokens de contexto anunciados; Mistral Small 24B pesa 14 GB e anuncia 32.000 tokens. Por fim, o esquema JSON do Ollama, para obrigar o modelo a responder em um formato que possa ser verificado.

Nenhum desses modelos foi validado para uso clínico por seus desenvolvedores. A capacidade deles em francês médico deve ser avaliada com seus próprios prontuários, seguindo o protocolo abaixo. Uma placa de 8 GB é suficiente para o primeiro; o segundo exige mais memória de vídeo, especialmente se o contexto for longo.

#Ler os documentos: lote FHIR e documento CDA

Para um lote FHIR, que é um contêiner de uma coleção de recursos, a forma mais simples é ler o JSON tal como está e buscar os recursos por tipo. Isso evita depender de uma biblioteca cujas versões de FHIR variam. Cada fato registrado recebe um identificador curto (F1, F2...) e um texto legível: é isso que permitirá, posteriormente, localizar a origem de cada frase da síntese.

import json

def libelle(cc):
    if not cc:
        return None
    if cc.get('text'):
        return cc['text']
    c = (cc.get('coding') or [{}])[0]
    return c.get('display') or c.get('code')

def faits_fhir(chemin):
    lot = json.load(open(chemin, encoding='utf-8'))
    faits = []
    for e in lot.get('entry', []):
        r = e.get('resource', {})
        t = r.get('resourceType')
        if t == 'Condition':
            texte = f"Diagnostic : {libelle(r.get('code'))} (début {r.get('onsetDateTime', 'date inconnue')})"
        elif t == 'MedicationStatement':
            dose = (r.get('dosage') or [{}])[0].get('text', 'posologie non précisée')
            texte = f"Traitement : {libelle(r.get('medicationCodeableConcept'))}, {dose}"
        elif t == 'Observation':
            v = r.get('valueQuantity', {})
            texte = f"Résultat : {libelle(r.get('code'))} = {v.get('value')} {v.get('unit', '')} ({r.get('effectiveDateTime', 'date inconnue')})"
        elif t == 'AllergyIntolerance':
            texte = f"Allergie : {libelle(r.get('code'))}"
        elif t == 'Procedure':
            texte = f"Acte : {libelle(r.get('code'))} ({r.get('performedDateTime', 'date inconnue')})"
        else:
            continue
        faits.append({'ref': f'F{len(faits) + 1}', 'type': t, 'texte': texte})
    return faits

Em um documento CDA, o texto útil está nas seções do corpo estruturado: cada seção tem um título, um código e um bloco de texto narrativo. O código abaixo extrai essas seções com seus títulos, sem incluir o cabeçalho do documento, que contém a identidade do paciente. Os namespaces do CDA são os do HL7 versão 3.

from lxml import etree

NS = {'h': 'urn:hl7-org:v3'}

def sections_cda(chemin):
    racine = etree.parse(chemin).getroot()
    for s in racine.iterfind('.//h:structuredBody//h:section', NS):
        texte = s.find('h:text', NS)
        if texte is None:
            continue
        code = s.find('h:code', NS)
        yield {
            'titre': (s.findtext('h:title', default='', namespaces=NS) or '').strip(),
            'code': code.get('code') if code is not None else None,
            'texte': ' '.join(''.join(texte.itertext()).split()),
        }

#Quais fatos reter e com que cautela

A última coluna conta mais do que as demais. Um modelo lê os fatos que você lhe fornece e não sabe o que falta: se um tratamento interrompido não for marcado como tal, ele aparecerá como em andamento na síntese. O código deve conter o status e a data, e o prompt deve pedir para indicar fatos sem data ou de status incerto. A ausência de informação não é uma informação: a síntese deve dizer isso.

#Escrever uma síntese que cite suas fontes, depois verificá-la

O prompt fornece os fatos numerados e exige que cada linha da síntese termine com as referências dos fatos utilizados, por exemplo [F3][F7]. Ele não contém o nome do paciente: a idade e o sexo são suficientes, e a identidade permanece no software usado na atividade profissional. A resposta tem formato livre, mas é estruturada em seções, o que permite lê-la em uma página.

import requests

SYSTEM = open('system_med.txt', encoding='utf-8').read()

def synthese(faits, age, sexe, modele='qwen3.5:9b'):
    liste = '\n'.join(f"[{f['ref']}] {f['texte']}" for f in faits)
    r = requests.post('http://localhost:11434/api/chat', json={
        'model': modele, 'stream': False,
        'messages': [{'role': 'system', 'content': SYSTEM},
                     {'role': 'user', 'content': f'Patient : {age} ans, {sexe}.\n\nFAITS :\n{liste}'}],
        'options': {'temperature': 0.1, 'num_ctx': 16384}})
    return r.json()['message']['content']

O controle vem depois, no código. Duas verificações capturam a maioria dos erros graves: cada referência citada deve existir na lista de fatos e cada número da síntese deve estar presente nos fatos. Um número que aparece de forma inexplicável é um sinal típico de invenção ou erro de cópia, especialmente em valores biológicos ou posologias.

import re

def verifier(synthese, faits):
    refs_ok = {f['ref'] for f in faits}
    citees = set(re.findall(r'\[(F\d+)\]', synthese))
    def nombres(t):
        t = re.sub(r'\[F\d+\]', ' ', t).replace(',', '.')
        return set(re.findall(r'\d+(?:\.\d+)?', t))
    source = nombres(' '.join(f['texte'] for f in faits))
    return {
        'references_inconnues': sorted(citees - refs_ok),
        'nombres_absents_de_la_source': sorted(nombres(synthese) - source),
        'lignes_sans_reference': [l for l in synthese.split('\n') if l.strip().startswith('-') and not re.search(r'\[F\d+\]', l)],
    }

#O prompt de sistema

Tu prépares une synthèse de reprise de dossier pour un médecin.
Tu ne poses AUCUN diagnostic, tu ne proposes AUCUN traitement ni modification de traitement.
Tu utilises UNIQUEMENT les faits fournis. Tu n'ajoutes aucune donnée.
Chaque ligne de la synthèse se termine par les références des faits utilisés, par exemple [F3][F7].
Si un fait n'a pas de date, ou si un statut est incertain, tu l'écris explicitement.
Si des faits semblent contradictoires, tu les signales sans trancher.
Si une information attendue est absente, écris : non renseigné.

SECTIONS : Pathologies, Traitements en cours, Allergies, Derniers résultats,
Actes et antécédents, Points à vérifier.

A seção « Pontos a verificar » é a mais útil na prática. Ela transforma as zonas de incerteza (tratamento sem data de término, resultado sem unidade, dois valores contraditórios) em perguntas a serem feitas ao médico, em vez de disfarçá-las em uma frase fluida.

#Avaliar a confiabilidade antes de qualquer uso

A confiança não se estabelece por decreto. Um estudo publicado em 2025 na npj Digital Medicine mediu os erros de modelos de linguagem na geração de notas clínicas: em 12.999 frases anotadas por profissionais clínicos, observou 1,47% de frases com alucinações e 3,45% de omissões, com 44% das alucinações consideradas graves, ou seja, capazes de afetar o diagnóstico ou a assistência ao paciente se não forem corrigidas. Esses números se referem a outra tarefa, com outros modelos: não são os seus. Eles mostram que uma baixa taxa de erro por frase continua sendo preocupante quando se considera um documento inteiro.

Uma síntese de trinta linhas com 1,5% de erro por linha, supondo erros independentes, contém pelo menos um erro em cerca de um terço dos casos. É uma ordem de grandeza para fins didáticos, não uma previsão. Daí o protocolo a seguir, que substitui o critério “zero erros em 50 prontuários”: esse critério não prova muita coisa, pois zero erros observados em 50 prontuários é compatível com uma taxa real de cerca de 6% no nível de confiança de 95% (regra dos três, 3 dividido por 50).

1. 01
   Reunir uma amostra de prontuários anonimizados

   Use prontuários variados: pacientes com múltiplas doenças, tratamentos numerosos, resultados antigos. Remova os dados de identificação e os dados desnecessários antes de qualquer uso fora do contexto de atendimento.
2. 02
   Solicitar a anotação por um médico

   Cada frase de síntese é classificada: correta, imprecisa, omissão, erro. Diferencie erros que poderiam alterar uma decisão clínica.
3. 03
   Contar por categoria e por gravidade

   O número de erros graves por prontuário conta mais do que a taxa média. Defina um limite com o médico responsável antes de começar.
4. 04
   Medir também as omissões

   Um resumo que esquece uma alergia ou um tratamento é mais perigoso do que uma frase mal elaborada.
5. 05
   Executar novamente a cada mudança

   Modelo, prompt ou formato de exportação: cada alteração exige executar a avaliação novamente.

#Entrada em produção: registros, acesso e escopo

Registrar cada geração

Conserve a data, a versão do modelo, a lista de fatos fornecida e a síntese gerada em um espaço protegido: é isso que permite reconstruir o que o médico leu.

Controlar os acessos

O servidor de inferência não deve ser acessível de fora; os discos estão criptografados; as contas são vinculadas a usuários identificados nominalmente.

Mostrar fontes

A interface mostra a síntese com o fato original correspondente a cada linha. Um médico que pode verificar com um clique realmente verifica.

Limitar o escopo

Comece com uso interno no consultório ou na instituição, com um pequeno número de usuários, antes de qualquer expansão. Um serviço oferecido a outras instituições altera seu status em relação à hospedagem.

Prever uma validação humana explícita

A síntese é assinada ou validada pelo profissional de saúde antes de ser incluída no prontuário; caso contrário, não deve constar nele.

• Saúde: transcrição de consultas
• Transcrição médica e LLM local: dados do paciente
• Criptografar o disco dos modelos
• Checklist de privacidade
• Limitar as alucinações de um LLM local
• LLM local e RGPD: dados privados nas empresas

• Fonte: seção de transmissão CDA-R2 do CI-SIS (ANS)
• Fonte: hospedagem de dados de saúde (Relyens, segundo a ANS)
• Fonte: estudo npj Digital Medicine sobre alucinações clínicas
• Fonte: recurso Bundle do FHIR R4
• Fonte: saídas estruturadas do Ollama