MVP nel settore sanitario: come lanciare velocemente senza

Quando si tratta di prodotti sanitari minimi funzionanti, non puoi permetterti di lanciarli se non sei ancora sicuro. Anche se la velocità di immissione sul mercato è fondamentale in questo settore super competitivo, la sicurezza, la protezione e la conformità normativa dei prodotti sanitari sono ancora più importanti. Allora, come dovrebbe essere un MVP sanitario ideale e come possono gli innovatori del settore sanitario essere veloci senza prendere scorciatoie né in ambito clinico né in quello della sicurezza? Abbiamo accumulato esperienze in oltre 300 progetti per delineare come lanciare un MVP sanitario il più rapidamente possibile senza tralasciare nulla.

In generale, un MVP, che è anche conosciuto come prodotto minimo funzionante, è la versione prototipo del tuo prodotto che devi lanciare per capire se il tuo concetto di prodotto risponde esattamente al problema che l'utente sta vivendo. L'idea di base della fase di sviluppo MVP è che dovrebbe essere fatto come un prodotto con solo le caratteristiche essenziali che servono per farlo funzionare. Una volta lanciato, gli sviluppatori raccolgono i commenti degli utenti per poter aggiungere altre cose in base a quello che vuole il mercato. Comunque, un prodotto minimo funzionante nel settore sanitario è molto diverso dai normali MVP orientati al consumatore:

Differenze chiave tra MVP standard e MVP sanitari

Contrariamente a quanto si pensa, un prodotto minimo funzionante nel settore sanitario richiede strategie diverse. In poche parole, da dove inizi dipende da dove c'è il rischio più grande:

Quando usare ciascun approccio

Prova di concetto (PoC) - Quando ti trovi nella fase "Riusciremo a realizzarlo in modo sicuro?", il tuo progetto sanitario richiede una prova di concetto per capire se la tua idea tecnologica ad alto rischio può essere implementata con successo dal punto di vista tecnico. Una PoC è di solito pensata per essere usata internamente. Prototipo - La risposta alla domanda "I medici e i pazienti lo useranno nel modo giusto?" è dare un prototipo. Un prototipo è un modello illustrato e interattivo di un'idea di prodotto che mostra come sarà e cosa farà. MVP - Il primo vero traguardo che risponde alla domanda "Funziona e rispetta i requisiti?" è un MVP. A differenza dei PoC e dei prototipi, gli MVP sono pronti e possono anche essere testati nel mondo reale in condizioni controllate.

Gli MVP sanitari non sono minimi. Il processo di creazione di un MVP ha più a che fare con lo sviluppo di un prodotto minimo funzionante e convalidato di cui gli utenti possano fidarsi, sia dal punto di vista clinico che etico. La velocità è importante, ma per ottenere slancio, gli innovatori devono affrontare questioni di sviluppo specifiche del settore.

Andare veloci con un playbook normativo

Nel caso di un'azienda che sta sviluppando un'applicazione da usare nella pratica clinica, i requisiti normativi sono parecchio severi, e giustamente. Questi prodotti software, visto che possono influenzare i risultati sanitari, influenzare le decisioni cliniche e persino causare danni alla salute, devono seguire le regole della FDA, dell'EU MDR e di altri regolamenti in giro per il mondo. Le normative mediche di solito dicono che i team di sviluppo devono avere:

• Processi organizzati (Sistema di gestione della qualità ISO 13485)
• Registrazioni relative alla progettazione e ai controlli dei rischi (IEC 62304 Ciclo di vita del software e ISO 14971 Gestione dei rischi)
• I sistemi convalidati ci sono anche se è solo un MVP

A differenza di altri MVP basati sul campo, gli MVP sanitari non si limitano a coinvolgere gli utenti. Il loro obiettivo principale è dimostrare la loro sicurezza ed efficacia in contesti reali di cura dei pazienti e nel flusso di lavoro clinico. Ciò può comportare:

• Recensioni professionali con prodotto
• Test di usabilità
• Programmi pilota approvati da un comitato di revisione istituzionale (IRB)

Non tutti gli MVP sanitari devono passare attraverso lunghi studi clinici; però, tutti devono essere basati su una scienza plausibile perché il confine tra benessere e medicina è sottile.

Fiducia degli utenti ad alto rischio

I software sanitari non vengono usati da un gruppo di utenti con interessi elevati (pazienti) e bassi (operatori sanitari) che il software deve soddisfare senza cercare soluzioni alternative. Per creare questo livello di fiducia durante lo sviluppo dell'MVP, il team di sviluppo dovrà:

• Lavora insieme al personale in prima linea per mappare le caratteristiche cliniche ai percorsi clinici già esistenti
• Capisci e basa le caratteristiche sulle linee guida mediche o sulle prove scientifiche
• Crea l'esperienza utente seguendo le migliori pratiche di accessibilità (WCAG, ADA)
• Sii chiaro sui limiti dell'applicazione

Sicurezza dei dati e interoperabilità garantite

Un MVP nel settore sanitario non arriverà nemmeno alla fase pilota o alle discussioni di partnership con un livello minimo di sicurezza dei dati. Ecco perché la crittografia, l'accesso basato sui ruoli, i registri di controllo e altri standard industriali esistenti in materia di sicurezza dei dati sono un requisito imprescindibile per un'app sanitaria fin dal primo giorno. Oltre alla sicurezza dei dati, i team di sviluppatori sanitari devono pensare all'interoperabilità fin dall'inizio, nel caso in cui il prodotto debba essere parte di un ambiente tecnologico sanitario più ampio. L'interoperabilità implica la creazione di un'app che condivida i dati con cartelle cliniche elettroniche, sistemi ospedalieri e dispositivi indossabili. Dal punto di vista tecnico, l'interoperabilità è garantita grazie a:

• Standard dei dati, inclusi HL7 o FHIR
• Usa i vocabolari standard, come SNOMED CT, LOINC o ICD-10

Per creare un MVP nel settore sanitario ci vogliono in media dai 2 ai 6 mesi. Il tempo necessario dipende soprattutto da quanto è complicato il prodotto, dalle regole e dalle caratteristiche che sono state messe nell'MVP.

Scoperta del prodotto

Il processo di sviluppo del prodotto inizia con un'approfondita analisi del prodotto, che aiuta chi è coinvolto nel progetto a capire bene lo scopo del prodotto, chi lo userà e le regole da seguire. Risultati attesi: specifiche di prodotti di qualità per l'assistenza sanitaria, wireframe, un prototipo funzionante e un modello di business approvato per il prodotto.

Pianificazione dello sviluppo

Anche se nella fase di scoperta del prodotto viene definito un elenco di caratteristiche indispensabili, quando il team perfeziona le caratteristiche e le classifica in un secondo momento, si basa su:

• Necessità clinica - Cosa serve per garantire la sicurezza dei pazienti e la facilità d'uso?
• Rischio normativo - Quali caratteristiche potrebbero portare a un aumento dei requisiti di conformità?
• Budget e tempistiche - Come possiamo trovare un equilibrio tra portata e fattibilità?

Risultati attesi: definizione dello stack tecnologico, composizione del team e calendario, progetto dell'architettura della soluzione, stima preliminare dei costi.

Sviluppo e test MVP

Anche se l'MVP sanitario ha delle caratteristiche uniche nell'implementazione, le fasi di progettazione e sviluppo seguono gli stessi modelli di sviluppo agile o iterativo degli altri progetti, ma con un'organizzazione più forte e un livello di documentazione più alto. Se il team crea app per raccogliere risultati clinici o inviarli alle autorità (FDA/marchio CE), gli sviluppatori devono seguire gli standard ISO 13485 e IEC 62304. Risultati attesi: Sistema di progettazione UI/UX definitivo, MVP funzionale, codice sorgente e documentazione tecnica, rapporti di collaudo.

Convalida e rilascio MVP

Questo vuol dire che un MVP sanitario deve essere testato nel mondo reale, tipo con test clinici e normativi, quando è quasi pronto. Invece di un lancio generale, all'inizio viene usato in contesti controllati che possono includere:

• Programmi pilota con operatori sanitari
• Studi approvati dall'IRB
• Implementazioni per uso interno in collaborazione con consulenti clinici
• Ambienti sandbox insieme a versioni di prova di EHR o sistemi di terze parti

I prezzi dello sviluppo di MVP nel mercato sanitario dipendono dal progetto e dalle caratteristiche dell'app, dal processo di regolamentazione e dalle tecnologie. Per questo motivo consigliamo sempre di richiedere un preventivo gratuito alla società di sviluppo, in modo da avere un'idea realistica dei costi da sostenere.

Esempio di ripartizione dei costi

Basandoci sul nostro progetto di piattaforma di monitoraggio remoto dei pazienti, ecco una ripartizione dettagliata dei costi (stimati a 50 dollari l'ora):

Se c'è una cosa che abbiamo imparato in 15 anni di attività sul mercato, è che i progetti di sviluppo di software per il settore sanitario sono molto complessi e coinvolgono numerose variabili.

Inizia con la questione specifica e giusta (e non con la tecnologia più cool)

Le aziende non possono cercare di trasformare l'intera assistenza nella versione 1 in un cambiamento radicale. Iniziare con un piccolo passo (il più piccolo possibile), come la digitalizzazione di un flusso di lavoro manuale o un'area specifica di interesse clinico, aiuterà il prodotto a ottenere una prima trazione e credibilità. Esempio: Teladoc non è nato come un modello completo di assistenza virtuale. All'inizio, il prodotto era una soluzione essenziale che offriva ai pazienti accesso 24 ore su 24, 7 giorni su 7, a medici autorizzati, nei casi non urgenti.

Investi nella documentazione come parte del prodotto

Anche se le aziende che vogliono seguire un percorso normativo spesso hanno già tutto pronto, quelle che stanno sviluppando una soluzione inizialmente non regolamentata spesso saltano questo passaggio.

Progettare tenendo conto dei vincoli normativi

Nella maggior parte dei casi di innovazione, chi lavora nel settore sanitario pensa che la conformità o un'esperienza utente (UX) facile da usare siano le uniche due opzioni. Ma non deve per forza essere così, se il team di progettazione usa la conformità normativa come un limite creativo.

Conosci bene la classificazione del tuo SaMD

Se la tua soluzione sanitaria ha uno o più usi medici, che vengono fatti senza che sia un dispositivo medico hardware, probabilmente rientra nella categoria Software come dispositivo medico.

Non basta dire che la loro IA è precisa al 99%, bisogna dimostrarlo

Nel settore sanitario, un'azienda non può andare in giro dicendo che i suoi algoritmi sono i migliori. Gli enti di regolamentazione come la FDA (e anche i medici) vogliono vedere dimostrazioni concrete e reali che il tuo strumento mantiene le promesse.

La velocità non è mai a buon mercato nell'innovazione sanitaria

Puoi arrivare solo fino a un certo punto con lo sviluppo rapido di funzionalità critiche a scapito della sicurezza, della conformità e della fiducia degli utenti. L'MVP nel settore sanitario non implica la creazione del prodotto più piccolo possibile. Si tratta piuttosto di creare l'iterazione più sicura della tua visione che ne mantenga comunque l'impatto sul mondo reale. Quando si parte da un approccio che mette al primo posto la conformità normativa, si parallelizza la validazione clinica e si struttura in modo modulare per espandersi in futuro, è possibile entrare nel mercato più rapidamente, senza dover apportare tagli che finiscono per ritorcersi contro.