デザイン検証vs.検証:医療機器開発のための6つのヒント

Posted on

製品、特に医療機器を開発する場合、デザイン検証とデザイン検証（v&Vとも呼ばれる）という用語を聞いたことがあります。 ここでは、二つの活動が何であるかを説明します,それらの違い,プラスあなたの努力を最大限に活用するための共有のヒント.ノート

: このコンテンツがあなたにとって有用であることを検証するために、私たちは、医療機器V&v、医療機器ソフトウェア、製品およびソフ あなたは彼女の洞察力と例を見つけることができます！

フォローするか、後のセクションにスキップします。

  • デザイン検証とデザイン検証
  • デザイン検証とは何ですか？FDAの設計検証とは何ですか？
  • 検証vs検証の概要
  • 設計検証プロセスの基礎
  • より良い検証のための6つのヒント&検証
  • ビデオ：簡略化V&V
  • V&V
  • V&V
  • V&V
  • V&v:用語集

デザイン検証とデザイン検証：違いは何ですか？検証と検証の違いは何ですか？ 簡単に言えば、設計検証は、あなたが適切な製品を構築しているかどうかを決定します。 デバイスはエンドユーザーの意図したとおりに動作しますか？ 設計検証は、製品を正しく構築しているかどうかを決定します。 設計出力は設計入力と一致していますか？

これは、下のグラフにはっきりと示されているような単純な違いです。

画像ブログデザイン検証チャート
デザイン検証：あなたは正しい製品を構築していますか？ 設計検証：製品を正しく構築していますか？しかし、あなたはもちろん、より多くの詳細と例が必要です。 検証から始めましょう。

設計検証とは正確には何ですか？ 設計検証は、構築したデバイスが意図したとおりにエンドユーザーのために機能することを証明（「検証」）するテストプロセスです。FDAからの公式の言葉（21CFR820.3）は、設計検証は「デバイスの仕様がユーザーのニーズと意図された使用に準拠しているという客観的な証拠によって確立され”

設計検証例

患者の呼吸を維持する人工呼吸器を構築しており、ユーザーが患者の輸送中に動作させたいと考えてみましょう。

まず、ユーザーのニーズを定義する必要があります。 ユーザーは換気装置にある間、患者を動かしたいと思う。 しかし、彼らは実際に何をしようとしていますか？ 「輸送」には、病院内で患者を移動させることが含まれる場合があります。 または救急車または空気による輸送を含むかもしれません。 たとえば、ユーザーのニーズは次のようになります。

ユーザーのニーズ

UsNe-0001 人工呼吸器は、患者の病院内輸送中に使用するのに適しています。

このユーザーのニーズは、製品を設計し、構築するために、製品の要件と設計仕様に分類されます。 （私たちは、設計検証の下で一瞬でそれらを見てみましょう。)

その前に、ユーザーのニーズを調べ、どのような設計検証テストケースが必要かを見てみましょう。 ユーザーニーズの検証テストは次のようになります。

ユーザー
必要		 検証
テスト
UsNe-0001
UsNe-0001
人工呼吸器は、患者の病院内輸送中の使用に適しています。 TCase-0001 検証テストスイート：病院輸送スタッフの15人が人工呼吸器を簡単に転がすことができることをテストします。
TCase-0002 検証テストスイート: 廊下、ドア詰まり、エレベーターのしきい値をロールダウンしながら、換気装置がその仕様の範囲内で動作することをテストします。
TCase-0003 検証テストスイート：ac電源とバッテリ動作の間を移行しながら、人工呼吸器がその仕様内で動作することをテストします。

検証テストには、テストケース、テストスイート、または製品が構築されていることを証明するように設計された臨床試験が含まれます。 これらのテストは実稼働または同等の生産単位で実行する必要があるため、設計検証テストは多くの場合、最後に実行されるテストです。

基本的に、設計検証では、製品がユーザーのニーズを満たしていることを実証する必要があります。

ところで、上の表は、ユーザーのニーズとテストケースの間のトレーサビリティも示しています。 このトレース行列は、FDAが必要とするvの証拠の一部を提供します。FDAの設計検証とは何ですか？ 設計検証は、設計出力が設計入力と一致することをテスト（「検証」）する場所です。また、FDAによると、デザイン検証とは、「指定された要件が満たされているという客観的な証拠の検討と提供による確認」です。”

それはテストを伴うだろうが、他の許容可能な検証活動があることに注意してください。テスト、検査、および分析を含めることができます（詳細については、FDA Design Control Guidanceを参照してください）。

設計検証例

人工呼吸器の例に戻りましょう。 ここでは、デバイスが何をしなければならないのか、どのようにしなければならないのかを特定しましょう。それを達成するために、我々は特定の製品要件を定義する必要があります。

たとえば、

  • 患者の最大負荷は何ですか？ （人工呼吸器はどのくらいの空気を動かす必要がありますか？)
  • バッテリーはどのくらい持続する必要がありますか？ （輸送にはどのくらいの時間がかかりますか？)
  • 彼らは輸送中にどのような条件が発生しますか？ （ドアジャム？ エレベーター?)
  • 満たす必要がある規制基準はありますか？ （安全基準？)

“明確で、完全で、明確で、テスト可能な要件は、成功した開発プロジェクトの重要なコンポーネントです。 不十分な要件は、無駄な時間、設計エラー、大規模なリワーク、および壊れやすいまたはエラーが発生しやすい製品につながります。”-Megan Martin,V&V Consultant

これは、デバイス特性を定義する”どのような”部分です。 デバイスは正確に何をする必要がありますか？ ユーザーニーズのための製品要件（製品要件文書に含まれることが多い）は、以下のようになります。

製品要件

PrRq-0001

人工呼吸器は、毎分20呼吸で2リットルのボリューム制御呼吸の最大設定を持っていな/p>

PrRq-0002

人工呼吸器は、最大設定で最低90分間バッテリー電源で動作しなければなりません。

PrRq-0003

人工呼吸器は、ローリングサポートスタンドに取り付けることができるものとします。/p>

PrRq-0004

人工呼吸器とスタンドは、典型的な病院のドアとエレベーターのしきい値を横断することができなければなりません。

最後に、設計仕様が必要です。 「私たちはすでに達成しようとしていることを定義していますが、今はそれをどのように行うかを定義する必要があります」とMegan氏は言います。 これは、書面による仕様書、電気的または機械的図面、部品購入仕様書、または他の方法を含む、さまざまな方法で達成することができます。

たとえば、設計仕様と図面には次のように表示される場合があります。

設計仕様

dspec-0001

毎分40リットルの空気を生成することができるタービン。

DSpec-0002

リチウムイオン電池パックは、少なくとも100アンペア時間定格。/p>

dspec-0003

ローリングスタンド用のマウントは、22ポンドの定格鋼レバーアクションクランプを使用しています。/p>

DSpec-0004

スタンドベースは22インチワイドで5つの車輪が付いています。/p>

DSpec-0005

スタンドホイールの直径は4インチです。

設計検証は、設計出力（実際の製品）が設計入力（製品要件と設計仕様）を満たしているという証拠（テスト結果）を提 検証される項目に応じて、テストケースまたはテストスイートが実行されるか、必要な証拠を提供するために検査または分析が行われます。

以下の表は、それがどのように見えるかを示しています。 彼らはまた、FDAが期待するトレーサビリティを示しています。

製品要件 検証テスト
PrRq-0001 人工呼吸器は、2リットルのボリューム制御呼吸の最大設定を有する毎分20回の呼吸。 TCase-0004 テストケース：最大ブレス設定またはブレス設定の組み合わせを確認します。
PrRq-0002 人工呼吸器は、最大設定で最低90分間バッテリー電源で動作しなければなりません。 TCase-0005 テストスイート: 完全に充電された新しいバッテリーで最大設定のランタイムを確認します。
TCase-0006 テストスイート：50回の充電サイクルを経たバッテリーで最大設定のランタイムを確認します。
PrRq-0003 人工呼吸器は、ローリング支持スタンドに取り付けることができるものとする。 TCase-0007 実証試験：人工呼吸器をローリングスタンドから取り付け、取り外すことができることを実証します。
PrRq-0004 人工呼吸器とスタンドは、典型的な病院のドアとエレベーターのしきい値を横断することができなければなりません。 TCase-0008 外部テスト：換気装置とスタンドを検証するためのテストサービスによって実行されるテストは、IEC60601-1医療電気規格に従って転倒することな

製品の要件の検証は、上記のように、製品は、我々はそれが行うだろうと言ったことを行うことを示しています。

次に示す設計仕様の検証は、製品が私たちが言ったようにそれを行うことを示しています。

設計仕様 検証テスト
DSpec-0001 毎分40リットルの空気を生成することができるタービン。 TCase-0009 テストスイート：交流電力またはバッテリ電力のいずれかで40lpmでタービンによる空気生成を確認します。
DSpec-0002 100アンペア時間定格リチウムイオンバッテリーパック。 TCase-0010 検査テスト：バッテリーの購入仕様を確認するタイプはリチウムイオンであることを示しています。
TCase-0011 分析テスト：テストデータを収集し、バッテリーの寿命にわたってバッテリーの性能を実証するためにデータ分析を行い、100アンペア時間を満た
DSpec-0003 圧延の立場のための台紙は22のlbsのために評価される鋼鉄レバー行為クランプを使用する。 TCase-0012 検査テスト：部品仕様が22ポンド以上の定格スチールレバーアクションクランプ用であることを確認します。/td>
DSpec-0004 スタンドベースは22インチワイドで5つの車輪が付いています。Td>

TCase-0013

 テストケース：測定ベース直径;カウントホイール;測定ホイール直径
DSpec-0005 スタンドホイールは4″直径を持

基本的に、設計検証では、私たちが構築した製品が、私たちが構築すると述べた製

V&Vレポートで一緒に収集すると、検証と検証テスト結果の組み合わせは、ユーザーのニーズ、製品要件、および設計仕様に戻ってトレーサビリティーと一緒に、FDAがクリアランスのために医療機器を提出する際に必要とする証拠の一部を提供します。

検証と検証の概要

ここでは、主な違いの簡単な、わずかに単純化されている場合、要約です。

Design Verification

Design Validation

Design output is as expected.

Final design meets user’s needs.

System, subsystem and unit testing.

System testing.

During development.

After development.

Test individual module or completed system under any conditions.

Test conditions per user needs.

システム検査、分析、およびテストが含まれます。

実際の使用条件下での生産同等ユニットのテストが含まれます。

実行されたテスト、テスト結果、およびトレーサビリティのレポートが含まれます。 報告書は、審査、承認、および署名されています。

規制レビューの準備ができて、テスト結果とトレーサビリティと、最終報告書が含まれています。 報告書は、審査、承認、および署名されています。

設計検証プロセスの基本

設計検証プロセスは、主にデバイスのテストで構成されます。 状況に応じて、いくつかの方法でこれを行うことができます。 活動には、以下が含まれます。

  • 同様の目的のために実行する同様の機器と比較する。
  • 数学的モデリングによる機能のシミュレーション。
  • ユーザーのニーズに定義されているようにシステムが動作することを証明するために、最終的な設計をテストします。

テスト計画、テストケース、テスト実行記録、およびテスト結果は、設計記録の一部として文書化され、維持される必要があります。 検証は、その全体が単一のアクティビティの結果ではなく、すべての検証アクティビティの結果のコレクションです。

設計検証プロセスの基礎

検証は、単純な五段階のプロセスに減らすことができます。

特定と準備

検証を行うための最良のアプローチを特定します。 何を測定するか、どのように測定するかを定義します。 また、検証を成功させるために必要なリソース、人材、およびツールを検討する必要があります。

計画

検証の計画は、プロジェクトのライフサイクル全体にわたって行われます。 重要なマイルストーンをキャプチャするテスト計画を作成します。 設計入力に変更が加えられるたびに、計画を更新する必要があります。

開発中

製品開発が始まります！ これは、選択した方法論（スクラム、ウォーターフォール、ハイブリッドなど）を使用して行われます。). プロセスのこの部分には、検証に使用されるテストケースの作成、テスト運転、および承認も含まれます。

実行

テスト手順は計画どおりに実行されます。 無効な結果は文書化され、レビューされ、承認されるか、欠陥として記録されます。 製品の欠陥が解決され、解放され、回帰テストが実行されます。 トレーサビリティマトリクスは、検証テスト計画で特定された設計入力がテストされ、合格したことを確認するために作成されます。

レポート

レポートは、検証の各フェーズの最後に実行されます。 詳細なレポートには、構成管理およびリリースレポート、テストの種類または製品バージョン別のテスト結果、検証作業中に検出された問題が含まれます。 設計検証トレーサビリティレポートには、テスト結果と要件のカバレッジが表示されます。 最後に、各設計検証活動の後にレビューが完了し、承認されます。

より良い検証のための6つのヒント&検証

ここでは、検証を最大限に活用するためのヒントがあります&検証

先に計画してください（そして早期にテストしてください）

しっかりした計画を立てて、みんなをループしてください。 テストエンジニアを開発計画の初期段階に含め、要件と設計が明確で、完全で、テスト可能であることを確認します。 “テスト方法の早期開発は、技術の問題が大きな障害になる前に明らかにすることができます。”初期のテスト開発では、テストツールを提供することもできます。 これらは、製品開発プロセスをスピードアップするだけでなく、正式なテスト中にテスト証拠を提供するために使用することができます。

共有命名法を使用する

チームを同じページに配置することは、設計検証を成功させるために重要です&検証。 同じページに乗ることの一部は、共有用語を使用することを意味します。 同じ用語を使用すると、チームメンバー（新しいメンバーだけでなく、ベテランも）の混乱がなくなります。 用語の基礎を開発するために、以下の用語集と一般的な頭字語を参照してください。

エンドツーエンドのトレーサビリティを持つツールを使用してください

その最も簡単で、トレーサビリティは、word文書やスプレッドシートで達成す

“正確なトレース行列は、製品の変更やバグ修正後に再テストする必要があるかを決定するために回帰分析を行うときに非常に貴重です。”-Megan Martin,V&V Consultant

強力な要件-テスト-ツー-結果トレース機能を備えたツールを使用すると、カバレッジの穴を特定し、製品内の脆弱

ブログALMトレースレポート
エンドツーエンドのトレーサビリティを備えたツールは、デバイス開発を簡素化します。 ヘリックスALMで示されているトレースレポート。

今すぐエンドツーエンドのトレーサビリティを取得

あなたが行くようにあなたのトレース行列を構築

“それはそれを先”ミーガン氏は述べています。 あなたが行くようにあなたのトレーサビリティを構築することは見過ごされて開発から穴を維持します。 開発作業が完了したと思ったときに、重要な要件、リスク軽減機能、または必須テストを逃したことを発見するよりも、回復するのが難しいことはほと

11時間目に設計と開発の重要な穴をパッチするよりも、要件、設計、テストが進化するにつれてトレーサビリティを維持するためのメンテナンス工 この作業は、どのくらいの作業が残っているか、開発スタッフやテストスタッフを追加する必要がある可能性がある場所、または配信スケジュールをいつ再評価する必要があるかを特定するのにも役立ちます。

テスト実行完了のためのブログALM要件
11時間の緊急事態を避けてください！ ここでは、ステータスは要件の間で追跡されます&Helix ALMで完了したテスト。

要件トレーサビリティを統合&異常追跡によるテスト

異常を要件に直接リンクできることは、テスターと開発者 それは非常に便利です。 テストプロトコルの障害から直接異常を生成することは、問題の詳細がキャプチャされることを意味します。 その結果、問題をより簡単に文書化、再現、修正、および再テストすることができます。

ブログALM異常生成
Helix ALMに示すように、失敗したテストから作成された異常。

メソッドに合わせてカスタマイズできるツールを選択

“選択した開発モデル—アジャイル、反復、変更されたウォーターフォール—V&vツールを提供するためにプロセスを適応させるのではなく、プロセスに適応させることによってサービスを提供するツール”とMeganは助言する。

あなたが選択した医療機器開発ツールは、あなたのチームがやっている仕事の正確さと有効性に追加し、彼らの毎日のタスクに不要なオーバーヘッドを追 良いツールは、重要なことが常に行われていることを確認するためにガードレールを提供します。 チームは、キャプチャしたデータをよりよく使用（および探索）するためのアドホックなビューとレポートを作成する柔軟性を提供します。 これは、vを提供します&vレポートの生産を簡単かつ再現可能にするために、データキャプチャとレポートを対象としました。

選択する前に、チームをサポートするツールをどのように定義するかを時間をかけてください。 その後、チームのニーズに合わせてツールを設定します。

ブログALMタスクボード
アジャイル、ウォーターフォール、ハイブリッド？ プロセスに合ったツールを選択します。 ここでは、ヘリックスALMのオプションのスプリントボード。

それをすべて一緒に持って来る

設計検証と検証は、成功したデバイス開発の不可欠なコンポーネ チーム間の理解と適切なツールを共有することで、デバイスを市場に投入するための強固なフレームワークが得られます。
時計のデモ今>>

簡素化V&VヘリックスALM

となっています。p>どらせんALMに加速できる医療機器を開発。このブログに非常に貴重な洞察を提供したVの専門家Megan Martinに感謝します！

Helix ALMを探る

*再び、V&Vの専門家Megan Martinに感謝します！

V&V:用語集

実際の結果–アクションが実行されたときにシステムが実際に何をするか。

異常–システムが期待どおりに動作しない場合。 たとえば、バグ、エラー、またはテストの失敗などです。

成果物–プロジェクトの実行の結果として生成される義務的なオブジェクト、通常は検証作業の文書。

偏差–プロセスまたは手順を定義どおりに実行できず、代替の方法または材料が使用されている場合。

偏差-プロセスまたは手順を定義どおり

期待される結果–アクションが実行されたときにシステムが何をすべきか。

統合テスト–サブシステムの相互作用と相互依存性を検証するために、二つ以上のサブシステムを使用して実施されたテスト。

Protocol–システムテストを文書化するために使用されるテストケースのコレクション。

Qualification–システムが定義された要件のコレクションを満たすことを指定するテストプロトコル。

品質保証–製品の品質またはプロセスの完全性を確保することを任務とするチームメンバー。

要件–システムが行うことができる必要があります何か。

レトロスペクティブ検証–既に存在するシステムの検証。

仕様–システムまたはコンポーネントの要件を概説する文書。

Subsystem Test–主要なサブシステムまたはコンポーネントのグループで実施されるテスト。

システム–検証を受けているもの。

システム所有者–システムを最終的に担当する個人。

システムテスト–システム全体を使用して実施されたテスト。テストケース-システムが要件または要件のコレクションを満たしていることをテストするために使用される文書化された手順。

テスト計画–システムが要件を満たしていることを確認するために確立されたテスト方法論。 テストステップ-テストケースの個々の行。 これには、指示、期待される結果、および実際の結果が含まれる必要があります。

トレーサビリティ–仕様書に記載されている要件がテストされていることを確認する能力。 多くの場合、要件トレーサビリティマトリックスでキャプチャされます。

単体テスト–ソフトウェアまたはハードウェアユニットまたは低レベルモジュールで実施されるテスト。

検証–デバイスの仕様がユーザーのニーズと意図された使用（複数可）に準拠していることを客観的な証拠によって確立します。

検証パッケージ–検証プロジェクト中に生成されたドキュメントのコレクション。

検証–指定された要件が満たされていることを客観的な証拠の検討と提供による確認。

V&V Plan–検証および検証される要件、およびv&v努力のマンパワー、責任ある個人、ツール、方法、リソース、およびスケジュー

Common Design Validation Acronyms

CC–Change Control

CCB–Change Control Board(どのような変更が行われ、いつ行われるかを制御する個人のグループ)

DS–Design Specification

FAT–Factory Acceptance Testing

FS–Functional Specification

FRS–Functional Requirement Specification(Functional Specificationを参照)

GCP–Good Clinical Practice(quality guidelines for clinical operations)

GCP–Good Clinical Practice(quality guidelines for clinical operations)

GCP–Good Clinical Practice(quality guidelines for clinical operations)

GCP-Good Clinical Practice(quality guidelines for/p>

glp-Good Laboratory Practice（医薬品検査業務のための品質ガイドライン）

GMP-Good Manufacturing P>

RTM–要件トレーサビリティマトリックス

SAD–ソフトウェアアーキテクチャ文書またはシステムアーキテクチャ文書

SAT–サイト受け入れテスト

SCCB–ソフ仕様

tm–トレーサビリティマトリックス

uat–ユーザー受け入れテスト

urs–ユーザー要件 Specification

UUT – Unit Under Test

VMP – Validation Master Plan

VP – Validation Plan

V&V – Verification and Validation

コメントを残す

メールアドレスが公開されることはありません。