Sintesi di dossier medici

#Il problema: cartelle cliniche accurate ma illeggibili

Un professionista sanitario che subentra nella cura di un paziente deve esaminare referti, risultati di laboratorio, prescrizioni e lettere, spesso prodotti da diversi software. Un modello locale può preparare una sintesi di una pagina per la ripresa in carico del caso. Il metodo affidabile in ambito medico è sempre lo stesso: estrarre i dati strutturati tramite codice deterministico, far redigere la sintesi esclusivamente sulla base di questi fatti, far citare in ogni riga l'identificativo del fatto di origine, controllare la sintesi tramite un programma, poi farla validare da un medico.

Un chiarimento terminologico evita una confusione frequente. In Francia, i documenti sanitari scambiati e condivisi, in particolare tramite il Dossier Médical Partagé, seguono il quadro di interoperabilità dei sistemi informativi sanitari (CI-SIS) dell'Agence du numérique en santé, le cui sezioni descrivono documenti in formato CDA R2, uno standard HL7 basato su XML. HL7 versione 2 è un altro standard, basato su messaggi di testo delimitati da barre verticali, che serve per il trasporto. Infine FHIR, in JSON, è lo standard di scambio più recente e più semplice da elaborare, che si incontra soprattutto negli scambi tra applicazioni. Il tuo primo compito è quindi capire cosa ti fornisce il tuo software.

#Quadro: segreto medico, hosting e responsabilità

Tre questioni vanno affrontate prima di scrivere qualsiasi codice. La prima riguarda il segreto medico e la protezione dei dati sanitari, che impongono di trattare tali dati su un'infrastruttura controllata: l'elaborazione locale ne è l'attuazione pratica, ma occorre anche cifrare i dischi, limitare gli accessi e registrare le operazioni nei log. La seconda riguarda l'hosting dei dati sanitari. L'articolo L. 1111-8 del codice della sanità pubblica prevede che chiunque ospiti dati sanitari a carattere personale su supporto digitale debba essere certificato a tal fine, quando lo fa per conto di un titolare del trattamento o del paziente.

Questo obbligo non si applica sempre come si potrebbe pensare. Secondo l'Agence du numérique en santé, citata da un assicuratore specializzato, la certificazione del fornitore di hosting non è un obbligo normativo quando tutti i sistemi di una struttura memorizzano esclusivamente dati dei propri pazienti, salvo che la struttura svolga un'attività di hosting per conto di terzi. In altre parole, uno studio che esegue lo strumento al proprio interno, per i propri pazienti, non si trova nella stessa situazione di un produttore di software che offre questo servizio ad altri studi. Fai confermare la tua situazione dal tuo consulente o dal tuo responsabile della protezione dei dati.

La terza questione è la finalità. Un software che produce informazioni destinate a orientare una decisione medica può rientrare nella normativa sui dispositivi medici, a seconda della finalità dichiarata. Una sintesi per riprendere in esame una cartella clinica, presentata come ausilio alla lettura e validata dal medico, non ha la stessa portata di uno strumento che suggerisce un trattamento. Questa guida si attiene alla prima formulazione.

#Lo stack locale

Bastano tre componenti. Python per leggere i documenti: il modulo json per un lotto FHIR, lxml per un documento CDA, la libreria hl7 per eventuali messaggi di versione 2; quest'ultima si presenta come un parser di messaggi HL7 v2.x. Ollama per servire il modello: Qwen 3.5 con 9 miliardi di parametri pesa 6,6 GB, con 256.000 token di contesto dichiarati; Mistral Small 24B pesa 14 GB e dichiara 32.000 token. Infine, lo schema JSON di Ollama, per obbligare il modello a rispondere in un formato verificabile.

Nessuno di questi modelli è stato validato per un uso clinico dai rispettivi sviluppatori. La loro capacità di gestire il francese medico va valutata sulle tue cartelle cliniche, seguendo il protocollo riportato più sotto. Una scheda da 8 GB basta per il primo; il secondo richiede più memoria video, soprattutto se il contesto è lungo.

#Leggere i documenti: lotto FHIR e documento CDA

Per un bundle FHIR, che è un contenitore di una raccolta di risorse, il modo più semplice è leggere il JSON così com'è e cercare le risorse per tipo. Questo evita di dipendere da una libreria le cui versioni di FHIR variano. Ogni fatto selezionato riceve un identificativo breve (F1, F2...) e un testo leggibile: è ciò che permetterà poi di risalire alla fonte di ogni frase della sintesi.

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

Per un documento CDA, il testo utile si trova nelle sezioni del corpo strutturato: ogni sezione ha un titolo, un codice e un blocco di testo narrativo. Il codice sotto estrae le sezioni con il loro titolo, senza includere l'intestazione del documento, che contiene l'identità del paziente. Gli spazi dei nomi di CDA sono quelli della versione 3 di HL7.

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()),
        }

#Quali fatti ricordare, e con quale prudenza

L'ultima colonna conta più delle altre. Un modello legge i fatti che gli fornisci e non sa cosa manchi: se un trattamento interrotto non è indicato come tale, apparirà come ancora in corso nella sintesi. Il codice deve quindi contenere lo stato e la data, e il prompt deve chiedere di segnalare i fatti senza data o con uno stato incerto. L'assenza di informazioni non è un'informazione: la sintesi deve dirlo.

#Scrivere una sintesi che cita le fonti, poi verificarla

Il prompt fornisce i fatti numerati e richiede che ogni riga della sintesi termini con i riferimenti ai fatti utilizzati, ad esempio [F3][F7]. Non contiene il nome del paziente: età e sesso sono sufficienti, e l'identità rimane nel software professionale. La risposta ha una forma libera ma è strutturata in sezioni, il che la rende leggibile in una pagina.

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']

Il controllo avviene poi tramite codice. Due verifiche individuano la maggior parte degli errori gravi: ogni riferimento citato deve esistere nell'elenco dei fatti e ogni numero della sintesi deve comparire nei fatti. Un numero comparso dal nulla è il segno tipico di un'invenzione o di un errore di trascrizione, soprattutto quando riguarda un valore biologico o una posologia.

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)],
    }

#Il prompt di 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.

La sezione « Punti da verificare » è la più utile in pratica. Trasforma le zone grigie (terapia senza data di fine, risultato senza unità di misura, due valori contraddittori) in domande da porre al medico, invece di appianarle in una frase scorrevole.

#Valutare l'affidabilità prima di qualsiasi utilizzo

La fiducia non si impone per decreto. Uno studio pubblicato nel 2025 su npj Digital Medicine ha misurato gli errori dei modelli linguistici nella generazione di note cliniche: su 12.999 frasi annotate da clinici, ha rilevato l'1,47% di frasi con allucinazioni e il 3,45% di omissioni, con il 44% delle allucinazioni giudicate gravi, cioè tali da poter influire sulla diagnosi o sulla presa in carico se non vengono corrette. Questi dati riguardano un'altra attività, con altri modelli: non sono i tuoi. Mostrano che un basso tasso di errore per frase resta preoccupante su scala di un intero documento.

Una sintesi di trenta righe con una probabilità di errore dell'1,5% per riga, supponendo che gli errori siano indipendenti, contiene almeno un errore in circa un terzo dei casi. È un ordine di grandezza a scopo didattico, non una previsione. Da qui deriva il protocollo seguente, che sostituisce il criterio «zero errori su 50 dossier»: questo criterio non dimostra molto, poiché l'assenza di errori osservati su 50 dossier è compatibile con un tasso reale di circa il 6% a un livello di confidenza del 95% (regola del tre, 3 diviso 50).

1. 01
   Creare un campione di cartelle anonimizzate

   Scegli cartelle cliniche diverse: pazienti con più patologie, numerosi trattamenti, risultati risalenti a tempo fa. Rimuovi i dati identificativi e quelli inutili prima di qualsiasi utilizzo al di fuori dell'assistenza sanitaria.
2. 02
   Fare annotare da un medico

   Ogni frase di sintesi è classificata: corretta, imprecisa, omissione, errore. Distingui gli errori che potrebbero cambiare una decisione clinica.
3. 03
   Contare per categoria e per gravità

   Il numero di errori gravi per cartella conta più del tasso medio. Stabilisci una soglia con il medico responsabile prima di iniziare.
4. 04
   Misurare anche le omissioni

   Una sintesi che omette un'allergia o un trattamento è più pericolosa di una frase formulata male.
5. 05
   Rieseguire a ogni modifica

   Modello, prompt o formato di esportazione: ogni modifica richiede di ripetere la valutazione.

#Messa in produzione: tracce, accessi e ambito

Registrare ogni generazione

Mantieni data, versione del modello, elenco dei fatti forniti e sintesi prodotta in uno spazio protetto: è ciò che permette di ricostruire ciò che il medico ha letto.

Controllare gli accessi

Il server di inferenza non deve essere raggiungibile dall'esterno; i dischi sono crittografati; gli account sono nominativi.

Mostra le fonti

L'interfaccia mostra la sintesi con, per ogni riga, il fatto originale. Un medico che può verificare con un clic verifica davvero.

Limitare l'ambito

Comincia con un uso interno allo studio o alla struttura, con un piccolo numero di utenti, prima di qualsiasi estensione. Un servizio offerto ad altre strutture cambia il tuo status rispetto all'hosting.

Prevedere una validazione umana visibile

La sintesi viene firmata o convalidata dal professionista sanitario prima di essere inserita nella cartella clinica; in caso contrario, non deve esservi inclusa.

• Salute: trascrizione di consulti
• Trascrizione medica e LLM locale: dati del paziente
• Crittografare il disco dei modelli
• Checklist sulla riservatezza
• Limitare le allucinazioni di un LLM locale
• LLM locale e GDPR: dati privati in azienda

• Fonte: sezione sulla trasmissione CDA-R2 del CI-SIS (ANS)
• Fonte: hosting dei dati sanitari (Relyens, secondo l'ANS)
• Fonte: studio npj Digital Medicine sulle allucinazioni cliniche
• Fonte: risorsa Bundle di FHIR R4
• Fonte: output strutturati di Ollama