Esempio svolto. Questo è un esempio svolto illustrativo, non un risultato di un cliente. Il gruppo di cliniche e ogni numero sono ipotesi. Mostra l'ia per l'autorizzazione preventiva: software che legge la cartella del paziente, estrae i fatti richiesti dall'assicuratore e compone il fascicolo. Non decide la necessità medica e non invia nulla da solo. Un coordinatore approva.
Immagina un gruppo di più cliniche in cui preparare il fascicolo di autorizzazione preventiva è lento. Per illustrare, ipotizza che i coordinatori passino il tempo a copiare fatti tra una cartella clinica, un portale dell'assicuratore e una checklist. Questo post percorre il design e cosa misurare. Non riporta alcun risultato.
Il gruppo è ipotetico, quindi non c'è nessun cliente da nominare. Un dettaglio conta più di un nome: la pipeline estrae e compone, ma non invia mai in automatico. Un coordinatore approva ogni fascicolo, e ogni esecuzione conserva un registro di audit di ciò che il modello ha letto e prodotto.
#Dove se ne va il tempo in un caso di autorizzazione preventiva?
Comincia misurando, non costruendo. Osserva i coordinatori preparare un campione di casi e cronometra ogni passaggio. Scrivere è veloce. Cercare, leggere e ribattere è lento.
- Leggere la cartella per individuare la diagnosi, i farmaci provati senza successo e le note del medico prescrittore.
- Far corrispondere quei fatti AI requisiti dello specifico assicuratore, che cambiano da piano a piano.
- Ribattere tutto nel fascicolo e nel portale, poi ricontrollare, tra un'interruzione e l'altra.
- Aspettare. Un fascicolo a metà resta fermo finché il coordinatore non ci torna.
Quindi l'obiettivo non è mai stato "scrivere più in fretta". Era "smettere di far cercare a una persona dati che sono già nella cartella".
#Come l'ia per l'autorizzazione preventiva riduce il lavoro di preparazione?
Come riduce l'ia il tempo di preparazione dell'autorizzazione preventiva?
Legge la cartella, estrae i fatti clinici richiesti dall'assicuratore e scrive il fascicolo in modo che un coordinatore rilegga invece di ribattere. Un gruppo di cliniche misurerebbe tempo di preparazione e ore dei coordinatori prima e dopo. Il coordinatore approva comunque ogni invio prima che raggiunga l'assicuratore.
La pipeline funziona in quattro passaggi: estrarre i dati rilevanti dalla cartella, assemblarli nel formato del pacchetto del payer, validare che i campi richiesti siano presenti e coerenti tra loro, poi instradare il pacchetto verso la coda di approvazione di un coordinatore. Niente esce da quella coda senza che un umano clicchi approva.
Il design usa lo stesso schema di elaborazione documentale dei nostri esempi svolti su sinistri logistici e onboarding, adattato a un settore sanitario regolamentato. La forma è descritta nella nostra pagina di implementazione ia: estrarre, validare, instradare, coda di approvazione umana. La differenza qui è il registro di audit. Trattandosi di sanità, si registra ogni campo che il modello ha letto e ogni campo che ha scritto, così un revisore può risalire da qualsiasi riga del fascicolo alla sua fonte nella cartella.
#Cosa succede quando l'AI sbaglia un dato?
Viene intercettato, perché una persona lo legge. è tutto il senso della coda di approvazione. Aspettati che una parte dei fascicoli redatti richieda a un coordinatore di correggere o aggiungere un campo, e monitora quel tasso. Non è un fallimento della pipeline. è la pipeline che fa il suo lavoro: fornire presto una bozza perché una persona dedichi il suo tempo a rivedere invece che a cercare.
We are
Stennir costruisce una pipeline di elaborazione documentale che prepara la bozza dei pacchetti di autorizzazione preventiva perché un coordinatore li approvi, con un audit trail completo.
We aren't
Stennir non è un bot a invio automatico che decide la necessità medica o presenta claim a un payer da solo.
Qui non c'è nessuna citazione di un cliente, perché non c'è nessun cliente. Il test del design è se i coordinatori smettono di ribattere la cartella mentre il modello non decide nulla.
#Cosa misurerebbe un gruppo di cliniche?
Tempo di preparazione del fascicolo e ore dei coordinatori, prima e dopo, sulle stesse cliniche, con gli stessi coordinatori e lo stesso mix di assicuratori, con la linea di base rilevata prima che cambi qualcosa. è così che si distingue un miglioramento reale da una demo. Qui non si dichiara alcun risultato.
Se dirigi le operations di un gruppo di cliniche e il tuo team ribatte cartelle nei portali degli assicuratori, è questa la forma di lavoro a cui si adatta. Cominciamo misurando, come fa questo esempio, prima di costruire qualsiasi cosa. Puoi leggere come lo impostiamo nella nostra pagina di consulenza ia, e come ragioniamo nel resto del journal. Se suona come la tua settimana, raccontaci cosa stai costruendo.
