'Agile' può essere applicato ai team IT della sanità?

Agile può essere impiegato in un campo come l'IT sanitario, in cui gran parte dell'assistenza ai pazienti dipende dalla qualità e dalla consegna tempestiva dei sistemi?

Sì, lo sviluppo agile ha assolutamente un ruolo nello sviluppo IT della sanità. Nessuno, non l'utente finale, non il paziente e certamente non il team di sviluppo è ben servito da un processo di sviluppo mal fatto. Considerando alcuni dei principi che sono alla base del manifesto Agile (elenco strappato senza vergogna da Wikipedia con il mio commento):

• Soddisfazione del cliente grazie alla rapida consegna di software utile . Quando non è questo un obiettivo?
• Benvenuti a cambiare i requisiti, anche in ritardo di sviluppo . L'IT sanitario si integra in un campo che, sebbene assolutamente inondato di tecnologia, non è particolarmente focalizzato sull'IT. Il potenziale per un sistema progettato per "farlo bene" fin dall'inizio è piuttosto basso.
• Il software funzionante viene consegnato frequentemente (settimane anziché mesi) . Come utente finale di alcune di queste cose, dio mi piacerebbe questo. I rapidi cambiamenti di lavoro sono inestimabili e ciò che trasforma l'IT Healthcare da "quella cosa che dobbiamo fare" a "quella cosa che cambia il modo in cui svolgo il mio lavoro".
• Il software di lavoro è la principale misura del progresso . Ha senso nella maggior parte delle applicazioni, quindi non c'è davvero alcun motivo per cui non si estenda a HIT.
• Sviluppo sostenibile, in grado di mantenere un ritmo costante . Lo vedi in tutta l'assistenza sanitaria, dalla sorveglianza delle infezioni all'HIT alle strutture. L'assistenza sanitaria non è un ciclo boom-o-bust, è un drumbeat costante.
• Stretta collaborazione quotidiana tra uomini d'affari e sviluppatori . La maggior parte degli HIT non è uno strumento di sviluppo. È uno strumento creato dagli sviluppatori. Il contatto con il cliente è e dovrebbe essere la chiave. È anche molto più facile ottenere un sistema adottato se funziona e si integra nel flusso di lavoro dei client, piuttosto che dover essere applicato, patchato, ecc.
• La conversazione faccia a faccia è la migliore forma di comunicazione (co-location) . Dalla mia interazione con i clinici, è molto più facile fare cose di persona, preferibilmente con blocchi di carta, che in qualsiasi altro modo.
• I progetti si basano su individui motivati, di cui ci si dovrebbe fidare . Questo è qualcosa che renderà la tua vita migliore - quindi sì, dovrebbe essere adottato;)
• Attenzione costante all'eccellenza tecnica e al buon design . Questo è di nuovo uno di quei "tutti dovrebbero farlo, quindi ovviamente dovresti" cosa. Ma considera la complessità dei sistemi HIT e la miriade di modi in cui finiscono per essere utilizzati, giorno dopo giorno. Un sistema scadente non lo taglierà.
• Semplicità . Dovrebbe funzionare fuori dalla scatola. Dovrebbe funzionare bene, sempre e nel modo in cui dovrebbe. Le persone sono idioti. Gli operatori sanitari sono persone. Quindi ... tu conosci il resto. La semplicità aiuta.
• Team auto-organizzanti . Questo potrebbe essere un po 'più di un tratto per HIT. Onestamente, non sono abbastanza sicuro di dire in un modo o nell'altro se l'auto-organizzazione in questo contesto è buona o no.
• Adattamento regolare alle mutevoli circostanze . L'HIT è un settore attivo e in crescita con oneri normativi complessi e in evoluzione. Essere in grado di adattarsi sembra un'idea decente.

Le discussioni sull'uso dello sviluppo di software per dispositivi medici Agile in un ambiente regolamentato dalla FDA sono in corso da un po 'di tempo e sono rilevanti per questa domanda. Ecco alcuni motivi:

1. I vantaggi e gli svantaggi di Waterfall vs. Iterative sono essenzialmente gli stessi e dovrebbero essere presi in considerazione per qualsiasi progetto IT di salute.
2. I sistemi di qualità incaricati dalla FDA (vedi Principi generali di convalida del software; Guida finale per il personale dell'industria e della FDA ) per lo sviluppo di software per dispositivi medici utilizzati è lo standard di riferimento del settore. Va notato che questi regolamenti non dettano alcuna particolare metodologia di sviluppo. In ogni caso, la qualità del software IT per la salute sarebbe notevolmente migliorata se queste migliori pratiche fossero seguite da tutti.
3. La maggior parte dello sviluppo di software IT Heath attualmente non opera secondo questi standard normativi FDA. Poiché le barriere per l'interoperabilità dei dispositivi medici continuano a cadere, in particolare per le piattaforme mobili, è probabile che questo cambi - vedi FDA Addresses Mobile Medical Apps .
4. Inoltre, se stai sviluppando un software IT commerciale per la salute, devi chiederti se stai creando un sistema di dati per dispositivi medici (MDDS): Il mio prodotto è un MDDS?

La risposta breve è "Sì". Una risposta più lunga ma più accurata è "Se la prendi sul serio".

Ci sono alcuni temi da tenere a mente, che mi piace separare in preoccupazioni relative a (a) sicurezza dei pazienti e qualità del prodotto, e (b) regolamentazione del settore.

Dal punto di vista della sicurezza e della qualità, tieni presente che è difficile creare un software sicuro. Alcuni bravi programmatori con una certa conoscenza del dominio possono far partire software incredibilmente utile che è abbastanza sicuro. Se fanno parte della distribuzione in un ambiente clinico locale e possono continuare a rispondere e adattarsi agli eventi durante l'implementazione e l'uso del software, il software potrebbe fornire valore, salvare o migliorare la vita con solo poche lesioni o decessi correlati all'uso degli errori o bug del software. Ma il software richiederà ai programmatori di essere sempre presenti, di rispondere, di co-evolvere il software man mano che l'uso del software si evolve. Questo non è un processo scalabile e quando i programmatori muoiono o si annoiano, il sistema può facilmente diventare molto pericoloso molto rapidamente. Al fine di migliorare questi risultati e rendere il software sicuro, ci sono importanti fasi del processo di sviluppo che devono essere prese durante lo sviluppo del software. Una buona introduzione "out of the box" a questi può essere trovata nello standard internazionale per lo sviluppo di software per dispositivi medici, ISO / IEC 62304. Il concetto principale è la gestione del rischio di sicurezza in tutte le fasi - durante l'analisi dei casi d'uso e lo sviluppo della storia, requisiti chiarimenti, progettazione di sistemi e architetture, implementazione, test unitari e di integrazione. Essere agili non farà sparire nulla di tutto questo lavoro, o sarà meno difficile, ma concentrandosi sulla creazione di valore ed eliminando il lavoro (come funzionalità non necessarie o cicli di test / correzione di verifica eccessivi) che non creano valore, lo sviluppo agile può consentire a un team di integrare questo lavoro nello sviluppo, dando vita a un software più sicuro sviluppato contemporaneamente. Le pratiche di sviluppo iterativo comunemente utilizzate dai team agili sono molto adatte per portare a termine il lavoro di gestione dei rischi per la sicurezza, evolvendosi per tutta la durata del progetto anziché essere un ripensamento. E dopo che il software è operativo, è necessario considerare, individualmente e in forma aggregata, il feedback degli utenti e tutti gli eventi che potrebbero portare a lesioni, in modo da mantenere il software sicuro da usare. Agile può aiutare qui se fornisce un processo rapido e sicuro per incorporare le modifiche senza rompere altre parti del sistema - che a sua volta richiede ancora una buona architettura e interazioni di progettazione ben comprese che sono state create durante lo sviluppo del software. evolversi durante la vita del progetto piuttosto che essere un ripensamento. E dopo che il software è operativo, il feedback da parte degli utenti e qualsiasi evento che possa anche portare a lesioni devono essere considerati, individualmente e in forma aggregata, per mantenere il software sicuro da usare. Agile può aiutare qui se fornisce un processo rapido e sicuro per incorporare le modifiche senza rompere altre parti del sistema - che a sua volta richiede ancora una buona architettura e interazioni di progettazione ben comprese che sono state create durante lo sviluppo del software. evolversi durante la vita del progetto piuttosto che essere un ripensamento. E dopo che il software è operativo, è necessario considerare, individualmente e in forma aggregata, il feedback degli utenti e tutti gli eventi che potrebbero portare a lesioni, in modo da mantenere il software sicuro da usare. Agile può aiutare qui se fornisce un processo rapido e sicuro per incorporare le modifiche senza rompere altre parti del sistema - che a sua volta richiede ancora una buona architettura e interazioni di progettazione ben comprese che sono state create durante lo sviluppo del software.

La seconda preoccupazione è normativa. In un mondo ideale, le norme di sicurezza si applicherebbero a tutti i prodotti che potrebbero essere sufficientemente pericolosi e un venditore sarebbe in grado di conformarsi facendo alcune cose semplici una volta che hanno iniziato a varcare il limite. In pratica, le normative globali sono complesse e in rapida evoluzione in questo settore, il che significa che un giorno puoi sviluppare una piccola app per iPhone che mostra alcuni dati medici e il prossimo ti aspetto di rispettare gli standard ISO e FDA per la "gestione della qualità sistema "o QMS. Questo può essere spaventoso per le aziende che non hanno avuto un QMS formale in passato. E l'agile può esacerbare questo perché potresti iniziare con un concetto di prodotto e, attraverso lo sviluppo evolutivo, entrare inconsapevolmente in un uso previsto regolamentato (come la visualizzazione di dati di diagnosi clinica a un utente). È ottobre 2011; il mio consiglio a qualsiasi azienda che intenda commercializzare un prodotto che abbia "salute", "medicina", "assistenza sanitaria" nel nome della categoria è che dovrebbero avere un piano per quando il prodotto che fanno viene regolato da uno o più regolatori di dispositivi medici in tutto il mondo. Anche in questo caso l'agile può aiutare, poiché le pratiche agili generalmente producono (o facilmente potrebbero produrre) risultati conformi per soddisfare i clienti normativi sia per le domande di autorizzazione pre-immissione sul mercato (come FDA 510k), la certificazione (come ISO 13485) e le operazioni post-immissione sul mercato. Lo sviluppo test-first si adatta perfettamente al software medico. L'integrazione continua, i test di unità automatizzati e i metadati di sprint SCRUM possono fornire prove oggettive complete che la gestione del rischio e la corretta verifica vengono eseguite non solo come ripensamento, ma integrate nel processo di sviluppo. Nella maggior parte dei casi penso che l'agile produca più artefatti rispetto alla "cascata", forse non nella stessa forma. Ma la conversione degli output in regolatori soddisfacenti è un problema relativamente piccolo da risolvere.

Quindi, in sintesi ... sì, Virginia, esiste uno sviluppo software agile per l'IT (e altri dispositivi medici). Come tutte le cose agili, ci vuole dedizione al processo, supporto aziendale e coraggio.

Sì, una delle premesse dello sviluppo agile è il coinvolgimento dei clienti. Ciò è fondamentale nei sistemi e nei processi IT sanitari. I dipartimenti IT sanitari prenderanno decisioni migliori se è coinvolto un rappresentante del cliente e forniranno input su come le decisioni influenzeranno l'assistenza ai pazienti.

Penso che sia possibile, ma l'industria ha bisogno di un enorme cambiamento di paradigma. Sono al mio secondo anno come sviluppatore di assistenza sanitaria e la fiducia e l'auto-organizzazione non sono da nessuna parte evidente. L'assistenza sanitaria trarrebbe grandi benefici dall'adottare formalmente agile, dato che comunque è per lo più caos, con uno sviluppo iterativo chiamato "thrash" e requisiti che cambiano in ritardo perché, beh, il grande design iniziale non funziona comunque.

Capisco la tua domanda. Un buon esempio di sviluppo Agile è la creazione di un sito Web per qualcuno. Di solito un cliente non sa esattamente cosa vuole, quindi c'è molta interazione con il cliente.

L'IT sanitario potrebbe sembrare un campo molto predefinito nell'informatica; con i suoi standard rigorosi (DICOM, HL7) sembra che ci sia solo un modo per implementarli, ma ci sono anche molte preferenze e decisioni.

Secondo me, qualunque prodotto tu stia realizzando, non sei in grado di determinare TUTTI i requisiti in anticipo, quindi un metodo di sviluppo software agile funziona molto bene.

Come notato, la risposta è sì.

Quando si applica Agile ad aree regolamentate o ad alto rischio, è necessario definire "Fine" ad ogni iterazione in modo tale da includere la conformità normativa e altre strategie di mitigazione del rischio. Ad esempio, ciò può richiedere la documentazione di QA, la tracciabilità dei requisiti, l'audit di sicurezza e altre azioni da completare su ogni iterazione.

C'è buona arte e pratica, ad esempio, per l'applicazione degli approcci Agile agli ambienti regolamentati dalla FDA.

La risposta breve: Sì. C'è un buon blog su Agile in ambienti ad alta affidabilità che fornisce alcuni suggerimenti.

Tuttavia, ci sono alcuni compromessi che devono essere fatti. Considera il Manifesto Agile :

Individui e interazioni su processi e strumenti

Software funzionante su documentazione completa

Collaborazione con i clienti sulla negoziazione del contratto

Rispondere al cambiamento seguendo un piano

Gli enti regolatori apprezzano il lato sinistro tanto quanto i team agili, ma richiedono più enfasi sul lato destro di quanto farebbe un tipico team agile. La FDA, ad esempio, richiede la convalida dei processi e degli strumenti, richiede una documentazione di progettazione e test abbastanza completa e richiede sicuramente una buona pianificazione.

D'altro canto, molti principi agili si adattano molto bene al mondo dell'assistenza sanitaria, tra cui:

• Programmazione TDD e coppia - aumenta la qualità
• Stretti cicli di feedback dei clienti: la convalida anticipata è ottima
• Pianificazione iterativa - gli organismi regolatori si occupano della pianificazione

Alcune discipline sono già di natura agile. L'assistenza infermieristica, ad esempio, si basa su cicli di "valutazione-valutazione-pianificazione-intervento" che dipendono da più iterazioni di diagnosi / prognosi per raggiungere progressivamente i risultati finali.

Tuttavia, sarebbe una fatale conflazione tentare di suggerire che i servizi di assistenza sanitaria forniti in questo modo sono specificamente adatti a un'applicazione essenzialmente a istanza singola dello sviluppo di software Agile verso uno strumento software o un sistema da utilizzare in detta fornitura di servizi.

AAMI sta lavorando attivamente a un rapporto di informazioni tecniche intitolato:
AAMI TIR SW1, Guida all'uso di pratiche agili nello sviluppo di software per dispositivi medici.

Ho sentito che potrebbe essere pubblicato nel 2012.

Discute l'allineamento dei principi del Manifesto Agile (vedi la risposta di EpiGrads) con i requisiti normativi, i processi tipici e le altre funzionalità del prodotto associate al software dei dispositivi medici.