医療機器の設計管理3

もし、クリエイティブで少し慎重な人がいたら、顧客がどの様なニーズを持っているか、自分が作ろうとする製品はそのニーズをどの様な形で満たすか、そのために製品はどの様な性能や性質を持っているかを事前にまとめているかもしれない。素晴らしいことにDesign inputをしっかりと作成して、多くの人を救うデバイスを開発したのだ。それでは、そのデバイスを製品として売ることができるだろうか？

残念ながら今回も答えはNoである。なぜならば、Design inputがどの様に製品という実体に翻訳されたか、その翻訳に漏れがないという証拠（文書）がなく、設計が正しく行われたか、正しいものが作れているかということを確認できないからだ。エンジニアたちはDesign inputで示された言葉をもとに、設計・開発を進める。例えば、inputとして「重量は200g以下」、「〇〇規程の衝撃試験に耐える」という要求があったとする。するとエンジニアは、うんうんと頭を悩ませながら軽量ながらも衝撃に強い材料や構造を考えて、inputを様々な図面などに翻訳していく。この様にして、Design inputをもとに設計活動から作成された図面などをDesign outputと呼ぶ。医療機器の規制では、outputは下記の様な状態でなければならないとされている。

・inputで与えられた要求事項を満たす
・購買や製造、サービス提供に対して適切な情報を提供する
・製品の合否判定を含むかそれを参照している
・安全な使用及び適切な使用に不可欠な製品の特性を明確にする

また、outputはinputと対比して、検証に適した形式としなければいけない。これは、後々解説するDesign verificationやDesign validationのためである。

また、outputは様々なものがあるが、FDAは例として次の様なものがあると言っている。
•assembly drawings（図面や組図）
• component and material specifications（部品や材料の仕様）
• production and process specifications（製造やプロセスの仕様）
• software machine code（ソフトウェアの機械語）
• work instructions（作業手順書）
• quality assurance specifications and procedures（品質保証の仕様とプロセス）
• installation and servicing procedures（設置やサービスの手順）
• packaging and labeling specifications, including methods and processes used（パッケージやラベル、製品の使い方やプロセスの仕様）

さらに、inputで定められた要求事項に対して、下記の項目もoutputとなり得る。
• the results of risk analysis（リスク分析の結果）
• software source code（ソフトウェアのソースコード）
• results of verification activities（検証活動の結果）
• biocompatibility test results（生体適合性試験の結果）
• bioburden test results（バイオバーデン試験の結果）

また、もう一つ重要なこととして、outputはレビューされ、承認されなければいけないということだ。エンジニアたちが作成したoutputがレビューを突破して、承認されれば、設計は次のステップであるDesign verificationへと進むことになる。それに関しては、また別の記事で紹介をしたいと思う。

ここまで読んでくれた方、ありがとうございました。