Comments
Description
Transcript
再生医療製品患者登録システム構築及び 業務運用設計等業務委託
再生医療製品患者登録システム構築及び 業務運用設計等業務委託 調達仕様書 平成 27 年 2 月 独立行政法人 医薬品医療機器総合機構 安全第一部医療機器安全課 目次 １ 件名 ......................................................................................................................................4 ２ 作業の概要 ...........................................................................................................................4 （1） 目的........................................................................................................................ 4 （2） 用語の定義............................................................................................................. 4 （3） 業務の概要............................................................................................................. 4 （4） 情報システム化の範囲 .......................................................................................... 5 （5） スケジュール ......................................................................................................... 7 （6） 作業内容 ................................................................................................................ 8 （7） 成果物 .................................................................................................................... 9 （8） 検収...................................................................................................................... 11 ３ 作業要件 .............................................................................................................................12 （1） プロジェクト管理業務 ........................................................................................ 12 （2） 運用システム設計................................................................................................ 12 ４ 情報システムの要件 ..........................................................................................................15 （1） 機能要件 .............................................................................................................. 15 （2） 画面要件 .............................................................................................................. 15 （3） 帳票要件 .............................................................................................................. 16 （4） 情報・データ要件................................................................................................ 16 （5） 外部インタフェース要件 ..................................................................................... 16 （6） ガイドラインの遵守 ............................................................................................ 16 （7） 監査証跡 .............................................................................................................. 16 （8） CSV（Computerized System Validation） ......................................................... 17 （9） 個人情報及びプライバシー保護への配慮 ........................................................... 17 ５ 規模・性能要件 ..................................................................................................................18 （1） 規模要件 .............................................................................................................. 18 （2） 性能要件 .............................................................................................................. 18 ６ 信頼性等要件 .....................................................................................................................18 （1） 信頼性要件........................................................................................................... 18 i （2） 拡張性要件........................................................................................................... 20 （3） 上位互換性要件 ................................................................................................... 20 （4） システム中立性要件 ............................................................................................ 20 （5） 事業継続性要件 ................................................................................................... 20 ７ 情報セキュリティ要件 .......................................................................................................20 （1） セキュリティ設計................................................................................................ 20 （2） 権限要件 .............................................................................................................. 20 （3） 情報セキュリティ対策 ........................................................................................ 21 ８ 情報システム稼動環境 .......................................................................................................22 （1） ハードウェア設計................................................................................................ 22 （2） ソフトウェア設計................................................................................................ 22 （3） ネットワーク構成................................................................................................ 23 （4） クライアント要件................................................................................................ 23 ９ テスト要件 .........................................................................................................................23 （1） システム機能等テスト ........................................................................................ 23 １０ 移行要件 .............................................................................................................................25 （1） 移行に係る要件 ................................................................................................... 25 （2） 教育に係る要件 ................................................................................................... 25 １１ 運用設計 .............................................................................................................................25 （1） 運用システム設計................................................................................................ 25 （2） ヘルプデスク設計................................................................................................ 25 （3） データシステム運用設計 ..................................................................................... 26 （4） 運用施設・設備設計 ............................................................................................ 26 １２ 保守設計 .............................................................................................................................27 （1） ソフトウェア保守設計 ........................................................................................ 27 （2） ハードウェア保守設計 ........................................................................................ 27 １３ 作業の体制及び方法 ..........................................................................................................28 （1） 作業体制 .............................................................................................................. 28 （2） 開発方法 .............................................................................................................. 28 ii １４ 特記事項 .............................................................................................................................29 （1） 基本事項 .............................................................................................................. 29 （2） 各業者との役割分担等 ........................................................................................ 29 （3） 入札制限 .............................................................................................................. 29 （4） 応札条件 .............................................................................................................. 30 （5） 知的財産等........................................................................................................... 30 （6） 瑕疵担保責任 ....................................................................................................... 30 （7） 再委託 .................................................................................................................. 31 （8） 機密保持 .............................................................................................................. 32 （9） 遵守事項 .............................................................................................................. 32 （10） 作業場所 .............................................................................................................. 33 （11） 環境への配慮 ....................................................................................................... 33 （12） その他 .................................................................................................................. 33 １５ 落札者決定方法 ..................................................................................................................33 （1） 予定価格 .............................................................................................................. 33 （2） 評価の配点........................................................................................................... 33 （3） 価格評価の方法 ................................................................................................... 33 （4） 技術点評価基準 ................................................................................................... 33 （5） 選定方法 .............................................................................................................. 34 １６ 窓口連絡先 .........................................................................................................................35 別紙 1 業務運用方針 別紙 2 機能要件 別紙 3 情報・データ要件 iii １ 件名 再生医療製品患者登録システム構築及び業務運用設計等業務委託 一式 ２ 作業の概要 （1） 目的 独立行政法人医薬品医療機器総合機構（以下、「PMDA」という。）では、第 3 期中期計 画において、再生医療等製品を迅速かつ安全に国民に提供するための安全対策業務として、 再生医療製品患者登録システム（以下、「患者登録システム」という。）を構築することと している。また、厚生労働省では再生医療製品患者登録システム整備事業（以下、「本事業」 という。）において、再生医療等製品の患者登録システムの在り方等について検討が行われ てきたところである。 以上を踏まえ、再生医療製品患者登録システム構築及び業務運用設計等業務委託（以下、 「本調達」という。）では、患者登録システムの構築、及び運用設計等業務（データマネジ メント、統計解析並びに施設訪問監査等）を委託し、患者登録システムの運営に資すること を目指すものである。 （2） 用語の定義 表 1 用語の定義 用語 概要 医薬品医療機器等法 「医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律」の本書 における略称。 患者登録システム 再生医療等製品を使用した患者の情報を登録・蓄積するためのデータベースシス テム（情報システム）及び運用システム（業務、運用の仕組み）を総称した、全 体の仕組みを指す。 データシステム 再生医療等製品を使用した患者の情報を登録・蓄積するためのデータベースシス テム（情報システム）を指す。 運用システム 患者登録システムを運営するために必要な業務、運用の仕組みを指す。 管理主体 患者登録システムの初期構築費用の負担元かつ管理責任の主体であり、運営委員 会の決定内容に対して最終的な承認を行う。当面は PMDA が担うが、将来的には学 会や再生医療等製品等製販業者などが協力し、 主体を PMDA から引き継いでいくこ とが想定される。 運営委員会 全体の意思決定機関であり、アカデミア（再生医療学会、大学等）、管理主体、 業界団体、運営主体で構成することを想定している。システム登録項目の決定、 データ公開請求への可否判断や範囲の指定、システム改修の可否、その他運用方 法の変更等の決定を行う。 運営主体 データシステムの管理及び運営を行う。 （3） 業務の概要 本調達における業務を以下に示す。各業務運用方針等については｢別紙１ 業務運用方針｣ を参照のこと。 4 １）データシステムのアプリケーションの構築 ２）患者登録システム運用のための以下の運用システムの設計 ① 患者登録システム参加 ② 患者同意の取得 ③ データ入力に関する教育 ④ データ入力 ⑤ データ入力サポート体制（ヘルプデスク等） ⑥ データの品質確保体制 ⑦ フィードバック ⑧ 個人情報の取り扱い ⑨ （4） データ対外公表 情報システム化の範囲 １）患者登録システムの全体像 患者登録システムの全体像を図 1 に示す。データシステムは、医療機関が患者情報・診断 情報・手術情報等のデータを登録する。登録されたデータは、医療機関、再生医療等製品製 販業者、管理主体（当面は PMDA を想定）がそれぞれの権限の範囲で閲覧または統計情報の 提供を受け、データ解析等に活用する。 連携 医薬品医療機器 総合機構 （管理主体） 関連学会 （再生医療学会等） 運営委員会 委託 連携 使用成績評価制度 副作用・不具合報告 運営主体 データシステム 詳細調査 医療機関 再生医療等製品製販 業者 情報提供 図 1 患者登録システム全体像 5 ２）対象法制度及びデータの範囲 本調達は医薬品医療機器等法に基づく再生医療等製品及びそれらを使用された患者に係る 基本情報・安全性情報を対象とし、主に医療機関等からのデータ登録を対象とする。 ３）データシステムの構築基本方針 再生医療等製品は、今後徐々に承認される製品数が増え、対象疾患領域も拡大していく。製 品や診療領域により登録すべきデータが異なることから、将来的な拡張性を考慮した登録項目 のデータ構造及びシステム構成とすることが求められる。 そのため、登録項目のデータ構造は、図 2 に示すように、全ての製品に必須とする共通の項 目と、製品や製品群、診療領域ごとに特有の項目に分けて設定することを想定している。 また、製品や診療領域により診察のための医療機関訪問回数やエンドポイントの設定は異な る。追跡調査の方法も、患者単位で追跡を行う場合、再生医療等製品が用いられた部位単位で 追跡を行う場合等、製品や診療領域により必要な対応が異なる。これらの製品や診療領域ごと に必要となる機能は、当該製品または診療領域に応じたシステム改修を行う際に設定すること とする。 本調達では、図 2 に示す「全ての製品に必須とする共通の基本項目」部分（以下、「基本項 目部分」という。）の構築を対象とする。本調達で基本項目部分を構築するにあたっては、「製 品や診療領域ごとに特有の項目」部分（以下、「特有項目部分」という。）を構築することを 見据え、特有項目部分を構築する際に基本項目部分の改修を極力不要とするよう、設計及び開 発において工夫すること。 再生医療製品患者登録データベース データシステム 循環器領域 製品や診療領域ごとに 特有の項目 眼科領域 ・・・ 歯科領域 ・条件・期限付き承認における調査事項に関する情報 ・長期の有効性に関する情報 など 全ての製品に必須とする 共通の基本項目 ・患者の基本情報 ・有害事象の発現情報 など 図 2 データシステム構造イメージ ４）本調達の範囲 本調達は、１）及び（4）３）に示すデータシステムの基本項目部分のアプリケーションの構 築並びに２）に示す運用システムの設計及び必要な資料（手順書、関連様式、利用規約 等） の作成を行うものである。データシステムのハードウェア、ネットワーク及びデータセンター の調達は本調達の範囲外である。ソフトウェアについて、アプリケーションの設計、開発及び 6 テスト（受入テストを含む）に必要なものの調達は本調達の範囲内である。本調達で開発する アプリケーションを別調達のハードウェアにインストール及びセットアップ等する作業は本調 達の範囲外であるが、インストール及びセットアップ等する際に用いる導入ツールの開発及び 納入は本調達の範囲内である。 （4）３）に示すデータシステムの特有項目部分の構築については、本調達の範囲外とする。 特有項目部分の構築時期は未定であるが、一部は本調達と並行して構築する可能性がある。本 調達において、特有項目部分の構築のための基本的な方式、インタフェースについては設計を 行うこと。この設計においては、製品や診療領域により医療機関訪問回数やエンドポイントの 設定、追跡調査方法（患者単位または再生医療等製品が用いられた部位単位）が異なること等 を考慮すること。 （5） スケジュール 患者登録システムの構築及び運用に係るスケジュール概要を図 3 に示す。本調達では平成 28 年 3 月末までにデータシステムのアプリケーションを構築する。図 3 はあくまで想定のス ケジュールであり、本調達の実施スケジュールは受注者が検討すること。 分類１ 1 マイルストーン 分類２ 条件付承認 2 製品利用 平成26年度 平成27年度 10-12月1-3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 ▲（時期は想定） （データシステム未稼働期間は 紙での運用を想定） 3 調達 4 業務計画 業務実施計画書作成 5 データシステム構築 要件定義 「全ての製品に必須 6 とする共通の基本項 設計 目」部分 7 開発 8 テスト 9 教育 10 運用システム設計等 運用システム設計 11 運用システム関連資 料作成 契約 12 データシステム構築 「製品や診療領域ご とに特有の項目」部 13 分 設計・開発 （時期は未定。右記 は想定スケジュール） 図 3 スケジュール概要（赤点線枠内が本調達の範囲） 7 （6） 作業内容 本調達は、データシステムのアプリケーションの構築及び運用システム設計を行うものであ る。本調達の作業内容は以下及び「３ 作業要件」以降を参照すること。 １）プロジェクト管理業務 ① 業務実施計画書等の作成 ② 各種ミーティング ③ 業務報告 ２）運用システム設計 ① 患者登録システム参加 ② 患者同意の取得 ③ データ入力に関する教育 ④ データ入力 ⑤ データ入力サポート体制（ヘルプデスク等） ⑥ データの品質確保体制 ⑦ フィードバック ⑧ 個人情報の取り扱い ⑨ データ対外公表 ３）データシステムのアプリケーションの構築 ① ※データシステムアプリケーションの要件定義、設計、開発、テスト※ ② ※データシステム導入ツールの設計、開発、テスト ③ データシステムのアプリケーションの受入テスト支援 ④ データシステムの運用設計及び保守設計 ※設計、開発、テストに必要なソフトウェアの調達も含む。 8 （7） 成果物 作業工程及び納入成果物を表 2 に示す。ただし、納入成果物の構成、記載項目、記載様式等 の詳細については、受注後、PMDA と協議し取り決めること。 「3 情報システムの要件」に基づき、詳細事項その他について PMDA と協議し、要求仕様書、 機能仕様書等を作成・改訂し、PMDA の了承を得た上で、開発・テスト工程に進むこと。 表 2 作業内容・工程と成果物 No 1 工程 計画 2 要件定義・ 基本設計 3 詳細設計・ 開発 4 検証・ テスト 5 データシス テム運用 6 データシス テム保守 納入成果物 ・業務実施計画書（業務スコープ、体制 表、作業分担、スケジュール、標準管 理要領、WBS 等） ・バリデーション計画書 ・アセスメント計画書 ・品質計画書 納入期日 （PMDA による検収 完了期日） 平成 27 年 3 月 31 日 SLCP-JCF2013 のアクティビティ 1.2.4 契約の実行 2.3.1 システム開発プロセス開始の準備プ ロセス 平成 28 年 3 月 31 日 システム要件定義プロセス システム方式設計プロセス ソフトウェア要件定義プロセス ソフトウェア方式設計プロセス ・要求仕様書 ・機能仕様書 ・設計仕様書 ・トレーサビリティマトリクス （要求仕様～設計） ・セキュリティ設計書 ・詳細設計書 ・環境定義書 ・開発環境 ・ソースコード、実行プログラム ・導入ツール ・導入手順書 ・DQ 計画書、報告書 ・IQ 計画書、報告書 ・OQ 計画書、報告書 ・PQ 計画書、報告書 ・トレーサビリティマトリクス （要求仕様～PQ） ・バリデーション報告書 ・テストデータ 平成 28 年 3 月 31 日 2.3.2 2.3.3 2.4.2 2.4.3 平成 28 年 3 月 31 日 2.4.4 ソフトウェア詳細設計プロセス 2.4.5 ソフトウェア構築プロセス 平成 28 年 3 月 31 日 （ソフトウェア関連テスト） 2.4.6 ソフトウェア結合プロセス 2.4.7 ソフトウェア適格性確認テストプロ セス 2.3.5 システム結合プロセス 2.3.6 システム適格性確認テストプロセス 2.4.9 ソフトウェア受入れ支援プロセス （運用関連テスト） 3.1.2 運用テスト及びサービスの提供開始 1.7.2 運用テスト ・データシステム運用計画書 ・データシステム運用手順書 ・変更管理手順書 ・ドキュメントインデクス ・ヘルプデスク設計書 ・データシステム保守計画書 ・データシステム保守手順書 平成 28 年 3 月 31 日 3.1.1 運用の準備 平成 28 年 3 月 31 日 2.6.1 プロセス開始の準備 9 No 工程 7 その他 8 運用システ ム設計 納入成果物 納入期日 （PMDA による検収 完了期日） 平成 28 年 3 月 31 日 （※必要に 応じて随時 提出） ・打合せ資料 ・議事録 ・月次報告書 ・機密情報受理管理台帳 ・データ消去証明書 ・瑕疵担保責任対応に係る保有情報一覧 ○患者登録システム参加 平成 28 年 ・手順書案（患者登録システム参加） 3 月 31 日 ・参加申請書類等のフォーマット案 ○患者同意の取得 ・手順書案（患者同意の取得） ○データ入力に関する教育 ・操作マニュアル ・教育コンテンツ案 ○データ入力 ・手順書案（データ入力） ○データ入力サポート体制 ・手順書案（データ入力サポート体制） ○データの品質確保体制 ・手順書案（ロジカルチェック、マニ ュアルチェック、施設監査） ・ロジカルチェック内容案 ・マニュアルチェック内容案 ・雛形案（監査計画書、調査票、チェ ックリスト、監査結果通知書） ○フィードバック ・手順書案（フィードバック） ○個人情報の取扱い ・患者登録システム利用規約案 ・患者登録システム運用規定案 ○データ対外公表 ・アニュアルレポートの項目案 ・手順書案（アニュアルレポート） SLCP-JCF2013 のアクティビティ 1.2.4 契約の実行 ○データ入力に関する教育 3.1.5 6.4.1 6.4.2 6.4.3 利用者教育 スキルの識別 スキルの開発 スキルの取得及び提供 ※上記の「手順書案」は、全体をまとめ て一つの成果物としても構わない。 なお、納入成果物については、以下の条件を満たすこと。 ① 文書を紙及び磁気媒体等（CD-R 又は CD-RW 等）により日本語で提供すること。 10 ② 紙のサイズは、日本工業規格 A 列 4 番を原則とする。図表については、必要に応じて A 列 3 番縦書き、横書きを使用することができる。バージョンアップ時等に差し換えが可 能なようにバインダー方式とする。 ③ 磁気媒体等に保存する形式は PDF 形式及び Microsoft Office2013 で扱える形式とする。 ただし、PMDA が別に形式を定めて提出を求めた場合は、この限りではない。 ④ 紙及び磁気媒体については二部ずつ用意すること。ただし、作成プログラム（ソフトウ ェア製品、開発環境、実行プログラム、各種ソースコード等）は紙媒体での提出は不要 である。 ⑤ 一般に市販されているツール、パッケージ類の使用は PMDA と協議の上、必要であれ ば使用を認めることとするが、特定ベンダーに依存する（著作権、著作者人格権を有す る）ツール等は極力使用しないこと。 ⑥ 機能仕様書、設計仕様書及び詳細設計書等は、最低限以下のドキュメントを含み、他業 者がこれを基にして同一システムを開発できるレベルの設計書を作成すること。必須ド キュメント：システム機能設計書、コード設計書、画面設計書、画面遷移図、データ設 計書（ER 図、データモデル、論理データ設計書、ファイル定義書、物理データベース 設計書を含む。） 、ジョブ設計書（ジョブフロー）、障害対策設計書、セキュリティ 対策設計書、完成図書（機能説明書、プログラム説明書）、インタフェース設計書（イ ンタフェース一覧、インタフェース関連表、インタフェース定義書等）及びプログラム リスト等。開発ツールを導入する場合はそのライセンス及びメディアを納入すること。 ⑦ 本調達で開発ツール等を利用する場合は、5 年間は利用可能なものを選択し、そのライ センス及びメディアを納入すること。 ⑧ 本調達を実施する上で必要となる一切の機器物品等は、受注者の責任で手配するととも に、費用を負担すること。 ⑨ 本調達の納入実行ファイルを作成した開発環境（開発ツール及び実行ファイル作成に用 いたプログラム等で構成された環境一式を示す。）について、将来的に他業者も改修ま たは運用業務を行うことを想定した場合に容易に環境の利用または移行が行えるよう、 仮想環境の利用も含め検討すること。環境の構築方針については、PMDA と協議のうえ 決定すること。なお、仮想環境を利用する場合は、仮想環境で使用する OS、ミドルウ ェア、各種ソフトウェア等のライセンス費用は、本調達に含めるものとする。 ⑩ 各工程の中間成果物も含め、本調達に係る全ての資料を納品すること。 １）納入場所 独立行政法人 医薬品医療機器総合機構 安全第一部 医療機器安全課 電話：03-3506-9030 （8） 検収 納入成果物については、適宜、PMDA に進捗状況の報告を行うとともに、レビューを受け ること。最終的な納入成果物については、（7）成果物に記載のすべてが揃っていること及び レビュー後の改訂事項等が反映されていることを、 PMDA が確認し、 これらが確認され次第、 検収終了とする。 11 なお、以下についても遵守すること。 １）検査の結果、納入成果物の全部又は一部に不合格品を生じた場合には、受注者は直ちに 引き取り、必要な修復を行った後、PMDA の承認を得て指定した日時までに修正が反映 されたすべての納入成果物を納入すること。 ２）「納入成果物」に規定されたもの以外にも、必要に応じて提出を求める場合があるので、 作成資料等を常に管理し、最新状態に保っておくこと。 ３）PMDA の品質管理担当者が検査を行った結果、不適切と判断した場合は、品質管理担当 者の指示に従い対応を行うこと。 ３ 作業要件 （1） プロジェクト管理業務 １）業務実施計画書等の作成 ① 業務着手前に業務実施計画書を作成し、PMDA の承認を得ること。作成した業務実施計 画書は必要に応じて見直しを行い、PMDA と協議の上、改訂し、適切に管理を行うこと。 ② 業務実施計画書では本調達全体の工程表、管理体制、実施体制、執務場所等の明確な記 載を含めること。 ③ 各業務の経験を有する適切な責任者・担当者を選任し、実施体制を整備するとともに、 業務に先立ち、受注者側の連絡体制について PMDA へ書面で届け出ること。実施体制 を変更する場合には速やかに申し出ること。各業務の管理責任者及び主担当者について は、業務経歴を示すこと。 ④ 受注者のプロジェクト管理業務の範囲は、本調達で受注者に求められる全ての業務であ る。 ２）各種ミーティング ① PMDA を含む関係者とのキックオフミーティングを始め、関係者との調整、個別事項に 関する担当者間の打合せ、進捗・手順・課題の確認等の全般的な事項に関する定期的な 会議の開催・運営（準備・議事録作成を含む。）を行うこと。 ② PMDA が設置する本事業の運営・業務遂行のための委員会（以下「運営委員会」という。） へ必要に応じて出席すること。 ３）業務報告 ① 業務報告に係る様式を定め、毎月、月次報告書を提出すること。 ② 業務実施計画書に基づいて実施した業務の実施状況・結果、計画からの変更点、成果物 等について確認を行い、月次報告書にとりまとめること。 （2） 運用システム設計 以下の運用システムについて、「別紙 1 業務運用方針」を参照し、業務の実施方法、実 施体制、役割分担（管理主体、運営委員会、運営主体、医療機関、再生医療等製品製販業者、 PMDA、関連学会（再生医療学会等）の関係等）及び業務の流れ等を設計し、手順書案、マ 12 ニュアル並びに各種様式類（計画書、報告書及びチェックリスト等）の雛形案等を作成する こと。手順書、マニュアル及び各種様式類の雛形は、特有項目部分のデータシステム構築並 びに運用システムの検討及び試行的な運用を経て、確定することを予定している。本調達に おいて受注者は、手順書、マニュアル及び各種様式類に求められる基本的な内容を案として 定め、特有項目部分のデータシステム構築が行われた際に円滑に案を確定版に改訂できるよ う、PMDA と協議の上、対応すること。 １）患者登録システム参加 ① 患者登録システムに参加する医療機関の登録、倫理審査委員会への承認・申請取得等患 者システムへの参加の手順書案及び医師・看護師等のデータシステム登録に係る手順書 案を作成すること。 ② 医療機関及び利用者（医師、看護師等）が患者登録システムに参加する際に運営主体に 提出する参加申請書類等のフォーマット案を作成すること。作成したフォーマット案は データシステムの認証が不要な画面（ログイン前の画面）に掲載することを予定してい る。 ③ 運営主体は、利用者に対し ID・パスワードの発行を行う。ID・パスワードの発行の際 には発行日、発行者、ID・パスワード発行対象者等の記録を残すこととし、当該記録は 削除、改ざん等されないよう仕組みを構築すること。当該記録の保存期間は管理主体と 検討の上、決定すること。 ④ 運営主体は、患者登録システムの情報管理やセキュリティ等の観点から、ID・パスワー ドの管理方法やデータシステムのデータ管理方法、端末の管理方法等、患者登録システ ム参加者が守るべき事項と対応方法について検討し、３）で作成する教育コンテンツ案 にまとめること。 ２）患者同意の取得 ① 医療機関による患者からの同意取得からデータシステムへの患者同意日登録までの手 順をまとめた手順書案、同意書の雛形等必要な様式案を作成すること。 ３）データ入力に関する教育 ① 本調達の範囲に係るデータシステムの操作マニュアル及び教育コンテンツ案を作成す ること。操作マニュアルは、「④データ入力」における医師・看護師等によるデータの 仮入力及び承認権限を持つ医師による承認に係る操作方法など、利用者の属性や権限等 に応じた内容を記載し、データシステムの利用者にとって分かりやすいものとすること。 ② 操作マニュアル及び教育コンテンツ案の作成、改訂、公開等に係る手順をまとめた手順 書案を作成すること。 ４）データ入力 13 ① 未入力アラート、副作用・不具合アラートの通知文面等について、設計時に検討するこ と。 ② 副作用・不具合アラートを受信した企業が副作用・不具合報告等を作成するまでの標準 的な手順をまとめた手順書案を作成すること。 ５）データ入力サポート体制（ヘルプデスク等） ① 医療機関等からの問合せの受付から回答までの手順、FAQ の作成・改訂手順をまとめ た手順書案を作成すること。問合せ内容について、運営主体のヘルプデスクで回答する もの及び管理主体へ回答に関し相談するものの基準を定め、手順書案に記すこと。 ② 問合せの想定件数や対応時間に応じたヘルプデスクの運用体制案について、PMDA と協 議し検討すること。 ６）データの品質確保体制 ① データマネジメント業務 ア データの品質を確保するためのデータマネジメント業務に関する手順書案、計画書案、 報告書案及び必要な雛形様式案を作成すること。その際、ロジカルチェック、マニュ アルチェック、クエリについては、データシステム上で監査証跡として記録される仕 組みを設けること。 ② 施設監査 ア 施設監査の手順をまとめた手順書案を作成すること。施設監査の実施は本調達の範囲 外である。施設監査の手順は、以下に示す施設監査業務の流れ（想定）を参考にする こと。 a. 監査準備：施設監査の手順書及び計画書を作成し、運営主体の監査担当が監査 日程調整等を行う。監査担当は、施設訪問監査実施時に必要な登録データ票、 チェックリスト等の資料を印刷する。 b. 監査準備：監査担当が参加施設を訪問し、監査を実施する。監査対象施設は、 年間 3 施設程度を予定している（但し、対象製品により異なる）。 c. 結果報告： 監査終了後、監査実施施設に対して監査結果通知書を発行し、写し を管理主体へ提出する。 イ 監査計画書、監査実施時に用いる登録データ票、チェックリスト、監査結果通知書等 の雛形案を作成すること。チェックリスト等は監査における確認項目に沿ったものを 作成すること。施設監査では、データ入力の体制の確認、診療録のデータが正しくデ ータシステムに登録されているか等のデータ確認、同意書の取得・管理状況等の運用 状況の確認等を行うことを想定している。 ７）フィードバック ① 医療機関、管理主体、運営主体及び再生医療等製品製販業者のデータ閲覧・ダウンロー ド権限及びその方法について PMDA と協議のうえ整理し、手順書案にまとめること。 ② 再生医療等製品製販者のデータ閲覧・ダウンロード権限については、患者同意のある範 囲及び次の法的要求を満たす範囲に留めることとする。 14 ア 再生医療等製品製販業者が医薬品医療機器等法、第二十三条の二十六の第三項、第二 十三条の二十九の第四項、第二十三条の三十一の第四項、に規定された再審査等のた めに利用すること。 イ 再生医療等製品製販業者が有害事象が発生した場合に、医薬品医療機器等法、第六十 八条の十の第一項、第六十八条の十三に定められた適切な対応が取れるようにするこ と。 ８）個人情報の取り扱い ① データシステムでは、患者の氏名や医療機関における患者 ID 等の個人情報を蓄積しな い方針としている。この方針に基づき、データシステムでは、医療機関における患者 ID とは異なる患者登録システム固有の ID を付与する等の機能を設ける。また、データシ ステムの利用者が例えばデータ登録時に自由記載のフォームに患者氏名等の個人情報 を記載してしまう等のことが生じないよう、ルール化することも必要である。こういっ た個人情報の取扱いに関する方針、個人情報が特定されることを避けるためのデータシ ステムの特徴的な機能、及び運用システムにおける対応等を記した、患者登録システム の利用規約、運用規定の案を作成すること。 ９）データ対外公表 ① アニュアルレポートの項目案を検討し、PMDA と協議すること。 ② データの集計、アニュアルレポートの作成、HP への公開までの手順をまとめた手順書 を作成すること。 ４ 情報システムの要件 （1） 機能要件 機能要件について「別紙 2 機能要件」に示す。 本調達で開発するアプリケーションを別調達のハードウェアにインストール及びセットア ップ等する際に用いる導入ツールも開発すること。受注者以外の業者が導入ツールを利用し てアプリケーションのインストール及びセットアップ等を実施できるよう、導入ツールの操 作や必要な設定等について記載した導入手順書を作成すること。 （2） 画面要件 上記（１）の機能要件に沿って設計等を行うこと。作成する画面について、以下の要件を 満たすこと。 １）画面の遷移、画面レイアウト、項目入力・更新方法、出力メッセージや操作方法等に一 貫性があり、シンプルかつ理解が容易で、操作性に優れた画面を設計すること。 ２）画面には Web ブラウザを使用し、クライアント端末環境に極力依存しない画面レイアウ ト及び操作性とすること。 ３）日付や時間等について、直接入力に加え、カレンダー画面や時刻リストからの選択入力 も可能とすること。 15 ４）入力内容の妥当性に関するロジカルチェックを行い、問題があれば警告メッセージある いはエラーメッセージを表示すること。 ５）数値や漢字、カナなど入力項目に応じた入力制限を行うこと。（例：手術日や使用量等 は数値のみ入力可能とする 等） ６）画面遷移と操作の関係を利用者が容易に把握できるようにすること。（例：画面ヘッダ ーに操作フローと現在位置を表示する 等） （3） 帳票要件 運営主体がアニュアルレポートを作成するために、データシステムのデータを抽出可能な こと。運営主体は、製品ごとに治療が実施された件数、治療を行った医療機関、患者の年齢、 性別構成等の項目をデータシステム外で統計解析し、アニュアルレポートを作成する。アニ ュアルレポートは、運営主体が HP で公開する。 （4） 情報・データ要件 本調達で構築するデータシステムの基本項目部分のデータ項目について「別紙 3 情報・ データ要件案」に示す。この項目はあくまで現時点の案であり、今後変更する可能性がある。 項目数は最大で 50 項目程度と想定すること。 （5） 外部インタフェース要件 データシステムは、現時点で他システムとの連携は想定していない。 （6） ガイドラインの遵守 データシステムの信頼性を確保するために、次のガイドラインを遵守すること。具体的に 求める要件は、PMDA と協議のうえ決定する。 １）民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律（平成 16 年 12 月 1 日 法律第 149 号、e-文書法） ２）医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用につい て（平成 17 年 4 月 1 日 薬食発第 0401022 号厚生労働省医薬食品局長通知、ER/ES 指 針） ３）厚生労働省 医療情報システムの安全管理に関するガイドライン （7） 監査証跡 データシステムは（6）２）の指針を遵守したものとするため、監査証跡を残すことが求め られる。監査証跡として以下をはじめとするデータシステムの操作及び処理について全て記 録し、記録した監査証跡を閲覧するための仕組みを構築すること。 １）利用者 ID、運営主体のシステム管理者 ID ２）アクセス日時、処理日時 ３）利用者接続元 IP アドレス ４）利用機能 16 ５）処理内容（登録／修正／削除／閲覧／承認 等） ６）登録データ内容、修正前／修正後のデータ内容、閲覧データ内容、承認時の登録内容 ７）クエリの記録 ８）マスタ情報の登録／修正／削除の内容 ９）その他データシステムの操作、処理の記録 （8） CSV（Computerized System Validation） １）データシステムは（6）の指針を遵守し、監査証跡を確実に残すため、開発に当たっては CSV を行う必要がある。データシステムの開発に際し CSV を行い、各種ドキュメントを 作成すること。CSV のドキュメントには、セキュリティ、バックアップ、監査証跡の記 録等に係る仕様及び設計等についても記載すること。 ２）CSV では、バリデーション計画を策定し、必要な手順の作成、記録の保持・維持を行う こと。バリデーション記録の保存期間について PMDA と協議すること。バリデーション 計画には、将来的なデータシステムの改修時に行うバリデーションに係るドキュメント の更新、管理方法についても計画を含めること。 ３）CSV を実施する人員は、データシステム構築要員と明確に区分すること。 ４）運用設計及び保守設計においては、以下の項目などについて CSV を考慮して検討するこ と。 ① データシステム稼働時の手順作成 ② データシステム稼働監視の手順化 ③ 運用に係るデータシステム操作の手順化 ④ データシステムの運用管理に係る手順化 ⑤ データシステム構成管理の手順化 ⑥ 安全対策（ウィルス対策等）の手順化 ⑦ 障害の切り分け、周知、対応方法の手順化 ⑧ 保守作業の定義（業務マニュアル整備・保守を含む） ⑨ ネットワーク、ハードウェア、アプリケーションの保守の手順化 ５）以下リンクに示す再生医療等製品の GPSP に対応可能なこと。 ① 再生医療等製品の製造販売後の調査及び試験の実施の基準に関する省令 ② 再生医療等製品の製造販売後の調査及び試験の実施の基準に関する省令の施行につい て http://www.pmda.go.jp/operations/shonin/outline/shinrai/tuchi_gyomutejun.html （9） 個人情報及びプライバシー保護への配慮 患者登録システムの運用について、設計段階からプライバシー保護に配慮したものとする ため、Privacy By Design に基づいた方策を提案すること。また、提案した方策について、 プライバシー影響評価（PIA）を行い、リスクの低減または回避を行うこと。 17 ５ 規模・性能要件 （1） 規模要件 患者登録システムの想定規模（年間ベース）に関する要件は表 3 の通り。 表 3 規模要件 項目 No 1 利用者数、 医療機関 施設数 再生医療等 平成 27 年度末時点推定 平成 32 年度末時点推定 10 医療機関、約 50 人 50 医療機関、約 3,000 人 2 業者、約 10 人 10 業者、約 60 人 製品製販業者 2 データ登 録件数 疾患情報 10 件（1～2 製品） 600 件（10 製品前後） 3 平均アク セス数 通常時 120 アクセス／日 1,800 アクセス／日 （1 医療機関当たり 1 日 10 アクセス、 （1 医療機関当たり 1 日 30 アク 1 業者当たり 1 日 10 アクセスで推定） セス、1 業者当たり 1 日 30 アク セスで推定） ピーク時 540 アクセス／日 5,500 アクセス／日 （1 医療機関当たり 1 日 50 アクセス、 （1 医療機関当たり 1 日 100 アク 1 業者当たり 1 日 20 アクセスで推定） セス、1 業者当たり 1 日 50 アク セスで推定） （2） 性能要件 １）データシステムの性能設計について、以下に要求レスポンスの目安を示す。但し、各レ スポンス時間はデータセンター内の環境で処理した場合の計測時間とし、インターネッ トの通信速度に係るネットワークの影響を考慮しない。いずれも全トランザクションの 80%が目標値以内のレスポンス時間であることを要件とする（ただし、更新系処理につ いて添付ファイルのデータ量が大きくなる場合は除く）。なお、本要件は、稼働して 5 年後のデータ量及び処理量等においても性能が低下しないよう設計すること。 ① 参照系処理（登録されたデータの表示等）：平均 3 秒以内 ② 更新系処理（疾患情報の登録、マスタ情報の更新等）：平均 3 秒以内 ③ 検索系処理（データシステムに登録された全件から 50 件程度の検索結果一覧を表示 等）：平均 5 秒以内 ２）データの蓄積によるデータ量の増大や、同時複数の業務機能実行等に伴って、著しい処 理性能の低下を招かない設計とすること。 ６ 信頼性等要件 （1） 信頼性要件 以下の信頼性要件を満たす設計とすること。 １）基本要件 18 ① 保守等に係る計画停止時間を除いて、365 日稼働が可能であること。 ② 設計に際し機器構成及び基本ソフトウェア等は、信頼性に関して実績のある製品及び技 術の採用を検討すること。 ③ 基本ソフトウェア等について、製品サポート等を含む信頼性が保証されていること。 ２）稼働率 ① 利用者へのサービス提供時間は、原則毎日 06:00～02:00 とする。02:00～06:00 はデー タシステム保守等のメンテナンスやバックアップ取得等を行うために使用可能である。 データシステム保守等のメンテナンスは年に 1 度程度を想定しているが、詳細はデータ システム保守設計で決定する。 ② 02:00～06:00 以外の時間にデータシステムを停止する場合は事前に利用者に対しシス テム停止時間のアナウンスを行うことをデータシステム保守設計で定めること。 ③ 主要なサーバとネットワーク機器の稼働率は 95%以上を保証し、遵守できるよう必要 な処置を取ること。稼働率の算出方法は下記の通りとする。但し、運用時間に、メンテ ナンス時間と計画停止時間は含めない。 稼働率＝（運用時間－停止時間）÷ 運用時間 ３）機器の構成 ① 主要なサーバ、ネットワーク機器及び電源・CPU などの主要部品等について、５.規模・ 性能要件と６.信頼性等要件を考慮した、最適な構成を設計すること。 ４）バックアップ対策 ① サーバに格納されているデータ及び各種設定等をバックアップするための仕組みを導 入すること。 ② データのバックアップの対象は監査証跡を含むデータシステム内の全てのデータとす ること。 ③ バックアップの取得頻度、取得範囲（フルバックアップ、差分バックアップ）、管理世 代数、保存期間等はデータ量等を考慮し、PMDA と相談の上、決定すること。 ④ データシステムのバックアップはプログラム改修やパッチ適用が行われた場合に取得 することをデータシステム運用設計で定めること。 ⑤ データシステムバックアップとデータバックアップの記録媒体は、データシステムを設 置するデータセンターとは異なる、PMDA が指定する場所にて保管することをデータシ ステム運用設計で定めること。 ⑥ バックアップに必要な記録媒体について検討すること。 ⑦ データシステム障害等によりデータシステムのデータが消失等した場合には、バックア ップデータからリカバリすることをデータシステム運用設計で定めること。リカバリを 行った際にはリカバリの実施に係る記録を残すことをデータシステム運用設計で定め ること。 19 （2） 拡張性要件 １）２３）及び２４）に示す通り、将来的な対象製品及び対象診療領域が拡大した場合にも、 大幅なデータシステム改修が不要となるようなデータ構造及びデータシステム構成を設 計すること。本調達において、特有項目部分の構築のための基本的な方式、インタフェ ースについては、設計を行うこと。 ２）管理データ量の増加等に伴うディスク容量等の増設が可能な構成を設計すること。 ３）ネットワークについて、処理件数や利用者数の増加等に対応するため、回線容量を変更 できるよう設計すること。 （3） 上位互換性要件 １）パッケージソフトウェア等を使用する場合は、運用期間を通じて継続的にサポートでき る製品を採用するよう設計に際し検討すること。 （4） システム中立性要件 １）継続的な保守運用、システム拡張に配慮し、将来に渡り技術者・代替製品等が市場で平 易に確保できるよう、設計に際しては極力、特定のメーカーに偏らない汎用的な製品及 び技術の採用を検討すること。 （5） 事業継続性要件 １）大規模災害等でデータシステムが損壊し継続使用が困難になった場合に登録管理データ が消失し復旧できなくなる事態を避けられるよう、データシステム及びデータのバック アップ及びリカバリ計画を策定すること。 ７ 情報セキュリティ要件 （1） セキュリティ設計 １）以下（2）及び（3）に係るセキュリティ設計を行い、セキュリティ設計書を作成するこ と。セキュリティ設計書はセキュリティに係るデータシステム及び運用設計の変更等が 発生した場合には適切に更新を行い、常に最新化すること。 （2） 権限要件 １）利用者・運営主体のシステム管理者等の権限を、処理機能・データ・ファイル・データ 項目等の単位で設定できる仕組みを設けること。付与する権限の情報は設計時に PMDA と協議すること。 ２）利用者の種別（利用者 ID を発行する対象）は以下を想定すること。 ① 医療機関 ② 再生医療等製品製販業者 ③ 管理主体 ３）権限は利用者単位及び利用者の所属組織単位で設定できること。 20 ４）権限は「登録・参照・修正可」、「承認可」、「参照のみ可」、「不可」等、複数のレ ベル、複数の権限の組み合わせで設定できること。 ５）権限の変更は運営主体のシステム管理者により変更可能とすること。 （3） 情報セキュリティ対策 １）データシステムの設計・開発等に際して、受注者は PMDA と調整の上、表 4 に示す対策 をはじめとする必要なセキュリティ対策のセキュリティ設計を行い、セキュリティ設計 書を作成すること。また、本調達の範囲における必要な対策を講じること。 表 4 情報セキュリティ対策 区分 対策の概要 コンピュータウイルス等対策 ・コンピュータウイルス対策基準（平成 12 年 12 月 28 日（通商産業省告示 第 952 号））に準じた対策を講じること。 ・セキュリティパッチの適用、ウイルス定義ファイルの更新等を適切に行う こと。但し、適用に際してはデータシステムの安定性を損なうことのない よう、十分注意すること。 ・外部からのファイル取込み時には、必要なセキュリティ対策を施し、ウイ ルスチェック等を行うこと。 ボット対策 ・ボットに感染したコンピュータからのサイバー攻撃等を迅速かつ効果的に 停止させるための対策を考慮すること。 不正アクセス対策 ・データシステムへの外部からの不正アクセスを防止するため、ファイアウ ォールの設定による経路制御等の必要な措置を講ずること。 ・ウェブサイトに係る機能等に関しては、クロスサイト・スクリプティング や SQL インジェクション等の脆弱性を狙った攻撃に対する対策を講じる こと。 ・異常検知時のデータシステム管理者への自動通知機能を有すること。 脆弱性対策 ・ソフトウェア等脆弱性関連情報取扱基準（平成 16 年 7 月 7 日（経済産業 省告示 第 235 号））に準じた対策を講じること。 ・公表されている脆弱性情報及び公表される脆弱性情報をデータシステムの 構築時及び運用期間中の年に 1 度以上把握すること。 ・把握した脆弱性情報について、対処の要否、可否を判断すること。対処し たものに関して対処方法、対処しなかったものに関してその理由、代替措 置及び影響を脆弱性情報の把握の都度、書面にて報告すること。 監査証跡管理 ・データシステムの処理等について、利用者 ID、IP アドレス、利用機能、 アクセス日時、処理（登録／修正／閲覧／承認） 、修正前後のデータ、ク エリの記録等の、監査証跡が取得出来ること。 ・監査証跡の収集及び一元管理が可能であること。監査証跡のファイルは一 定期間ハードディスク上に保存し、それを超えた分については、外部可搬 媒体にて保存可能なこと。 ・取得した監査証跡は削除、改ざん等が行われないよう必要な仕組みを設け ること。 ・監査証跡の保存期間は管理主体と協議の上、決定すること。 利用者管理、主体認証 ・個人認証に用いるパスワードは、桁数・文字、有効期間、再利用禁止期間、 ログオン失敗回数、初期設定値からの強制変更通知等について設定・変更 21 区分 対策の概要 可能とすること。 ・ログイン中、一定時間操作が行われない場合にタイムアウトとして以降の 操作ができないよう制御すること。タイムアウトまでの時間は、運営主体 のシステム管理者が設定変更可能とすること。 ・証明書の発行及び適用により利用者の端末認証を行う等、ID 及びパスワ ード以外の要素による認証（二要素認証）の仕組みを設けること。 暗号化 ・患者情報や利用者の情報等、個人情報又は機微性の高い情報の通信・保管・ 管理において、通信及びデータの暗号化を行うこと。暗号化の実施方法に ついて、PMDA と協議の上、必要な対策を取ること。 データ及びデータシステムの改 ざん・破壊等の防止、監視 ・データ及びデータシステムが改ざん・破壊されることのないよう、データ システムの監視・異常の検知を行う機能を有すること。 ・万一、改ざん・破壊があった場合にも早急に復旧を行えるような仕組みを 設けること。 ・通信時のデータ改ざんを検知するための機能を有すること。 ２）セキュリティの専門家が開発に関与し、セキュリティを確保したデータシステム構成及 びネットワーク構成とすること。 ３）セキュリティ及び独立性（本事業以外の他の治験や臨床試験のデータとは独立した環境 （入力画面・データベース等）で管理・運営されていること）を保証すること。 ８ 情報システム稼動環境 （1） ハードウェア設計 １）データシステムのライフサイクルを通した経済性を考慮し、導入に係る初期費用、保守 運用費用、及びデータセンターにおけるデータシステムの占有面積や所要電力等を、可 能な限り抑制した構成を設計すること。 ２）CPU 性能やメモリ容量、HDD 容量等について、５規模・性能要件を満たす水準でハード ウェア設計を行うこと。ハードウェアスペック等の詳細はハードウェア設計時に定める こと。 ３）将来的な利用者数の増加に対応するため、段階的な管理データ量や処理量の増加を考慮 し、主記憶装置の増設、接続機器の追加等を容易に行える設計とすること。 （2） ソフトウェア設計 １）データシステムのライフサイクルを通した経済性を考慮し、導入に係る初期費用、保守 運用費用、及びライセンス費用等を、可能な限り抑制した構成を設計すること。 ２）オープンソースソフトウェアを利用する場合及び利用しない場合のどちらであっても、 類似システムでの豊富な採用実績があること。またデータシステムの安定稼働やデータ システム稼働後のサポートに関して支障の無いよう留意すること。 ３）原則、調達時期における最新のバージョンであること。但し、安定性や採用実績等を考 慮し旧バージョンの方が望ましい場合はその限りではない。 22 ４）メーカー固有の製品（ミドルウェア等）を利用する場合には、使用条件の他に、将来に 渡る拡張性・経済性を十分考慮すること。 ５）設計及びソフトウェアの選定にあたっては、極力クライアント端末に特別なソフトウェ アの導入を必要としないことを前提とすること。 （3） ネットワーク構成 １）ネットワーク設計を行うこと。ネットワークについて、初期構築時は表 5 の構成とする。 表 5 ネットワーク概要 No 1 種別 利用者接続用 通信回線 Internet 通信暗号化 SSL 通信容量・回線数 100Mbps×1 （ベストエフォート） ２）処理件数や利用者数の増加等に対応するため、回線容量を変更できる設計とすること。 ３）ネットワーク設計において不正アクセス等の防止策と常時監視について検討すること。 （4） クライアント要件 １）受注者は、利用者がデータシステムを利用するために推奨されるクライアント端末の OS、 ブラウザ、スペック等について動作条件をデータシステムの画面に明記すること。 ２）利用者のクライアント端末のブラウザは原則として Internet Explorer 11 以降を想定する こと。また Internet Explorer10 での動作も保証すること。 ９ テスト要件 （1） システム機能等テスト テストを計画的に実施するため、受注者は、PMDA と調整の上、表 4「テスト項目と概要」 に係るテストの実施項目を決めるとともに、テスト計画書に以下の項目を明記し、PMDA の 承認を得てテストを行うこと。 PMDA 及び受注者のテスト実施体制と役割 テストに係る詳細な作業及びスケジュール テスト環境 テストツール 合否判定基準 等 受注者は、受入テスト前に総合テスト(※)を実施すること。 また、PMDA にて実施する受入テストに関して、下記の支援を実施すること。 ア．受入テスト計画書（案）の作成 イ．受入テスト手順書（案）の作成 23 ウ．受入テスト資源（ソフトウェア、テストデータ、データシステム操作等相談要員）の 提供。受入テスト時に本番データを使用する場合は、本番データの準備は PMDA が行 う。 エ．受入テスト環境構築 オ．障害の解析と報告 カ．プログラム、ドキュメント等の修正 （※）本番データを使用し、システムレベルのテストを受注者が実施する。今回開発する全 機能の正常稼働を確認する。 表 6 テスト項目と概要 No. テスト項目 テスト概要 1 単体・結合テスト ソフトウェアをほかのソフトウェアと結合する前に単体でその完全 性を評価する。また、それらの結合テスト・評価を行う。 2 機能テスト アプリケーションの各機能が実行するタスクが、要求仕様書・設計 文書に違反する動作をしていないかを確認する。 3 強制エラーテスト プログラムを強制的にエラーにするような異常系テストを行う。ま た極端な入力データに対するプログラムの応答を確認する。 4 システムレベルテスト システム全体を通して動作させ、正常に機能するかを確認する。 バグ修正後に、それが確実に修正されているかとともに、新たなバ グが発生していないかをテストする。 5 現実のユーザレベルテスト ユーザがプログラムに対して行うであろうことを予測してテストす る。 6 探索型テスト 問題の「起こりそうな」場所に焦点をしぼってテストする。 7 負荷／ボリュームテスト プログラムが大量のデータ／計算／処理をどのように扱うかをテス トする。 8 ストレステスト 限られたリソースのもとでプログラムを動作させる。 9 パフォーマンステスト ユーザが許容できるシステム性能を維持できるかどうかをテストす る。 10 ドキュメントテスト 資料の記載内容や参照先が正しく記述されているかを確認する。 11 ユーティリティ、ツール、その 他付属品のテスト システムに付属するもののテスト、インストール／アンインストー ルテスト、インストーラのテスト、README やアイコンの確認、イ ンストールした機能が正常に動作するかをテストする。 12 フェイルオーバーテスト システムレベルのエラー処理やリカバリプロセスをテストする。 13 アベイラビリティテスト システムやコンポーネントが動作可能でアクセス可能な状態となる 24 テスト項目 No. テスト概要 までをテストする。 14 信頼性テスト システムが一定時間の間連続で操作可能かをテストする。 15 ユーザインタフェイステスト 使いやすさや見た目の評価、UI が仕様通りに動作するかをテストす る。 16 ユーザビリティテスト 使いやすさやユーザの満足度をはかる情報を収集する等、場合によ っては、外部の協力者の評価も交えてテストする。 17 セキュリティテスト 脆弱性／情報洩れ等がないかをテストする。 １０ （1） 移行要件 移行に係る要件 １）本調達では移行が必要なデータは無い。 ２）将来的にシステム環境移行等を行う際、データ抽出を円滑に行えるよう、患者登録シス テムに登録された全てのデータ、マスタ及び監査証跡等は、PMDA が指定する形式で、 全件を容易に出力可能とすること。 （2） 教育に係る要件 １）３３）に示す、本調達に係るマニュアル及び教育用コンテンツ案を作成すること。 ２）データシステム稼動後はテストのための検証環境を、教育・研修用にも使用可能とする こと。 １１ （1） 運用設計 運用システム設計 １）受注者は（2）に示す運用システム設計を行うこと。 （2） ヘルプデスク設計 １）受注者は、管理主体が以下の条件を満たすヘルプデスクを平成 28 年度以降に委託する際 に必要となる要件を検討し、ヘルプデスク設計書としてまとめること。ヘルプデスクの 運用は本調達の範囲外である。 ① ヘルプデスクとして、患者登録システム運用開始から契約期間中を通して、利用者及び PMDA 等からのデータシステムに関する問い合わせを受け付ける。 ② 問い合わせはメール及び電話で受け付ける。 ③ 問い合わせへの対応時間は行政機関の休日に関する法律第一条にて定められた行政機 関の休日以外の日の 9:00～17:00 とする。 25 ④ 問い合わせ内容は管理表で管理し、問い合わせ事項の解決までフォローする。 ⑤ 利用者からの意見・質問を受け付けるフォームを作成する。 ⑥ 問い合わせ内容により受注者による回答が困難な場合には、 PMDA にエスカレーション する。エスカレーションされた事項は PMDA により回答案等を作成し受注者に連絡す る。問い合わせ者への回答はヘルプデスクが行う。 ⑦ 受け付けた意見・質問、問い合わせに対し、PMDA と相談の上 FAQ を作成し公開する。 FAQ は半年に 1 回程度の頻度で定期的に更新することを想定している。 ⑧ 問い合わせ状況等について月次で PMDA に報告する。 ⑨ 利用方法の説明等に関して画面単位でデータシステムにヘルプを登録する。 ⑩ 定期的に問題解決状況・滞留状況について報告すること。また、特に緊急度の高いイン シデントや長期滞留しているインシデントについては、求めに応じ原因及び調査分析状 況について報告する。 （3） データシステム運用設計 １）データシステム運用業務として以下業務を想定している。受注者は、患者登録システム のデータシステム運用設計を行い、データシステム運用計画を作成しデータシステム運 用手順書を策定すること。データシステム運用業務は本調達の範囲外である。 ① データシステムの稼働状況監視 ② ディスク使用量、メモリ使用量等のリソース監視 ③ アクセスログ管理（ログ管理、アクセス状況の分析等） ④ バックアップ（日次、週次等） ⑤ 装置、部品等の定期点検 ⑥ 障害発生時の初期対応（障害切分け、関係者と調整） ⑦ 運転管理、リブート ⑧ 定期報告 ２）データシステム運用状況について月次で PMDA に報告することをデータシステム運用設 計書等で定めること。 ３）障害発生時等、特に報告すべき事項が発生した場合には、月次の報告とは別に適切なタ イミングで PMDA に報告することをデータシステム運用設計書等で定めること。 （4） 運用施設・設備設計 １）受注者はデータシステムを設置するデータセンター環境の設計を行うこと。データセン ター環境の設計に際して以下について考慮すること。 ① データシステムのライフサイクルを通した経済性を考慮し、導入に係る初期費用、保守 運用費用、及びデータシステムの占有面積や所要電力等を、可能な限り抑制した構成と する。 ② データセンターの建物は、震度 6 相当に耐え得る免震構造とする。 ③ データセンターの立地は、海や河川から離れ、津波・高潮・洪水等による自然災害の影 響が少ない場所とする。 26 ④ データセンターの立地上に活断層が発見されていないこととする。 ⑤ 24 時間 365 日体制で入退室管理や警備が行われていることとする。 ⑥ 伴連れ防止用のゲートの設置等、権限を持たない者が立ち入りできない対策が整備され ていることとする。 ⑦ 入退室管理が可能なこととする。 ⑧ 受電設備について本線・予備線を有しており、複数系統の受電に対応していることとす る。 ⑨ 非常用発電機用の燃料は、広域災害時にも優先的に確保できる体制が整備されているこ ととする。 ⑩ マシン室内には火災を早期発見できるよう、煙感知器が設置されていることとする。 ⑪ データセンターは、JIS Q 27001 又は ISO/IEC27001 の認証に準ずる、適切な情報セキ ュリティ管理が行われていることとする。 ⑫ 公共交通機関を用いて PMDA から 120 分以内に到着可能な場所にあることとする。 ⑬ ６信頼性等要件及び７情報セキュリティ要件等の要件を満たす構成とすることとする。 １２ （1） 保守設計 ソフトウェア保守設計 １）OS、ミドルウェア等のソフトウェアの保守設計を行うこと。保守の時間帯、内容につい ては、以下のとおりとすること。ソフトウェア保守業務は本調達の範囲外である。 ① 保守の時間帯は、月曜日から金曜日までの 9：00 から 17:00 までとする（祝日及び年 末年始は除くものとする）。 ② セキュリティホール等の情報及びパッチを入手可能とする。また、パッチの適用につい て技術的な情報を提供する。 ③ OS、ミドルウェア等のソフトウェアについて障害が発生した場合は、PMDA 職員の指 示のもと、原因解析を行う。ソフトウェアの不具合であった場合には、ソフトウェアの 保守の範囲でパッチにより復旧する。パッチによりアプリケーションの機能に影響を及 ぼす場合には、PMDA 職員と対応について協議する。 ④ PMDA 担当者からの仕様、利用方法、操作方法等の問い合わせについて対応する。 ⑤ 契約期間内にライセンス・証明書等の更新費用が発生するソフトウェアがある場合は、 その費用及び更新手続きも含める。 （2） ハードウェア保守設計 １）ハードウェアの保守設計を行うこと。保守の時間帯、内容については、以下のとおりと すること。ハードウェア保守業務は本調達の範囲外である。 27 ① 保守の時間帯は、月曜日から金曜日までの 9：00 から 17:00 までとする（祝日及び年 末年始は除くものとする）。 ② 機器等の障害発生及び PMDA 職員の求めに対し、迅速な対応が出来る体制を取り、障 害の連絡をした場合、保守要員を 8 時間以内に派遣し、障害復旧作業に着手することを 目標とする。ただし、システムの冗長化が図られている場合等、短時間の切り替えで継 続運用が可能な構成の場合は、PMDA 職員と協議し、対応を決めることができることと する。 ③ 機器等に関する仕様等の基本情報及びその他製品に関する技術情報を提供する。 ④ 機器の安定稼働を維持するための予防保全を行う。 ⑤ 機器等について障害が発生した場合、PMDA 職員の指示のもと、障害の復旧作業を行う。 ⑥ PMDA 担当者からの仕様、利用方法、操作方法等の問い合わせについて対応する。 １３ （1） 作業の体制及び方法 作業体制 １）受注者は、業務受託後、PMDA に対して作業体制（受注者側の体制図とそれぞれの役割 の詳細）を報告し、承認を得て業務を進めること。 ２）この際、業務に従事する者のスキル（IT スキル標準（ITSS））や資格、これまでの業務 実績を明記すること。 ３）承認された作業体制における受注者の PM（プロジェクトマネージャ）を含む作業従事者 は、特段の事情のない限り、役割として定められた任務について、着手から完了まで一 貫して作業にあたること。やむを得ず受注者側の事情により作業従事者を交代する場合 は、新たな作業体制について PMDA に対して予め承認を得ること。 その際、秘密保持 等に関する誓約書について、新たな作業体制に基づき作業従事者名を変更し、再提出す ること。 ４）また、受注者の PMO（プロジェクトマネジメントオフィス）あるいは品質保証部門にお ける責任者及び連絡担当者を作業実施体制図（案）に明記し、PMDA からの連絡・要望 に対して必要な対応が取れるようにすること。 （2） 開発方法 １）設計・開発・テスト・プロジェクト管理等において使用する開発方法論について PMDA と協議し取り決めを行い、その取り決めに基づき PMDA の指示に従うとともに、関係機 関との連携・協力を図りつつ実施すること。 ２）（9）に示す通り PIA を実施すること。 ３）データシステムの開発環境（開発用のハードウェア、開発ツール等のソフトウェアを含 む。）、作業場所、その他必要となる環境については、受注者の責任において確保する こと。 ４）受入テストの実施前には、通信ネットワーク処理を含む仮想的なテスト環境を整備し、 この中で十分な単体・結合テストを行い、障害等が発生しないようにすること。 ５）PMDA の保有する情報については、受注者に開示するので、それを基に設計・開発を行 うこと。 28 ６）その他、データシステム設計・開発を行うにあたり、想定されるリスクやその対応策等 を明示すること。 ７）契約締結後、業務一式のプロジェクト実施計画書を提示すること。また、契約締結以降 に変更が発生した場合には、その都度速やかに変更後のプロジェクト実施計画書を提出 すること。 ８）進捗状況や直近における予定等の報告をすること。報告のタイミングは PMDA と協議し 取り決めを行い、その取り決めに基づき行うこと。それ以外にも、PMDA 又は受注者が 必要と判断した場合は、必要に応じて随時追加の報告を行うこと。 １４ （1） 特記事項 基本事項 受注者は、次に掲げる事項を遵守すること。 １）本調達の遂行に当たり、業務の継続を第一に考え、善良な管理者の注意義務をもって誠 実に行うこと。 ２）本調達に従事する要員は、PMDA と円滑なコミュニケーションを行う能力と意思を有し ていること。 ３）本調達で取り扱う情報及び書類等について、他の業務のものと混在等することのないよ う適切に管理すること。 ４）本調達に従事する要員は、履行場所での所定の名札の着用等、従事に関する所定の規則 に従うこと。 ５）要員の資質、規律保持、風紀及び衛生・健康に関すること等の人事管理並びに要員の責 めに起因して発生した火災・盗難等不祥事が発生した場合の一切の責任を負うこと。 ６）受注者は、本調達の履行に際し、PMDA からの質問、検査及び資料の提示等の指示に応 じること。また、修正及び改善要求があった場合には、別途協議の場を設けて対応する こと。 ７）PMDA が依頼する技術的支援に対する回答、助言を行うこと。 ８）本調達においては、業務終了後の運用等を、受注者によらずこれを行うことが可能とな るよう詳細にドキュメント類の整備を行うこと。 （2） 各業者との役割分担等 システム設計・開発等を複数業者が連携（再委託を含めて）して実施する等の場合は、参 画する各業者の役割分担等を明示すること。 （3） 入札制限 情報システムの調達の公平性を確保するために、以下に示す事業者は本調達に参加できな い。 １）PMDA CIO 補佐が現に属する、又は過去 2 年間に属していた事業者等 ２）本調達の調達仕様書の作成に直接関与した事業者等 29 ３）①～②の親会社及び子会社（「財務諸表等の用語、様式及び作成方法に関する規則」（昭 和 38 年大蔵省令第 59 号）第 8 条に規定する親会社及び子会社をいう。以下同じ。） ４）①～②と同一の親会社を持つ事業者 ５）①～②から委託を受ける等緊密な利害関係を有する事業者 （4） 応札条件 応札希望者は、以下の条件を満たしていること。 １）本事業を理解しており、本調達にあたり、PMDA に逐次業務の説明を求めることなく担 当者とスムーズな会話ができる知識を有していること。 ２）応札時には、開発工数、概算スケジュールを含む見積り根拠資料の提出が可能であるこ と。なお、応札後に PMDA が見積り根拠資料の提出を求めた際、提出されなかった場合 には、契約を締結しないことがある。 ３）CSV ポリシー、CSV ガイドラインを有しており、患者登録システムの CSV を実施でき ること。 （5） 知的財産等 知的財産の帰属は、以下のとおり。 １）本件に係り作成・変更・更新されるドキュメント類及びプログラムの著作権（著作権法 第 21 条から第 28 条に定めるすべての権利を含む。）は、受注者が本件のシステム開発 の従前より権利を保有していた等の明確な理由により、あらかじめ書面にて権利譲渡不 可能と示されたもの以外、PMDA が所有する等現有資産を移行等して発生した権利を含 めてすべて PMDA に帰属するものとする。 ２）本件に係り発生した権利については、受注者は著作者人格権（著作権法第 18 条から第 20 条までに規定する権利をいう。）を行使しないものとする。 ３）本件に係り発生した権利については、今後、二次的著作物が作成された場合等であって も、受注者は原著作物の著作権者としての権利を行使しないものとする。 ４）本件に係り作成・変更・修正されるドキュメント類及びプログラム等に第三者が権利を 有する著作物が含まれる場合、受注者は当該著作物の使用に必要な費用負担や使用許諾 契約に係る一切の手続きを行うこと。この場合は事前に PMDA に報告し、承認を得るこ と。 ５）本件に係り第三者との間に著作権に係る権利侵害の紛争が生じた場合には、当該紛争の 原因が専ら PMDA の責めに帰す場合を除き、受注者の責任、負担において一切を処理す ること。この場合、PMDA は係る紛争の事実を知ったときは、受注者に通知し、必要な 範囲で訴訟上の防衛を受注者にゆだねる等の協力措置を講ずる。 なお、受注者の著作又は一般に公開されている著作について、引用する場合は出典を明 示するとともに、受注者の責任において著作者等の承認を得るものとし、PMDA に提出 する際は、その旨併せて報告するものとする。 （6） 瑕疵担保責任 30 本調達の最終検収後 2 年以内の期間において、委託業務の納入成果物に関して本システム の安定稼動等に関わる瑕疵の疑いが生じた場合であって、PMDA が必要と認めた場合は、受 注者は速やかに瑕疵の疑いに関して調査し回答すること。調査の結果、納入成果物に関して 瑕疵等が認められた場合には、受注者の責任及び負担において速やかに修正を行うこと。な お、修正を実施する場合においては、修正方法等について、事前に PMDA の承認を得てから 着手すると共に、修正結果等について、PMDA の承認を受けること。 受注者は、瑕疵担保責任を果たす上で必要な情報を整理し、その一覧を PMDA に提出する こと。瑕疵担保責任の期間が終了するまで、それら情報が漏洩しないように、ISO/IEC27001 認証（国際標準）又は JISQ27001 認証（日本工業標準）に従い、また個人情報を取り扱う場 合には JISQ15001（日本工業標準）に従い、厳重に管理をすること。また、瑕疵担保責任の 期間が終了した後は、速やかにそれら情報をデータ復元ソフトウェア等を利用してもデータ が復元されないように完全に消去すること。データ消去作業終了後、受注者は消去完了を明 記した証明書を作業ログとともに PMDA に対して提出すること。なお、データ消去作業に必 要な機器等については、受注者の負担で用意すること。 （7） 再委託 １）受注者は、受注業務の全部又は主要部分を第三者に再委託することはできない。契約金 額の 10％を超える受注業務の一部を再委託する場合は、事前に再委託する業務、再委託 先等を PMDA に申請し、承認を受けること。申請にあたっては、「再委託に関する承認 申請書」の書面を作成の上、受注者と再委託先との委託契約書の写し及び委託要領等の 写しを PMDA に提出すること。受注者は、機密保持、知的財産権等に関して本仕様書が 定める受注者の責務を再委託先業者も負うよう、必要な処置を実施し、PMDA に報告し、 承認を受けること。なお、第三者に再委託する場合は、その最終的な責任を受注者が負 うこと。 ２）受注者又は本調達の一部の委託を受けた業者（以下この項において「委託元業者」とい う。）から本調達に係る業務の一部を受けた業者は、当該業務の一部を第三者に再委託 することができる。この場合、再委託する業務の範囲及び再委託先等について、委託元 業者を通じ、受注者が取りまとめの上、PMDA に申請し、承認を受けること。申請にあ たって必要な書類及び手続き並びに本仕様書に定める責務について、１）に準拠する。 なお、再委託された業務に係る最終的な責任は受注者が負うこと。 ３）１）における「主要部分」とは、以下に掲げるものをいう。 ア 総合的企画、業務遂行管理、手法の決定及び技術的判断等。 イ SLCP-JCF2013 の 2.3 開発プロセス、及び 2.4 ソフトウェア実装プロセスで定める各プ ロセスで、以下に示す要件定義・基本設計工程に相当するもの。 ・ 2.3.1 プロセス開始の準備 ・ 2.3.2 システム要件定義プロセス ・ 2.3.3 システム方式設計プロセス ・ 2.4.2 ソフトウェア要件定義プロセス ・ 2.4.3 ソフトウェア方式設計プロセス ４）１）における「主要部分」であっても、以下の場合には再委託を認めることがある。 31 ア 補足説明資料作成支援等の補助的業務 イ 機能毎の工数見積において工数が比較的小さい機能に係るソフトウェア要件定義等の 小規模な業務 （8） 機密保持 本調達を実施する上で必要とされる機密保持に係る条件は、以下のとおり。 １）受注者は、受注業務の実施の過程で PMDA が開示した情報（公知の情報を除く。以下同 じ。）、他の受注者が提示した情報及び受注者が作成した情報を、本受注業務の目的以 外に使用又は第三者に開示若しくは漏洩してはならないものとし、そのために必要な措 置を講ずること。 ２）受注者は、本受注業務を実施するにあたり、PMDA から入手した資料等については管理 台帳等により適切に管理し、かつ、以下の事項に従うこと。 複製しないこと。 用務に必要がなくなり次第、速やかに PMDA に返却又は消去すること。 受注業務完了後、上記１）に記載される情報を削除又は返却し、受注者において 該当情報を保持しないことを誓約する旨の書類を PMDA に提出すること。 ３）応札希望者についても上記１）及び２）に準ずること。 ４）「独立行政法人 医薬品医療機器総合機構 情報システム管理利用規程」の第 52 条に従う こと。 ５）「秘密保持等に関する誓約書」を別途提出し、これを遵守しなければならない。 ６）機密保持の期間は、当該情報が公知の情報になるまでの期間とする。 （9） 遵守事項 本調達を実施するにあたっての遵守事項は、以下のとおり。 １）受注者は、「政府機関の情報セキュリティ対策のための統一基準群（平成 24 年度版）」 （平成 24 年 4 月 26 日、情報セキュリティ政策会議決定）に定めるほか、PMDA が定め る情報セキュリティの規定を遵守すること。 ２）PMDA へ提示する電子ファイルは事前にウイルスチェック等を行い、悪意のあるソフト ウェア等が混入していないことを確認すること。 ３）民法、刑法、著作権法、不正アクセス禁止法、個人情報保護法等の関連法規を遵守する ことはもとより、下記の PMDA 内規程を遵守すること。 独立行政法人 医薬品医療機器総合機構 情報システム管理利用規程 独立行政法人 医薬品医療機器総合機構 個人情報管理規程 ４）受注者は、本調達において取り扱う情報の漏洩、改ざん、滅失等が発生することを防止 する観点から、情報の適正な保護・管理対策を実施するとともに、これらの実施状況に ついて、PMDA が定期又は不定期の検査を行う場合においてこれに応じること。万一、 情報の漏洩、改ざん、滅失等が発生した場合に実施すべき事項及び手順等を明確にする とともに、事前に PMDA に提出すること。また、そのような事態が発生した場合は、PMDA に報告するとともに、当該手順等に基づき可及的速やかに修復すること。 32 （10） 作業場所 受注業務の作業場所は、（再委託も含めて）PMDA 内、又は日本国内で PMDA の承認した 場所で作業すること。PMDA 内での作業においては、必要な規定の手続を実施し承認を得る こと。なお、必要に応じて PMDA 職員は現地確認を実施できることとする。 （11） 環境への配慮 環境への負荷を低減するため、以下に準拠すること。 １）本件に係る納入成果物については、「国等による環境物品等の調達の推進等に関する法 律（グリーン購入法）」（平成 15 年 7 月 16 日法律第 119 号）に基づいた製品を可能な 限り導入すること。 ２）導入する機器等がある場合は、性能や機能の低下を招かない範囲で、消費電力節減、発 熱対策、騒音対策等の環境配慮を行うこと。 （12） その他 PMDA 全体管理組織（PMO）が担当課に対して指導、助言等を行った場合には、受注者も その方針に従うこと。 １５ 落札者決定方法 落札者の決定は、一般競争入札(総合評価落札方式)により、総合評価点の最も高い者を落 札者とする｡ なお、技術の評価に当たっては、PMDA に設置する一般競争入札（総合評価落札方式）選 定委員会にて評価を行い、入札プロセスの中立性、公正性等を確保するため、機構 CIO 補佐 に意見を聴くものとする。 （1） 予定価格 競争入札につき公表しない｡ （2） 評価の配点 評価にあたっては、120 点の範囲内で採点を行い、価格評価による得点（以下「価格 点」という。）と技術評価による得点（以下「技術点」とい。）に区分し、配点を 1：3 とする。 総合評価点＝価格点（30 点満点）＋技術点（90 点満点） （3） 価格評価の方法 価格点は、入札価格を予定価格で除して得た値を 1 から減じて得た値に入札価格に対 する得点配分を乗じて、小数第三位以下を切り捨てたものとする。 価格点＝（1－入札価格÷予定価格）×30 点 （4） 技術点評価基準 １）評価項目 ① 【課題理解】・・・10 点 33 PMDA 業務、関連する各種制度、再生医療製品患者登録システムの目的/利活用に関 して十分に理解した上で、患者登録システムの構築における課題を的確に捉えてい るか。 ② 【提案能力】・・・60 点 本業務を実施するにあたり、必要な技術について水準以上のレベルを有しているか。 ア 業務運用の設計、関連資料作成について、検討項目、検討方法、成果のイメー ジが具体的に提案されているか。また、その内容は妥当なものか。 イ 提案されたデータシステム構成は、今後の製品追加に係るデータ改修の範囲を 最小限かつ安価に実施するための工夫がされているものか。また、その内容は 妥当なものか。 ウ セキュリティ、CSV（Computer System Validation）、バックアップ、監査ロ グ等、医療分野における研究データの蓄積及び分析のためのデータシステムの 構築に求められる対応について実現方法が具体的に提案されているか。またそ の他のデータシステムの機能に関して、実現方法が具体的に示され、利用者に 理解しやすく操作が容易である等、利便性に配慮した有効な提案があるか。さ らにその他の患者登録システム構築に求められる対応について実現方法が具体 的に提案されているか。 ③ 【管理能力及び実績】・・・20 点 ア 本業務を実施するにあたり、体制・人員及びプロジェクト管理能力は十分であ るか。 イ 取り組む課題への対応能力・技術力、プロジェクト進行の管理能力及び変動事 象に対する柔軟な対応力を有するか。 ウ 複数の医療機関から医療情報を登録し管理するシステム構築業務の運用設計等 の経験を十分に備えているか。 ２）評価点 ① 各評価項目に設定する範囲の点数で評価を行う。 ② 各項目には基礎点（5 点～30 点）を設定し、各項目の合計（45 点）を基準点とする。 ③ 採点結果が基準点に達しなければ、当該事業の確実な遂行が危ぶまれる可能性があ るため、不合格とする。 （5） 選定方法 １）価格入札を実施。入札価格が予定価格を上回った者はその時点で失格となり、プレゼン テーションに進めない。ただし、入札をした全ての者の入札価格が予定価格を上回った 場合は、その場で再度入札を実施する場合がある。 ２）入札価格が予定価格の範囲内であった参加者は、技術審査として、企画提案書に基づき プレゼンテーションを行う。 ３）参加者は各委員から質疑を受ける。 ４）各委員は、上記１）及び２）の結果を審議する。 34 ５）審査終了後､各委員は参加者の技術点数を投票用紙に記入し、投票する｡ ６）機構は各参加者が入札した価格と機構設定の予定価格により、各参加者の価格点を決定 する｡ ７）機構は、上記５）と６）の合計点を算出し、最高点を得た参加者を選定する。結果につ いては速やかに参加者全員に通知する。 最高点を得た者が入札に際し著しく低い価格の入札があった場合には、機構が調査を実 施し、契約の履行ができないと認められる場合には、その者と契約を結ばず、次点の者 と契約を結ぶこととする。また、次点の者についても同様とする。 １６ 窓口連絡先 独立行政法人 医薬品医療機器総合機構 安全第一部 医療機器安全課 電話：03-3506-9030 城谷 真理 E-mail：[email protected] 35 別紙1 業務運用方針 ※本資料に記載した業務運用方針は、実際の運用を示すものではないことに留意すること。 データシステム構築及び患者登録システム運用のための運用システム設計においては、 本業務運用方針に則り実行できる様な設計とすること。 0 業務運用方針 一覧 1. 患者登録システム参加 2. 患者同意の取得 3. データ入力に関する教育 4. データ入力 5. データ入力サポート体制（ヘルプデスク等） 6. データの品質確保体制 7. フィードバック 8. 個人情報の取り扱い 9. データ対外公表 用語 実施主体（当面） 役割 管理主体 総合機構 患者登録システムの費用の負担元かつ管理責任の主体であり、運営委員会の決定内容に対して最終的な承認を行う。将来的には学会 や再生医療等製品等製販業者などが協力し、主体を総合機構から引き継いでいくことが想定される 運営委員会 アカデミア 管理主体 業界団体 運営主体...等 運営委員会は全体の意思決定機関であり、各ステークホルダーから参加者を受け入れる。アカデミア（再生医療学会、大学）を中心に、 管理主体（総合機構、厚労省）、業界団体（FIRMなど）、運営主体の各機能グループ（システム改修、データ分析、品質担保・教育、ヘル プデスク）の参加を想定している。システム登録項目の決定、データ公開請求への可否判断や範囲の指定、システム改修の可否、その 他運用方法の変更等の決定を行う 運営主体 運営主体 システム改修 運営主体が仕様を作成した上で運営委員会の判断を仰ぎ、改修内容が決まれば、システム改修を行う データ分析 アニュアルレポートの作成を行い、成果を外部に公表。分析内容によっては大学、研究機関、第三者機関との 連携を図る 品質担保・教育 医療機関のデータ入力者に向けた操作マニュアルの作成と、品質管理のため、入力データに誤りがないか確 認し、必要に応じて医療機関に指導を行う ヘルプデスク システムへの質問に対しての1次相談窓口となる。入力方法、パスワード忘れなど回答可能な範囲の問い合わ せの際はその場で対応し、高度な知見が必要な場合は、管理主体や運営委員会等に諮りつつ適宜回答を行う 再生医療等製品 製販業者 再生医療等製品 製販業者 再生医療等製品を製造販売する企業。 1 １．患者登録システム参加 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ 運営主体が病院用、個人用の患者登録システム参加申請書類（Excel等）のフォーマットを作成 運営主体が患者登録システム参加申請書類をデータシステムの認証が不要な画面（ログイン前の画面）にアップロード 医療機関が申請書類をデータシステムよりダウンロードし記入する 医療機関が記入済申請書類とIRB承認書類を提出する 運営主体が記入済申請書類とIRB承認書類の内容を確認し、記入済申請書類の内容をデータシステムに登録する 医師・看護師がID/パスワード発行のための申請書類をデータシステムよりダウンロードし記入する 医師・看護師が記入済申請書類を提出する 運営主体が記入済申請書類の内容を確認し、記入済申請書類の内容をデータシステムに登録する 運営主体が医療機関の医師・看護師等の個人宛にデータシステム利用のためのID/パスワードを発行・郵送する 医師・看護師等が発行されたID/パスワードを用いてデータシステムにログインする 医療機関 医 療 機 関 の 登 録 パ ス ワ ー ド 発 行 運営主体 再生医療等製品製販業者 データシステム ①申請フォーマット（病院用）作成 ③申請書類をダウンロード・記入 ④記入済申請書類と IRB承認書類を提出 ②申請書類をHP上に公開 ⑤申請書類の内容を確認し 申請書類の内容を データシステムに登録 利用機関登録 ①申請フォーマット（個人用）作成 ⑥申請書類をダウンロード・記入 ②申請書類をHP上に公開 ⑦記入済申請書類をアップロード ⑧申請書類の内容を確認し 申請書類の内容を データシステムに登録 ID/ 医 師 ・ 看 護 師 等 の 管理主体 利用者登録 ⑨ID/パスワードを発行・郵送 ⑩ID/パスワードを用いてログイン 個人ログイン 2 １．患者登録システム参加の論点と現状仮説 個人（医師・看護師等）ごとに運営主体がデータシステムに登録を行い、個人単位でID/パスワードの管理を行う 入力者を明確にするため個別の医師・看護師ごとに登録を行い、パスワードとIDを発行する。 パスワードは3ヶ月など、一定期間ごとに変更を求めてID/パスワードの使い回しを避ける。但し、使用していない期間が長期 に亘る場合には自動的に失効するのではなく、次にログインした場合に変更する。 管理上、医師が別の医療機関に移動した際には、再度新たなID/パスワードを申請する。 個人が登録に必要な情報は下記のような一般的な情報を想定する 医療機関情報、登録本人情報、承認情報（医師/権限あり、医師/権限無し、看護師・その他/権限なし等）を登録する。 申請内容については、運営主体が医療機関コードや病院の住所等が誤っていないかなど、基本的な情報を確認する。 ID/パスワードの送付は現地医療機関宛に郵送で行うことで、登録者が在籍していることを担保する。 項目 医療機関情報 医療機関名 登録本人情報 氏名 医療機関コード 所属 郵便番号 電話番号 所在地 Fax番号 承認情報 権限の有無 e-mail セキュリティの観点から登録に用いるIPアドレスを固定することが望ましい ＩＰアドレスはセキュリティの観点からは固定することとするが、実運用上のデメリットが大きければセキュリティを確保した上 で固定しない方法を検討する。 3 ２．患者同意の取得の手順 ① ② ③ 医療機関が患者同意フォーマットを作成 医師が患者に患者同意フォーマットに基づき説明を行い、患者登録システムへの参加への患者同意を取得 医師がデータシステムに同意取得をチェックをした上で登録。同意書の原本は各医療機関で保管 医療機関 管理主体 運営主体 再生医療等製品製販業者 データシステム ①患者同意フォーマットを作成 ②患者同意を取得 ③データシステムに同意日時を 登録 同意書原本は医療機関で保管 データ登録 4 ２．患者同意の取得の論点と現状仮説 再生医療等製品使用の同意を取得する際に、患者登録システムのデータ登録に関する同意を取得する 再生医療等製品の使用前には医師が製品の説明と患者からの同意取得を行うため、その際に同時に患者登録システムへ の登録と分析を行う同意も同時に取得する。また、データシステムに登録されたすべてのデータが分析対象となる。 患者登録システムへのデータ登録の同意とともに、患者登録システムにおいて、データがデータシステム外に抽出される場 合には個人が特定されないよう処理を行った上で抽出される旨を説明文書に記載した上で同意を取得する。 患者からの申し出により同意撤回を認める レジストリへの登録は必須であるが、登録後に患者自身からの同意撤回を認める。データシステムでは同意撤回日を入力す る。 同意撤回日以降のデータ登録は行わないが、同意撤回日前のデータは削除せず分析対象とする。 同意撤回が可能な旨については、同意取得時に説明を行う。 5 ３．データ入力に関する教育の手順 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ 運営主体が患者登録システムの操作マニュアルを作成 運営主体が操作マニュアルをHP（一般に公開されている部分）にアップロード 医療機関のデータ入力者が、データ入力前に操作マニュアルによる学習を行う 運営主体が患者登録システムの教育コンテンツを作成 運営主体が教育コンテンツを用いシステム講習会にて講義を実施 医療機関のデータ入力者が、システム講習会にて講義を受講し学習を行う 2階の煩雑な入力項目について再生医療等製品製販業者が記載例等を作成する 運営主体が記載例をデータシステムに反映する 医療機関のデータ入力者が、記載例を見て学習して入力を行う 医療機関 管理主体 運営主体 再生医療等製品製販業者 システム講習会 ①操作マニュアルの作成 ③操作マニュアルを用いた学習 ②操作マニュアルの公開 ⑤教育コンテンツを用いた システム講習会 ④教育コンテンツの作成 ⑥システム講習会に出席しての学習 製品ごと（2階）部分 ⑨記載例を見ての学習 ⑧記載例をデータシステムへ反映 ⑦記載例等の作成 6 ３．データ入力に関する教育の論点と現状仮説 極力簡便なデータ入力方式を採用することで、データ入力に関する教育は最小限に留める データ入力では、入力者側の労力を軽減するため、また看護師など医師以外でも一次的な入力が可能となるよう、基本的に 非常に簡便な入力になるよう設計を行う。 独立した講習などは実施せず、下記の2点によるシステム講習とする。 • 操作マニュアル配布 （HP上にて公開） • 再生医療学会の認定医の講習会の一部としての取り扱い （再生医療学会との相談事項） 個別製品によって異なる有害事象や有効性評価など、複雑な入力が求められる場合には入力ガイドを作成する（2階部分） 個別の製品の特性によって、自由記述欄も含めて入力が煩雑となる場合、入力をサポートするため、記載例などをデータシ ステム上に表示する。その際の記載例は、製品の特性を把握している再生医療等製品製造販売業者が作成することが適当 である 7 ４．データ入力の手順 ① ② ③ ④ ⑤ ⑥ データシステムに登録された医師・看護師等が患者データを仮入力 承認権限を持つ医師が入力内容を確認した上で承認することでデータシステムにデータ登録 副作用・不具合が発生した場合は医師・看護師等がデータを入力 副作用・不具合のデータ入力があった製品は、副作用・不具合アラートメールをシステムから再生医療等製品製販業者に自動発 信 定期的に経過観察が求められる製品は、定期調査の時期が近づくと、システムからアラートメールを入力医師に自動発信 定期検査の時期から一定期間経過しても入力がない場合は未入力アラートメールを入力医師に自動配信 医療機関 管理主体 運営主体 再生医療等製品製販業者 データシステム データ入力時 ①データシステムに登録された メンバーに よる仮登録 データ仮登録 ②承認権限を保持するメンバーに よる承認 データ登録 副作用・不具合が発生した 場合 ③副作用・不具合情報の登録 ④副作用・不具合アラートの受信 副作用・不具合 アラート通知 定期的な経過観察の時期が 近づいた場合 ⑤定期検査時期アラートの受信 ⑥未入力アラートの受信 定期検査時期の アラート通知 定期検査の 未入力アラート通知 8 ５．データ入力サポート体制（ヘルプデスク等）の手順 ① ② ③ ④ ⑤ 医療機関等からの問合せ受付窓口は運営主体が設置するヘルプデスクに一元化する。 医療機関等からの問合せは、(a)データ入力に係るシステムの操作方法・障害発生等に関する問合せ、(b)再生医療患者登録シス テム整備事業・法制度・安全対策業務等に関する問合せに分類できる。ヘルプデスクが問合せ内容を分類し、ヘルプデスクが回 答を検討する。(b)は内容により、ヘルプデスクから管理主体（当面は総合機構を想定）に相談し回答を検討する。管理主体は内 容により運営委員会等に相談する。 医療機関等への回答は、ヘルプデスクから行う。ヘルプデスクにて、問合せ管理表に問合せ内容、対応結果等を記録する。 ヘルプデスクにおいて、良くある問合せをFAQにまとめ、管理主体のホームページ等に掲載し情報提供する。 ヘルプデスク及び管理主体は問合せ管理表を定期的に分析し、事業・制度・業務の見直しや、システムの改修を検討する。 医療機関 運営主体 管理主体 運営委員会等 再生医療患者登録システム整備事業、 法制度、安全対策業務等に関する問 合せのうち、ヘルプデスクが回答でき ないもの 問合せ 問合せ分類 相談（内容により） 回答 回答検討 相談回答 回答 回答確認 9 ５．データ入力サポート体制（ヘルプデスク等）の論点と現状仮説 運営主体のヘルプデスクが医療機関等からの問合せを一元的に受付ける。事業・法制度・業務に係る問合せもヘルプデスクが回 答するが、内容により管理主体が回答を検討 データシステムの操作方法の質問やシステム障害報告の受付窓口として、運営主体がヘルプデスクを設置する。医療機関 等からの問合せはヘルプデスクを窓口として一元化し、問合せ内容・回答状況の管理をヘルプデスクにて行う。 再生医療患者登録システム整備事業、法制度、安全対策業務等、高度な業務知見を必要とする問合せは、基本的にヘルプ デスクが回答するが、内容により回答が難しいものはヘルプデスクからエスカレーションを受け、管理主体が回答を検討する。 管理主体は、回答の検討に際し必要に応じ運営委員会等に相談する。 ヘルプデスクの回答状況について、定期的に運営主体が管理主体に報告する。 ヘルプデスクの問合せ対応に最低1名程度の専用要員が必要 ヘルプデスクにおける電話での問合せ受付時刻を仮に平日9:00～17:00と設定すると、ヘルプデスクは1名程度の専用要員 が必要となる。土日祝日、早朝・夜間の電話対応も行う場合には、さらに人員が必要となる。 問合せはメールのみで受け付け、回答は翌営業日までとする等の方法で体制を絞ることも考えられるが、利用者の利便性を 考慮すると望ましくない。少なくともシステム稼働後しばらくの間は、電話での受付体制を整備し、問合せの発生状況に応じ て体制の増減を検討するべきではないか。 10 ６．データの品質確保体制の手順 ① ② ③ ④ ⑦ ⑧ ⑨ ⑩ 運営主体がデータマネジメント（DM）の手順書、計画書、チェック内容の素案等を作成（⑤も同様） 再生医療等製品製販業者がチェック内容を確認（⑥も同様） 運営主体がロジカルチェック内容をデータシステムに反映する 医療機関のデータ入力者がデータシステムにデータを入力し、入力データに対してシステムからのロジカルチェックがかかる 運営主体がロジカルチェック後の登録データを、マニュアルチェック内容に基づいてチェックを行う マニュアルチェック登録データに不備がある場合、運営主体がクエリを発行する 医療機関がクエリへの回答をデータシステムに入力し、修正が必要な場合はデータを修正する 医療機関が登録したデータを、運営主体がマニュアルチェック内容に基づいてチェックを行う 医療機関 管理主体 運営主体 ①DMの実施内容の作成 ロジカルチェック 再生医療等製品製販業者 ②チェック内容の確認 ③ロジカルチェック内容のシス テムへの反映 Ｄ Ｍ で の チ ェ ッ ク 手 順 システムでの ロジカルチェック ④データ入力（手順は４に従う） ⑤マニュアルチェック内容の作成 マニュアルチェック、クエリ ⑥マニュアルチェック内容の確認 ロジカルチェック後 登録データ ⑦マニュアルチェック内容に基づく 登録データの確認 ⑧クエリ発出 クエリ ⑨回答及び/又はデータ修正 マニュアルチェック後 登録データ ⑩回答及び/又は修正内容の確認 チ施 ェ設 ッ監 ク査 手 順で の 医療機関 管理主体 運営主体 データシステム 再生医療等製品製販業者 データシステム ⑪監査手順書/計画書作成 ⑬施設監査への対応 ⑫施設監査 11 ６．データの品質確保体制の論点と現状仮説 データマネジメントでのデータチェックの実施方法 （データマネジメント業務のうち、ロジカルチェック、マニュアルチェック、クエリに関する実施方法を以下に示す） • ロジカルチェックによる確認 データ項目が製品別に異なるため、ロジカルチェックも製品別に検討が必要。ロジカルチェックの検討は医学的な知見が必 要なものもあり、運営主体がロジカルチェック内容を作成した上で再生医療等製品製販業者が確認を行う。 • マニュアルチェックによる確認、クエリ ロジカルチェック同様、検証項目・検証方法は製品別に検討する必要があり、運営主体がロジカルチェック内容を作成した上 で再生医療等製品製販業者が確認を行う。 マニュアルチェック後の登録データについて、再生医療等製品製販業者が内容の不備を発見した場合には、その旨の指摘 を運営主体に対して行い、運営主体から医療機関に対して再度クエリ発行などを行いデータを修正する。 施設監査でのデータチェックの実施方法 • 施設監査による確認 運営主体が監査計画書・手順書を作成し、年に1～2施設を訪問することで監査を行う。監査を行うのは運営主体内でも本シ ステムに関するDM業務、ヘルプデスク業務などに携わっていない第三者が行うこととする。 監査方法、訪問者等の詳細は運営委員会にも諮ることとする。 データマネジメント業務（ロジカルチェック、マニュアルチェック、クエリ） ロジカルチェック システムによる自動チェック 【チェック項目の一例】 ○単純項目チェック ・必須登録項目の空白 ・数値が入るべき項目に文字 ○複数項目チェック ・登録値の上下関係 ・日付の前後関係 ○異常値のチェック ・年齢（200歳 等） ・単純誤り（男性の妊娠 等） マニュアルチェック、クエリ 運営主体による目視での確認 【チェック項目の一例】 ○登録項目内での矛盾点の確認 施設監査 医療機関の入力体制・運用等を訪問して監査 【チェック項目の一例】 ○入力体制 ・データ入力者、入力情報確認者 ・ID/パスワードの管理方法 （なりすまし防止） ○データ入力の正確性等 ・診療録、手術記録等との整合確認 ○運用 ・同意書の取得・管理状況 ・登録情報の自己チェック方法 ・登録情報の利活用方法 12 ７．フィードバックの手順 ① ② 医療機関は、リアルタイムに自施設の登録内容と全国の集計情報が閲覧できる 再生医療等製品製販業者は、リアルタイムに自社製品の市販後調査に係る結果が閲覧できる 医療機関 管理主体 運営主体 再生医療等製品製販業者 データシステム 医療機関 登録データ ①データ閲覧 自施設の登録内容と全国統計の結果 再生医療等製品製販業者 ②データ閲覧 登録データ 自社製品の市販後調査に係る情報 13 ７．フィードバックの論点と現状仮説 医療機関には、自施設の登録内容と全国統計の結果は閲覧可能とする 再生医療等製品製販業者には、自社製品に関わる市販後調査に必要な情報は全て閲覧可能とする 医療機関は自施設の登録したデータについては全てリアルタイムで閲覧可能とすることに加え、その他の医療機関の結果 の統計値もリアルタイムに閲覧可能とする。 自社製品の市販後調査にかかる項目について、データシステムに登録された情報はシステム上で企業がリアルタイムに ローデータを閲覧できるようにする。その際、セキュリティ対策のため企業側からアクセス可能なIPアドレスを固定し、端末認 証の仕組みを採用する等の手法でセキュリティを担保する。 上記の医療機関、再生医療等製品製販業者以外が、どの程度調査項目の設定と閲覧権限を与えるかは、運営委員会で精査する 本システムを活用し、どの程度の項目の収集を行うか、また収集した項目の閲覧権限をどの程度与えるかは、分析の目的 等を明確に申請元が示した上で、運営委員会がその是非について判断を行う。 提供されるデータは世間一般に公開されることが予測されるため、どのようなで形式でデータが公表されるのかまでの審査 が必要である。 14 ８．個人情報の取り扱いの論点と現状仮説 医療機関は患者に対して、本システム登録のための任意の番号（医療機関管理ID）を付与する 本DBではデータシステム登録時に発行されるDB固有の患者IDにより、情報の紐付をする。 個人を特定しうる電子カルテ等のIDは入力しないことを原則とする。 データベース側では患者情報の取り扱いをせず、患者個人との紐付は医療機関が行う 運営主体・企業側など、医療機関以外では患者特定は不可とする。 システム固有IDと患者ID（電子カルテ番号等） の対応表は医療機関が管理 システム 固有患者ID 運営主体・企業 患者ID 医療機関 他の情報との組み合わせで個人が特定されることを避けるため、集計に含まれる個人の数が5人以下の場合、秘匿処理を行う システム 固有患者ID 患者数が少ない場合は、秘匿処理（5名以下や一定割合以下などの場合は数値を表示させない等）をすることによって個人 の特定をさせない。 利用規約で、個人を特定する可能性がある行為（他の情報との組み合わせ等）について禁じる 目的外利用の禁止、個人を特定する可能性がある分析の禁止等を利用規約に定める。 15 ９．データ対外公表の手順 ① ② ③ ④ ⑤ ⑥ 運営主体がアニュアルレポートの項目を検討 運営主体が患者登録システムに登録されたデータを集計 運営主体がアニュアルレポートを作成 管理主体がアニュアルレポートの内容を承認 運営主体がアニュアルレポートをHP上に公開する 患者・国民・医療機関・企業などがアニュアルレポートをWeb上から自由に取得可能とする 医療機関 管理主体 運営主体 再生医療等製品製販業者 データシステム ①アニュアルレポートの項目検討 ②登録されたデータの集計 ④アニュアルレポートの承認 登録データ ③アニュアルレポートの作成 ⑤アニュアルレポートをHPに公開 16 ９．データ対外公表の論点と現状仮説 データシステムを用いて収集したデータについて、公開可能なものを精査した上で一般向けの情報公開を行う データシステムで得られた情報の中で、治療効果等に関係の無い男女別、年齢別、使用製品別の症例数などを公開していく。 公開情報の受け取り手としては、まだ患者登録システムに参加していない医療従事者や、患者、国民などが想定され、再生 医療等製品の使用実態についての普及啓発とする。 アニュアルレポートの分析イメージ（NJRのアニュアルレポートより抜粋） 左：医療機関の実施件数別の構成割合 右：患者の年齢別の構成割合 17 ■別紙2 機能要件 ※［凡例］ ○：登録・更新・閲覧・処理等、 ▲：閲覧のみ、 ―：利用しない No 分類１ 分類２ 医療機関 利用者※ 再生医療等製 総合機構 品製販業者 ○ ○ 概要 運営主体 ○ システム 自動処理 ― ・ID/パスワードで利用者を認証する機能。 1 認証 ログイン認証機能 ○ 2 IPアドレス認証機能 ― ― ― ― ○ ・端末の接続元IPアドレスでアクセス制御する機能。 3 ポータル ポータル画面 ○ ○ ○ ○ ― ・データシステムへのログイン後、利用者が確認する画面。 ・利用者が利用可能な機能リスト、運営主体からのお知らせ、データ修正等に係るメッセージ等を表示可能なこと。 4 データ入力 患者情報新規入力機能 ○ ― ― ― ○ ・再生医療製品使用患者情報等を新規に入力する機能。 ・承認権限を持たない医師・看護師等が登録した患者情報は「仮登録」状態とし、承認権限を有する医師が当該情報を 承認した場合にデータが「登録」されるような仕組みを有すること。 ・新規に患者情報を登録した場合には、データシステムで患者IDを自動発番すること。 ・データ登録項目は「別紙3_情報・データ要件」を参照のこと。 ・本調達は仕様書「図2 データ構造イメージ」の「全ての製品に必須とする共通の基本項目」のみを構築対象とするが、 「製品や診療領域ごとに特有の項目」を構築する際に大規模な改修が発生しないよう、データ構造や画面等を工夫すること。 5 患者情報追加・変更入 力機能 ○ ― ― ― ― ・同一患者の経過情報等、既入力情報の追加・変更を行う機能。 ・医療機関が患者情報を患者ID、性別、年齢、手術情報、副作用・不具合情報等で検索し、情報の追加・変更の 対象患者情報を特定できること。 ・患者単位、症例単位等で次に何の情報を入力すべきかを一覧表示する等、画面で容易に把握可能とすること。 6 患者同意撤回登録機能 ○ ― ― ― ― ・患者から患者登録システムへの参加に関する同意の撤回の意思表示があった場合に、医療機関が、当該患者の 同意撤回日の情報を患者登録システムに登録する機能。 ・同意撤回日後は、同意を撤回した患者の情報はシステムに登録しない。 ・同意撤回日前のデータはシステムから削除しない。 7 アラート発信機能 ― ― ― ― ○ ・定期的に経過観察が求められる製品は、所定の期間が過ぎると、未入力アラートを入力医師のe-mailに自動発信すること。 ・副作用・不具合が発生した製品は、副作用・不具合アラートメールをデータシステムから再生医療等製品製販業者に 自動発信すること。 ・定期的に経過観察が求められる製品は、定期調査の時期が近づくと、データシステムからアラートメールを入力医師に 自動発信すること。 8 ロジカルチェック機能 ― ― ― ○ ○ ・入力情報に必須項目不足等の誤りが無いか自動でロジカルチェックを行い、誤りがあればエラーを表示する機能。 チェック項目等のロジカルチェックの内容は設計時に決定する。 ・チェック項目等のロジカルチェックの内容は製品ごとに運営主体が登録可能なこと。 9 マニュアルチェック（クエ リ）機能 ○ ― ― ○ ○ ・登録された情報について、運営主体がマニュアルチェックを行い、誤りが見つかった場合等に、運営主体が医療機関に対し 当該データの修正を依頼する（クエリ）ための機能。 ・運営主体が医療機関に対し修正を依頼する際、誤りが見つかった情報を特定し修正依頼内容をコメント記載した メッセージを医療機関に送信可能なこと。 ・メッセージは医療機関のポータル画面に表示するとともに、入力医師のe-mailに自動発信すること。 ・医療機関によるデータ修正後、運営主体が修正内容を確認し、問題が無ければ当該データを確定状態にすること。 ・クエリの発出から医療機関によるデータ修正、運営主体確認後のデータ確定までの一連の経過及び結果は、 監査証跡として記録を残すこと。 10 検索・分析 登 録 情報 検索 ・ 閲 覧・ データ抽出機能 ○ ○ ― ○ ― ・登録された情報について、医療機関名、提出日、再生医療製品名等で検索する機能。 ・検索結果はデータをCSV形式で出力可能とすること。 ・検索条件は、「全ての製品に必須とする共通の基本項目」及び「製品や診療領域ごとに特有の項目」を想定しているが、 本調達においては、「全ての製品に必須とする共通の基本項目」での検索を可能とすること。 ・医療機関、再生医療等製品製販業者は自組織のデータのみ閲覧及びデータ抽出可能とすること。 ・再生医療等製品製販業者に対して、データ項目の単位で閲覧及びデータ抽出可否を設定できること。 ・データを抽出する場合には抽出目的により一部情報を抽出しないまたは一部情報に秘匿処理を行う等、データに必要な 対策を施した上で抽出することが可能なこと。 11 簡易集計機能 ▲ ― ― ― ○ ・全国の医療機関における患者情報等の登録状況等について、集計情報をデータシステムで自動計算すること。 ・医療機関がデータを閲覧する際、自組織のデータと合わせて、全国の集計情報を閲覧可能とすること。 ・集計情報は以下の例のように、患者情報の登録数など簡易に算出可能なものを対象とすることを想定しているが、 詳細は設計時に決定する。 ［集計情報の例（想定）］ 患者背景（性・年齢等）別登録数、製品別登録数、副作用・不具合等の発生数、死亡数 等 ・患者数が少ない場合等は、集計結果に秘匿処理（5名以下など一定値以下の場合は数値を表示させない等）を施すことを 可能とすること。秘匿処理の実施有無や秘匿処理を行う閾値は設定により変更可能とすること。 12 管理機能 申請書類等登録・参照 機能 ○ ― ― ▲ ― ・患者登録システムへの参加に際し、医療機関が患者登録システム参加申請書類及びIRB承認書類を、 医師・看護師がID/パスワード発行のための申請書類等を、それぞれアップロードするための機能。 ・医療機関及び医師・看護師は、自身がアップロードした患者登録システム参加申請書類等を閲覧可能なこと。 ・運営主体は、アップロードされた患者登録システム参加書類等を閲覧可能なこと。 13 利用機関管理機能 ▲ ▲ ― ○ ― ・運営主体が利用機関（医療機関、再生医療等製品製販業者）情報の新規登録・削除等を行う機能。 ・利用機関情報を新規登録した場合、利用機関IDを発行すること。 ・利用機関情報を削除した場合は削除フラグを立てることとし、データそのものは削除しないこと。 14 利用者管理機能 ― ― ― ○ ― ・運営主体が利用者情報の新規登録・削除、アクセス権、承認権限の管理等を行う機能。 ・利用者情報を新規登録した場合、利用者IDとパスワードを発行すること。 ・利用者の氏名等の個人情報や利用者IDとの対応表等は暗号化して保管しシステム画面・処理上は利用者IDのみを利用する など、 限られた権限を持つ者以外は利用者の個人情報の特定ができないような仕組みを設けること。 ・パスワードのポリシー（桁数、文字種等）は設定により変更可能とすること。 ・利用者情報は、利用機関情報（利用者の所属組織）と紐づけて登録することが可能なこと。 ・利用者情報を削除した場合は削除フラグを立てることとし、データそのものは削除しないこと。 ・利用者のパスワードについて前回変更時からの期間を管理し、一定期間経過時には変更するよう、 自動で利用者に促す仕組みを有すること。 ・上記の仕組みに相当し、患者登録システムが求める利用者管理及びセキュリティ要件等への対応が可能であれば、 既存のアカウントシステムの利用も可とする。 15 利用者情報変更機能 ○ ○ ○ ― ― ・利用者が自身の登録情報、パスワード等を変更するための機能。 16 マスタ管理機能 ― ― ― ○ ― ・利用者情報、再生医療等製品製販業者情報、製品情報等のマスタについて、追加・更新・削除等を行う機能。 ・システムで作成するマスタの詳細は、設計時に検討する。 17 ヘルプ登録・表示機能 ▲ ▲ ▲ ○ ― ・画面単位及びポータル画面にヘルプを登録及び表示する機能。 ・画面の操作方法等を記載したPDFファイルを運営主体が作成し、アップロードすること。 ・運営主体が作成する、利用者からの良くある問合せ及び回答をまとめたFAQを登録及び表示できること。 18 監査証跡取得機能 ― ― ― ― ○ ・データシステムの処理等について、利用者ID、IPアドレス、利用機能、アクセス日時、処理（登録／修正／削除／閲覧／承 認）、 修正前後のデータ、クエリの記録等の、監査証跡を取得する機能。 ・記録した監査証跡は、CSVで出力可能とすること。出力する監査証跡は処理日時、利用者ID、処理内容、処理対象データ、 処理結果等をタブ区切り等で分割する等、監査証跡を分析する際に分析しやすい構成とすること。 19 監査証跡参照機能 ▲ ▲ ― ▲ ― ・監査証跡を画面上で参照する機能。 ・運営主体は全ての監査証跡を参照可能とすること。 ・医療機関及び再生医療等製品製販業者は、自組織の関連する監査証跡のみ参照可能とすること。 別紙3 情報・データ要件 ※本資料に記載した項目はあくまで現時点の案であり、今後変更する可能性がある。 項目数は最大で50項目程度と想定すること。 0 データ項目と入力方法（案） （階層） 1：共通項目（1階部分/今回の対象内） 2：個別項目（2階部分/今回の対象外） （入力方式） 自動：システムで自動で入力され入力者は入力しない ラジオボタン：複数（最大10程度）から一つを選択 プルダウン：複数（必要に応じて管理側または医療機関で追加可能）から一つを選択 チェックボックス：複数の中から複数を選択 フリー：自由に記述（但し、明らかに誤った数値はエラーとする） 整理 項目 階層 入力方式1 番号 1 患者ID（データシステム固有） 1 自動 1 フリー（西暦年月日） 2 生年月日 年齢 1 自動 3 性別 1 ラジオボタン 4 患者情報 フリー 5 既往歴 フリー 6 合併症 1 フリー（西暦年月日） 7 同意取得日 1 フリー（西暦年月日） 8 同意撤回日 入力方式2 データシステムで固有の患者IDを自動割付 入力完了時点で年齢が表記されるように設定 生年月日により自動入力 男性/女性 ICDコードから選択 ICDコードから選択 同意が取得された場合は、同意取得日を入力する 同意撤回時に入力し以降はデータを入力しない あり/なし（ありの場合フリー入 力） 9 アレルギー 1 ラジオボタン/フリー 10 身長 11 体重 12 原疾患 1 フリー 1 フリー 1 フリー フリー（西暦年月日）＋ 1 （○日後、○週後、○ヶ 月、○年後） 1 フリー（西暦年月日） 1 プルダウン 運用側でマスタ作成 手術情報 13 観察日 14 使用日または使用開始日 15 販売名 備考 初回のみでなく、観察ごとに入力される 本項目に紐付いた形で2階建て部分が引用される 1 データ項目と入力方法（案） 整理 番号 項目 階層 入力方式1 16 有害事象の発生の有無 1 ラジオボタン 17 有害事象名 1 フリー 18 因果関係評価 1 ラジオボタン 副作用等 （共通） 一部、再 生医療等 製品不具 19 重篤性 合感染症 症例報告 書の項目 から引用 （薬食安 発1002第 20 発現日 20号参 21 転帰日 照） 22 転帰 23 有害事象に対する意見 24 有害事象に対する処置等 25 26 27 28 その他 不具合等の発生有無 不具合名 発生日 死亡日 29 調査終了日 1 ラジオボタン 入力方式2 あり/なし 備考 調査期間中の有害事象の発生の有無について、入力 する 「関連あり」、「おそらく関連あり」、 「関連があるかもしれない」、「関 連なし」又は「不明」（薬食安発 1002第17号参照） 「死に至るもの」、「人体の構造 又は機能の永続的な障害に至 るもの」、「生命を脅かす疾病又 は障害に至るもの」、「入院又は 入院期間の延長が必要となるも の」、「先天異常又は胎児の死 亡若しくは機能不全を来すもの」 又は「その他の医学的に重篤な 状態」 （薬食安発1002第17号 参照） 1 フリー（西暦年月日） 1 フリー（西暦年月日） 副作用・感染症の転帰日を入力 「死亡」、「未回復」、「軽快」、 1 ラジオボタン＋フリー 「回復」、「その他」（記入欄）（薬 食安発1002第17号参照） 1 フリー 当該不具合に関する診断、因果関係評価又は関連が あると考えられるその他の問題について担当医の意見 を記載する（薬食安発1002第17号参照） 放射線療法/輸血/手術/麻酔/ 1 ラジオボタン＋フリー 医薬品（記入欄）/その他（記入 欄） 1 ラジオボタン あり/なし 1 フリー 1 フリー（西暦年月日） 1 フリー（西暦年月日） 1 フリー（西暦年月日） 調査が終了した日、又は脱落（同意撤回、死亡等）した 日を入力する 2