L'intelligenza artificiale fisica nel settore sanitario: ingegneria di dispositivi medici e flussi di lavoro

Cosa significa l’intelligenza artificiale fisica in medicina?

Considera uno strumento di laboratorio che osserva un portacampioni, un prototipo di riabilitazione che misura il movimento o un assistente robotico che risponde al feedback dei sensori. Ciascuno combina osservazioni fisiche con calcoli e un risultato che qualcuno può utilizzare. L'output potrebbe guidare un operatore, organizzare un'attività o contribuire a una funzione del dispositivo.

Inizia scrivendo lo scopo previsto in un linguaggio semplice. Chi utilizzerà il sistema? In quale ambiente? Cosa osserva? Quali risultati fornisce e chi decide cosa succederà dopo? Un sistema che sposta le forniture all’interno di un ospedale non dovrebbe ereditare le affermazioni o i presupposti di un dispositivo utilizzato nella cura dei pazienti.

Per i dispositivi medici abilitati all’intelligenza artificiale negli Stati Uniti, lo FDA descrive un approccio che considera l’uso previsto e le caratteristiche tecnologiche. Il percorso di mercato di un dispositivo non può essere dedotto dal suo processore o dall’etichetta “AI”. Vedi il Panoramica dei dispositivi medici abilitati all'intelligenza artificiale di FDA. I requisiti in altri mercati necessitano di una valutazione propria con il produttore responsabile e gli specialisti in regolamentazione.

Aree applicative da valutare

Questi esempi descrivono possibili progetti di ingegneria. Non affermano che Alvexis attualmente fornisca dispositivi medici approvati o algoritmi di intelligenza artificiale validati clinicamente.

Un utile brief di progetto distingue il sottosistema di rilevamento, la funzione AI e il prodotto finale. Un'integrazione riuscita della fotocamera non convalida di per sé un'interpretazione clinica. Una dimostrazione del modello funzionante non stabilisce di per sé l'idoneità elettrica, meccanica o del flusso di lavoro.

Progettare insieme il percorso di misurazione e il percorso decisionale

Definire l'interfaccia tra queste fasi. Per un prototipo di rilevamento, registrare le unità, le frequenze di campionamento, i parametri di calibrazione e qualsiasi trasformazione applicata prima della conservazione. Per una pipeline di immagini, includere esposizione, ottica e illuminazione nella configurazione. Le modifiche all'acquisizione possono cambiare il significato dell'input di un algoritmo.

Specificare l'aspetto di un'osservazione non valida. Un sensore disconnesso, un contatto inadeguato, una visuale oscurata o un segnale fuori portata non dovrebbero diventare una conseguenza ordinaria. Includere uno stato esplicito non disponibile o incerto, quando appropriato, e decidere come risponde l'utente o la funzione downstream.

L'elaborazione locale può ridurre la quantità di dati grezzi che devono lasciare il dispositivo e può aiutare il flusso di lavoro a funzionare durante un'interruzione della rete. Non rende automaticamente un prodotto privato o sicuro. Definire i dati conservati, l'accesso autorizzato, la trasmissione, la cancellazione e le interfacce di manutenzione per la particolare installazione.

Cosa cambia quando il prototipo diventa un prodotto fisico?

L'imballaggio e l'installazione fanno parte dell'ambito di sviluppo. Discutere con il proprietario del prodotto le condizioni di contatto, i metodi di pulizia, il montaggio, l'accesso ai connettori, i limiti termici e le procedure di assistenza. Il team responsabile dovrebbe identificare quali valutazioni elettriche, meccaniche, di usabilità e normative si applicano al dispositivo previsto.

Costruisci il piano energetico e termico in base al carico di lavoro completo. Acquisizione, elaborazione, visualizzazione, comunicazione e registrazione possono essere eseguite insieme. Misurare il comportamento sostenuto all'interno dell'involucro proposto e durante il ciclo di lavoro previsto. La specifica di picco di un acceleratore non è un risultato completo delle prestazioni del prodotto.

Pianificare l'accesso per calibrazione, test di produzione e indagini sui guasti. Una baseboard personalizzata può fornire le interfacce e l'adattamento richiesti, ma crea anche responsabilità per la disponibilità dei componenti, la verifica della scheda e il controllo della configurazione. Il baseboard personalizzato per una guida al modulo di calcolo spiega tali dipendenze del progetto.

Mantenere distinte la verifica tecnica e l'evidenza clinica

La verifica ingegneristica può stabilire che un sottosistema misura, elabora e comunica secondo le sue specifiche. La valutazione clinica chiede se la funzione finale funziona in modo appropriato per lo scopo medico previsto. Nessuno dei due dovrebbe essere sostituito dall'altro.

Il Principi di trasparenza FDA, Health Canada e MHRA enfatizzare chiaramente l'uso previsto, gli utenti, le popolazioni, il flusso di lavoro, le prestazioni e le limitazioni. Discutono anche della comunicazione dei cambiamenti e del monitoraggio delle prestazioni. Per un team di progetto, questi sono suggerimenti utili per specificare di quali prove e informazioni sull'utente ha bisogno il prodotto.

Gli FDA Risorsa GMLP sottolinea i principi IMDRF che coprono il ciclo di vita dei dispositivi medici. La pianificazione dello sviluppo dovrebbe includere il prodotto distribuito e le relative modifiche, anziché terminare con l'addestramento di un modello.

Un modo per organizzare il progetto è una tabella di tracciabilità: per ogni funzione dichiarata, registrare le condizioni di input richieste, l'output, il metodo di verifica, il proprietario e la prova di accettazione. Includere casi di fallimento e revisione umana. Congelare l'hardware, il software, il modello e la configurazione utilizzati per ciascuna valutazione in modo che i risultati possano essere interpretati e riprodotti.

Un primo pilota pratico

1. Concordare scopo e proprietà. Identificare il produttore, gli utenti previsti, i partner clinici ove pertinente e il team responsabile dell'accettazione.
2. Scegli una domanda ristretta. Gli esempi includono la ripetibilità della misurazione, l'osservazione della posizione del campione o il rilevamento dello stato dell'apparecchiatura in condizioni definite.
3. Definire il riferimento. Specificare il processo di misurazione o revisione utilizzato per valutare i risultati. Concordare le autorizzazioni relative ai dati prima di raccogliere informazioni relative al paziente.
4. Strumentare il prototipo. Registra i tempi, la qualità dell'input, lo stato di elaborazione e la configurazione del dispositivo insieme al risultato.
5. Rivedere le prove prima dell'espansione. Decidere cosa dimostra il prototipo, cosa rimane incerto e quale ulteriore valutazione è necessaria per il prodotto previsto.

Mantenere espliciti i confini di una dimostrazione di ricerca o di ingegneria nell'accordo pilota. Passando dall'osservazione alla decisione di cura o all'azione fisica, cambia ciò che deve essere stabilito prima dell'uso.

Dove Alvexis si inserisce nel programma di sviluppo

Alvexis può discutere di progettazione elettronica personalizzata, interfacce di sensori, supporto software integrato e integrazione meccanica con OEM medicali, gruppi di ricerca e integratori di sistema. La prima conversazione dovrebbe identificare il sottosistema di ingegneria e le prove che il programma di prodotto più ampio richiederà.

Per il progetto concordato devono essere stabilite l'idoneità medica specifica, le responsabilità del sistema di qualità, le affermazioni cliniche e l'autorizzazione all'immissione in commercio. Questo articolo descrive un approccio ingegneristico; non si intende affermare che una piattaforma Alvexis esistente sia certificata dal punto di vista medico o autorizzata per la diagnosi o il trattamento.

Per un contesto più ampio, leggi IA fisica in tutti i settori. Per i limiti di movimento, percezione e controllo incorporato, continuare con Guida all'intelligenza artificiale della robotica.