要求・リスク・試験を、1 件ずつつないで管理する。
医療機器の設計開発では、要求から検証までのつながりと、誰がいつ承認したかが問われます。設計開発支援は、要求・リスク・試験などを 1 件ずつの項目（要素）として持ち、要素どうしをリンクでつなぐシステムです。トレーサビリティ表（RTM）は、このリンクから作ります。別の Excel で RTM を作り直す必要はありません。規制コンサルティングを 30 年続けてきた当社の進め方を、入力の順番と承認の手順にしています。システムの利用料は無料です。
設計開発文書づくりの不安に、こう応えます
設計開発の担当者や、スタートアップの経営者からよく伺う不安と、設計開発支援での応え方です。
規制コンサルティング 30 年の進め方が、そのまま画面の手順に。
迷わず、早く、安く、査察で確かめられる記録を備えた設計開発文書をつくれます。
「何を、どの順番で作ればよいか分からない」
設計管理で求められる記録の流れを、システムの入力の順番にしてあります。ユーザーニーズ・顧客要求から製品要求、下位の要求、設計出力へ。RM 計画からハザード、受容判定へ。検証計画から実施記録、検証報告へ。画面に沿って入力すれば、必要な文書の骨組みと、その間のつながりが自然にそろいます。
- 要求・リスク・試験を、1 件ずつの要素として、作業版と確定版で管理します
- 登録した内容は、当社の文書テンプレートの体裁で Word に出力できます。表は Excel にも出せます
- 今お持ちの Excel や XML の要求一覧は、そのまま取り込めます
- 設計管理の手順書がまだ無い場合は、QMS管理の AI ドラフト作成で、規制と上位文書に沿った手順書の案から始められます
「規制や QMS に合っているか自信がない」
システムの流れ自体が、当社が査察と是正の現場で積み重ねてきた進め方です。たとえば、合格した後の再試験は、設計変更・逸脱・CAPA とのひも付け、理由、作成者以外の承認がそろわないと認めません。作成・編集・確定にかかわった人は、その要素を承認できません。こうした決まりを、人の注意ではなく、システムの手順として組み込んでいます。
- 要求の書き方の指摘と言い換え案、下位要求の提案を AI が出します（順次提供）
- 設計管理の手順書は、QMS管理の AI レビューで規制・規格と照らし合わせられます
- AI だけでは判断がつかないときは、当社コンサルタントのスポット支援もご利用いただけます（別途お見積り）
「査察で指摘されないか不安」
査察で確かめられるのは、要求から検証までが漏れなくつながっていること、そして誰がいつ何を承認したかです。設計開発支援では、横断のトレーサビリティ表（RTM）でつながりを示し、節目ごとに確定版でベースラインを凍結します。凍結した内容は、表示した内容とハッシュで照合できます。設計の主な成果物は要素ごとに電子署名で承認し、登録・変更は監査証跡に残ります。査察の場では、設計アイテムの査察ビューを監査ルームで査察官に見せられます。
- RTM は要素のリンクから作ります。別の Excel で作り直す必要はありません
- 上流の要素が変わると、下流のリンクに「要再確認」の印が付きます
- ベースラインは確定版だけで作ります
- 設計入力・設計出力・検証計画・実施記録・検証報告・RM 計画の 6 種類を、要素ごとに電子署名で承認します
- デザインレビューの独立性の宣言と終結、ゲートの通過も電子署名です
「コンサルタントや専用ツールに払う予算がない」
システムの利用料は無料で、利用者数でも課金しません。料金がかかるのは、AI を使う分の AI クレジットと、ディスク容量を追加するときだけです。登録すると、AI クレジット 2,000 とディスク 2GB が付きます。必要なときにだけ当社コンサルタントに相談する、という使い方もできます。
- システム利用料は 0 円。利用者数は無制限です
- AI クレジット・ディスクが足りなくなったら、オンラインショップで追加購入できます
- 当社の QMS 文書（標準QMSライブラリ）を導入する場合は、別途ご購入いただきます
文書の内容と、製品が規制に適合しているかの最終的な判断は、貴社の担当者が行います。システムと AI は、その判断に必要な記録と下書きを整えます。
ALM・設計管理システムが定着しない 5 つの理由と、答え方
ALM（要求・リスク・試験を項目で持つ仕組み）は、入れただけでは定着しません。公開されている導入事例や調査から、よくある理由は次の 5 つです。設計開発支援の機能と、当社の支援での答え方を並べました。
1. 文書も作り続けて、二重管理になる
Word や Excel の文書も今までどおり作ると、システムは「もう 1 つの置き場」になります。どちらが正しいのか、分からなくなります。
- 答え方：記録の種類ごとに、正しい内容を置く場所（正本）を決めます。文書は、正本から出す出力物にします
- 設計開発支援では、要求と RTM の正本を要素とリンクに置きます。Word・Excel は、そこから出力します
- 正本を画面で設定する機能は、今後の予定です。今は当社の支援で、正本の決め方を設計開発計画に書き込みます
2. 項目の粒度が決まらず、リンクが意味を持たない
1 つの項目に要求を何個も書くと、どの要求をどの試験で確かめたかが分かりません。逆に細かすぎると、リンクが増えすぎて誰も見なくなります。
- 答え方：システムを入れる前に、プロセスと情報モデル（どの記録を、どの粒度で、どうつなぐか）を決めます
- 設計開発支援では、要素の型とリンクの種類があらかじめ決まっています。1 件の要素には、1 つの要求と受入基準を書きます
- 当社の支援で、貴社の製品と手順書に合わせた粒度を一緒に決めます
3. 全製品を一度に載せて、追いつかない
全製品を一度に移すと、設定と教育が追いつきません。移す作業の量も、多くの場合は見込みより大きくなります。
- 答え方：1 製品から小さく始めます。うまくいったら、次の製品に広げます
- 設計開発支援は、プロジェクトごとに使い始められます。今の Excel の要求一覧は取り込めます
- 試行の進み具合を数字で見る画面は、今後の予定です
4. QMS の外に置かれ、正式な記録にならない
部署の判断で入れたツールは、QMS の手順書に載らないことがあります。すると、システムの中の記録は正式な記録として扱えません。結局、紙や PDF の文書を別に作ることになります。
- 答え方：システムを QMS の中に置き、使う前にバリデーション（コンピュータ化システムの妥当性確認）を行います
- 設計開発支援は eQMS「AI Compliance」の一部です。電子文書管理・変更管理・CAPA などと同じ仕組みで、電子署名と監査証跡を残します
- 当社は CSV（コンピュータ化システムバリデーション）の支援も行っています（別途お見積り）
5. 担当者がいない
システムの設定や、決まりを守っているかの確認をする人がいないと、使い方が人によってばらばらになります。
- 答え方：システムより先に、人と運用を整えます。誰が要素を確定し、誰が承認するかを決めます
- 設計開発支援では、作成・編集・確定にかかわった人は、その要素を承認できません。役割の分担を、システムの手順として守ります
- 当社のコンサルタントが、運用の立ち上げを支援します（別途お見積り）
参考：Axendia が 2022 年に、医療機器の実務者 96 名に調査しました。自社の要求管理を「効果的でない」または「ある程度効果的」と答えた人は 68％でした。出典：Axendia「The Costly Impact of Ineffective Requirements Management in the Medical Device Industry」（2022 年。Jama Software が配布）。
主な機能
設計開発の記録は、要素とリンクでこうつながります
- ユーザーニーズ・顧客要求
- 製品要求
- 下位の要求（ソフト・機構・電気・試薬）
- 設計出力
- RM 計画（電子署名で承認）
- ハザード
- 受容判定・FMEA
- リスクマネジメントファイル
- 検証計画
- 実施記録（時系列）
- 検証報告
- 記録ドライブへ登録
この節の機能は、お客様ごとに順次ご提供します。ご利用の開始時期は、お問い合わせください。
要素で持つ：要求・設計出力を 1 件ずつ
要求や設計出力は、文書の中の 1 行ではなく、1 件ずつの要素として持ちます。要素には、ID・題名・本文・受入基準があります。書き進める間は作業版として自動で保存します。内容が固まったら「確定」し、変わらない確定版にします。
- ユーザーニーズ・顧客要求から、製品要求、下位の要求、設計出力までを要素で管理します
- 要素ごとに、作業版と確定版を分けて持ちます
- 文書の形・ツリー・表（グリッド）の 3 つの見方で、同じ要素を表示します
領域ごとの下位要求（ソフト・機構・電気・試薬）
下位の要求は、領域ごとの型で持ちます。型は、ソフトウェア・機構（メカ）・電気（エレキ）・試薬（IVD）の 4 つです。製品に必要な型だけを使えます。
- ソフトウェア・機構・電気・試薬の 4 つの型
- 領域ごとに必要な項目を足す拡張（ソフトの安全クラス、試薬の性能評価など）は、今後の予定です
型付きのリンクと「要再確認」の印
要素どうしは、関係の種類を付けたリンクでつなぎます。上流の要素を確定し直すと、下流につながるリンクに「要再確認」の印が付きます。担当者は、下流の要素を見直してから印を外します。見直しが済んでいないつながりは、画面で一覧できます。
- リンクには、関係の種類が付きます
- 上流が変わると、下流に「要再確認」の印が付きます。印を外すのは人です
- つながりの欠け（検証のない要求など）を、トレースギャップとして表示します
リンクから作る RTM（第二の Excel を持たない）
トレーサビリティ表（RTM）は、要素のリンクから作ります。RTM のために別の Excel を作り、手で更新する必要はありません。RTM は、当社の様式（F405）の形で Excel に出力できます。今お使いの Excel の要求一覧は、取り込めます。
- RTM はリンクから作ります。手で作り直す表は持ちません
- RTM を、当社の様式の形で Excel に出力します
- Excel の要求一覧を取り込めます
確定版とベースライン
節目では、その時点の確定版をまとめてベースラインにします。ベースラインに入れられるのは確定版だけです。どの内容で判断したかが、後から確かめられます。
- ベースラインは確定版だけで作ります
- ベースラインの承認は電子署名で行います
リスクマネジメント・FMEA
リスク管理担当者は、まず RM 計画（リスクマネジメント計画）を作り、電子署名で承認します。その計画に沿ってハザードを登録し、受容判定を行います。FMEA は、設計 FMEA と工程 FMEA の両方を扱います。故障モードごとに、重大度・発生度・検出度を評価します。製品全体の残留リスクの受容は、2 名の署名で行います。
- RM 計画の承認は電子署名で行います
- ハザードの登録と受容判定、リスクマネジメントファイル
- 設計 FMEA と工程 FMEA（重大度・発生度・検出度）
- 全体の残留リスクの受容は 2 名の署名
検証・バリデーション
検証は、計画・実施記録・報告の 3 つに分けて持ちます。試験を実施するたびに実施記録を残します。記録は時系列で残り、後から経緯をたどれます。合否を決めるのは人です。
合格した後の再試験には条件があります。設計変更・逸脱・CAPA のどれかとのひも付け、再試験の理由、作成者以外の承認の 3 つがそろったときだけ認めます。
- 計画・実施記録・報告の 3 つに分けて管理します
- 合格後の再試験は、ひも付け・理由・作成者以外の承認がそろったときだけ
- 試験文書は、電子文書管理の承認済み文書につなげます
要素ごとの電子署名
設計の主な成果物は、要素ごとに電子署名で承認します。署名のたびにパスワードの入力が必要です。その要素の作成・編集・確定にかかわった人は、承認できません。電子署名と監査証跡の共通の仕組みは紹介ページをご覧ください。
- 設計入力・設計出力・検証計画・実施記録・検証報告・RM 計画の 6 種類
- 作成・編集・確定にかかわった人は承認できません
プロジェクト管理と設計記録
設計プロジェクトの計画からデザインレビュー、DHF、設計移管までを、同じシステムで扱います。この節の機能は、どのお客様のテナントでもお使いいただけます。
設計プロジェクト・計画・フェーズとゲート
プロジェクトの責任者は、設計プロジェクトを作り、計画を立て、フェーズに分けて進めます。フェーズの区切りにはゲートを置きます。ゲートの通過は電子署名で行います。
- 設計プロジェクトと計画
- フェーズとゲート（通過は電子署名）
デザインレビュー
デザインレビューでは、独立性の宣言を電子署名で行います。レビューの終結も電子署名で行います。
- 独立性の宣言は電子署名
- レビューの終結は電子署名
DHF（設計履歴ファイル）と設計移管
DHF は、設計の経緯をまとめたファイルです。ある時点の内容をスナップショットとして残し、ZIP のパッケージにまとめられます。設計が終わった後の、製造への設計移管も扱います。
- DHF のスナップショット
- DHF の ZIP パッケージ
- 設計移管
供給者管理・ライブラリ・ナレッジの意味検索
設計にかかわる供給者を管理できます。ライブラリも使えます。ナレッジは、キーワードと意味検索で関連する資料を探せます。検索の機能で、答えの文章は作りません。
- 供給者管理
- ライブラリ
- ナレッジの検索（キーワードと意味検索）
統計的手法とサンプルサイズの計算機
検証項目には、計数値のサンプルサイズ計算機があります。二項分布にもとづく、不良ゼロの成功連続法の計算です。信頼度と信頼水準を入れると、必要な数を計算し、根拠文を下書きします。
計算は画面の中で行います。計算の過程は記録に残りません。監査証跡に残るのは、人が保存した根拠文だけです。計量値の計算には対応していません。統計的手法を使うかどうかは、人が判断します。
- 計数値だけに対応（二項分布・不良ゼロの成功連続法）
- 信頼度と信頼水準から必要な数を計算し、根拠文を下書き
- 記録に残るのは、人が保存した根拠文だけ
業務の流れの例
- 1 製品から始めるまず 1 つの製品で設計プロジェクトを作り、計画とフェーズ・ゲートを決めます。記録ごとの正本と、役割の分担もここで決めます。
- 要求を要素で登録するユーザーニーズから製品要求、下位の要求までを要素で登録します。今の Excel の要求一覧は取り込めます。
- リスクを評価するRM 計画を電子署名で承認し、ハザードの登録、受容判定、FMEA を進めます。
- 設計出力と検証をリンクでつなぐ設計出力を確定し、検証計画に沿って試験を実施し、実施記録を残します。要求・リスク・試験をリンクでつなぎます。
- 変更を見直す上流の要素を確定し直したら、「要再確認」の印が付いた下流を見直します。
- レビューし、承認するデザインレビューを行い、要素ごとに電子署名で承認します。
- ベースラインを作るRTM でつながりを確かめ、確定版でベースラインを作ります。全体の残留リスクは 2 名の署名で受容します。
- ゲートを通過し、設計移管へゲートを電子署名で通過し、設計移管へ進みます。DHF（設計履歴ファイル）は、スナップショットと ZIP パッケージにまとめられます。
実際の画面で見る、詳しい操作例
要求の確認からリスク・検証・レビュー・設計ファイルまで、7点の実機画面とともに具体的な操作と注目点を解説します。
今回の操作例：抗原検出キットの「判定しやすさ」を確認する
使用するデモ：DP-0003「デモ イムノクロマト法 抗原検出キット（迅速診断用・デモウイルスA型）」
「判定しやすい」というユーザニーズを出発点に、操作性・判定の製品要求、判定時間や表示に関する試薬要求、判定線の読み違いのリスク、検証記録、レビュー指摘を確認します。
掲載画面は2026年10月17日に撮影した実機のデモデータです。試験条件・数値・日付・合否は操作説明用であり、実製品の性能や推奨する試験基準を示すものではありません。一部に警告や未完了の状態を残し、確認ポイントとして解説しています。撮影時の画面に「旧画面」と表示される機能は、以下でも区別して案内します。
STEP 01 / 設計計画
設計の各段階と、予定・実績をそろえる
最初に、企画から設計移管までの進め方を確認します。予定と実績を別々に持つことで、どの段階に確認が必要かを見渡せます。
開く場所：設計開発支援 → 対象プロジェクト → マネジメント文書（計画）
- プロジェクト一覧から、対象のプロジェクトを開きます。
- 「マネジメント文書」または「計画とゲート · 旧画面」を開き、「スケジュール」へ移動します。
- 各段階の開始・終了予定日、実績開始・終了日、進捗・遅延を確認します。
- 日程や実績を記録する場合は、確認した内容を入力して「段階の日程・実績を保存」を使います。
- 見る箇所①：予定と実績。予定どおり進んだかを、日付の記録で確認できます。
- 見る箇所②：進捗・遅延。画面の警告から、開始予定日を過ぎても未着手の段階に気付けます。
- 見る箇所③：期限超過の成果物。段階の進み方と、成果物の承認状況は別々に確認します。
業務でのポイント：計画の日付を動かすだけで終わらせず、実績と判断の根拠を残します。段階の詳細では、入口・出口基準や成果物ごとの責任者・照査者・承認者も確認できます。
STEP 02 / 要求の整理
「判定しやすい」を、確認できる要求へ展開する
要求をファイル名だけで管理すると、その背景や受入基準を探し直す場面が生まれます。M04では、ID・題名・本文・受入基準を要素として扱います。
開く場所：対象プロジェクト → 要求と設計 → グリッド
- 「要求と設計」を開き、「グリッド」に切り替えます。
- 「型」で「製品要求」を選び、製品として満たす要求に絞ります。
- 「PRS-0003 操作性・判定」の本文と受入基準を読みます。
- 別の要求を探すときは「表示ID・語句で検索」を使い、必要に応じて担当でも絞り込みます。
デモの製品要求 PRS-0003：「本品は目視で、定められた時間内に判定できること」。受入基準は「判定時間・判定のしやすさの要求を満たすこと」です。詳細は試薬要求へ展開して確認します。
- 見る箇所①：本文と受入基準。何を満たすかと、どう判定するかを分けて確認します。
- 見る箇所②：型と状態。ユーザニーズ・製品要求・試薬要求・設計出力を区別できます。
- 見る箇所③：欠落。このデモの「未検証要求」は、確認すべき関連付けが残っていることを示します。
業務でのポイント：要求を登録したことと、その要求を確認する試験が結び付いていることは、別の確認事項です。後述のトレース表示で、上流と下流をたどります。
STEP 03 / リスクマネジメント
判定線の読み違いを、対策と要求の両方から確認する
「弱陽性の線を陰性と読んでしまう」場面を考えます。リスクの内容だけでなく、対策をどこへ実装し、何で確認するかまで整理します。
開く場所：リスク · 旧画面 → ③ 評価・リスクコントロール
- 「リスク · 旧画面」を開き、「③ 評価・リスクコントロール（§6・§7）」を選びます。
- 「RSK-0005」のハザード・危険状態・危害と、対策前後の評価を確認します。
- 対策の説明と「実装（要求）→検証」の欄を確認します。個別の内容は行のIDから開けます。
- 実装先が未リンクの場合は、関連付ける要求を検討します。画面には「要求ID」と「＋要求」の操作が用意されています。
- 見る箇所①：危害までの流れ。何が起き、誰にどのような影響があるかを確認します。
- 見る箇所②：コントロール。対策の内容と区分を読みます。
- 見る箇所③：実装先のリンク。「実装先が未リンク」の警告は、対策の記載だけでは確認が完了しないことを示す例です。
業務でのポイント：リスク評価が低くなっていても、対策の実装と有効性の確認が済んだとは限りません。画面の数値・受容区分は、このデモに設定された基準による表示です。
STEP 04 / 検証とトレース
試験の結果と、要求へのつながりを確認する
4-1. 判定時間の検証記録を読む
開く場所：検証・バリデーション · 旧画面 → 検証サマリ → VER-0007
- 「検証・バリデーション · 旧画面」を開きます。
- 一覧から「VER-0007 判定時間の妥当性」を開きます。
- 上部の本文・受入基準を確認した後、「検証の計画・記録」を確認します。
- 方法・試料数の根拠・実施環境と、実施日・実施者・合否・実測値の要約を突き合わせます。
デモの受入基準：15分と20分の判定一致率100%。
記録の例：15分と20分は一致率100%（40/40）。30分では陰性1検体に非特異線が出たことも、判定時間外の観察として記録されています。
業務でのポイント：「合格」の表示だけでなく、試験条件・判定基準・結果の根拠を確認します。このデモの記録は画面説明用で、生データや成績書の添付はありません。実運用では必要なエビデンスもそろえます。
4-2. 元のニーズと下位要求をたどる
開く場所：要求と設計 → グリッドで要求を選択 → トレース
- 「要求と設計」の「グリッド」で「PRS-0003 操作性・判定」の題名セルを選びます。
- 要素を選択したまま「トレース」に切り替えます。
- 「起点：PRS-0003」を確認し、上流のニーズと下流の試薬要求をたどります。
- 必要に応じて「関係の種類」や「要確認だけ表示」で対象を絞ります。
- 見る箇所①：上流。「外来で迅速に判定したい」「判定しやすい」など、要求の出発点を確認できます。
- 見る箇所②：下流。製品要求から判定時間・判定のしやすさなどへ展開した関係を確認できます。
- 見る箇所③：欠落の警告。関係が「正常」と表示されても、必要な検証がそろったことまでは意味しません。このデモには「未検証要求」の表示が残っています。
業務でのポイント：「要求が存在する」「関係がつながっている」「その要求を検証した」は、それぞれ確認します。変更を検討するときも、関連する要素をたどることで見直し対象を考えやすくなります。
STEP 05 / デザインレビュー
指摘を、担当・期限・対応根拠まで管理する
議事録に指摘を書いて終えると、対応の完了を追いにくくなります。M04では、DRごとの指摘と未クローズの状態を確認できます。
開く場所：レビューと承認 · 旧画面 → DR-0003 → 指摘
- 「レビューと承認 · 旧画面」のDR一覧を開きます。
- 「DR-0003 DR3 設計バリデーション／移管判定」を選びます。
- 「指摘（未クローズ 1）」タブで、指摘内容・重大度・区分・担当者・期限を確認します。
- 対応を記録するときは「対応方針・対応内容」「エビデンス（参照）」「変更参照（CHG/REQ等）」を記入し、「対応を保存」を使います。
- 対応内容を確認した上で、クローズの操作に進みます。画面では「対応記入が前提」と明示されています。
業務でのポイント：リスクの対策として挙げた「弱陽性例を判定図に載せる」が、実際の成果物に反映されたかをレビューで確認する、という使い方をイメージできます。指摘の重要度と対応の根拠を見て、人が判断します。
STEP 06 / 設計ファイル
設計記録をまとめる前に、不足を見つける
DHF（設計履歴）では、計画に連動する成果物や、レビュー・トレースの不足を確認します。まず未完了の仕事をそろえ、その後に対象時点の記録を固定する流れです。
開く場所：設計ファイル（DHF／設計開発ファイル） · 旧画面 → 完全性チェック
- 「設計ファイル（DHF／設計開発ファイル） · 旧画面」を開きます。
- 「完全性チェック」を選び、未承認の成果物・未判定のDR・未クローズの指摘・トレースの不足を確認します。
- 「DR一覧で確認」「RTMで確認」などのリンクから、対応する画面へ移動します。
- 「動的目次（成果物）」と「スナップショット」のタブで、成果物の整理状況と対象時点の記録を確認します。
- 見る箇所①：承認状況。成果物が存在することと、承認済みであることを区別します。
- 見る箇所②：レビューの完了。DRの判定と指摘のクローズを確認します。
- 見る箇所③：トレース。対象のない試験や、不整合のある参照を確認します。
業務でのポイント：不足が見えている状態を、完成済みと取り違えないことが大切です。このデモではスナップショットは未作成です。確定の説明では、カットオフ時点の版を固定し、確定後の訂正は新しいスナップショットで行う方式が示されています。
よくあるご質問
医療機器や試薬の種類に応じて確認できますか？
この例は試薬のデモを使っています。貴社の製品に必要な要求・リスク・試験や設計段階を整理し、実際の業務シナリオに合わせてご相談ください。
既存のExcel・Wordを使う入口はありますか？
「要求と設計」には「Excel／CSV を取り込む」「様式 F405 で出力」「Word で出力」が用意されています。取り込み形式や出力範囲など、貴社の文書に合わせて確認する必要があります。
システムを導入すれば、設計管理の適合性が確保されますか？
記録と確認を支援する仕組みに加えて、適用する要求事項、社内手順、役割、受入基準、承認の運用を整える必要があります。貴社の業務に合わせて導入範囲をご相談いただけます。
画面撮影・確認日：2026年10月17日。登録済みデモデータの閲覧と操作経路を確認した例です。AI生成・電子署名・ゲート通過・スナップショット確定の実行を示す事例ではありません。
AI が下書きし、人が決める
設計開発支援の AI は、下書きと指摘までを行います。確定と承認は、人が電子署名で行います。次の 2 つは、どちらも順次提供です。
AI が下書き・提案すること
- 要求の品質検査：要求の文への指摘と、言い換えの案を出します（順次提供）
- 下位要求の提案：上位の要求から、リンク付きで下位の要求の案を出します（順次提供）
人が決めること
- AI の結果は提案です。元の要素は変わりません。人が「採る」「直して採る」「捨てる」を選びます
- 要素の確定と、要素ごとの承認（電子署名）
- 「要再確認」の印を外すこと
- 試験の合否と、合格後の再試験を認めるかどうか（作成者以外が承認）
- 全体の残留リスクの受容（2 名の署名）
- 統計的手法の要否と、外部試験施設の選定
出力・記録
| 出力・記録 | 形式・保存先 | 補足 |
|---|---|---|
| 要求と設計 | Word | 当社の文書テンプレートの体裁 |
| RTM | Excel | リンクから作り、当社の様式の形で出力 |
| リスク・検証などの表 | Excel | 表示どおりに出力 |
| リスクの報告書・検証の報告書 | 記録ドライブ | 記録ドライブへ登録 |
| ベースライン | システム内 | 確定版だけで作成 |
| DHF | スナップショット・ZIP | 設計の経緯をまとめて保存 |
| サンプルサイズの根拠文 | 監査証跡 | 人が保存した根拠文だけが残ります |
今後の予定
次の機能は、今後の予定です。今はお使いいただけません。時期は決まりしだいお知らせします。
- 正本の設定：記録の種類ごとに、正本をどこに置くかを画面で決めます
- 外部の記録の参照：図面・部品表など、ほかのシステムにある記録を、版と承認の状態つきで参照します
- IVD の承認済み構成：機器・ソフト・試薬・校正物質の組合せを版つきで固定し、性能評価とつなぎます
- 導入状況の画面：試行プロジェクトで、つながりの充足や「要再確認」の残りを数字で見ます
- 領域ごとの拡張：ソフトの安全クラス、試薬の性能評価・安定性などの項目
- AI による受入基準の案と、設計開発計画の点検
規制に沿った設計開発文書づくりを、まずは無料で。
ユーザー登録は無料です。スタートアップの方の設計管理の立ち上げや、資料請求・導入のご相談も承ります。