Kann Agile auf IT-Teams im Gesundheitswesen angewendet werden?

Kann Agile in einem Bereich wie der Healthcare-IT eingesetzt werden, in dem ein Großteil der Patientenversorgung von der Qualität und der pünktlichen Lieferung der Systeme abhängt?

Ja, agile Entwicklung spielt bei der IT-Entwicklung im Gesundheitswesen eine wichtige Rolle. Niemand, nicht der Endbenutzer, nicht der Patient und schon gar nicht das Entwicklungsteam wird von einem schlecht durchgeführten Entwicklungsprozess gut bedient. In Anbetracht einiger Prinzipien, die dem Agile-Manifest zugrunde liegen (Liste, die mit meinem Kommentar schamlos aus Wikipedia entnommen wurde):

• Kundenzufriedenheit durch schnelle Lieferung nützlicher Software . Wann ist das kein Ziel?
• Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung . Die IT im Gesundheitswesen fügt sich in ein Gebiet ein, das zwar mit Technologie überflutet ist, aber nicht besonders auf IT ausgerichtet ist. Das Potenzial für ein System, das auf Anhieb darauf ausgelegt ist, alles richtig zu machen, ist recht gering.
• Arbeitssoftware wird häufig geliefert (Wochen statt Monate) . Als Endverbraucher einiger dieser Dinge würde ich das lieben. Schnelle, funktionierende Veränderungen sind von unschätzbarem Wert und was die IT des Gesundheitswesens von "dem, was wir tun müssen" zu "dem, was meine Arbeit verändert".
• Arbeitssoftware ist das wichtigste Maß für den Fortschritt . Ergibt in den meisten Anwendungen Sinn, es gibt also keinen Grund, warum es nicht zu HIT führen würde.
• Nachhaltige Entwicklung, die in der Lage ist, ein konstantes Tempo beizubehalten . Sie sehen dies im gesamten Gesundheitswesen, von der Infektionsüberwachung über die HIT bis hin zu Einrichtungen. Das Gesundheitswesen ist kein Boom-or-Bust-Zyklus, sondern ein ständiger Schlagabtausch.
• Enge, tägliche Zusammenarbeit zwischen Geschäftsleuten und Entwicklern . Das meiste HIT ist kein Entwicklertool. Es ist ein Tool, das von Entwicklern erstellt wurde. Der Kontakt zum Kunden ist und sollte der Schlüssel sein. Es ist auch viel einfacher, ein System einzuführen, wenn es funktioniert und sich in den Workflow des Kunden einfügt, anstatt angeheftet, gepatcht usw. zu werden.
• Das persönliche Gespräch ist die beste Form der Kommunikation (Co-Location) . Durch meine Interaktion mit Klinikern ist es viel einfacher, Dinge persönlich zu erledigen, vorzugsweise mit Papierblöcken, als auf jede andere Weise.
• Projekte bauen auf motivierten Personen auf, denen vertraut werden sollte . Dies ist etwas, das dein Leben verbessern wird - also sollte es angenommen werden;)
• Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design . Dies ist wieder eines der Dinge, die "jeder tun sollte, also sollte man es natürlich". Bedenken Sie jedoch die Komplexität der HIT-Systeme und die unzähligen Möglichkeiten, wie sie Tag für Tag eingesetzt werden. Ein schlampiges System wird es nicht abschneiden.
• Einfachheit . Es sollte sofort funktionieren. Es sollte die ganze Zeit gut funktionieren und so, wie es sein soll. Menschen sind Idioten. Beschäftigte im Gesundheitswesen sind Menschen. Deshalb ... kennst du den Rest. Einfachheit hilft.
• Selbstorganisierende Teams . Dieser könnte für HIT ein bisschen mehr anstrengend sein. Ehrlich gesagt, bin ich nicht zuversichtlich, auf die eine oder andere Weise zu sagen, ob Selbstorganisation in diesem Umfeld gut ist oder nicht.
• Regelmäßige Anpassung an sich ändernde Umstände . HIT ist eine aktive, wachsende Branche mit komplexen, sich ändernden regulatorischen Belastungen. Sich anpassen zu können, scheint eine anständige Idee zu sein.

Die Diskussionen über den Einsatz von Agile Medical Device Software Development in einem von der FDA geregelten Umfeld bestehen seit einiger Zeit und sind für diese Frage relevant. Hier sind einige Gründe warum:

1. Die Vor- und Nachteile der Wasserfall- und der iterativen Entwicklung sind im Wesentlichen gleich und müssen für jedes IT-Gesundheitsprojekt berücksichtigt werden.
2. Die von der FDA vorgeschriebenen Qualitätssicherungssysteme (siehe Allgemeine Grundsätze der Software-Validierung; Endgültige Leitlinien für die Industrie und die Mitarbeiter der FDA ) für die Entwicklung von Software für medizinische Geräte sind der Goldstandard der Branche. Es ist zu beachten, dass diese Vorschriften keine bestimmte Entwicklungsmethode vorschreiben. In jedem Fall würde sich die Qualität der Health IT-Software erheblich verbessern, wenn alle diese Best Practices befolgt würden.
3. Die meisten IT-Softwareentwickler von Heath arbeiten derzeit nicht unter diesen FDA-Richtlinien. Da die Hindernisse für die Interoperabilität von Medizinprodukten, insbesondere für mobile Plattformen, weiter sinken, wird sich dies wahrscheinlich ändern - siehe FDA-Adressen für mobile medizinische Apps .
4. Wenn Sie kommerzielle Health IT-Software entwickeln, müssen Sie sich auch fragen, ob Sie ein MDDS (Medical Device Data System) erstellen: Ist mein Produkt ein MDDS?

Die kurze Antwort lautet "Ja". Eine längere, aber genauere Antwort lautet: "Wenn Sie es ernst nehmen."

Es sind einige Themen zu beachten, die ich gerne in Bezug auf (a) Patientensicherheit und Produktqualität und (b) Branchenregulierung aufteilen möchte.

Beachten Sie im Hinblick auf Sicherheit und Qualität, dass es schwierig ist, sichere Software zu erstellen. Ein paar gute Programmierer mit etwas Domänenwissen können unglaublich nützliche Software entwickeln, die ziemlich sicher ist. Wenn sie Teil des Einsatzes in einer lokalen klinischen Umgebung sind und während des Einsatzes und der Verwendung der Software weiterhin auf Ereignisse reagieren und sich darauf einstellen können, kann die Software einen Nutzen bringen und Leben retten oder verbessern, wobei nur wenige Verletzungen oder Todesfälle mit Verwendungsfehlern zusammenhängen oder Software-Fehler. Für die Software ist es jedoch erforderlich, dass die Programmierer die ganze Zeit da sind, reagieren und die Software mitentwickeln, wenn sich die Verwendung der Software weiterentwickelt. Dies ist kein skalierbarer Prozess, und wenn die Programmierer sterben oder sich langweilen, kann das System sehr schnell sehr gefährlich werden. Um diese Ergebnisse zu verbessern und sichere Software zu erstellen, Während der Entwicklung der Software müssen wichtige Schritte des Entwicklungsprozesses ausgeführt werden. Eine gute "out of the box" -Einführung in diese Themen findet sich in der internationalen Norm für die Entwicklung von Software für Medizinprodukte, ISO / IEC 62304. Das Hauptkonzept ist das Sicherheitsrisikomanagement in allen Phasen - während der Analyse von Anwendungsfällen und der Entwicklung von Storys - Anforderungen Aufklärung, System- und Architekturdesign, Implementierung, Unit- und Integrationstests. Agil zu sein, wird diese Arbeit nicht zum Erliegen bringen oder weniger schwierig machen, aber wenn man sich auf die Wertschöpfung konzentriert und Arbeit eliminiert (wie nicht benötigte Funktionen oder übermäßige Verifikationstests / Korrekturzyklen), die keinen Wert schaffen, kann agile Entwicklung Ermöglichen Sie einem Team, diese Arbeit in die Entwicklung zu integrieren, was zu einer sichereren Software führt, die zur gleichen Zeit entwickelt wird. Die von agilen Teams üblicherweise angewendeten iterativen Entwicklungspraktiken eignen sich sehr gut, um die Sicherheitsrisikomanagementarbeit zu erledigen, die sich während der gesamten Projektlaufzeit weiterentwickelt, anstatt ein nachträglicher Einfall zu sein. Und nachdem die Software betriebsbereit ist, müssen die Rückmeldungen der Benutzer und alle Ereignisse, die möglicherweise zu Verletzungen führen, einzeln und in ihrer Gesamtheit berücksichtigt werden, um die sichere Verwendung der Software zu gewährleisten. Agile kann hier Abhilfe schaffen, wenn es einen schnellen und sicheren Prozess zum Einbeziehen von Änderungen bietet, ohne andere Teile des Systems zu beschädigen - was wiederum eine gute Architektur und gut verstandene Designinteraktionen erfordert, die bei der Entwicklung der Software erstellt wurden. sich während des gesamten Projektlebens weiterentwickeln, anstatt ein nachträglicher Einfall zu sein. Und nachdem die Software betriebsbereit ist, müssen die Rückmeldungen der Benutzer und alle Ereignisse, die möglicherweise zu Verletzungen führen, einzeln und in ihrer Gesamtheit berücksichtigt werden, um die sichere Verwendung der Software zu gewährleisten. Agile kann hier Abhilfe schaffen, wenn es einen schnellen und sicheren Prozess zum Einbeziehen von Änderungen bietet, ohne andere Teile des Systems zu beschädigen - was wiederum eine gute Architektur und gut verstandene Designinteraktionen erfordert, die bei der Entwicklung der Software erstellt wurden. sich während des gesamten Projektlebens weiterentwickeln, anstatt ein nachträglicher Einfall zu sein. Und nachdem die Software betriebsbereit ist, müssen die Rückmeldungen der Benutzer und alle Ereignisse, die möglicherweise zu Verletzungen führen, einzeln und in ihrer Gesamtheit berücksichtigt werden, um die sichere Verwendung der Software zu gewährleisten. Agile kann hier Abhilfe schaffen, wenn es einen schnellen und sicheren Prozess zum Einbeziehen von Änderungen bietet, ohne andere Teile des Systems zu beschädigen - was wiederum eine gute Architektur und gut verstandene Designinteraktionen erfordert, die bei der Entwicklung der Software erstellt wurden.

Das zweite Problem ist die Regulierung. In einer idealen Welt würden die Sicherheitsbestimmungen für alle Produkte gelten, die ausreichend gefährlich sein könnten, und ein Anbieter wäre in der Lage, die Anforderungen zu erfüllen, indem er einige einfache Dinge ausführt, sobald er anfängt, die Grenze zu überschreiten. In der Praxis sind globale Vorschriften in dieser Branche komplex und schnelllebig. Dies bedeutet, dass Sie eines Tages eine kleine iPhone-App entwickeln können, die einige medizinische Daten anzeigt, und dass Sie beim nächsten Mal die ISO- und FDA-Standards für "Qualitätsmanagement" einhalten müssen system "oder QMS. Für Unternehmen, die in der Vergangenheit kein formelles QMS hatten, kann das beängstigend sein. Und Agile kann dies noch verschlimmern, da Sie möglicherweise mit einem Produktkonzept beginnen und durch die evolutionäre Entwicklung unabsichtlich einen regulierten Verwendungszweck festlegen (z. B. die Anzeige klinischer Diagnosedaten für einen Benutzer). Es ist Oktober 2011; Mein Rat an jedes Unternehmen, das über die Vermarktung eines Produkts nachdenkt, dessen Kategorien "Gesundheit", "Medizin" und "Gesundheitswesen" lauten, lautet, dass es einen Plan haben sollte, wann das von ihm hergestellte Produkt von einem oder mehreren Medizinproduktregulierungsbehörden weltweit reguliert wird. Auch hier kann Agile helfen, da die Agile-Praktiken im Allgemeinen konforme Ergebnisse produzieren (oder leicht produzieren könnten), um regulatorische Kunden sowohl bei Zulassungsanträgen vor dem Inverkehrbringen (wie FDA 510k) als auch bei Zertifizierungen (wie ISO 13485) und nach dem Inverkehrbringen zu befriedigen. Die Test-First-Entwicklung passt direkt in die medizinische Software. Kontinuierliche Integration, automatisierte Komponententests und SCRUM-Sprint-Metadaten können einen vollständigen objektiven Beweis dafür liefern, dass Risikomanagement und ordnungsgemäße Verifizierung nicht nur nachträglich erfolgen, sondern in den Entwicklungsprozess integriert sind. In den meisten Fällen, denke ich, produziert Agile mehr Artefakte als "Wasserfall", vielleicht nicht in der gleichen Form. Die Umwandlung der Ausgänge in zufriedenstellende Regler ist jedoch ein relativ kleines Problem, das gelöst werden muss.

Fazit: Ja, Virginia, es gibt flexible Möglichkeiten für die Entwicklung von IT-Software (und anderer medizinischer Geräte) für das Gesundheitswesen. Wie alles, was agil ist, erfordert es Engagement für Prozesse, Geschäftsunterstützung und Mut.

Ja, eine der Voraussetzungen für eine agile Entwicklung ist die Einbeziehung der Kunden. Dies ist in IT-Systemen und -Prozessen im Gesundheitswesen von entscheidender Bedeutung. IT-Abteilungen des Gesundheitswesens treffen bessere Entscheidungen, wenn ein Kundenvertreter involviert ist, und geben Input darüber, wie sich die Entscheidungen auf die Patientenversorgung auswirken.

Ich denke, es ist möglich, aber die Branche braucht einen großen Paradigmenwechsel. Ich bin in meinem zweiten Jahr als Entwickler im Gesundheitswesen und Vertrauen und Selbstorganisation sind nirgends erkennbar. Das Gesundheitswesen würde von der formalen Einführung von Agilität stark profitieren, da es sowieso größtenteils ein Chaos ist, mit einer iterativen Entwicklung, die als "Thrash" bezeichnet wird, und sich spät ändernden Anforderungen, da großes Design im Voraus ohnehin nicht funktioniert.

Ich verstehe deine Frage. Ein gutes Beispiel für eine agile Entwicklung ist die Erstellung einer Website für jemanden. Normalerweise weiß ein Kunde nicht genau, was er / sie will, daher gibt es viel Interaktion mit dem Kunden.

Die IT im Gesundheitswesen scheint in der Informatik ein sehr vordefiniertes Gebiet zu sein. Aufgrund der strengen Standards (DICOM, HL7) scheint es nur einen Weg zu geben, diese umzusetzen, aber es gibt auch viele Präferenzen und Entscheidungsprozesse.

Meiner Meinung nach können Sie, unabhängig von Ihrem Produkt, nicht ALLE Anforderungen im Voraus bestimmen , sodass eine agile Softwareentwicklungsmethode sehr gut funktioniert.

Wie bereits erwähnt lautet die Antwort ja.

Wenn Sie Agile auf regulierte Bereiche oder Bereiche mit hohem Risiko anwenden, müssen Sie bei jeder Iteration "Fertig" definieren, damit die Einhaltung von Vorschriften und andere Strategien zur Risikominderung berücksichtigt werden. Dies kann beispielsweise erfordern, dass die QS-Dokumentation, die Nachverfolgbarkeit der Anforderungen, die Sicherheitsüberprüfung und andere Aktionen bei jeder Iteration ausgeführt werden.

Es gibt zum Beispiel gute Kunst und Praxis für die Anwendung agiler Ansätze in FDA-regulierten Umgebungen.

Die kurze Antwort: Ja. Es gibt einen guten Blog über Agile in Hochsicherheitsumgebungen , der einige Tipps gibt.

Es gibt jedoch einige Kompromisse, die gemacht werden müssen. Betrachten Sie das Agile Manifest :

Individuen und Interaktionen über Prozesse und Werkzeuge

Arbeitssoftware über umfangreiche Dokumentation

Zusammenarbeit der Kunden bei Vertragsverhandlungen

Reagieren, um nach einem Plan umzuschalten

Die Aufsichtsbehörden schätzen die linke Seite genauso wie agile Teams, aber sie erfordern mehr Nachdruck auf der rechten Seite als ein typisches agiles Team. Die FDA verlangt zum Beispiel, dass Sie Ihre Prozesse und Tools validieren, eine ziemlich umfassende Design- und Testdokumentation anfordern und auf jeden Fall viel Planung benötigen.

Auf der anderen Seite passen viele agile Prinzipien sehr gut in die Welt des Gesundheitswesens, darunter:

• TDD und Pair Programming - Qualität steigern
• Enge Kunden-Feedback-Schleifen - eine frühzeitige Validierung ist großartig
• Iterative Planung - Regulierungsbehörden befassen sich mit Planung

Einige Disziplinen sind bereits agiler Natur. Die Pflege basiert zum Beispiel auf einem Zyklus „Bewertung, Bewertung, Planung, Intervention“, der von mehreren Iterationen der Diagnose / Prognose abhängt, um schrittweise Endergebnisse zu erzielen.

Es wäre jedoch eine fatale Überschneidung zu versuchen, darauf hinzuweisen, dass die auf diese Weise bereitgestellten Gesundheitsdienste speziell für eine im Wesentlichen einmalige Anwendung der agilen Softwareentwicklung auf ein Softwaretool oder -system zur Verwendung bei der Bereitstellung dieser Dienste geeignet sind.

AAMI arbeitet aktiv an einem technischen Informationsbericht mit dem Titel:
AAMI TIR SW1, Anleitung zum Einsatz agiler Praktiken bei der Entwicklung von Software für Medizinprodukte.

Ich habe gehört, dass es 2012 veröffentlicht werden könnte.

Es wird die Angleichung der Prinzipien des Agilen Manifests (siehe Antwort von EpiGrad) an die behördlichen Anforderungen, typischen Prozesse und sonstigen Produktpraktiken im Zusammenhang mit Software für medizinische Geräte erörtert.