Pokala HealthIntel: A No-PHI Public-Source Healthcare Evidence Review Workspace

Sintesi Tecnica: Pokala HealthIntel

Problematica
I dataset sanitari di origine pubblica (ad esempio, openFDA, ClinicalTrials.gov) offrono risorse preziose per revisioni regolatorie, di sicurezza, dei fornitori e del contesto di mercato. Tuttavia, esiste una lacuna critica nel flusso di lavoro della revisione a valle: le affermazioni derivate da questi artefatti pubblici spesso si distaccano dal loro contesto essenziale. I revisori possono imbattersi in note di sicurezza o segnali di mercato senza avere un accesso immediato all'identità della fonte di supporto, alla scala dei dati (conteggio delle righe), alla freschezza dello snapshot o alle specifiche limitazioni che ne vincolano l'interpretazione. Nell'informatica sanitaria, questa separazione crea il rischio che gli output di revisione di fonti pubbliche vengano interpretati erroneamente come evidenza clinica, inferenze a livello di paziente o supporto decisionale validato, nonostante manchino dei necessari confini probatori.

Metodologia e Design del Sistema
Il documento presenta Pokala HealthIntel, uno spazio di lavoro per la revisione di evidenze sanitarie da fonti pubbliche privo di PHI (Informazioni Sanitarie Protette), progettato per mantenere il collegamento tra le affermazioni di revisione e i metadati espliciti dell'evidenza.

• Architettura: Il sistema utilizza un modello di artefatto orientato agli snapshot. Ingestisce input da fonti pubbliche pre-elaborati e li organizza in "record di evidenza collegati all'affermazione". Il deployment consiste in un frontend React/Vite e una superficie di routing gestita tramite Cloudflare Worker, con i dati gestiti tramite Cloudflare D1 (un database SQLite serverless).
• Schema Core: L'unità fondamentale del design non è una scheda di dashboard, ma un record di evidenza strutturato contenente cinque campi obbligatori:
  1. Affermazione/Titolo: L'osservazione riassunta.
  2. Fonte: La categoria o l'artefatto che supporta l'affermazione.
  3. Conteggio Righe: Il contesto di scala dell'artefatto.
  4. Freschezza: Il contesto di attualità o dello snapshot.
  5. Limitazione/Confine: Dichiarazioni esplicite su ciò che l'affermazione non deve essere utilizzata per inferire.
• Protocollo di Valutazione: Lo studio è una dimostrazione di sistema e una valutazione a livello di implementazione. Non ha valutato la sicurezza clinica, gli esiti dei pazienti o l'accuratezza diagnostica. Invece, la valutazione si è concentrata su:
  • Build & Deployment: Installazione delle dipendenze e successo della build del frontend.
  • Disponibilità della Rotta: 20 richieste per ogni rotta pubblica per controllare i tassi di risposta 2xx e la latenza.
  • Copertura dell'Evidenza: Ispezione dei record di evidenza di alto livello per la presenza dei cinque campi di metadati richiesti.
  • Lineage e Confini: Verifica del lineage canonico, scansione di frasi proibite del linguaggio pubblico (per garantire che non vi siano eccessive affermazioni cliniche) e controllo dello stato del manifesto della fonte.

Risultati Chiave
La valutazione ha prodotto i seguenti risultati:

• Build & Deployment: L'installazione delle dipendenze e la build del frontend sono passate con successo.
• Performance degli Endpoint: Sei rotte pubbiche controllate hanno restituito il 100% di risposte 2xx su 20 richieste ciascuna. Le latenze mediane sono variate da 119,87 ms a 136,61 ms, con latenze p95 tra 144,96 ms e 542,31 ms.
• Metadati dell'Evidenza: I metadati dello snapshot hanno riportato 172.228 righe di evidenza attraverso quattro fonti. Tutti e quattro i record di evidenza di alto livello selezionati contenevano il 100% dei campi richiesti (affermazione/titolo, fonte, conteggio righe, freschezza e limitazione/confine).
• Lineage e Confini: Il verificatore del lineage canonico è passato, confermando la coerenza tra i conteggi riportati di righe/fonte e i metadati. La scansione del linguaggio pubblico non ha trovato frasi proibite e lo stato del manifesto della fonte è stato incluso.
• Stato degli Strumenti: Uno script locale di validazione dell'artefatto è stato segnalato come elemento di manutenzione a seguito di cambiamenti nel layout della fonte, ma ciò non ha influenzato le affermazioni principali del sistema.

Contributi Chiave e Significato
Il documento posiziona Pokala HealthIntel non come un sistema di supporto alle decisioni cliniche, un modello diagnostico o un motore di raccomandazione terapeutica, ma come una dimostrazione di sistemi di informatica sanitaria.

• Modello Auditabile: Il contributo primario è un modello modesto e auditabile per la revisione di evidenze da fonti pubbliche. Dimostra che le affermazioni di revisione selezionate possono rimanere strutturalmente collegate ai metadati di fonte, scala, freschezza e limitazione all'interno di uno spazio di lavoro distribuito.
• Comunicazione dei Confini: Il sistema impone esplicitamente un confine "no-PHI" e "non clinico". Incorporando i campi di limitazione direttamente nello schema del record di evidenza, il design mira a prevenire l'interpretazione errata di artefatti pubblici come inferenze a livello di paziente o validazione clinica.
• Provenienza e Allineamento FAIR: Sebbene non sia una certificazione formale, il sistema operazionalizza i principi di provenienza (W3C PROV) e i principi dei dati FAIR assicurando che le affermazioni derivate siano accompagnate dai metadati necessari per giudicare la loro idoneità all'uso.

Limitazioni e Ambito
Gli autori dichiarano esplicitamente che questo lavoro è una valutazione a livello di implementazione, non uno studio di validazione clinica. Il sistema non fornisce diagnosi, triage o guida specifica per il paziente. Le metriche di valutazione (latenza, disponibilità) riflettono un singolo test e non costituiscono un accordo sul livello di servizio (SLA) o una garanzia di affidabilità della produzione. Inoltre, sebbene lo stato del manifesto della fonte sia incluso, è necessario un lavoro futuro per espanderlo in un manifesto a monte completo con URL di recupero, checksum e note di trasformazione. Il documento conclude che lo spazio di lavoro serve come prova di concetto per l'uso secondario responsabile di dati sanitari pubblici, distinto dall'IA clinica o dalle piattaforme cliniche di produzione.