医療機器

医療機器業界における設計管理

医療機器メーカーは、ユーザーニーズを満たしつつ規制要件を遵守した安全な製品を設計していることを証明する必要があります。

多くの企業は、製品開発時にドキュメントや設計記録の作成に手動プロセスを使用しています。

手動プロセスは労働集約的でエラーが発生しやすいです。

製品が正しく設計され規制に準拠していても、不完全または誤ったデータが存在すると、監査での問題や市場投入計画の遅延を引き起こす可能性があります。

医療機器メーカーは、完全な設計管理を実現するための必要なツールを提供する独自の統合機能を備えた専用のPLMソリューションが必要です。

Aras Medical Deviceで設計管理のデジタル変革を実現しましょう。

多くの企業は、設計プロセスにおけるドキュメントの作成だけでなく、その保存、検索、適切な承認の取得、ゲート承認プロセスの通過、プロジェクトステータスの更新などにも多大な時間を費やしています。さらに、この作業はドキュメントの保存や作成時に時間がかかるだけでなく、ドキュメントを検索する必要が生じた際にも同様の時間がかかります。

企業は、適切なドキュメントを検索するだけで多大な時間を費やしています。市場にあるほとんどのソリューションは、医療機器業界の特有の要件に最適化されていないためです。プロセスは部分的にしかカバーされておらず、ドキュメントの手動更新、手動チェックイン、ドキュメントの変換が必要となり、エラーのリスク増加、作業量の増加、可視性の欠如を引き起こしています。

この動画では、プロジェクトが予定から外れている場合に、正確で最新のプロジェクトステータスを達成するためのドキュメント管理方法をご紹介します。ドキュメントの検索速度向上、可視性の向上、エラーリスクの低減を実現します。システムは、予定から外れている具体的なデリバブルを指摘するため、初回から正しいドキュメントをすぐに取得できます。

ドキュメントに変更や修正を加えると、システムは自動的に変更を追跡し、ログを記録します。これにより、全員が最新のバージョンで作業できるようになります。システムはまた、ドキュメントをPDFなどの他のファイル形式に自動的に変換することも可能です。最後に、新しいデリバブルが完了とマークされると、変更の承認を担当する担当者に自動的に通知されます。全員が作業を完了すると、デリバブルが完了し、フェーズが自動的に完了し、全員が次の段階に進むことができます。マイクが職場に到着すると、最初にMinerva PLMにログインします。システムにログイン後、マイクはプロジェクトの進捗状況を確認したいと考えています。そのため、プロジェクト画面に移動し、換気装置プロジェクトPB 560がスケジュールから外れていることを確認します。

プロジェクトを開き、遅延の原因を確認するため、デリバブルマトリックスをロードします。このマトリックスでは、すべてのデリバブルのステータスが明確に表示されます。2つのデリバブルが遅延していることがわかります。そのうち1つはオーナーによるクローズルール、もう1つはデリバブルリリースによるクローズルールが設定されています。国リストと言語要件のクローズルールはマイク自身のデリバブルのため、クローズボタンを押すことで手動でクローズできます。

これにより、システムにマイクが完了したことが通知され、このデリバブルのステータスが自動的に「完了」に設定されます。未完了のもう1つのデリバブルは、ブザーボードの顧客要件文書です。これは、ECOによってクローズされるべきWord文書です。マイクはオフィスコネクタ経由でWordを開きます。

彼はArasデータベースでこの特定のファイルを検索します。ファイルを見つけたら開いて編集できます。WordはArasからファイルを自動的に読み込み、マイクは文書を完了させます。彼はこの文書が換気式PB 560モデルにも適用されるように追加し、改訂履歴がPLMシステムで管理されるため、不要になった改訂履歴を削除し、目次を更新します。文書をArasに保存すると、Aras内のファイルが更新され、閲覧可能なPDFファイルが自動的に生成されます。文書が保存されると、Wordに通知されます。彼は戻り、文書オブジェクトを開き、サイドバーをクリックして閲覧可能なファイルをロードし、変更がファイルに反映されているか確認できます。スクロールダウンすると、目次が更新され、改訂履歴が削除されていることが確認でき、この文書がPB 560換気装置シリーズにも適用されるという彼の更新も反映されていることが確認できます。

ドキュメントのメインフォームに戻り、マイクは「変更」タブに移動して、このドキュメントのリリースプロセスのステータスを確認できます。ドキュメントの変更オーダーへの関連付けを見つけ、それが自分に割り当てられていることを確認し、マイクはリリースプロセスに承認を付与できます。これによりドキュメントがリリースされ、プロジェクトで遅延していた最後のデリバブル行も自動的に閉じられます。ドキュメントは現在リリースされています。マイクはプロジェクトに戻り、デリバリーマトリックスをリフレッシュすると、最後の遅延していたデリバブルが閉じられていることを確認できます。再びプロジェクトを検索すると、すべてが正常であることを確認できます。

すべてのプロジェクトが予定通り進捗しており、彼は業務を継続できます。

設計履歴ファイルとデバイスマスターレコードは、規制当局が求める2つの文書構造の例です。これらの文書はデバイスまたは製品に関連付けられており、変更内容を記録する必要があります。多くの場合、この作業は手動で実施する煩雑な作業となります。したがって、医療機器業界のソリューションでは、必要な数の規制文書構造を簡単に作成し、同じ方法で管理できるシステムが必須です。これにより、文書構造が自動的に作成され、追跡され、基準化されることが保証されます。当社のいくつかの顧客は、技術ファイルのような他の文書構造も、DHFやDMRと同様に管理する必要があることに気づいています。DHFやDMRと同様の変更管理と追跡可能性の要件を満たす新しい文書データ構造を簡単に作成できることは、現在のニーズだけでなく、将来のニーズにも対応できるための重要な要因です。

ある企業では、新しい呼吸用人工呼吸器の設計チームがプロジェクトを進めています。このような機器の開発は極めて複雑なプロジェクトであり、誰が何を変更したかを完全に追跡できることは、人工呼吸器を市場に迅速に投入するためだけでなく、規制当局からの必要な承認を取得するためにも不可欠です。この企業では、プロジェクトの変更はもはや悪夢ではありません。マイクと彼のチームは呼吸器プロジェクトの完了に尽力していますが、コンセプトフェーズにおいて、特許出願をコンセプトフェーズ内に完了できないことが判明し、エンジニアリングプロトタイプフェーズへ移行したいと考えています。

Minerva PLMでこのような変更を行うには、変更注文（デザイン変更）を作成する必要があります。これは、変更の監査トレイルと追跡可能性を維持するためです。これらの変更は、プロジェクトの変更セクションから「デザイン変更」ボタンをクリックすることで自動的に作成できます。これにより変更注文が作成され、マイクは自動的に次のステップに投票できます。

この作業を開始すると、新しいリビジョンが作成されます。リビジョンがDからEに変更され、現在作業中状態になっています。これにより、マイクはこのプロジェクトを編集できます。彼は特許出願のデリバブルを右クリックし、切り取り、エンジニアリングプロトタイプフェーズに貼り付けます。「保存」をクリックすると、このデリバブルがコンセプトからエンジニアリングプロトタイプに移動します。ここでも確認できるように、プロジェクトのエンジニアリングプロトタイプフェーズに配置されています。プロジェクトのステータスは「作業中」のままです。つまり、このプロジェクトの変更は未承認です。承認を得るためには、マイクがこの設計変更をレビューステップに送信し、ステアリンググループが提案された変更を評価し、承認するかどうかを決定する必要があります。

マイクはレビューに送信します。コメントを記入することもできます。時間的制約のため、特許出願を次のフェーズに移動したいと考えています。完了をクリックすると、ステアリンググループ全体にマイクから変更リクエストが送信された通知が送信されます。彼らはこの変更を評価し、承認するかどうかを判断できます。

その間、マイクは待つしかありません。しばらくして、マイクはステアリンググループが変更を承認した通知を受け取ります。プロジェクトに戻ると、リビジョンEがリリースされたことが確認できます。プロジェクトに移動すると、特許出願がコンセプトフェーズからエンジニアリングプロトタイプフェーズに移動されたことがわかります。

これにより、チームはコンセプトフェーズを完了し、適切に作業を進めるための少しの時間を確保できました。追跡可能性の観点から、すべてのバージョンとベースラインはシステムに常に保持されます。したがって、誰かが確認したい場合、現在リビジョンEの状態を確認し、このプロジェクトのリビジョンDの状態や、その時点でのデリバブルマトリックスとすべてのデリバブルの状態を確認できます。

マイクは、プロジェクトのバージョンセクションを開き、プロジェクトのすべてのバージョンとベースラインを確認できます。リビジョンDに戻り、それを開くことができます。プロジェクトのリビジョンDを開くと、特許出願がコンセプトフェーズの一部であったことが明確に確認でき、現在はエンジニアリングプロトタイプフェーズの一部となっていることがわかります。

このベースライン設定では、Minerva PLMは各フェーズに何があったかの履歴を保持するだけでなく、各デリバブルのどのバージョンがどの時点において有効であったかを追跡します。したがって、以前のバージョンから任意のファイル、デリバブル、または部分を開くと、その時点において有効であったデリバブルの特定のバージョンに必ず移動し、プロジェクトの強力な監査トレイルと真のベースライン設定を提供します。

設計履歴ファイルとデバイスマスターレコードの記録は、規制当局が求めるドキュメント構造の例です。これらはデバイスまたは製品に関連付けられており、変更内容を記録できないと、手作業で煩雑な作業になるのを防ぐ必要があります。解決策は当然ながら、これらの変更とベースラインをすべて追跡する機能を備える必要があります。

しかし、当社のいくつかの顧客は、地域によってはDHFやDMRと同様に管理する必要がある技術ファイルなど、他のドキュメント構造が存在することを指摘しています。ある企業では、新しい呼吸用人工呼吸器の設計チームが作業を進めています。このような機器の開発は極めて複雑なプロジェクトであり、誰が何を変更したかを完全に追跡できることは、換気装置を市場に迅速に投入するためだけでなく、規制当局からの必要な承認を取得するためにも不可欠です。この企業では、プロジェクトの変更はもはや悪夢ではありません。Minerva PLMがどのように支援しているかを見てみましょう。今日はプロジェクトにアクセスし、人工呼吸器プロジェクトの特許出願作業を開始します。

私がやることは、プロジェクトにアクセスし、デリバブルマトリックスを開いて特許出願の場所を特定することです。プロジェクトを開くと、多くのドキュメントデリバブルがまだ作成されていないことが分かり、これらのデリバブルがどの製品に関連しているか、この開発プロジェクトでどの製品が作成されているかも確認できます。

これらのデリバブルは、当然ながらDHF（設計履歴ファイル）とこの製品に関連するすべてのDMR（設計レビュー文書）にも含まれる必要があります。製品を開くと、2つのタブが表示されます。デザインヒストリーファイルタブを開くと、この人工呼吸器用の自動的に生成されたDHFを確認できます。各デリバブルのプロジェクトステータスも確認できます。

特許出願を確認すると、現在審査中であることがわかります。9月4日までに完了する予定ですが、まだ作成されていません。プロジェクトに戻り、特許出願を検索すると、グリッド内を検索し、インターフェースコンセプトに該当する箇所が見つかります。

デリバブルの行はありますが、まだ作成されていません。インスタンス化をクリックすると、システムがテンプレートを取得し、特許出願の文書を自動的に作成します。ご覧の通り、この文書は特許出願のテンプレートから自動的に作成されました。プロジェクトのコンテキストでDHFを確認すると、特許出願が作成されたことが確認できます。

M3とDHFには関連するドキュメントが紐付いています。パーツに戻ると、パーツのDHFタブに特許出願が作成されていることが確認できます。プロジェクト内で実施した操作に応じて、DHFが自動的に更新されるため、すべてが一致しているか確認しやすくなります。