MVP dans le domaine de la santé : comment se lancer

Quand il s'agit de produits de santé minimums viables, tu n'as pas le choix de les lancer si tu n'es pas encore tout à fait prêt. Même si la rapidité de mise sur le marché est super importante dans ce marché très concurrentiel, la sécurité, la sûreté et la conformité réglementaire du produit de santé sont encore plus importantes. Alors, à quoi ressemblerait un MVP idéal dans le domaine de la santé, et comment les innovateurs peuvent-ils aller vite sans faire de compromis sur la clinique ou la sécurité? On a pu accumuler l'expérience de plus de 300 projets pour montrer comment lancer un MVP dans le domaine de la santé le plus vite possible sans rien oublier.

En gros, un MVP, aussi appelé produit minimum viable, c'est la version prototype de ton produit que tu dois lancer pour voir si ton concept répond bien au problème précis que rencontre l'utilisateur. Le concept de base derrière le développement MVP, c'est de créer un produit avec juste les fonctionnalités de base qu'on pense nécessaires pour qu'il marche. Une fois sorti, les développeurs rassemblent les retours des utilisateurs pour pouvoir ajouter des intégrations supplémentaires en fonction de ce que veut le marché. Mais bon, un produit minimum viable dans le domaine de la santé, c'est vraiment différent des MVP habituels qui s'adressent aux consommateurs :

Différences clés entre les MVP standard et ceux du secteur de la santé

Contrairement à ce qu'on pense souvent, un produit minimum viable dans le domaine de la santé demande des stratégies différentes. En gros, c'est là où le risque est le plus grand que tu dois commencer :

Quand utiliser chaque approche

Preuve de concept (PoC) - Quand tu te demandes « Est-ce qu'on peut vraiment construire ça en toute sécurité? », ton projet de santé a besoin d'une preuve de concept pour voir si ton idée technologique à haut risque peut être mise en place sans problème sur le plan technique. En général, une PoC est plutôt destinée à être utilisée en interne. Prototype - Pour savoir si les pros de santé et les patients vont bien utiliser ça, il faut montrer un prototype. Un prototype, c'est un modèle illustré et interactif d'une idée de produit qui montre à quoi ça ressemble et comment ça marche. MVP - Le premier vrai jalon qui répond à la question « Est-ce que ça marche et est-ce que ça respecte les règles? » est un MVP. Contrairement aux PoC et aux prototypes, les MVP sont prêts à être testés dans des conditions réelles et contrôlées.

Les MVP dans le domaine de la santé ne sont pas minimaux. Leur création consiste davantage à développer un produit minimum viable et validé auquel les utilisateurs peuvent faire confiance, tant sur le plan clinique qu'éthique. La rapidité est importante, mais pour créer une dynamique, les innovateurs doivent s'attaquer aux problèmes de développement spécifiques à l'industrie.

Aller vite avec un guide réglementaire

Quand une boîte développe une appli pour la pratique clinique, les règles à respecter sont super strictes, et c'est tout à fait normal. Ces logiciels, parce qu'ils peuvent influencer les résultats des soins de santé, biaiser les décisions cliniques et même causer des problèmes de santé, sont soumis à la FDA, au RDM de l'UE et à d'autres cadres réglementaires dans le monde. Les réglementations médicales impliquent généralement que les équipes de développement doivent disposer :

• Processus organisés (système de gestion de la qualité ISO 13485)
• Enregistrements de la conception et des contrôles des risques (cycle de vie des logiciels IEC 62304 et gestion des risques ISO 14971)
• Les systèmes validés sont là, même si c'est juste un MVP.

Contrairement aux autres MVP basés sur le terrain, les MVP dans le domaine de la santé ne visent pas seulement à susciter l'intérêt des utilisateurs. Ils visent avant tout à prouver leur sécurité et leur efficacité dans le cadre réel des soins aux patients et du flux de travail clinique. Cela peut impliquer :

• Avis professionnels avec produit
• Tests d'utilisabilité
• Programmes pilotes approuvés par un comité d'éthique

Tous les MVP dans le domaine de la santé n'ont pas besoin de passer par des essais cliniques poussés ; mais ils doivent tous être basés sur des données scientifiques plausibles, car la frontière entre le bien-être et la médecine est mince.

La confiance des utilisateurs, un enjeu crucial

Les logiciels de santé ne sont pas présentés à un groupe d'utilisateurs à haut risque (patients) et à faible risque (prestataires de soins de santé) que le logiciel doit satisfaire sans chercher d'autre solution. Pour instaurer ce niveau de confiance lors du développement du MVP, l'équipe de développement devra :

• Travaille avec le personnel de première ligne pour faire correspondre les caractéristiques cliniques aux parcours cliniques existants.
• Comprenez et basez les fonctionnalités sur les directives ou les preuves médicales.
• Créez l'expérience utilisateur en suivant les bonnes pratiques en matière d'accessibilité (WCAG, ADA).
• Soyez transparent sur les limites de l'application.

Assurer la sécurité et l'interopérabilité des données

Un MVP dans le domaine de la santé ne va même pas arriver à discuter de projet pilote ou de partenariat sans un minimum de sécurité des données. C'est pour ça que le cryptage, l'accès basé sur les rôles, les journaux d'audit et d'autres normes existantes de sécurité des données dans le secteur sont indispensables dès le premier jour pour une appli de santé. En plus de la sécurité des données, les équipes de développeurs dans le domaine de la santé doivent penser à l'interopérabilité dès le début, au cas où le produit devrait s'intégrer dans un environnement technologique de santé plus large. L'interopérabilité, ça veut dire créer une appli qui partagera des données avec les dossiers médicaux électroniques, les systèmes hospitaliers et les appareils portables. Du point de vue technique, l'interopérabilité est assurée grâce à :

• Respecte les normes de données, comme HL7 ou FHIR.
• Vocabulaires standard, comme SNOMED CT, LOINC ou CIM-10

Créer un MVP dans le secteur de la santé prend en moyenne entre 2 et 6 mois. Le calendrier dépend surtout de la complexité du produit, des réglementations et des fonctionnalités intégrées au MVP.

Découverte du produit

Le processus de développement d'un produit commence par une découverte approfondie du produit, qui aide les parties prenantes du projet à bien comprendre l'objectif du produit, ses utilisateurs et le cadre réglementaire. Livrables : spécifications d'un produit de qualité dans le domaine de la santé, maquettes fonctionnelles, prototype fonctionnel et modèle commercial approuvé pour le produit.

Planification du développement

Même si, au moment de découvrir le produit, on définit une liste de fonctionnalités indispensables, quand l'équipe peaufine les fonctionnalités et les classe plus tard, elle se base sur :

• Nécessité clinique - Qu'est-ce qui est nécessaire pour garantir la sécurité des patients et la facilité d'utilisation?
• Risque réglementaire - Quelles caractéristiques pourraient rendre les exigences de conformité plus strictes?
• Budget et calendrier - Comment trouver le bon équilibre entre ce qu'on veut faire et ce qui est possible?

Livrables : définition de la pile technologique, composition de l'équipe et calendrier, plan de l'architecture de la solution, estimation préliminaire des coûts.

Développement et test du MVP

Même si les MVP dans le domaine de la santé ont des caractéristiques uniques en matière de mise en œuvre, les phases de conception et de développement suivent les mêmes modèles de développement agile ou itératif que les autres projets, mais avec une organisation plus solide et un niveau de documentation plus élevé. Si l'équipe crée des applications pour collecter des résultats cliniques ou les envoyer aux autorités (FDA/marquage CE), les développeurs respectent les normes ISO 13485 et IEC 62304. Livrables : système de conception UI/UX final, MVP fonctionnel, code source et documentation technique, rapports de test.

Validation et publication du MVP

Ça veut dire qu'un MVP dans le domaine de la santé doit être testé dans le monde réel, par exemple par des essais cliniques et réglementaires, avant qu'il soit presque fini. Plutôt que de le lancer tout de suite, on commence par le tester dans des conditions contrôlées, comme :

• Programmes pilotes avec des prestataires de soins de santé
• Études approuvées par le comité d'éthique
• Déploiements à usage interne en collaboration avec des conseillers cliniques.
• Environnements sandbox associés à des instances de test de DSE ou de systèmes tiers

Les prix du développement MVP sur le marché de la santé dépendent du projet et des spécificités de l'application, du processus de réglementation et des technologies. C'est pourquoi on recommande toujours de demander un devis gratuit à la société de développement afin de se faire une idée réaliste du montant à investir.

Exemple de ventilation des coûts

D'après notre projet de plateforme de surveillance à distance des patients, voici une ventilation détaillée des coûts (estimés à 50 $/heure) :

Si on a appris quelque chose en 15 ans sur le marché, c'est que les projets de développement de logiciels de santé sont super compliqués et impliquent plein de variables.

Commence par le problème spécifique et pertinent (et pas par la technologie cool)

Les entreprises ne doivent pas essayer de transformer l'ensemble des soins de la version 1 en un revirement. Commencer par un petit changement (aussi petit que possible), comme la numérisation d'un flux de travail manuel ou un domaine clinique spécifique axé sur la douleur, aidera le produit à gagner en popularité et en crédibilité. Exemple : Teladoc n'a pas commencé comme un modèle complet de soins virtuels. Au début, c'était juste une solution simple qui permettait aux patients de parler à des médecins agréés 24 heures sur 24, 7 jours sur 7, pour les cas non urgents.

Investissez dans la documentation comme partie intégrante du produit

Même si les entreprises qui veulent suivre une voie réglementaire ont souvent déjà mis ça en place, celles qui développent une solution initialement non réglementée sautent souvent cette étape.

Concevoir en tenant compte des contraintes réglementaires

Dans la plupart des cas d'innovation, les innovateurs du secteur de la santé pensent qu'il faut choisir entre la conformité et une expérience utilisateur conviviale. Mais ça ne doit pas forcément coûter si cher, à condition que l'équipe de conception utilise la conformité réglementaire comme une contrainte créative.

Connais bien la classification de ton SaMD

Si ta solution de santé a une ou plusieurs utilisations médicales, qui sont faites sans être considérées comme un dispositif médical matériel, elle va probablement entrer dans la catégorie des logiciels utilisés comme dispositifs médicaux.

Dire que leur IA est précise à 99 % ne suffit pas, il faut le montrer

Dans le domaine de la santé, une entreprise ne peut pas se permettre d'affirmer que ses algorithmes sont les meilleurs. Les organismes de réglementation tels que la FDA (et les cliniciens, d'ailleurs) veulent des preuves concrètes et réelles que votre outil tient ses promesses.

La rapidité n'est jamais bon marché dans le domaine de l'innovation en matière de soins de santé

Tu ne peux pas aller trop loin dans le développement rapide de fonctionnalités essentielles au détriment de la sécurité, de la conformité et de la confiance des utilisateurs. Le MVP dans le domaine de la santé ne consiste pas à créer le produit le plus petit possible. Il s'agit de créer l'itération la plus sûre de ta vision, qui reste néanmoins efficace en termes d'impact sur le monde réel. Quand tu commences par penser d'abord aux réglementations, que tu fais la validation clinique en parallèle et que tu structures de manière modulaire pour pouvoir te développer plus tard, tu peux entrer plus vite sur le marché, sans avoir à faire des coupes qui finiront par te hanter.