'Agile' peut-il être appliqué aux équipes informatiques de santé?

Agile peut-il être employé dans un domaine comme l'informatique de la santé, où une grande partie des soins aux patients dépend de la qualité et de la livraison rapide des systèmes?

Oui, le développement agile a absolument un rôle à jouer dans le développement informatique des soins de santé. Personne, pas l'utilisateur final, pas le patient et certainement pas l'équipe de développement n'est bien servi par un processus de développement mal fait. Considérant certains des principes qui sous-tendent le manifeste Agile (liste extraite sans vergogne de Wikipédia avec mon commentaire):

• Satisfaction du client par la livraison rapide de logiciels utiles . Quand n'est-ce pas un objectif?
• Bienvenue aux exigences changeantes, même en retard de développement . L'informatique de santé s'intègre dans un domaine qui, bien qu'inondé de technologie, n'est pas particulièrement axé sur l'informatique. Le potentiel d'un système conçu pour «bien faire les choses» dès le départ est assez faible.
• Le logiciel de travail est livré fréquemment (semaines plutôt que mois) . En tant qu'utilisateur final de certains de ces trucs, Dieu aimerais-je cela. Des changements rapides et efficaces sont inestimables, et ce qui transforme l'informatique de la santé de «cette chose que nous devons faire» à «cette chose qui change ma façon de faire mon travail».
• Le logiciel de travail est la principale mesure du progrès . Cela a du sens dans la plupart des applications, il n'y a donc vraiment aucune raison qu'il ne s'étende pas au HIT.
• Développement durable, capable de maintenir un rythme constant . Vous voyez cela partout dans les soins de santé, de la surveillance des infections au TIH en passant par les établissements. Les soins de santé ne sont pas un cycle d'expansion ou de récession, c'est un battement de tambour constant.
• Une coopération étroite et quotidienne entre les hommes d'affaires et les développeurs . La plupart de HIT n'est pas un outil de développement. C'est un outil conçu par les développeurs. Le contact avec le client est et devrait être la clé. Il est également beaucoup plus facile de faire adopter un système s'il fonctionne et s'intègre dans le flux de travail des clients, plutôt que d'avoir besoin d'être cloué, patché, etc.
• La conversation en face à face est la meilleure forme de communication (colocalisation) . De mon interaction avec les cliniciens, il est beaucoup plus facile de faire des choses en personne, de préférence avec des blocs de papier, que toute autre façon.
• Les projets sont construits autour d'individus motivés, auxquels il faut faire confiance . C'est quelque chose qui rendra votre vie meilleure - alors oui, cela devrait être adopté;)
• Une attention continue à l'excellence technique et à une bonne conception . C'est encore une de ces choses "tout le monde devrait le faire, donc bien sûr vous devriez" chose. Mais considérez la complexité des systèmes HIT et les innombrables façons dont ils finissent par être utilisés, jour après jour. Un système de mauvaise qualité ne va pas le couper.
• Simplicité . Cela devrait fonctionner hors de la boîte. Cela devrait bien fonctionner, tout le temps et de la façon dont il est censé le faire. Les gens sont des idiots. Les travailleurs de la santé sont des personnes. Par conséquent ... vous connaissez le reste. La simplicité aide.
• Équipes auto-organisées . Celui-ci pourrait être un peu plus extensible pour HIT. Honnêtement, je ne suis pas assez confiant pour dire d'une manière ou d'une autre si l'auto-organisation dans ce contexte est bonne ou non.
• Adaptation régulière à l'évolution des circonstances . HIT est une industrie active et en croissance avec des charges réglementaires complexes et changeantes. Être capable de s'adapter semble être une idée décente.

Les discussions entourant l'utilisation du développement de logiciels de dispositifs médicaux agiles dans un cadre réglementé par la FDA existent depuis un certain temps et sont pertinentes pour cette question. Voici quelques raisons:

1. Les avantages et les inconvénients du développement cascade par rapport au développement itératif sont essentiellement les mêmes et devraient être pris en compte pour tout projet informatique de santé.
2. Les systèmes de qualité mandatés par la FDA (voir Principes généraux de validation des logiciels; Guide final pour le personnel de l'industrie et de la FDA ) pour le développement de logiciels pour les dispositifs médicaux utilisés sont la norme de référence de l'industrie. Il est à noter que ces réglementations ne dictent aucune méthodologie de développement particulière. Dans tous les cas, la qualité des logiciels informatiques de santé serait considérablement améliorée si ces meilleures pratiques étaient suivies par tous.
3. La plupart des logiciels de développement informatique Heath ne fonctionnent pas actuellement en vertu de ces normes réglementaires de la FDA. Alors que les obstacles à l'interopérabilité des dispositifs médicaux continuent de tomber, en particulier pour les plates-formes mobiles, cela va probablement changer - voir FDA Adresses Mobile Medical Apps .
4. De plus, si vous développez un logiciel informatique de santé commercial, vous devez vous demander si vous créez un système de données de dispositifs médicaux (MDDS): Mon produit est-il un MDDS?

La reponse courte est oui". Une réponse plus longue mais plus précise est «Si vous prenez cela au sérieux».

Il y a quelques thèmes à garder à l'esprit, que j'aime séparer en préoccupations liées à (a) la sécurité des patients et la qualité des produits, et (b) la réglementation de l'industrie.

Du côté de la sécurité et de la qualité, gardez à l'esprit qu'il est difficile de créer un logiciel sûr. Quelques bons programmeurs avec une certaine connaissance du domaine peuvent lancer des logiciels incroyablement utiles et assez sûrs. S'ils font partie du déploiement dans un environnement clinique local et peuvent continuer à répondre et à s'adapter aux événements pendant le déploiement et l'utilisation du logiciel, le logiciel peut apporter de la valeur, sauver ou améliorer des vies avec seulement quelques blessures ou décès liés à des erreurs d'utilisation. ou des bogues logiciels. Mais le logiciel exigera que les programmeurs soient là, tout le temps, répondant, co-évoluant le logiciel à mesure que l'utilisation du logiciel évolue. Ce n'est pas un processus évolutif et lorsque les programmeurs meurent ou s'ennuient, le système peut facilement devenir très dangereux très rapidement. Afin d'améliorer ces résultats et de rendre les logiciels sûrs, il y a des étapes importantes du processus de développement qui doivent être prises pendant le développement du logiciel. Une bonne introduction "prête à l'emploi" à ces derniers se trouve dans la norme internationale pour le développement de logiciels pour les dispositifs médicaux, ISO / IEC 62304. Le concept principal est la gestion des risques de sécurité à toutes les étapes - pendant l'analyse de cas d'utilisation et le développement d'histoires, les exigences élucidation, conception du système et de l'architecture, mise en œuvre, tests unitaires et d'intégration. Être agile ne fera pas disparaître tout ce travail, ni ne sera moins difficile, mais en se concentrant sur la création de valeur et en éliminant le travail (comme les fonctionnalités inutiles ou les cycles de test / correction excessifs) qui ne crée pas de valeur, le développement agile peut permettre à une équipe d'intégrer ce travail dans le développement, résultant en un logiciel plus sûr développé en même temps. Les pratiques de développement itératives couramment utilisées par les équipes agiles sont très bien adaptées pour faire le travail de gestion des risques de sécurité, évoluer tout au long de la vie du projet plutôt que d'être une réflexion après coup. Et une fois le logiciel opérationnel, les commentaires des utilisateurs et tout événement pouvant même entraîner des blessures doivent être pris en compte, individuellement et globalement, pour garantir la sécurité d'utilisation du logiciel. Agile peut aider ici s'il fournit un processus rapide et sûr pour incorporer les changements sans casser d'autres parties du système - ce qui nécessite à nouveau une bonne architecture et des interactions de conception bien comprises qui ont été créées lors du développement du logiciel. évoluer tout au long de la vie du projet plutôt que d’être une réflexion après coup. Et une fois le logiciel opérationnel, les commentaires des utilisateurs et tout événement pouvant même entraîner des blessures doivent être pris en compte, individuellement et globalement, pour garantir la sécurité d'utilisation du logiciel. Agile peut aider ici s'il fournit un processus rapide et sûr pour incorporer les changements sans casser d'autres parties du système - ce qui nécessite à nouveau une bonne architecture et des interactions de conception bien comprises qui ont été créées lors du développement du logiciel. évoluer tout au long de la vie du projet plutôt que d’être une réflexion après coup. Et une fois le logiciel opérationnel, les commentaires des utilisateurs et tout événement pouvant même entraîner des blessures doivent être pris en compte, individuellement et globalement, pour garantir la sécurité d'utilisation du logiciel. Agile peut aider ici s'il fournit un processus rapide et sûr pour incorporer les changements sans casser d'autres parties du système - ce qui nécessite à nouveau une bonne architecture et des interactions de conception bien comprises qui ont été créées lors du développement du logiciel.

La deuxième préoccupation est d'ordre réglementaire. Dans un monde idéal, les règles de sécurité s'appliqueraient à tous les produits qui pourraient être suffisamment dangereux, et un fournisseur pourrait se conformer en faisant des choses simples une fois qu'il a commencé à franchir la ligne. Dans la pratique, les réglementations mondiales sont complexes et évoluent rapidement dans cette industrie, ce qui signifie qu'un jour vous pouvez développer une petite application iPhone qui affiche des données médicales, et le lendemain, vous êtes censé se conformer aux normes ISO et FDA pour la «gestion de la qualité» système ", ou QMS. Cela peut être effrayant pour les entreprises qui n'ont pas eu de SMQ formel dans le passé. Et l'agilité peut exacerber cela parce que vous pourriez commencer avec un concept de produit et, par le biais d'un développement évolutif, entrer involontairement dans une utilisation prévue réglementée (comme l'affichage de données de diagnostic clinique à un utilisateur). C'est octobre 2011; mon conseil à toute entreprise qui envisage de commercialiser un produit qui a "santé", "médical", "soins de santé" dans le nom de la catégorie est qu'elles devraient avoir un plan pour quand le produit qu'elles fabriquent devient réglementé par un ou plusieurs régulateurs de dispositifs médicaux dans le monde entier. Là encore, l'agilité peut aider, car les pratiques agiles produisent généralement (ou pourraient facilement produire) des sorties conformes pour satisfaire les clients réglementaires à la fois pour les soumissions de dédouanement avant commercialisation (comme la FDA 510k), la certification (comme ISO 13485) et les opérations post-commercialisation. Le développement test-first s'intègre parfaitement dans les logiciels médicaux. L'intégration continue, les tests unitaires automatisés et les métadonnées de sprint SCRUM peuvent fournir une preuve objective complète que la gestion des risques et la vérification appropriée sont effectuées non seulement après coup, mais intégrées au processus de développement. Dans la plupart des cas, je pense que l'agile produit plus d'artefacts que la "cascade", peut-être pas sous la même forme. Mais la conversion des sorties en régulateurs satisfaisants est un problème relativement petit à résoudre.

Donc en résumé ... oui Virginie, il y a agile pour le développement de logiciels informatiques de santé (et autres dispositifs médicaux). Comme toutes les choses agiles, il faut du dévouement au processus, du soutien aux entreprises et du courage.

Oui, l'un des prémisses du développement agile est l'implication des clients. Ceci est essentiel dans les systèmes et processus informatiques de santé. Les services informatiques des soins de santé prendront de meilleures décisions si un représentant du client est impliqué et donne leur avis sur la façon dont les décisions affecteront les soins aux patients.

Je pense que c'est possible, mais l'industrie a besoin d'un énorme changement de paradigme. Je suis dans ma deuxième année en tant que développeur de soins de santé, et la confiance et l'auto-organisation ne sont nulle part apparentes. Les soins de santé bénéficieraient grandement de l'adoption formelle de l'agilité, car c'est surtout le chaos de toute façon, avec un développement itératif appelé "thrash" et des exigences changeantes tardives parce que, eh bien, le gros design initial ne fonctionne pas de toute façon.

Je comprends votre question. Un bon exemple de développement Agile est la création d'un site Web pour quelqu'un. Habituellement, un client ne sait pas exactement ce qu'il veut, il y a donc beaucoup d'interaction avec le client.

L'informatique de santé peut sembler un domaine très prédéfini en informatique; avec ses normes strictes (DICOM, HL7), il semble qu'il n'y ait qu'une seule façon de les implémenter, mais il y a aussi beaucoup de préférences et de prise de décision.

À mon avis, quel que soit le produit que vous fabriquez, vous ne pouvez pas déterminer TOUTES les exigences à l'avance, donc une méthode de développement logiciel agile fonctionne très bien.

Comme indiqué, la réponse est oui.

Lorsque vous appliquez Agile à des zones réglementées ou à haut risque, vous devez définir "Terminé" à chaque itération de sorte que la conformité réglementaire et d'autres stratégies d'atténuation des risques soient incluses. Par exemple, cela peut nécessiter la documentation d'AQ, la traçabilité des exigences, l'audit de sécurité et d'autres actions à effectuer à chaque itération.

Il existe par exemple de bonnes techniques et pratiques pour l'application d'approches Agiles aux environnements réglementés par la FDA.

La réponse courte: oui. Il existe un bon blog sur Agile dans les environnements à haute assurance qui donne quelques conseils.

Cependant, il y a des compromis à faire. Considérez le Manifeste Agile :

Individus et interactions sur les processus et les outils

Logiciel de travail sur une documentation complète

Collaboration client sur négociation de contrat

Répondre au changement suite à un plan

Les organismes de réglementation apprécient le côté gauche autant que les équipes agiles, mais ils ont besoin de mettre davantage l'accent sur le côté droit qu'une équipe agile typique. La FDA, par exemple, exige que vous validiez vos processus et outils, demande une documentation de conception et de test assez complète, et nécessite certainement une bonne planification.

D'un autre côté, de nombreux principes agiles s'intègrent très bien dans le monde de la santé, notamment:

• Programmation TDD et paire - augmenter la qualité
• Boucles de rétroaction serrées des clients - une validation précoce est excellente
• Planification itérative - les organismes de réglementation sont tout au sujet de la planification

Certaines disciplines sont déjà de nature agile. Les soins infirmiers, par exemple, s'appuient sur des cycles d '«évaluation-évaluation-planification-intervention» qui dépendent de plusieurs itérations de diagnostic / pronostic pour atteindre progressivement les résultats finaux.

Cependant, ce serait une confusion fatale d'essayer de suggérer que les services de soins de santé fournis de cette manière sont spécifiquement adaptés à une application essentiellement unique du développement logiciel Agile vers un outil ou un système logiciel à utiliser dans ladite prestation de services.

L'AAMI travaille activement sur un rapport d'information technique intitulé:
AAMI TIR SW1, Guidance on the use of agile practices in the development of medical device software.

J'ai entendu dire qu'il pourrait être publié en 2012.

Il discute de l'alignement des principes du Manifeste Agile (voir la réponse EpiGrads) avec les exigences réglementaires, les processus typiques et d'autres aspects pratiques des produits associés aux logiciels de dispositifs médicaux.