医療機器の設計管理2
みなさんは、ものを作ったり、システムを作ったりする時に、どの様なプロセスを踏むだろうか。おそらく、なんとなく頭の中に浮かんだことをやりたい様に形にしてくだろう。そして、もしあなたがその結果として人の命を救うデバイスを生み出したとする。それは医療機器として、世に売り出していけるだろうか...？
答えとしては「No」である。なぜなら医療機器を生み出す過程を管理していないからだ。管理されていないプロセスで作られた医療機器は、品質が十分出ない（患者に被害を出す可能性が大きい）とみなされ、売ることができないのだ。そのため、医療機器の品質が悪くないことを証明するために、設計のプロセスを管理しなければならない。そして、これはFDAやISO13485で要求されている。以前の記事で設計のプロセスは、Design Planから始まるということを述べた。今回はその次のステップとなるDesign inputの話をしよう。
さて、Design inputとは何か？大雑把にまとめると、開発される医療機器の機能や性能で決めておかなければいけない項目で、設計のスタート地点となるものだ。そして、Design inputをもとに、種々の設計活動やValidation（設計の妥当性を確認していく作業）が行われていく。また、Design inputは、例えば、意図した使われ方はどんなものか、ユーザーは何を求めているか、満たさなければいけない規制は何か、その他設計に関わる情報（類似品の情報など）何か、などを含めなければいけない。また、リスク分析の結果（製品を患者が使った時にどの様なリスクがあるかを分析したもの）もDesign inputの一部となる。FDAの820.30(b)では以下の様に言われている。
• Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient.
メーカーは各、デバイスに関する設計要件が適切であること、ユーザーと患者のニーズを含むデバイスの使用目的に対処するための手順を確立し、維持しなければならない。
• The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.
手順には、不完全な、あいまいな、または矛盾する要件に対処するためのメカニズムを含まなければいけない。
• The design input requirements shall be documented and shall be reviewed and approved by designated individual(s).
Desing inputの要件を文書化し、指定された個人がレビューおよび承認しなければならない。
• The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
承認は、要件を承認する個人の日付と署名を含め、文書化しなければならない。
技術者として、注意しないといけないのは、Design inputとコンセプト文書は違うという点だ。Design inputは、エンジニアリングレベルでの詳細が述べられていることが望ましい。例えば、製品がポータブルであるという要求があったとしよう。これは、厳密にはDesign inputではない。そうではなくて、ポータブルであるということからエンジニアの言葉に「翻訳」されたもの（数字など）がDesing inputとなる。例えば、縦×横×高さの寸法、重量、衝撃、振動、温度、湿度への耐久性などがinputである。また、実装できて正しさを確認できる様にしなければならない。
とはいえ、なかなかバッチリと決めるのは難しいし、どのレベルで決めるかをイメージしにくいかもしれない。そこで、少し例をあげて考えてみよう。例えば、「デバイスは世界中で充電できる」という要求があったとする。これでは、曖昧すぎてインプットとしては不適である。エンジニアは充電できるという要求をもう少し踏み込んで「翻訳」しなければいけないのだ。では、「日本、アメリカ、ヨーロッパで充電できる様にする」というインプットはどうだろうか。先ほどよりも、翻訳がすすんだ様であるが、これも不十分である。なぜならば、実装できるレベルまで翻訳が進んでいない上に、実装が正しく行われたかを確認できないからだ。そこで、もう一歩ふみこんで考えてみよう。上に挙げた国々で、実際に使われている電圧を調べて、それらの上限と下限をとり、「〇〇V〜□□Vの間で動作する」というインプットにするのだ。さらに、何かが原因で電圧が△Vだけ上下する可能性があることを考慮して、「〇〇 - △V〜□□+△Vの間で動作する」というふうにする。この様なインプットの場合、エンジニアは具体的な数字をもとに、回路や機械に落とし込み実装することができる。また、正しく実装がおこなえたかを検証することもできる。
この様に、明確に、理解できる様な形にインプットを落とし込むには頭を使わなければいけない上に、時間がかかってしまう（その上に早く設計開発を進めてほしいという周りからのプレッシャーもある）。そのため、Design inputにあまり時間をかけないで、ささっと決めてしまうことがあるかもしれない。しかし、これは間違いである。インプットは設計の基礎となるので、適当に決めてしまうと後々時間がかかることが多い。限られた時間の中で、しっかりと明確なインプットを決めるというのはエンジニアの腕の見せ所だろう（これが難しいのであるが...）。
さて、設計開発が進むにつれてエンジニアたちは開発初期段階と比べて、様々な情報を得ることになる。いくつかの検証の結果として、インプットを変更しなければならなくなる事態が発生する可能性がある（そしてこれはよくあるだろう...。特にインプットを適当に決めてしまった場合は多くの変更が必要になる場合が多い。）。その場合、インプットを変更することになるのだが、この場合、変更点や変更したことによる設計全体への影響などをしっかりと「文書化」して管理をしなければならない（これはChange controlと言って設計管理の重要な項目の一つとなっている）。
様々な点に思考を巡らせて、Design inputを作成し、これが承認された場合には設計開発が次のステップに進むことになる。それに関しては、また別の記事で紹介することにする。
ここまで読んでくれた読者の方、ありがとうございました。