È possibile applicare "Agile" ai team IT dell'assistenza sanitaria?

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 sottostanno al manifesto Agile (elenco strappato spudoratamente da Wikipedia con il mio commento):

• Soddisfazione del cliente mediante consegna rapida di software utile . Quando non è questo un obiettivo?
• Benvenuto nel cambiare i requisiti, anche in ritardo nello sviluppo . Healthcare IT si integra in un settore che, seppure completamente sommerso dalla tecnologia, non è particolarmente focalizzato sull'IT. Il potenziale per un sistema che è stato progettato per "farcela" fin da subito è piuttosto basso.
• Il software di lavoro viene consegnato frequentemente (settimane anziché mesi) . Come utente finale di alcune di queste cose, a me piacerebbe questo. I cambiamenti rapidi e di lavoro hanno un valore inestimabile e cosa trasforma Healthcare IT da "quella cosa che dobbiamo fare" a "quella cosa che cambia il modo in cui faccio il mio lavoro".
• Il software di lavoro è la principale misura di 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 . Si vede tutto questo sulla sanità, dalla sorveglianza delle infezioni a HIT alle strutture. L'assistenza sanitaria non è un ciclo boom-and-bust, è un drumbeat costante.
• Stretta collaborazione quotidiana tra uomini d'affari e sviluppatori . La maggior parte degli HIT non è uno strumento per gli sviluppatori. È uno strumento creato dagli sviluppatori. Il contatto con il cliente è, e dovrebbe essere, la chiave. È anche molto più semplice ottenere un sistema adottato se funziona e si integra nel flusso di lavoro dei clienti, piuttosto che dover essere attaccato, rattoppato, ecc.
• La conversazione faccia a faccia è la migliore forma di comunicazione (co-locazione) . Dalla mia interazione con i medici, è modo più facile ottenere cose fatte di persona, preferibilmente con fogli di carta, che in qualsiasi altro modo.
• I progetti sono costruiti attorno a individui motivati, di cui ci si deve fidare . Questo è qualcosa che renderà la tua vita migliore - quindi sì, dovrebbe essere adottato;)
• Attenzione continua all'eccellenza tecnica e al buon design . Questo è di nuovo uno di quelli "tutti dovrebbero farlo, quindi ovviamente dovresti" cosa. Ma considerate 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 idiote Gli operatori sanitari sono persone. Quindi ... tu conosci il resto. La semplicità aiuta.
• Squadre auto-organizzanti . Questo potrebbe essere un po 'più di un tratto per HIT. Onestamente, non sono abbastanza fiducioso da dire in un modo o nell'altro se l'auto-organizzazione in questo contesto è buona o meno.
• Adattamento regolare alle circostanze mutevoli . HIT è un'industria attiva e in crescita con oneri normativi complessi e mutevoli. Essere in grado di adattarsi sembra una buona idea.

Le discussioni sull'uso dello Sviluppo di software per dispositivi medici agili in un ambiente regolamentato dalla FDA sono in giro da un po 'e sono rilevanti per questa domanda. Ecco alcuni motivi per cui:

1. I vantaggi e svantaggi di Waterfall vs. Iterative sono essenzialmente gli stessi e dovrebbero essere presi in considerazione per qualsiasi progetto di Health IT.
2. I sistemi di qualità obbligatori della 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 utilizzato è 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 Health IT sarebbe notevolmente migliorata se tutte queste best practice fossero seguite da tutti.
3. La maggior parte dello sviluppo del software IT di Heath non lo fa attualmente operano secondo questi standard normativi FDA. Come il continuano a diminuire le barriere per l 'interoperabilità dei dispositivi medici in particolare per le piattaforme mobili, probabilmente lo farà modifica - vedi FDA indirizza le app mediche mobili .
4. Inoltre, se stai sviluppando un software commerciale Health Health devi chiederti se stai creando un MDDS (medical device data system): 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 dalle preoccupazioni relative alla (a) sicurezza dei pazienti & qualità del prodotto e (b) regolamentazione del settore.

Per quanto riguarda la sicurezza e la qualità, tieni presente che è difficile creare software sicuro. Alcuni buoni programmatori con una certa conoscenza del dominio possono lanciare software incredibilmente utile che è abbastanza sicuro. Se fanno parte dell'implementazione in un ambiente clinico locale e possono continuare a rispondere e ad adattarsi agli eventi durante l'implementazione e l'utilizzo del software, il software potrebbe fornire valore, salvare o migliorare vite umane con solo pochi infortuni o morti relativi all'utilizzo di errori o bug del software. Ma il software richiederà che i programmatori siano sempre presenti, rispondendo e co-evolvendo 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 sicuro il software, ci sono importanti fasi del processo di sviluppo che devono essere intraprese durante lo sviluppo del software. Una buona introduzione "pronta all'uso" 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 del caso d'uso e lo sviluppo della storia, requisiti elucidazione, progettazione di sistemi e architettonici, implementazione, test di unità e integrazione. Essere agili non renderà nulla di questo lavoro andare via, o essere meno difficile, ma concentrandosi sulla creazione di valore ed eliminando il lavoro (come funzionalità non necessarie, o cicli di test / correzione eccessivi di verifica) 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 nello stesso tempo. Le pratiche di sviluppo iterativo comunemente utilizzate dai team agili sono molto adatte per portare a termine il lavoro di gestione del rischio per la sicurezza, evolvendo per tutta la durata del progetto piuttosto che essere un ripensamento. E dopo che il software è operativo, il feedback degli utenti e di eventuali eventi che potrebbero portare a lesioni personali devono essere considerati, individualmente e in modo aggregato, per mantenere il software sicuro da utilizzare. 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 progettuali ben comprese che sono state create quando il software è stato sviluppato. / p>

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 ad attraversare la linea. In pratica, le normative globali sono complesse e in rapido movimento in questo settore, il che significa che un giorno si può sviluppare una piccola app per iPhone che mostra alcuni dati medici, e il prossimo ci si aspetta che siano conformi agli standard ISO e FDA per "gestione della qualità" sistema "o QMS. Ciò può essere spaventoso per le aziende che non hanno avuto un SGQ formale in passato. E agile può esacerbare questo perché si potrebbe iniziare con un concetto di prodotto, e attraverso lo sviluppo evolutivo entrare involontariamente in un uso previsto regolamentato (come la visualizzazione di dati di diagnosi clinica per un utente). È ottobre 2011; Il mio consiglio a qualsiasi azienda che contempli di 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'agilità può essere d'aiuto, poiché le pratiche agili generalmente producono (o potrebbero facilmente produrre) output conformi per soddisfare i clienti normativi sia per richieste di autorizzazione prima del mercato (come FDA 510k), certificazione (come ISO 13485), sia per operazioni successive al mercato. Lo sviluppo test-first si adatta perfettamente al software medico. L'integrazione continua, i test automatizzati delle unità ei metadati di sprint SCRUM possono fornire una prova oggettiva completa che la gestione dei rischi e la verifica corretta vengono eseguite non solo come un ripensamento, ma integrate nel processo di sviluppo. Nella maggior parte dei casi, penso che l'agile produca più artefatti di "cascata", forse non nella stessa forma. Ma la conversione delle uscite in qualcosa di soddisfacente è un problema relativamente piccolo da risolvere.

Quindi, in sintesi ... sì, Virginia è agile per lo sviluppo di software per la sanità IT (e altri dispositivi medici). Come tutte le cose agili, ci vuole dedizione per elaborare, supporto aziendale e coraggio.

Sì, una delle premesse dello sviluppo agile è il coinvolgimento del cliente. Questo è fondamentale nei sistemi e nei processi IT sanitari. I reparti IT dell'assistenza sanitaria prenderanno decisioni migliori se un rappresentante del cliente sarà coinvolto e fornirà indicazioni su come le decisioni influiranno sulla cura del paziente.

Penso che sia possibile, ma l'industria ha bisogno di un enorme cambio di paradigma. Sono al mio secondo anno come sviluppatore sanitario, e la fiducia e l'auto organizzazione non sono dovunque apparenti. L'assistenza sanitaria trarrebbe grande beneficio dall'adozione formale dell'agile, dal momento che è comunque il caos, con uno sviluppo iterativo chiamato "thrash" e requisiti in continua evoluzione perché, beh, il design di grandi dimensioni in anticipo non funziona comunque.

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

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

A mio parere, qualunque prodotto tu stia producendo, non sei in grado di determinare ALL i requisiti in anticipo, quindi un metodo di sviluppo software agile funziona molto bene.

Come notato, la risposta è sì.

Quando si applica Agile alle aree regolamentate o ad alto rischio, è necessario definire "Fatto" ad ogni iterazione in modo da includere la conformità normativa e altre strategie di mitigazione del rischio. Ad esempio, ciò potrebbe richiedere la documentazione di QA, la tracciabilità dei requisiti, la verifica della sicurezza e altre azioni da completare a ogni iterazione.

Ci sono buone arti e pratiche, ad esempio, per l'applicazione di 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 Agile Manifesto :

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Gli organismi di regolamentazione valutano il lato sinistro come fanno i team agili, ma richiedono una maggiore enfasi sul lato destro rispetto a 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.

Il rovescio della medaglia, molti principi agili si adattano molto bene al mondo sanitario, tra cui:

• TDD e programmazione coppie - aumenta la qualità
• Stretti loop di feedback dei clienti: la validazione anticipata è ottima
• Pianificazione iterativa: gli organismi di regolamentazione si occupano di pianificazione

Alcune discipline sono già di natura agile. L'infermieristica, per esempio, fa affidamento su un ciclo di 'valutazione-valutazione-pianificazione-intervento' che dipende da più iterazioni di diagnosi / prognosi per ottenere risultati finali in modo incrementale.

Tuttavia, sarebbe una conflittualità fatale cercare di suggerire che i servizi di assistenza sanitaria forniti in questo modo sono specificamente adatti per un'applicazione essenzialmente a istanza singola dello sviluppo del software Agile verso uno strumento software o un sistema da utilizzare in tale servizio. .

AAMI sta lavorando attivamente a una relazione informativa tecnica dal titolo: < br> 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 altri aspetti pratici del prodotto associati al software dei dispositivi medici.