はい、アジャイル開発はヘルスケアIT開発に絶対的な役割を果たします。エンドユーザーではなく、患者でも、開発チームでもない人は、不十分な開発プロセスで十分に対応できます。アジャイルマニフェストの根底にあるいくつかの原則を検討してください（私のコメント付きでウィキペディアから恥知らずに取り込んだリスト）：
- 便利なソフトウェアの迅速な提供による顧客満足度。これはいつ目的ではありませんか？
- 開発の後半であっても、ようこそ要件の変更。ヘルスケアITは、完全にテクノロジーが殺到しているが、特にITに重点を置いていない分野に統合されます。システムがすぐに「正しく」機能するように設計されている可能性はかなり低いです。
- 稼働中のソフトウェアは頻繁に配信されます（数か月ではなく数週間）。これらのいくつかのエンドユーザーとして、神は私がこれを好きになるでしょう。急速で機能的な変化は非常に貴重であり、ヘルスケアITを「やらなければならないこと」から「仕事のやり方を変えるもの」に変えるものは何ですか。
- 作業中のソフトウェアが進行状況の主要な測定基準です。ほとんどのアプリケーションで理にかなっているので、HITに及ばない理由はありません。
- 一定のペースを維持できる持続可能な開発。これは、感染監視からHIT、施設まで、ヘルスケア全体で見られます。ヘルスケアはブームでもバストでもないサイクルであり、常に鼓動しています。
- ビジネスマンと開発者の間の密接な毎日の協力。ほとんどのHITは開発者ツールではありません。開発者が作ったツールです。クライアントとの連絡は重要であり、重要であるはずです。また、システムが機能し、クライアントのワークフローに統合されている場合、システムに採用したり、パッチを適用したりする必要がないので、システムを採用する方がはるかに簡単です。
- 対面式の会話は、コミュニケーション（コロケーション）の最良の形態です。臨床医との私のやり取りから、やり方は、他のどの方法よりも、できれば紙のパッドを使って、直接行うことが簡単です。
- プロジェクトは、信頼されるべきであるやる気のある個人を中心に構築されます。これは、あなたの生活をより良くするものです-そうそう、それは採用されるべきです;）
- 卓越した技術と優れたデザインへの継続的な注意。これもまた、「誰もがこれを行うべきなので、当然あなたがすべき」ということの1つです。しかし、HITシステムの複雑さと、それらが日常的に使用される無数の方法を考慮してください。粗雑なシステムはそれをカットするつもりはありません。
- シンプルさ。そのまま使用できます。いつでも、想定どおりにうまく機能するはずです。人々は馬鹿です。医療従事者は人です。したがって...残りは知っています。シンプルさが役立ちます。
- 自己組織化チーム。これはHITにとってもう少しストレッチかもしれません。正直なところ、私はこの状況での自己組織化が良いかどうかについて、どちらかと言えば自信がありません。
- 状況の変化への定期的な適応。 HITは、複雑で変化する規制の負担を伴う活発で成長している業界です。適応できることはまともな考えのようです。
FDAで規制された環境での（== --- ==）Agile Medical Device Software Development の使用に関する議論は、しばらく前からあり、この問題に関連しています。理由は次のとおりです。
- ウォーターフォールと反復型開発の長所と短所は基本的に同じであり、あらゆるヘルスITプロジェクトで検討する必要があります。
- FDAが使用する医療機器ソフトウェア開発のための品質システム（ ソフトウェア検証の一般原則、業界およびFDAスタッフ向けの最終ガイダンス を参照）が業界のゴールドスタンダードである。これらの規制は特定の開発方法を規定するものではないことに注意してください。いずれにせよ、これらのベストプラクティスにすべて従えば、医療ITソフトウェアの品質は大幅に向上します。
- ほとんどのヒースITソフトウェア開発は現在、これらのFDA規制基準の下で動作していません。医療機器の相互運用性、特にモバイルプラットフォームの相互運用性の障壁は下がり続けているため、これはおそらく変化するでしょう- FDAがモバイル医療アプリに対応している を参照してください。
- また、商用のヘルスITソフトウェアを開発している場合は、医療機器データシステム（MDDS）を作成しているかどうかを自問する必要があります。 製品はMDDSですか？
短い答えは「はい」です。より長く正確な答えは「真剣に受け止めれば」です。
心に留めておくべきいくつかのテーマがあります。私は、（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つしかないようですが、多くの好みや意思決定もあります。
私の意見では、どのような製品を作成している場合でも、事前に要件を特定することはできません[〜＃〜] all [〜＃〜]要件なので、アジャイルソフトウェア開発方法は非常に機能しますうまく。
述べたように、答えはイエスです。
アジャイルを規制された領域またはリスクの高い領域に適用する場合は、規制の遵守やその他のリスク軽減戦略が含まれるように、反復ごとに「完了」を定義する必要があります。たとえば、QAドキュメント、要件のトレーサビリティ、セキュリティ監査、およびその他のアクションがすべての反復で完了する必要がある場合があります。
たとえば、FDA規制環境へのアジャイルアプローチの適用には、優れた芸術と実践があります。
短い答え：はい。 高保証環境でのアジャイル に関する良いブログがいくつかのヒントを提供しています。
ただし、いくつかの妥協が必要です。 Agile Manifesto について考えてみましょう：
プロセスとツール上の個人と相互作用
実用的なソフトウェア包括的なドキュメント
顧客とのコラボレーション契約交渉
計画への切り替えへの対応
規制機関は、アジャイルチームと同じように左側を重視していますが、通常のアジャイルチームよりも右側に重点を置く必要があります。たとえば、FDAは、プロセスとツールを検証することを要求し、かなり包括的な設計とテストの文書化を求め、間違いなく十分な計画が必要です。
反対に、以下を含む多くのアジャイル原則は、ヘルスケアの世界に非常によく適合します。
- TDDとペアプログラミング-品質の向上
- 厳しい顧客フィードバックループ-早期の検証は素晴らしい
- 反復計画-規制機関はすべて計画に関するものです
一部の分野は、本質的にすでにアジャイルです。たとえば看護は、最終的な結果を段階的に達成するために、診断/予後の複数の反復に依存する「評価-評価-計画-介入」サイクルに依存しています。
ただし、そのような方法で提供されるヘルスケアサービスが、サービス提供で使用するソフトウェアツールまたはシステムに対するアジャイルソフトウェア開発の本質的に単一インスタンスのアプリケーションに特に適していることを示唆しようとすると、致命的な混乱になります。
[〜＃〜] aami [〜＃〜] は、以下のタイトルの技術情報レポートに積極的に取り組んでいます：
AAMI TIR SW1、医療機器ソフトウェアの開発におけるアジャイルプラクティスの使用に関するガイダンス。
2012年に発行されると聞いています。
アジャイルマニフェストの原則（EpiGradsの回答を参照）と、医療機器ソフトウェアに関連する規制要件、一般的なプロセス、およびその他の製品の実用性との整合について説明します。