らくらくISO9001講座


口語訳 ISO13485:2016

7.製品に関わる業務(前半)
 7.3 設計・開発

赤字  ISO13485:2003及びISO9001:2015 にない決まり 
紫字  ISO9001:2015 にない決まり
緑字  この口語訳の追加説明

改訂 2017.12.14
前へ
次へ
トップへ
戻る

本記事のタイトルは口語訳ですが、内容は翻訳ではなく解釈の1例です
規格への適合性は原文や対訳版で判断して下さい






7章 製品に関わる業務(前半)

7.1 製品の管理方法


  ◆ 品番ごとにルールを決める
    会社は、製品の品番ごとのルールを決めること。(製品仕様、QC工程表、製造基準、検査基準、
    取扱い方法など)
    このルールは、他の仕事の仕組みと矛盾がないこと。
【文書】 【記録】 
  ◆ リスクマネジメントの実施
    製品の設計・開発、製造、出荷、使用などに関して、リスクマネジメントを行うこと。その方法を、
    文書で定めること。このリスクマネジメントの方法は、1つでなくても良い。
    リスクマネジメントの記録を残すこと(4.2.5に従って管理する)。
【記録】 
  ◆ 製品の品番ごとのルールとして、以下の項目(必要なもの)を決めること。
a) ・製品(品番、グレード)の仕様【要求事項】  
  ・製品品質に関する目標値【品質目標】
b) ・個々の製品の製造方法【プロセス】  
  ・そのために必要な施設、設備、作業環境など【資源】
  ・製造の途中で作成する文書(4.2.4に従って管理する)
  ・必要な人員(人数、技術、技能、資格など)【資源】
c) ・製造工程における監視、試験、検査、妥当性確認などの評価方法
  ・製品の合否の判定基準
  ・その保管方法、輸送方法、その間の取扱い方法、トレーサビリティのために必要なこと。
d) ・製品の品質を証明する記録(記録は4.2.5に従って管理すること)
【文書】 
  ◆ このような製品の品番ごとのルールを文書(書面、図面)で定めること。文書のスタイルは、
    自社で使いやすいもので良い。

  <補足説明> リスクマネジメントの実施方法はISO14971を参照すること。



7.2 顧客に関わること


 7.2.1 製品の仕様を明らかにする

  ◆ 製品(またはサービス)ごとに決められた仕様、性能、あるいはそのほかの決めごとを整理し、
    説明できること。

a) 顧客との約束【顧客要求事項】
  ・製品の仕様  ・納品に関する約束  ・納品後のサービスに関する約束
b) 顧客との約束以外で必要なこと【用途に応じた要求事項】
  ・顧客との約束はないが、当然しなければならないこと。
  ・顧客との間では詳細を決めておらず、自社の判断で対応すること。
  ・カタログやホームページで通知(不特定多数に約束)した内容。
c) 製品に関わる法令上または公的な決まり【法令・規制要求事項】
d) 製品を正しく安全に使ってもらうために、使用者(医師、検査技師など)に対して行う、使用
  説明やセミナー【ユーザートレーニング】
e) その他で、会社が必要だと考えること【組織の追加要求事項】
  ・経営方針、営業戦略、リスク回避などを考えて加えるもの


【記録】 【文書】 
 7.2.2 契約・受注

  ◆ 契約・受注の確認
顧客と約束をする前に、その内容を確認すること(ルールを決めて内容を点検すること)。
ここで言う約束とは、契約、納入仕様書、図面の承認、受注、見積書の提出、それらの変更
などを指す。

約束の確認では、次の点を確かめること。
a) 製品の仕様(及びその他の約束)が、書面で決まっている【文書化】。
b) 以前に交わした約束(今までの製品、以前に出した見積書など)と内容が変わる時には、変
  わる ことについて話が付いている。
c) 法令違反がない。
d) 使用説明や使い方のセミナーが必要な場合には、その実施や受講について予定されている。
e) 求められている品質やその他の条件に能力的(技術、納期、価格)に対応できる。

  ◆ 契約・受注の記録
顧客と約束した記録(文書のこともある)を残すこと。また、内容確認の結果として約束を変更
した場合は、その記録も残すこと(4.2.5に従って管理する)
顧客が注文を口頭で伝えてきた時も、内容を確認し、記録を残すこと。

  ◆ 契約・注文の変更
契約や注文内容の変更があった場合には、会社は、計画表、作業マニュアル、検査基準書
などの関連する文書を修正すること。また、変更の内容を関係者に理解させること。


【文書】 
 7.2.3 顧客や外部の機関との連絡方法

  ◆ 会社は、顧客と情報のやり取りをする方法や担当者を決めること。顧客と交わす情報には、次の
    ようなものがある。
a) 顧客への製品の紹介、顧客からの製品に関する情報や業界動向
b) 引き合い、契約、注文、またはそれらの変更
c) 顧客からの反響(市販後の安全情報、クレーム、意見など)
d) 通知書(販売後の顧客への追加情報)

  ◆ 関連する行政機関(役所・PMDAなど)と連絡を取る担当者や方法を決めること(法令に関する
    情報の受付、申請、問題発生時の届出)。


ページ頭に戻る

7.3 設計・開発

【文書】 
 7.3.1 設計・開発のルールを決める

    設計・開発の管理のルールを文書で定めること。


【文書】 
 7.3.2 設計・開発の計画

  ◆ 設計・開発の計画書
会社は、設計・開発の「計画書」を作ること。【計画文書】
設計・開発の進捗に伴って、計画の内容に変更があったら、計画書を改訂すること。

  ◆ 計画の内容
その計画の中で次のことを決めること。
a) 設計・開発はどのような段階に分かれているか。
b) 「設計・開発のレビュー」をどのように行うか。(時期、参加者、項目など)
c) 「設計・開発の検証」「設計・開発のバリデーション」「製造移管の確認」を、どのように行うか。
d) 設計・開発の責任者と担当者。その責任と権限の範囲を決める。
e) その設計・開発でクリアすべき各項目【インプット】が、どのように解決したかが、分かるよう
  な記録を作る(そのように計画する)。
f) 設計・開発に使用する設備、ソフトなどを決める。参加してもらう必要がある技術者、協力を
  求める外部の業者などを決める。


【記録】 
 7.3.3 設計・開発で考慮すべき項目【インプット】

  ◆ この設計・開発で「クリアすべき項目」(達成すべき製品の機能、制限条件、解決すべき問題
    など)【インプット】を、リストアップすること。
    これを、記録として残すこと(複数の文書の組み合わせでも良い)。

  ◆ 「クリアすべき項目」の中には、次の内容を入れること
a) 治療のために、求められている機能や性能、使いやすさ、安全上で必要なこと
b) 守らなければならない法律や公的な決まり
c) リスクマネジメントで、対応が必要だと決めた項目
d) 以前に、同じような設計・開発を行っているならば(先行製品があるならば)、そこから参考に
  すべき情報。その先行製品で問題となったこと。
e) その他の考慮しなければいけないこと
  ◆ このリストは、決められた責任者が、内容が適切かどうかを確認し、承認をすること。

  ◆ リストに挙げた項目は、必要な情報を網羅していること。
    あいまいではないこと。
    達成できたかどうかが確認できる(検証やバリデーションが可能な)項目であること。
    項目の間に矛盾がないこと。

  <補足説明> IEC62366-1は参考書である。


【記録】 
 7.3.4 設計・開発の結果【アウトプット】

  ◆ 設計や開発の結果【アウトプット】には、試作品、製品規格、図面などがある。これに加えて、
    次の資料を用意すること。
a) 設計・開発した製品が、「クリアすべき項目」【インプット】(7.3.3)をクリアしていることを示す
  記録。
b) 製造を行うために必要な資料を準備する。(作業標準、QC工程表、記録用紙など)
  部品、資材、原料などの購入や、外注を行うための資料を準備する。
c) 製品の合否判定基準を決める。それを決めている文書(例えば、申請書類、規格、薬局方
  など)を指定することでも良い。
d) 製品を安全に使うため/適切に使うために必要な情報を示す。

  ◆ クリアすべき項目【インプット】の一つ一つがどうなったかが、分かる資料を含めること。
  ◆ 責任者がこの結果【アウトプット】を承認した後に、次の設計段階や生産段階に進めること。
  ◆ 以上の結果を、記録として残すこと(4.2.5に従って管理すること) 


【記録】 
 7.3.5 設計・開発のレビュー(関係者による検討)

  ◆ 「設計・開発のレビュー」は、設計・開発の内容に問題がないかについて、関係者のチェックを
    受けることである。(会議、個別の打合せ、書面上のチェックなどの方法がある)
  ◆ 「設計・開発のレビュー」は、設計・開発のルール(7.3.1)と、計画書(7.3.2)に従って行うこと。
  ◆ 必要な検討が適切なタイミングでできるように、計画的【体系的】に行うこと(いつ、だれに、何を
    聞くか)。

  ◆ レビューの内容
「設計・開発のレビュー」では、次の観点から設計・開発の内容を確認すること。
a) 求められていた通りの設計・開発ができているか(できそうか)。
b) 問題を指摘し、対策を提案する。

  ◆ レビューの参加者
関連する部門(設計・開発を分担する各チーム、製造部門、品質保証部門,、サービス部門など)
    と、専門家(医師、技術専門家、法律の専門家など)のチェックを受けること。

  ◆ 記録
「設計・開発のレビュー」の記録を残すこと。(4.2.5に従って管理すること)
参加者と実施日を記録すること。いくつかの案件をまとめて行う場合は、どの議論がその医療
機器に当てはまり、だれがレビューの参加者であるかが分かるように記録すること。
また、レビューの結果を受けて、何かの対策をした時は、その内容も記録すること。



 7.3.6 設計・開発の検証(結果の確認)

  ◆ 「設計・開発の検証」として、設計・開発した製品【アウトプット】が7.3.3でリストアップした条件
    【インプット】をクリアしていることを確めること。(試作品や完成品の試験を伴う)
  ◆ この「設計・開発の検証」は、設計・開発のルール(7.3.1)と、計画書(7.3.2)に従って行うこと。

【文書】 
  ◆ 検証計画書
全体の計画書とは別に、検証の具体的な計画書(文書)を作成すること。その中では、検証の
方法(文書チェックの項目、試験方法など)を決めること。また、検証の合否を判断する基準を
決めること。

  ◆ 統計的な根拠
医学的な効能など、統計学による判断が必要な試験項目がある場合は、その分析方法を
検証計画書で決めること。特に、検体数をどのようにして決めたかについて、理論的な根拠を
示すこと。

  ◆ 他の医療機器との組み合わせ
他の医療機器と組み合わせて(または連結して)使う医療機器は、組み合わせた状態で試験
をすること。
【記録】 
  ◆ 記録
「設計・開発の検証」の記録を残すこと。また、その結果を受けて、何らかの対策をした時は、
その内容も記録すること(4.2.4または4.2.5に従って管理すること)




 7.3.7 設計・開発のバリデーション【妥当性確認】

  ◆ 「設計・開発のバリデーション」として、設計・開発した製品が、狙い通りに機能することを確認
    することを言う。(バリデーションには、現場での試験、実際の使用を想定した試験、試験データ
    の分析などがある)
  ◆ 「設計・開発のバリデーション」は設計・開発のルール(7.3.1)と、計画書(7.3.2)に従って行うこと。

【文書】 
  ◆ バリデーション計画書
全体の計画書とは別に、バリデーションの具体的な計画書を作成すること。
その中で、バリデーションの方法を決めること。また、バリデーションの合否を判断する基準を
決めること。
医学的な効能など、統計学による判断が必要な試験項目がある場合は、その分析方法を
計画書で決めること。
特に、検体数をどのようにして決めたかについて、理論的な根拠を記録に残すこと。
【記録】 
  ◆ バリデーションに用いる製品
実機試験に用いる製品は、実際の製造条件で製造されたものを使うこと。例えば、最初に製造
ラインで組み立てられた製品、量産試作された製品、またはこれと同等と考えられるものを使う
こと。その製品が、バリデーションに適切だと判断した理由を記録すること(4.2.5に従って管理
すること)。

  ◆ 臨床評価など
国の法令で臨床試験(GCP)や性能評価(体外試験機の実検体による試験)が定められている
場合は、実施すること。

  ◆ 他の医療機器との組み合わせ
他の医療機器と組み合わせて(または連結して)使う医療機器は、組み合わせた状態で試験
をすること。

  ◆ バリデーションは必須事項である
製品を、一旦顧客に引き渡した後で、実際に顧客で使用しながら「設計・開発のバリデーション」
を行う手法は認めない。バリデーションは、製品を顧客に引渡す前(市場に出荷する前)に
終わっていること。
ただし、設計・開発の途中で、(バリデーションとして)臨床試験(GCP)や性能評価を行うため
に製品を医療機関に提供することは認める(顧客への引き渡しではない)。
【記録】 
  ◆ 記録
 「設計・開発のバリデーション」の記録を残すこと。また、その結果を受けて何らかの対策をした
場合は、その記録も残すこと(4.2.4または4.2.5に従って管理すること)。


【文書】 【記録】 
 7.3.8 設計・開発から製造への移管

  ◆ 会社は、設計・開発が完了した製品を製造部門に移管する際のルールを、文書で定めること。

  ◆ 移管の際には、製造に必要な書類【最終製造仕様】(製品規格、図面、作業標準、記録用紙
    など)を用意すること。
  ◆ これらの書類の内容が、実際の作業に適していることを確めること。
    その書類に定めた製造方法で、基準に合った製品を(安定して)製造できることを確かめること。

  ◆ 移管の記録(打合せの記録、用意した文書、これに基づく製造の結果など)を残すこと(4.2.5に
    従って管理すること)。


【文書】 【記録】 
 7.3.9 設計・開発を変更する時

  ◆ 設計・開発(した結果)を「変更」する際のルールを、文書で定めること。

  ◆ 重大さの判定と対策
設計・開発を変更する時は、まずその変更の重要さ(変更によって発生しそうな不具合。その
不具合の重大さ)を判定すること。
重大さの判定は、医療機器の種類、危険性、それを用いて行う治療の内容【意図された用途】、
法律違反の可能性を元に判断すること。
その上で、不具合が起こらないように、適切な管理を行うこと(以上をルールとして定めること)。

  ◆ 変更の管理
設計・開発を変更する時は、以下の管理を行うこと。
a) 変更について(7.5.5に準じて)「設計・開発のレビュー」を行う。
b) 変更について「設計・開発の検証」を行う。変更によって計画通りの結果が得られたかを
  確認する。
c) 必要に応じて、(7.5.7)に準じて「設計・開発のバリデーション」を行う。
d) 責任者が変更を承認する。

  ◆ 変更の影響
変更のレビューの中で、変更が製品の他の部分に及ぼす影響について確かめること。
また、変更前の仕様で作られた製品に及ぼす影響について確認すること。
リスクマネジメントの見直しの必要がないかを、確認すること(新たなハザードがないか、リスク
の評価を変える必要はないか)。
変更前の製品を使用している顧客に影響がないかについても確認すること。(治療の一貫性、
他の医療機器との組み合わせ、交換部品との組み合わせなど)

  ◆ 記録
レビュー、検証、妥当性確認の結果を記録に残すこと。その結果として何らかの対策を行った
場合には、その記録も残すこと(4.2.5に従って管理すること)。


【記録】 
 7.3.10 設計・開発のファイル

  ◆ 会社は、製品の品番またはシリーズ毎に、設計・開発の記録をまとめたファイルを用意すること。
  ◆ このファイルに、設計・開発が適切に行われたことを証明する記録をまとめること(他の場所に
    ある記録を参照することでも良い)。



ページ頭に戻る

7章後半へ
トップへ
戻る