回答:
はい、アジャイル開発はヘルスケアIT開発において絶対的な役割を果たします。エンドユーザー、患者、開発チームのいずれも、不十分な開発プロセスによって十分なサービスを受けられません。アジャイルマニフェストの根底にあるいくつかの原則を考えてみてください（私のコメントでウィキペディアから恥知らずに引き裂かれたリスト）：
FDA規制環境でのアジャイル医療機器ソフトウェア開発の使用に関する議論はしばらく前からあり、この質問に関連しています。理由は次のとおりです。
短い答えは「はい」です。より長く正確な答えは、「真剣に受け止めた場合」です。
心に留めておくべきいくつかのテーマがあります。私は、（a）患者の安全性と製品の品質、および（b）業界の規制に関する懸念に分けたいと思います。
安全性と品質の面では、安全なソフトウェアを作成するのは難しいことを覚えておいてください。ある程度のドメイン知識を持っている少数の優秀なプログラマーは、非常に安全な信じられないほど便利なソフトウェアを開発できます。それらがローカルの臨床環境での展開の一部であり、ソフトウェアの展開および使用中にイベントへの応答と調整を続けることができる場合、ソフトウェアは価値を提供し、使用エラーに関連するわずかな負傷または死亡のみで命を救うか、改善する可能性がありますまたはソフトウェアのバグ。しかし、ソフトウェアは、プログラマーが常にそこにいて、ソフトウェアの使用が進化するにつれてソフトウェアに対応し、進化することを要求します。これはスケーラブルなプロセスではなく、プログラマーが死んだり退屈したりすると、システムはすぐに非常に危険になります。これらの結果を改善し、安全なソフトウェアを作成するために、ソフトウェアの開発中に実行する必要がある重要な開発プロセスのステップがあります。これらの優れた「すぐに使える」紹介は、医療機器ソフトウェアの開発に関する国際標準であるISO / IEC 62304にあります。主な概念は、すべての段階での安全リスク管理です。解明、システムおよびアーキテクチャの設計、実装、単体および統合テスト。アジャイルであっても、この作業がなくなることや難しくなることはありませんが、価値の創造に焦点を合わせ、価値を生み出さない仕事（不要な機能や過剰な検証テスト/修正サイクルなど）を排除することで、アジャイル開発が可能になりますチームがこの作業を開発に統合できるようにすることで、同時に安全なソフトウェアを開発できます。アジャイルチームで一般的に使用される反復的な開発プラクティスは、安全性リスク管理作業を完了させるのに非常によく適しており、後から考えるのではなく、プロジェクトの全期間を通じて進化します。また、ソフトウェアが動作可能になった後、ソフトウェアを安全に使用するために、ユーザーからのフィードバックや怪我につながる可能性のあるイベントを個別に、および総合的に検討する必要があります。アジャイルは、システムの他の部分を壊さずに変更を組み込むための迅速で安全なプロセスを提供する場合に役立ちます-これもまた、ソフトウェアの開発時に作成された優れたアーキテクチャと十分に理解された設計の相互作用を必要とします。後から考えるのではなく、プロジェクトの全期間を通じて進化します。また、ソフトウェアが動作可能になった後、ソフトウェアを安全に使用するために、ユーザーからのフィードバックや怪我につながる可能性のあるイベントを個別に、および総合的に検討する必要があります。アジャイルは、システムの他の部分を壊さずに変更を組み込むための迅速で安全なプロセスを提供する場合に役立ちます-これもまた、ソフトウェアの開発時に作成された優れたアーキテクチャと十分に理解された設計の相互作用を必要とします。後から考えるのではなく、プロジェクトの全期間を通じて進化します。また、ソフトウェアが動作可能になった後、ソフトウェアを安全に使用するために、ユーザーからのフィードバックや怪我につながる可能性のあるイベントを個別に、および総合的に検討する必要があります。アジャイルは、システムの他の部分を壊さずに変更を組み込むための迅速で安全なプロセスを提供する場合に役立ちます-これもまた、ソフトウェアの開発時に作成された優れたアーキテクチャと十分に理解された設計の相互作用を必要とします。
2番目の懸念は規制です。理想的な世界では、十分に危険である可能性のあるすべての製品に安全規制が適用され、ベンダーは、ラインを通過し始めたら、いくつかの簡単なことを行うことで対応できます。実際、この業界では世界的な規制が複雑で動きが速いため、いつか医療データを表示する小さなiPhoneアプリを開発でき、次は「品質管理」のISOおよびFDA標準に準拠することが求められます。システム」、またはQMS。これは、過去に正式なQMSを持っていなかった企業にとっては恐ろしいことです。そして、アジャイルはこれを悪化させる可能性があります。なぜなら、製品コンセプトから始めて、進化的開発を通じて、意図せずに規制対象用途（臨床診断データをユーザーに表示するなど）に入るからです。2011年10月です。カテゴリ名に「health」、「medical」、「healthcare」を含む製品のマーケティングを検討している会社に対する私のアドバイスは、製造する製品が世界中の1つ以上の医療機器規制当局によって規制されるようになる時期について計画を立てることです。ここでもアジャイルが役立ちます。これは、アジャイルプラクティスが一般に、市場投入前の申請（FDA 510kなど）、認証（ISO 13485など）、および市場投入後の操作の両方について、規制上の顧客を満足させるために準拠出力を生成する（または容易に生成できる）ためです。テストファースト開発は、医療ソフトウェアにぴったりです。継続的な統合、自動化された単体テスト、およびSCRUMスプリントメタデータは、リスク管理と適切な検証が単なる後付けとしてではなく、開発プロセスに組み込まれているという完全な客観的証拠を提供します。ほとんどの場合、アジャイルは「ウォーターフォール」よりも多くのアーティファクトを生成すると思いますが、おそらく同じ形ではありません。しかし、出力をレギュレーターを満たす何かに変換することは、解決するべき比較的小さな問題です。
要約すると...はい、バージニア州では、ヘルスケアIT（およびその他の医療機器）ソフトウェア開発に機敏です。すべてのアジャイルと同様に、プロセス、ビジネスサポート、および勇気に専念します。
はい、アジャイル開発の前提の1つは顧客の関与です。これは、ヘルスケアITシステムおよびプロセスで重要です。ヘルスケアIT部門は、顧客担当者が関与し、その決定が患者のケアにどのように影響するかについて意見を述べれば、より良い決定を下します。
それは可能だと思いますが、業界には大きなパラダイムシフトが必要です。私はヘルスケア開発者として2年目にいますが、信頼と自己組織化はどこにも見当たりません。ヘルスケアは、アジャイルを正式に採用することから大きな恩恵を受けます。それは、とにかく大混乱であり、「スラッシュ」と呼ばれる反復的な開発と、要件の変更が遅れているためです。
私はあなたの質問を理解しています。アジャイル開発の良い例は、誰かのためにウェブサイトを構築することです。通常、顧客は自分が何を望んでいるかを正確に知らないため、顧客とのやり取りがたくさんあります。
ヘルスケアITは、コンピューターサイエンスの非常に定義済みの分野のように思えるかもしれません。厳格な標準（DICOM、HL7）では、それらを実装する方法は1つしかないと思われますが、多くの設定と意思決定もあります。
私の意見では、どの製品を作成していても、事前にすべての要件を決定することはできないため、アジャイルなソフトウェア開発方法は非常にうまく機能します。
前述のとおり、答えはイエスです。
規制区域または高リスク区域にアジャイルを適用する場合、規制遵守およびその他のリスク軽減戦略が含まれるように、各反復で「完了」を定義する必要があります。たとえば、これにはQA文書、要件のトレーサビリティ、セキュリティ監査、およびその他のアクションが各反復で完了する必要がある場合があります。
たとえば、FDA規制環境へのアジャイルアプローチの適用には、優れた技術と実践があります。
簡単な答え：はい。高保証環境でのアジャイルに関するいくつかのヒントを提供する良いブログがあります。
ただし、いくつかの妥協が必要です。アジャイル宣言を検討してください。
プロセスとツールを介した個人と相互作用
包括的なドキュメントよりも機能するソフトウェア
契約交渉を介した顧客コラボレーション
計画に従うことによる変化への対応
規制機関は、アジャイルチームと同じように左側を重視していますが、典型的なアジャイルチームよりも右側を重視する必要があります。たとえば、FDAでは、プロセスとツールを検証し、かなり包括的な設計とテストのドキュメントを要求することを要求し、間違いなくかなりの計画を必要とします。
一方、次のような多くのアジャイルの原則は、ヘルスケアの世界に非常によく適合しています。