電子カルテシステム調達仕様書非機能要件 · 2019-06-25 · 電子カルテシステム調達仕様書非機能要件要求仕様 2 1 2 2 管理者権限で更新を伴う操作を行う場合は、確認画面を表示できること。

電子カルテシステム調達仕様書　非機能要件

非機能要件1 基本的要件1 1 システム全体1 1 1 システムの位置付け

1 1 1 1システム創出効果として、当院の掲げる「病院理念」及び「病院憲章」を実現するためのツールとなり得ること。

1 1 1 2現在当院が進める「医療の質推進プロジェクト」を実行するための仕組みとして構築すること。

1 1 1 3厚生労働省が進める「地域医療ビジョン」に対応すること。

1 1 1 4当院が目指している「第三次救急医療機関」としての医療業務の運用にもシステム対応できること。

1 1 2 システムの安全確保

1 1 2 1「医療情報システムの安全管理に関するガイドライン」に基づき、必要な対策を完全実施すること。

1 1 3 システムの導入範囲

1 1 3 1共通システムは運用後の機能拡張に備え、フルオプションでの導入とすること。

1 2 標準仕様の採用1 2 1 情報の相互運用性

1 2 2 1電子カルテシステムと部門システム間、他院との情報連携等、情報の相互運用に関する標準（ＩＨＥ、HL7、DICOM）に準拠したシステムであること。

1 2 2 情報の標準化

1 2 2 1システムで取り扱う医療情報は、業界の標準規格や標準フォーマット（ICD-10、HOT、JLAC10、JJ1017等）が採用されたシステムであること。

1 3 信頼性の確保

1 3 1電子カルテシステムを始めとし、共通システムおよび部門システムで取り扱う情報は、重要な資産として管理が可能であるよう以下の要件を考慮し、信頼性の高いシステムを構築すること。

1 3 2 完全性

1 3 2 1情報資産の正確さを確保するため、情報の改ざんが把握・追及可能な仕組みを有していること。

1 3 3 可用性

1 3 3 1情報資産を利用者が利用したいタイミングでアクセスできる仕組みを有していること。

1 3 4 機密性

1 3 4 1情報資産は、許可された利用者に公開され、第3者が容易に情報にアクセスできないよう考慮されたシステムであること。

1 3 5 保全性

1 3 5 1故障が発生しにくい考慮がされており、かつ故障や異常が発生した場合はいち早くそれを検知・修復する仕組みを有していること。

1 4 利用者情報・患者情報の一元化1 4 1 利用者基本情報

1 4 1 1利用者権限及び職員情報を総括的に管理するため、利用者基本情報を統合管理する利用者基本マスタを構築すること。

1 4 1 2

利用者基本情報は、病院独自で導入した個別システムを含む、全てのシステムから閲覧可能であること。また、各個別システムにて独自の権限・設定が必要な場合、拡張が可能であること。共通システムのデータベースで対応困難である場合、共通システムと常に連携し、リアルタイムで更新されるデータベースを独立して構築すること。

要求仕様

非機能要件１．基本的要件 1

1 4 1 3利用者基本情報は、追加、修正、削除が統合的に実施できること。（版管理ができること。）

1 4 1 患者基本情報

1 4 1 1

患者基本情報は、病院独自で導入した個別システムを含む、全てのシステムから閲覧可能であること。共通システムのデータベースで対応困難である場合、共通システムと常に連携し、リアルタイムで更新されるデータベースを独立して構築すること。

1 5 受託者の要件

1 5 1当院の効率的なIT投資と費用対効果の最大化のために、技術の最適な組み合わせと各種ソリューションをコーディネートできること。

非機能要件１．基本的要件 2


非機能要件2 セキュリティ要件2 1 システムの利用権限2 1 1 権限設定

2 1 1 1

職員毎に、ゲストユーザを含む利用者権限設定ができるようにすること。ただし、利用者IDについては、現行の電子カルテシステムの利用者IDからの移行を考慮し、設定すること。なお、京都市立病院においては、利用者IDと職員番号を別々に管理する必要があることから、これらの情報を継続して管理できる仕組みとすること。

2 1 1 2利用者ID以外に職種や研修属性等のフラグを設定できるようにすること。

2 1 1 3職種の追加に柔軟に（SE作業等を必要とせずに）対応できるシステムとすること。

2 1 1 4

システムへのログインのための認証においては、2要素認証を採用し、その中で、職員の負荷が少なく、かつ成りすましの難しい認証方式を提案すること。なお、バイオメトリクスを採用する場合には、手袋装着時等でバイオメトリクスが使用できない場合の対策もあわせて提案すること。

2 1 1 5システムの利用者の管理を効率化するため、各利用者を職種、職位、管理単位別にグループ化できること。

2 1 1 6利用者またはグループ単位で、利用できる機能や資産、システムを利用できる日時・時間帯、機能毎等に参照権限、更新権限を設定できること。

2 1 1 7

外注業者の権限設定等、多くのメンバが頻繁に権限設定を見直す必要があることを想定し、権限のメンテナンスが容易となる仕組みを提案すること。外注業者を含めて全ての利用者情報を人事情報とリンクした一元管理できる仕組みにすること。

2 1 1 8利用者とその利用者の属しているグループの権限が異なった場合は、原則として利用者個人の権限が優先するような仕組みとすること。

2 1 1 9システムへのログインのための認証は端末と独立した機能とし、本機能によって端末が特定されることがないようにすること。

2 1 1 10権限と機能のマトリクスを作成し、権限設定の状況を一覧できるようにすること。

2 1 2 管理者の権限

2 1 2 1管理者の権限を持つ者が以下の操作を容易に行えるようにすること。また、その結果については、画面上で分かりやすく表示し、必要に応じて印刷できること。

利用者及びグループの登録、変更、休止、削除等

登録されている利用者のシステム利用状況の把握（認証状況、システム利用時間、使用端末、中断状況、操作内容等）許可された権限別の利用者及びグループの把握

一定期間システムを利用しない利用者の把握

利用者が中断したシステムの処理の取り消し

システム動作に支障がない範囲の利用者のシステム処理の強制中断

システムの管理権限の設定、変更等

システムの利用権限付与状況の一覧形式での表示

端末の利用状況（最終起動及び利用日時、起動時間等）の把握等

利用者が操作できる端末の限定

要求仕様

非機能要件２．セキュリティ要件 3


要求仕様

2 1 2 2管理者権限で更新を伴う操作を行う場合は、確認画面を表示できること。

2 1 3 利用者権限機能

2 1 3 1利用者の特定を行うとともに、認証を完了していない利用者のシステム利用を禁止できるようにすること。

2 1 3 2利用者が一定回数認証に失敗した場合に、当該の利用者IDを一時的に停止できるようにすること。

2 1 3 3利用者が一定時間離席（非操作）となった場合に、表示されている内容を隠し、再度の認証を行わない限り操作不可にすること。また、管理者権限で、この時間の設定及び機能の利用有無の設定ができるようにすること。

2 1 3 4利用者が認証に成功した場合は、前回の認証成功日時、それ以降の認証失敗回数及び前回ログインした端末の設置場所を画面に表示できる、もしくはログとして出力できるようにすること。

2 1 3 5共通システム及び部門システムの利用者権限を統合し，集中的に管理できること。また，人事システムＤＢと連携が可能なこと。

2 2 セキュリティ監視2 2 1 セキュリティ監査ログに係る機能要件

2 2 1 1セキュリティ監査ログとして以下の内容を記録できるようにすること。

認証に失敗したシステム及び利用者とその端末

処理やアクセスに失敗したシステム名、その原因

管理権限を持つ者の操作内容

セキュリティ属性（権限設定等）の変更に関すること

資源の利用に関するエラーイベント

重要な資源へのアクセス要求

ハードウェアのエラー及び警告メッセージ

端末の強制電源断の情報

その他、必要となる項目

2 2 1 2セキュリティ監査ログには、最低限以下の情報を含み、それぞれのログで発生日時等の基本情報を統一し、一貫した監査ができるような形で記録すること。

発生端末、発生場所、種類、利用者ID、処理結果

システム及びサービスの名称等（ユーティリティ含む）

2 2 1 3一度記録されたセキュリティ監査ログは、改ざん等が不可能な仕組みで保存すること。

2 2 1 4セキュリティ監査ログは、任意の項目・キーワード等で検索、一覧表示が可能なようにデータベースとして保存する等の処理を行うこと。

2 2 1 5セキュリティ監査ログの収集を監視し、システム上致命的なログが発生した場合はアラーム等で管理者権限を持つ者に通知できるようにすること。

2 2 1 6セキュリティ監査ログ情報の管理・参照は、管理権限を持つ者に限定できるようにすること。

2 2 2 操作ログに係る機能要件

2 2 2 1操作ログの抽出は、以下の要件を満たすこと。



要求仕様原則として、今回構築する各システムにおける操作のログを抽出、管理できること。

操作対象は参照、登録、変更とすること。

各システムからのログとして、最低限、利用者ID、利用者氏名、操作開始時間、操作終了時間、操作種別、操作端末名、患者ID、患者氏名といった内容を含むこと。

外部媒体に抽出されるものは抽出条件が保存され抽出データが再現できるようにすること。

各システムで抽出されたログは、各システムで必要に応じて利用者の画面上で参照できること。

2 2 2 2アクセス状況検索は、以下の要件を満たすこと。

利用者ID単位、患者ID単位、端末単位に表示できること。

2 2 2 3データ出力状況検索は、以下の要件を満たすこと。

日別・時間帯別・端末別・利用者ID別等に表示できること。

月単位で出力回数の多い順に、利用者ID を表示できること。

2 2 2 4ログの分析は、以下の要件を満たすこと。

設定条件以上の操作が行われたものについて警告レポートを出力すること。その際の抽出条件として、操作時間帯、操作時間、操作回数、ログイン回数、選択患者、操作端末名、抽出データ量、患者ID、患者氏名等が設定できるようにすること。

2 2 3 セキュリティ監視に係るハードウェア

2 2 3 1各ログの保存期間は原則5年とするが、具体的な保存期間は別途協議する。

2 2 3 2操作ログは大量のデータとなることが予想されるため、一定期間を越えたものは圧縮し保存すること。また、日付単位にログファイルを生成するとともに、この単位でファイル検索ができるようにすること。

2 2 3 3サーバに障害が発生し、ログが保存できなくなった場合でも他のシステムの運用に影響を与えないこと。

2 3 機能2 3 1 完全性

2 3 1 1カルテの改ざんを防止し、客観的な検証を可能とするため、最新の暗号化技術を採用すること。

2 3 1 2システムの完全性を確保するため、利用者が入力したデータの妥当性をシステムで確実に検査し、矛盾等を生じさせないこと。

2 3 1 3保存されたデータの更新の日時、履歴、操作者等の記録及び開示（改ざん、破壊の検出を含む）により完全性を保証できること。

2 3 1 4

タイムサーバを設置し、システムで管理する機器全ての時刻はこのサーバにより常に自動同期できるようにすること。このタイムサーバは、インターネット回線等の回線経由ではなく、電波によって標準時刻を受信し、常に正しい時刻を設定できるようにすること。

2 3 1 5セキュリティ上重要なパッチプログラムがある場合、原則としてそれを適用するものとして扱うが、そのパッチプログラムの適用が業務システムに及ぼす影響を調査するために、テスト環境においてその検証ができるようにすること。

2 3 2 可用性

2 3 2 1システムの動作に関する障害の発生については、自動的にその検出を行い、その旨を運用担当者に通知できる仕組みを設けるとともに、原則としてその記録を全て残すこと。なお、詳細は運用保守要件を参照すること。



要求仕様

2 3 2 2システムのデータ及びプログラム等については、運用を停止させずに、世代管理を行いつつ確実に保存媒体にバックアップできる仕組みとすること。

2 3 2 3障害発生時にはバックアップされたデータを用いて、現状復旧ができること。

2 3 2 4広域に及ぶ大規模災害の発生を考慮して、診療行為を維持するために最低限必要な情報を京北病院または病院外のデータセンター等に保管できるように、外部出力の機能を有すること。

2 3 2 5利用者認証にあたっては、全システムで極力統一した方法とすること。特に参照系の認証についても本番系と同じにすること。

2 3 3 検証機能

2 3 3 1各システムのバックアップを行った際、バックアップの件数、データサイズ等を確認できること。

2 3 4 ウィルス対策

2 3 4 1

原則として、部門システムを含めるすべての医療情報システム端末にウィルス対策ソフトを導入し、自動的にパターンファイルの更新し常に最新のパターンファイルでの運用及び定期的なウィルス検査が実行できるようにすること。オフライン端末についても、ウイルス検索・駆除ツールを導入し、最新のパターンファイルによるウイルスの検索・駆除ができるようにすること。

2 3 4 2

本システムで導入するハードウェア及びソフトウェアの一切について、本システムの稼働に不要なサービスやポート等を全て停止する設定を行うこと。また、動作を許可していないアプリケーションプログラムが起動できないよう制限を行うこと。

2 3 4 3ウィルス対策ソフトのパターンファイル更新及び配信、クライアント管理・監視を行うためのサーバを設置すること。

2 3 4 4ウィルス対策ソフトの導入にあたっては、導入を行うソフトウェア、構成及び運用方法等について京都市立病院と別途協議を行い、その承諾を得ること。

2 3 4 5定期的なウィルス検査やパターンファイル更新の実施にあたっては、京都市立病院と協議し、業務を妨げない時間に設定すること。

2 3 5 その他

2 3 5 1職員のセキュリティ意識を高めるための研修、啓蒙資料を作成すること。ｅラーニングによる院内教育を実施可能にすること。

2 3 5 2その他、「医療情報システムの安全管理に関するガイドライン　第4.2版」に基づいて、システムとして必要な対策を行うこと。

2 3 6 クライアントPC管理

2 3 6 1Webコンソールを有すること。

2 3 6 2IT資産・ソフトウェアの資産管理ができること。

2 3 6 3アプリケーション・情報機器の稼動管理ができること。

2 3 6 4リモートコントロール機能を有すること。

2 3 6 5医療情報システム端末の定期再起動設定ができること。

2 3 6 6医療情報システム端末の操作状況を収集し、管理サーバにて集中管理できること。

2 3 6 7医療情報システム端末に操作ポリシーを設定し、操作ポリシーに反する操作を抑止し、ログ管理できること。

2 3 6 8管理サーバから操作ポリシーおよび設定などの一元管理ができること。

2 3 6 9グループごとに操作ポリシーが作成可能であること。



要求仕様

2 3 6 10メディアデバイスおよびUSBポートの使用を制限し、許可したデバイスのみが使用できること。

2 3 6 11現在導入している情報漏えい防止システム「LanScopeCat6」と同等以上の機能を有していること。



非機能要件3 設計・開発・テスト要件3 1 設計・開発要件3 1 1 設計・開発計画書の作成

3 1 1 1設計・開発計画の作成については、以下の要件を満たすこと。

本仕様書及び提案内容に基づき、作業内容定義、作業スケジュール、実施体制、レビュー実施計画、チェックポイント、開始・終了条件等を記載した設計・開発計画書を作成すること。作成後は京都市立病院と協議し、承認を得た上で成果物として納入すること。

パッケージシステムを前提とした設計・開発計画書とすること。

現行システムから次期システムに切り替わった時の業務運用の変更点を病院職員が十分理解できるよう設計書のレビューとともに変更点の説明を実施し、その実施期間を3カ月以上確保すること。

3 1 1 2設計については、以下の要件を満たすこと。

基本設計書、詳細設計書、インタフェース設計書を作成し、京都市立病院と協議の上、承認を得ること。

ユーザインタフェースの設計にあたっては、京都市立病院に対して、パッケージがインストールされた実機を用いたデモンストレーションの実施、サンプル提示等を行い、「ユーザインタフェース設計書」等に取りまとめること。運用検討においては、他病院の運用事例等に基づきWG等の場で提案を行なった上で、各業務について業務フローを作成し、成果物として納入すること。業務フローにおいては、旧来の運用との業務変更点を識別し、共通システムと部門システムとの間の利用分界について定義を行うこと。

基本処理フローのみならず、例外事象や障害等の異常事象が発生した場合の処理フローまでを含めて、考え得る全てのパターンを洗い出すこと。

京都市立病院の電源設計を踏まえ、停電時も緊急電源により全面的に診療が止まることのないような端末配置案を作成すること。

必要に応じて、病院内で使用している現行のシステムの機能や使用帳票等についても調査に協力し、その優劣点を把握するなど、業務運用の最適化を図る為の負担を惜しまないこと。

運用検討の結果、業務をスムーズに進めるためには、現行に加えて新たに要員配置することが望ましいと考えられる場合、必要人数等の情報を提言すること。

3 1 2 設計・開発スケジュール

3 1 2 1設計・開発スケジュールは別紙のマスタスケジュールに記載のスケジュールを想定する。

3 1 2 2設計業務は契約開始後から4カ月にて実施し、終了後、成果物を納品の上、中間検査を受けること。

3 1 2 3開発業務は単体テストと並行して実施することを想定しており、平成26年11月末に終了すること。

3 1 3 開発環境

3 1 3 1システム開発業務期間中の開発環境（開発用のハードウェア、ソフトウェア・開発ツール等）、作業場所（結合テスト以降は別途協議）、その他必要になる環境については、受託者の負担と責任において準備すること。

3 1 4 開発方法

3 1 4 1パッケージシステムを利用すること。パッケージの選定にあたっては、国内で十分な稼働実績を有するものを採用すること。

3 1 4 2

関連する他の業務機能及び移行データに関する改善要望があった場合は、京都市立病院と協議し、可能な限り必要となる改修等を行うこと。その際、設計書も修正し、スコープ管理を徹底すること。

要求仕様

非機能要件３．設計・開発・テスト要件 8


要求仕様

3 1 4 3法律改正により、設計・開発作業に戻りが発生した場合は、京都市立病院と協議し、必要となる改修等を行うこと。その際は設計書も修正し、スコープ管理を徹底すること。

3 2 テスト要件3 2 1 対象とするテストの範囲

3 2 1 1

電子カルテシステム及び部門システムの正常稼働を保証するためのテストとして、単体テスト（パッケージ標準部分を除く）、結合テスト、総合テスト（性能テスト含む）、受入テストを本テスト要件の範囲とする。なお、次期システムを使用した病院業務が円滑に遂行できることを確認するためのリハーサル及び稼働直前の現行システムとの並行稼働についても対象とする。

3 2 2 テスト計画の作成

3 2 2 1

受託者は、評価基準、開始・終了条件、テスト実施体制、テスト方法（使用ツール等含む）、テストデータ、テスト環境、テスト運営方法、テスト観点表について記述したテスト計画書を作成し、契約開始後4カ月以内に京都市立病院の中間検査を受けること。

3 2 2 2

テスト計画書は、全体テスト計画書の他、単体テスト（パッケージ標準部分を除く）、結合テスト、総合テスト、リハーサルについて、それぞれ作成すること。なお、病院側にて実施する受入テスト計画書の素案も作成すること。

3 2 2 3本番運用時に想定される全てのケースを洗い出し、全ケースについて網羅的にテスト実施可能となるようテスト実施計画を策定すること。

3 2 3 テスト実施体制と役割

3 2 3 1受託者は各テストを円滑に推進するために、テスト実施責任者等を設置し、京都市立病院、端末整備業者、ネットワーク整備業者、サーバルーム整備業者と作業調整、進捗報告等を行うこと。

3 2 3 2各テスト工程については、可能な限り京都市立病院に負荷を与えることなく、受託者が責任を持って作業を実施すること。

3 2 4 テストスケジュール

3 2 4 1単体テスト、結合テスト、総合テスト、受入テスト及びリハーサルは別紙のマスタスケジュールに記載の通り実施する想定である。

3 2 4 2平成26年12月末までにテスト及び結合テストを完了させ、それぞれのテスト仕様書、テストデータ、テスト結果報告書を提示の上、京都市立病院の中間検査を受けること。

3 2 4 3総合テストはテストで見つかった不具合に対する修正も含めて、稼働2カ月前までに完了させること。

3 2 4 4受入テストは並行稼働を開始する稼働1カ月前までに完了させること。

3 2 5 テスト環境

3 2 5 1

単体テスト、結合テストのために必要な機器等は受託者の負担と責任において準備すること。総合テスト、受入テスト、リハーサル期間に必要な環境については、別途調達する端末整備業者、ネットワーク整備業者、サーバルーム整備業者が準備する。

3 2 5 2

京都市立病院や病院職員の環境を用いてテストを実施する場合には、職員に対し負担をかけないよう事前に京都市立病院と協議し、その指示に従うこと。やむを得ず職員への作業依頼が必要な場合は、事前に京都市立病院に申し入れ、協議すること。

3 2 6 テスト方法

3 2 6 1単体テスト（パッケージ標準部分を除く）については、以下の要件を満たすこと。

単体テストは開発したモジュール等の単位で、プログラムが正常に動作することのテストを行うこと。また、設定したパラメータが正常に動作することのテストを行うこと。

単体テスト工程終了時については、単体テスト報告書を作成し、京都市立病院へ報告すること。



要求仕様

3 2 6 2結合テストについては、以下の要件を満たすこと。

結合テストは開発した機能及び電子カルテシステム、部門システムのデータ授受が正常に連動して動作すること等のテストを行うこと。

また、移行プログラムの結合テストのテスト結果（移行後データ）を用いてテストを行い、データ移行により電子カルテシステム及び部門システムが使用できるデータベースができていることを検証すること。

結合テスト工程終了時については、結合テスト結果報告書を作成し、京都市立病院へ報告すること。

3 2 6 3総合テスト（性能テスト含む）については、以下の要件を満たすこと。

総合テストでは電子カルテシステム及び部門システムを本番システム環境にてテストを行うことで、業務が遂行可能であること、適切にセキュリティが確保されていること、業務ピーク時を想定した状況下で性能要件を満たしていること等、電子カルテシステム及び部門システムとしての最終品質確保のためのテストを行うこと。これには、実際のデータ量を格納したデータによる性能確認テストや、薬品マスタ等の重要マスタに関しての全件発行テスト、障害を意図的に発生させて検証する耐障害性テスト等も含まれるものとする。

受託者は、総合テストを円滑に行い、必要なテストが漏れなく実施されるよう、端末整備業者、ネットワーク整備業者、サーバルーム整備業者と必要な調整、とりまとめを主体的に行うこと。

なお、業務ピークを想定したテストのため、受託者の負担と責任において負荷発生装置等を利用し、実施すること。また、総合テスト工程終了時については、総合テスト結果報告書を作成し、京都市立病院へ報告すること。テスト工程で発見された不具合については、総合テスト工程終了時までに対応を完了すること。

3 2 6 4受入テストについては、以下の要件を満たすこと。

受入テストは、総合テスト工程終了後に、京都市立病院が主導となり、業務が円滑に遂行できることを検証するテストである。実施主体は京都市立病院であるが、受託者は作業支援を行うこと。

受入テストの実施にあたっては、総合テストで使用したテスト仕様書、テストデータ、テストシナリオを全て京都市立病院に提示すること。

受入テスト期間中はユーザからの問合せを受けられるよう連絡先を京都市立病院に提示すること。

受け付けた問合せは問合せ管理表を作成して管理し、修正が必要な場合は修正を行うこと。修正にあたってはデグレードしないよう細心の注意を払うこと。

3 2 7 テストデータ

3 2 7 1テストデータについては原則受託者が作成すること。

3 2 7 2テストで使用するデータについては、各テストの計画書に使用するデータの種類等を記載し、使用したテストデータはテスト結果とともに納入すること。

3 2 7 3既存データ、外部接続先システム提供データ等を使用する場合については、その管理方法等について京都市立病院の指示に従うこと。

3 2 7 4なお、テスト時に使用した不要なデータ、ユーザID、プロセス、サービス等は京都市立病院と協議した期限までには完全に削除すること。

3 2 8 リハーサル



要求仕様

3 2 8 1

リハーサルは受託者が主導して実施すること。リハーサルの実施に向けて、以下の準備を実施すること。

・リハーサル実施シナリオ（案）作成・リハーサル目的・到達目標作成・リハーサルスケジュール作成・リハーサル実施手順作成・リハーサル環境構築・リハーサルデータ準備

3 2 8 2リハーサルは稼働1カ月前までの間に3回以上実施すること。また、前回のリハーサルで発生した課題の対応を完了させて次回のリハーサルに臨めるようリハーサル間の期間は2週間以上確保したスケジュールを立てること。

3 2 8 3リハーサルは、病院の通常業務に支障を与えないよう病院の休診日もしくは夜間帯に実施すること。

3 2 8 4リハーサルの実施にあたっては、病院職員の業務運用だけでなく、稼働当初は受託者が実施するシステム運用・保守業務についても体制に含めること。

3 2 8 5本番同様ヘルプデスクにてFAQを作成して実施に臨むこと。

3 2 8 6システム障害発生により電子カルテが停止した場合のシナリオも用意し、リハーサルを実施すること。

3 2 8 7リハーサルにて発生した問合せ、課題等は、受託者にて管理し、必要に応じて修正を含む対応を取ること。

3 2 8 8リハーサル時に使用した不要なデータ、ユーザID、プロセス、サービス等は京都市立病院と協議した期限までには完全に削除すること。

3 2 9 並行稼働

3 2 9 1本番稼働の1カ月前より以降の時期は、稼働を見据えた並行稼働期間とすること。

3 2 9 2並行稼働期間中における端末配置については、各外来・病棟において配置可能なスペースが限定されることを考慮した計画（外来におけるノートPCの活用、シンクライアント端末の活用等）を立案し、京都市立病院の承認を得ること。

3 2 9 3この並行稼働期間中に確認された重大な障害や瑕疵については、稼働までに必ず改修できる体制を整えること。



非機能要件4 移行要件4 1 移行共通要件4 1 1 共通要件

4 1 1 1既存の患者IDは変更しないことを前提とする。

4 1 1 2

現行システムのデータ移行に関する作業は、現行システム（電子カルテシステム及び必要に応じて部門システムも含む）からのデータの抽出は現行システム受託者が対応し、移行データに関する編集、クレンジング及び登録（アップロード）作業を受託者にて実施すること。ただし、この作業については、京都市立病院の指示にしたがって進めることとし、その詳細については別途協議とする。

4 1 1 3

本番稼働までの操作研修等の期間も含め、現行システムとの並行稼働時、及びデータ移行時等において、操作者である医療従事者に誤認や混乱を与えぬように配慮するとともに、診療業務に支障をきたさないよう十分な対策をとること。

4 1 1 4

稼働前後のスケジュール（並行稼働の開始時期、切替前後の電子カルテ停止時期、病棟・外来稼働日等）を整理するとともに、稼働前後に必要となる病院側の対応事項（稼働当初の患者数の絞り込み等）について、計画案を取りまとめ、平成26年9月末までに京都市立病院に提示し、対応について検討を行うこと。

4 1 1 5 受託者は、移行にあたって、その作業を円滑に進めるとともにデータの整合性等について十分に検証を進めることを目的として、この計画立案及び実施に係る移行統括責任者を設置し、システム品質を担保すること。

4 2 データ移行4 2 1 データ移行計画書の策定

4 2 1 1

受託者はデータ移行に関して、開始・終了条件、移行実施体制と役割、移行作業及びスケジュール、移行環境、移行方法、移行ツール、移行データ検証方法について記述したデータ移行計画書を作成し、京都市立病院の承認を得ること。また、作成した移行計画書に基づいて移行作業を実施すること。

4 2 1 2現行システムに含まれる外字については、JIS第三水準の漢字に置き換えを行うこと。ただし、置き換えが困難な文字についてはカナ表記への置き換えでも構わないこととする。

4 2 1 3

機種依存文字や外字、ユーザ定義文字のほか、自由文字列中に存在する半角・全角の空白文字、記号文字等を含む文字列の移行について、事前に移行対象データを調査のうえ、その移行方針について京都市立病院と十分に協議を行い、移行計画を立てること。移行計画策定においては、リハーサル開始前までに、各移行対象データについて、部分的な移行が実施され、リハーサルを通じて内容の検証が可能であるよう留意すること。

4 2 2 移行プログラムの開発

4 2 2 1移行に必要なツール等に関するプログラムの設計･開発、結合テスト、外部連携テストを実施すること。移行プログラムの設計･開発時においては、今回構築するシステムと十分に整合性を図ること。

4 2 2 2移行データ検証のために必要なツール等に関しては、受託者の負担と責任において準備すること。

4 2 3 データ移行の実施

4 2 3 1

厚生労働省が平成11年に通知した『診療録等の電子媒体による保存について』において示された、いわゆる電子カルテの3原則である「真正性」「見読性」「保存性」の確保を考慮に入れ、再利用が必要な現行システムのデータ（別紙参照）をすべて移行対象とすること。なお、移行対象としないデータについては、京都市立病院にて参照用システムを別途構築する。

4 2 3 2

現行システムからの移行対象データについて、ファイルレイアウト、データレイアウト、外字利用の有無、不備データの有無等を現行システム業者と協力して調査すること。なお、コード体系・マスタ体系については現行の体系を把握した上で、単純に踏襲するのではなく見直しを実施すること。

4 2 3 3

移行データの検証にあたっては、少なくとも薬品マスタについては正しくデータが移行されていることを確認するため、全件チェックとして、全薬品についてオーダ発行し、部門システム・医事システムへの連携内容を確認すること。その他のマスタについても可能な限り全件チェックを実施すること。

要求仕様

非機能要件４．移行要件 12


要求仕様

4 2 3 4次期システムの次のシステム（次々期システム）へのデータ移行を安価かつ容易に実現するための提案をすること。

4 2 3 5リハーサルを実施し、移行方法、移行スケジュールの妥当性を確認すること。また、実施にあたってはデータの移行漏れが発生しないよう細心の注意を払うこと。

4 2 3 6

部門システムのデータについては、移行範囲と方法の決定を現行部門システム担当及び新部門システム担当並びに病院の担当者で協議して決定することとするが、別紙に明示されたデータについては、移行範囲に含めることとする。

4 3 システム移行4 3 1 システム移行計画書の作成

4 3 1 1

受託者は、システム移行に関して、開始・終了条件、移行実施体制と役割、移行作業及びスケジュール、移行実施手順、運用保守工程への引き継ぎ方法、緊急時対応計画（コンティンジェンシープラン）について記述したシステム移行計画書を作成し、京都市立病院の承認を得た上で成果物として納入すること。

4 3 1 2

システム移行が、2.2.9に前述した並行稼働までに確実に終了できるよう、この移行計画をレビューする際に実現可能性について十分検討すること。特に、作業遂行上の前提条件が安易なもの、または非現実的なものになっていないかどうか確認を怠らないようにすること。

4 3 2 システム移行の実施

4 3 2 1システム移行計画書に基づいて、遅滞なくかつ、極力円滑に実施できる体制を確保した上で移行作業を実施すること。

4 3 2 2部門システムの刷新の際、システム間のデータの整合性が図れているか十分な確認作業を行うこと。

4 3 2 3リハーサルを実施し、移行方法、移行スケジュールの妥当性を確認すること。

4 4 業務移行4 4 1 業務移行計画書の作成

4 4 1 1

受託者は、システムの切替に際して業務が滞ることないよう、マニュアル整備、マスタ設定進捗管理、研修の実施、リハーサルの実施等、必要事項のスケジュール、緊急時対応計画（コンティンジェンシープラン）を記載した業務移行計画書を作成し、京都市立病院の承認を得た上で成果物として納入すること。

4 4 1 2業務移行がシステム本稼働までに確実に終了できるよう、実現可能性について十分検討すること。

4 4 1 3業務移行計画書においては、院内に流通済みの物品に添付されたラベルの張替え等、システム運用変更に必要な物理的な対応に関しても遺漏なく明記し、受託者の役務として実施すること。

4 4 1 4並行稼働時の特別運用に係る業務マニュアルを作成し、病院職員に周知徹底すること。

4 4 2 業務移行の実施

4 4 2 1業務移行計画書に基づいて、遅滞なくかつ、極力円滑に実施できる体制を確保した上で業務移行作業を実施すること。

非機能要件４．移行要件 13


非機能要件5 研修要件5 1 研修の目的

5 1 1稼働時のスムーズな業務運用を実現するために、ユーザがシステム操作に習熟し得るよう、受託者は新業務・新システムの操作等に関する研修を実施すること。

5 1 2システム操作のみならず、現行業務からの変更点を中心に、業務運用（誰がどの操作を行うか）についてもユーザが十分に習熟し得るよう、研修等を実施すること。各ワーキンググループごとに研修を実施すること。

5 2 研修実施計画の作成

5 2 1

受託者は、研修体制と役割、詳細な作業及びスケジュール、研修環境、研修方法等について記述した研修実施計画書を作成し、京都市立病院の承認を得た上で成果物として納入すること。また、作成した研修実施計画書に基づいて研修を実施すること。システムのバージョンアップ時においても、必要に応じて京都市立病院内で研修を行うこと。

5 2 2研修実施計画の作成にあたっては、研修の範囲を想定した上で、講師の手配や環境の準備に加えて、実際の受講者が研修の内容を効果的に体得できるよう、自習期間を含めて3カ月は習熟期間を確保すること。

5 2 3後続に実施するリハーサル時に、システム操作に留まらず病院業務運用の確認ができるよう、リハーサルまでにシステム操作に係る習熟度を高めておくスケジュールとすること。

5 2 4

研修実施計画の作成にあたっては、稼働前の基本的なシステム操作研修にとどまらず、稼働から一定期間後、システム習熟度が高まった段階でさらに詳細な機能研修を実施する等、システムの機能を余すところ無く利用者に周知する方法を意識すること。

5 2 5業務を運用するエンドユーザの研修に加え、システム管理者向けの研修を実施すること。

5 2 6新任の方が円滑に業務実施ができるよう、新任の方へ研修を行うための環境・マニュアル等を整備すること。

5 2 7職員全体に対する操作研修に先立ち、WGの中核検討メンバである外来、病棟、各科リーダに対する操作研修を実施し、マニュアル及びカリキュラムが十分であることを確認すること。

5 3 研修実施体制

5 3 1受託者は研修を効率的に進め、かつ、最大限の効果を得るために、研修資料の事前作成、実際の講義、研修後における受講者からの問合せ等に対応できる体制を確保すること。

5 3 2研修実施にあたっては、研修の範囲を想定した上で、講師の手配や環境の準備に加えて、実際の受講者が研修の内容を効果的に体得できるよう、無理のないスケジューリングを行うこと。

5 3 3院内の業務を円滑に回すための操作習熟に向けて、基本的なシステム操作研修に加えて、業務運用を意識したカリキュラムを組むこと。

5 3 4院内業務に即した研修では、特に現行業務からの業務上の変更点に着目してカリキュラムを組むこと。

5 3 5研修実施にあたっては、ＩＴに特化した専門用語等を多用せず、分かりやすい表現方法を用いること。

5 4 研修環境

5 4 1研修を行う際、事前に策定した実施計画に基づき、端末やプリンタ、サーバ機器、ネットワーク等を含めた環境を準備すること。マスタ・出力帳票に関しても極力実運用に即したものを用意するものとするが、詳細は別途協議とする。

5 4 2研修環境は原則として京都市立病院内に設置すること。ただし、事前に作成する研修実施計画においてこれと異なる内容が承認された場合は、この限りでない。

5 4 3研修にて使用するデータは、実際の現場での操作に適したものを用意すること。また、同じデータを用いての研修が繰り返しできるよう、データのバックアップを取得し、リストアを可能とすること。

5 4 4受講者の習熟度や理解度を登録･管理できるコンテンツを用意すること。

要求仕様

非機能要件５．研修要件 14


要求仕様

5 4 5研修環境は、研修実施時だけでなく、それ以外の時間にもユーザが操作練習をできるよう自習環境を設置すること。

5 4 6研修環境は常に最新版とすること。

5 5 研修資料の作成

5 5 1研修及び自習用の資料については、以下の要件を満たすこと。

原則として研修や運用に必要なマニュアルは業者が作成すること。

研修用教材（研修用テキスト、DVD・CD-ROM等）を作成し、病院に納品すること。

各システムの操作マニュアルを作成すること。

マスタ操作マニュアルとマスタ運用マニュアルを作成すること。

各部署の教育に使用する業務マニュアルは原則として業者が作成すること。

システム管理者用のマニュアルとして、システム運用マニュアルを作成すること。

障害発生時の対応手順や代替策、障害時の運用に関する障害時対応マニュアルを作成すること。

導入後の職員採用時に使用するシステム研修用の簡易マニュアルを作成し、病院に納入すること。

大きな運用改定があった場合は業者にてマニュアルの改訂を行うこと。

年に1度はマニュアルの見直しを業者にて行い更新版を病院に納入し変更箇所を説明すること。

操作マニュアルや障害時マニュアル等のマニュアルは業者が必要部数を作成し、納入すること。その際業者SEは積極的に病院にヒアリングを行い、単なるシステムのマニュアルにならないよう、医療従事者にわかりやすいマニュアルを作成・提案すること。

操作マニュアルは、運用マニュアルから、該当箇所を逆引きできるような対応表・索引等を備えること。

各システム操作時に、オンラインで操作マニュアルや障害時マニュアル等を参照できること。

5 5 3研修用資料のリリースにあたっては、必ず京都市立病院の承認を受けること。また、研修開始後であっても、資料に瑕疵や誤謬等があると認められる場合は、速やかに修正を行うこと。

5 5 4職種や利用者スキルに応じた適切な表現等を用いて、研修マニュアルや機材を用意すること。

5 6 研修の実施報告と評価

5 6 1研修を実施した場合は、受講者の理解度を調査するため、アンケート調査を実施し、実施記録、評価をまとめること。

5 6 2評価をとりまとめた結果、受講者の理解度が事前に定めた基準に達していなかった場合は、追加の研修等習熟度を高めるための対応を取ること。

非機能要件５．研修要件 15


非機能要件6 ハードウェア要件（基本ソフト含む）6 1 共通

6 1 124時間365日運用を考慮したハードウェア構成とすること。

6 1 2医療情報の共有を目的としたカルテ、オーダ、看護の一体化とデータベースの統合管理が可能なこと。

6 1 3障害発生を監視・通知するシステムを導入すること。

6 1 4システム運用中のまま障害となった装置に対しホットスワップ（切り離しや入替）が行えること。

6 1 5運用負荷の低い時間帯にバックアップ処理を実施すること。

6 1 6OS、ミドルウェア、DBは受託者で実績あるものを利用すること。

6 1 7OSの選定理由としてUNIX、Windows、Linux等の信頼性、障害性、ウィルス対策を比較し、提示すること。

6 1 8データの蓄積に伴う処理速度（レスポンス）の低下を抑制する仕組みを持つこと。

6 1 9受託者導入予定の電子カルテ、医事会計、看護支援システムについては1台の共用端末で全ての機能が利用できること。

6 1 10部門システム等も極力共用端末で全ての機能が利用できるよう検討すること。

6 1 11ハードウェア設計を行い、ハードウェア設計書を作成し、京都市立病院の承認を得ること。

6 1 12ハードウェア環境設計を行い、ハードウェア環境設計書を作成し、京都市立病院の承認を得ること。

6 1 13ソフトウェア一覧、ハードウェア一覧を作成すること。

6 1 14可用性設計、信頼性設計、保守性、保全性、機密性、拡張性設計、性能設計を行い、詳細設計書としてまとめること。

6 1 15詳細設計書に従い、病院と協議の上、テスト計画を立案し、テストを実施し、テスト結果について京都市立病院の承認を得ること。

6 1 16サーバ及びクライアントの運用設計を行い、運用手順書を作成し、京都市立病院の承認を得ること。

6 1 17バックアップ・リストア設計書を作成すること。また手順書もあわせて作成すること。

6 1 18業者はグリーン購入法の基準を満たす製品を、システムに適用できないか検討し、積極的に提案を行うこと。

6 2 サーバ要件

6 2 1電子カルテサーバ、医事会計サーバの稼働時間については、24時間365日を基本とすること。

6 2 2京都市立病院が必要とする性能要件を満たすサーバを提案すること。

6 2 3

現場の医療スタッフがストレスとならないレスポンスを確保するサーバスペックとすること。レスポンスについては、プレゼンテーションの際に、デモ機にて、病院から指定するシナリオに沿った操作を実施すること。京都市立病院にてその際の所要時間を評価する。導入業者は、プレゼンテーション時のレスポンスを確保できる構成を提案すること。なお、デモ機と本番環境でのレスポンスの差異が回避できない場合には、その程度をプレゼンテーション時にあらかじめ提示し、承諾を得ること。

要求仕様

非機能要件６．ハードウェア要件（基本ソフト含む） 16


要求仕様

6 2 4電子カルテシステムサーバ、医事会計サーバをはじめ全てのサーバについて基本方針として、以下の要件を満たすこと。

突然のサーバ停止を回避するよう、仮想サーバ又は同一構成サーバ2台による冗長構成（クラスタ構成）とすること。データ量が増加するであろう７年後においても当初のレスポンスを維持できる構成を提案すること。また、7年以後のレスポンスの悪化を想定し、悪化の程度について提案項目において提案し、その基準を順守すること。さらに、運用保守の範囲において、年に一度レスポンスに関するベンチマーク検証を行い、想定されたレスポンスが達成できていない場合には、改善を行うこと。

6 2 5電子カルテシステムサーバ、医事会計サーバの可用性として、以下の要件を満たすこと。

サーバ障害発生時は待機系に自動切り替え運転が可能であり、主系から待機系へのサービス切り替え時間を10分以内とすること。また，データ不整合が発生しない仕組みとすること。

6 2 6電子カルテシステムサーバ、医事会計サーバの信頼性として、以下の要件を満たすこと。

安定稼働後は稼働率を99.99％以上とすること。

サーバ内の電源、ファン、内蔵ディスク、バッテリー（UPS）は、原則としてホットスワップに対応した冗長構成とすること。耐障害性を考慮し、全てのサーバでストレージへの経路を二重化構成とすること。

全てのサーバのストレージで、CPU、インタフェース等のコンポーネントを、冗長構成とすること。

全てのサーバのストレージで、ディスクをRAID10の冗長構成とすること。

6 2 7電子カルテシステムサーバ、医事会計サーバの拡張性として、以下の要件を満たすこと。

メモリを2倍にできるだけの拡張スロットを装備していること。

ディスク容量を２倍にできるだけの拡張スロットを装備していること。

6 2 8電子カルテシステムサーバ、医事会計サーバの性能として、以下の要件を満たすこと。

運用時のCPUはリソース不足による処理遅延や処理不能状態が発生しないこと。また使用率を定期的に明らかにすること。

運用時のメモリはリソース不足による処理遅延や処理不能状態が発生しないこと。また使用率を定期的に明らかにすること。

運用時のディスクは処理遅延や処理不能状態が発生しないこと。

ピーク時のトランザクション量が導入時想定最大量の1.5倍になっても、安定稼働に問題を生じないシステム構成とすること。

システム導入から７年後でも、安定稼働に問題を生じないシステム構成にすること。

障害等の原因により、システムが待機系に切り替わった場合であっても、オンラインレスポンスの目標時間内に処理が完結すること。

バッチ処理の実行時間は、バッチ処理時間帯内で実行後に再実行ができるだけの余裕を持つこと。

バッチ処理は運用負荷の低い時間帯に実施するなど、病院業務に影響のでない処理スケジュールとすること。特に外来時間においては、バッチ処理を行わないスケジュールとすること。



要求仕様バッチ処理で処理するデータ量が導入想定最大量の1.5倍になっても、安定稼働に問題を生じないシステム構成とすること。

バッチ処理のデータ量が、導入想定最大量の1.5倍になっても、安定稼働に問題を生じないシステム構成とすること。ディスクアレイ装置は、性能要件を満たす入出力であること。

ディスクアレイの理論容量は、5年後のデータ運用に耐え、レスポンス低下が発生しないこと。

6 2 9監視システムサーバの導入方針は以下の要件を満たすこと。

サーバを監視する、監視システムを構築する。

各サーバ及び全クライアント端末に資源配布を行う、資源管理サーバを構築する。

障害及び障害予兆を検出した場合、エラーをアラーム音、パトランプ等でユーザに通知できる機能を装備していること。

6 2 10監視システムサーバの監視対象は以下の要件を満たすこと。

サーバのCPU使用率を監視すること。

サーバのメモリ利用率を監視すること。

サーバのディスク容量監視を行うこと。

サーバの障害予兆監視ができること。

サーバの障害監視ができること。

プロセス異常等を感知する監視システムを導入すること。

レスポンス性能を定期的に計測する仕組みを構築すること。

データ排他発生時、画面に排他先が特定できる情報を表示すること。

異常検知のアラートを、業者窓口に通知できること。

6 2 11監視システムサーバの信頼性は以下の要件を満たすこと。

安定稼働後は稼働率を99%以上とすること。

6 2 12データベースサーバは以下の要件を満たすこと。

データベースは、Oracle等シェアが大きいDBを採用すること。また、データベースの選定理由を明らかにすること。DB設計を行うこと。

データベースに格納可能な最大のデータ量を明らかにすること。

運用時は適宜DBチューニングを実施すること。

性能を向上させるために、テーブル分割等を考慮すること。

京都市立病院からの要求で、データベース等のチューニング情報（Oracleのstatuspack相当のもの）を開示すること。データベース及びテーブルは自動拡張機能を利用し、ＳＥによる随時作業としないこと。



要求仕様

6 2 13電子カルテサーバ、医事会計サーバ以外の全てのサーバについては、京都市立病院と同等規模の自治体病院を参考にし、スペック及び性能を決定し提案を行うこと。

6 2 14サーバのバックアップは以下の要件を満たすこと。

データ保全のためのバックアップは、原則としてオンラインバックアップとし、定期的にオフラインバックアップを組み合わせること。

バックアップはデータ量を考慮し、差分バックアップを検討すること。

電子カルテサーバについては、バックアップを目的としたシステム停止は想定していないため、システム停止せずにバックアップを行う仕組みを構築すること。

電子カルテシステムで保有している以下情報を専用サーバに格納し、京都市立病院外のデータセンターに保存すること。災害時等には、媒体等を利用し保存した情報を参照可能とすること。対象データは以下の情報を最低限とすること。・患者基本情報・患者属性（保険、住所、禁忌、アレルギー、感染症）・処方オーダ情報・注射オーダ情報・検体検査結果情報・有効傷病名

6 2 15サーバのリストアは以下の要件を満たすこと。

取得したバックアップから確実にデータを復旧すること。

リストアが可能なリカバリポイントを明確にし、復旧が可能な範囲を明確にすること。

6 2 16サーバのログ管理は以下の要件を満たすこと。

サーバの稼働状況、ログの確認について、一元的に管理できること。

システム監査に対応可能なログ、管理画面等を有すること。

ログデータのオーバーフロー等によりシステム停止を引き起こさないよう、ログデータは監視用のサーバに集約する等の工夫をおこなうこと。

6 2 17無停電電源装置（UPS）を備え、商用電源の異常時に自動的にサーバが停止するようにできること。また、設定変更により、自動停止機能を無効にできること。

6 2 18全てのサーバにおいて時刻同期が行えること。

6 2 19環境について、以下の要件を満たすこと。

電子カルテシステム・医事会計システム・看護支援システムは、本番環境とは別にテスト環境（開発環境含む）、研修環境を有すること。また、本番環境と、テスト環境・研修環境は、別サーバで構築すること。テスト環境と研修環境は同一サーバ上への構築も提案可能とする。

研修環境においては、稼働後も操作教育やテストが行えるようにすること。もしくは、研修用の環境を別途用意すること。また、職員の研修用と、学生教育用の双方に活用可能な仕組みとすること。

6 2 20全サーバをラック搭載とすること。

6 2 21高精細モニタ等、高額かつ高性能の既存資源のうち、新システムで使えるものを移行できるよう、提案を行うこと。



要求仕様

6 2 22電子カルテ導入業者は役務として、以下の要件を満たすこと。

新システムで使用するサーバの設置、設定と動作確認、及び業務ソフトウェア設定と動作確認を行うこと。

全サーバ及び全クライアント端末の導入作業完了後、全ての装置について動作確認を行うこと。

新システムを構成する機器のうち、相互通信を行う装置間の接続に関しては、通信テストを含む動作確認を行うこと。

新システムで使用する情報端末の設置調整（設定）作業を実施すること。

端末にインストールされているOS及びソフトウェアのライセンスを管理しておくこと。なお、ソフトウェアについてはソフトウェア管理ツールを導入して効率よく情報を収集すること。

6 2 23定期保守について、以下の要件を満たすこと。

サーバ及びその周辺装置に関して、機器の清掃点検を含む定期保守を6カ月に1回以上行うこと。

定期保守の日程は、病院担当者と協議の上、その指示に従うこと。

6 2 24平成27年5月の京都市立病院稼働にあわせて携帯端末を導入予定である。携帯端末は別途調達予定だが、本調達において、以下の要件を満たすこと。

携帯端末の稼働に備えたサーバを用意すること。

台数増加に備えた拡張性を備えること。



非機能要件7 運用・保守要件7 1 本項の記載内容

7 1 1

本項では、稼働後にスムーズな運用・保守ができるようにするためにシステム構築時に考慮しておくべき点及び、稼働後の保守作業について記載している。受託者においては、稼働後に運用保守業務が効率的に実施できるよう十分検討して設計するとともに、平成32年4年までの保守業務を実施すること。また、運用業務を別途調達することを考慮し、適切な引き継ぎを実施すること。

7 2 基本要件及び障害対応

7 2 1システムは24時間365日連続運転ができる設計とすること。また、特段の事情がない限り、ノンオペレーションで運用が続けられるシステムとすること。

7 2 2夜間や休日に障害が発生した場合でも迅速かつ、的確な対応ができるよう、障害箇所の特定が容易に行える仕組みとすること。また、24時間体制で緊急対応ができるハードウェア及びＳＥ・ＣＥによる保守体制を採用すること。

7 2 3

部門システムか否かを問わず、原則として全てのシステムで、そのサーバやネットワーク、UPS等を含めて稼働状況を一元的に把握できるよう、各種の監視機能やログ収集機能を備えるとともに、警告や障害に関して自動的に検出する機能、及びパトランプや電子メール等による通知機能等を用意すること。また、無線接続機器の監視については、位置情報を取得できる工夫を加えること。なお、これらの構築にかかる一切の費用は受託者の負担とするため、事前に内訳として明記されているか否かを問わず、導入経費の見積に含めること。

7 2 4運用、保守工程においても利用できるよう、各種のドキュメントについては、作成する前に必ずその体裁や様式、ファイル形式、記載内容等について京都市立病院と協議すること。

7 2 5

システム稼働後、受託者は、契約期間中現場で円滑な入力作業や運用作業ができるよう、外来・入院共に十分な支援体制を確保すること。ただし、利用者の習熟度向上やシステム稼働の安定化に伴い、この体制を縮小することは可能とし、詳細は京都市立病院と別途協議すること。

7 2 6医療従事者の操作を支援できるよう、ヘルプデスクからリモートで操作支援ができる機能を構築すること。

7 3 保守要件

7 3 1診療報酬制度改正等の内容に柔軟に対応できるよう、アプリケーションプログラムのロジックがシステム構造と密接に関係するような設計を行わないようにすること。

7 3 2

リモートメンテナンスによる外部からの操作及び診断ができるシステムとすること。なお、リモートメンテナンスを行う場合、その対象や実施条件、運用方法等の詳細は別途協議対象とするが、それを前提としても支障がないようにしておくこと。

7 3 3ハードウェア保守を一定期間毎に実施することを前提としても、性能等に大きな支障がないようにすること。

7 3 4ハードウェアについては予備機等を複数台用意し、障害時の現場の負荷を最小限にする等の措置を講じること。

7 3 5端末の予備機等を用いる場合は、各現場に合わせた端末構成をただちに復元できる等の措置を講じること。

7 3 6

サーバ等、主要なハードウェアについては、以下の項目を含んだ定期点検を実施すること。なおその際、実施時期は別途協議とするが、原則としてシステムは無停止で行うこととし、診療サービスそのものは継続できるようにすること。

ハードウェアの目視による点検

各種ツールによる診断

ローカルに保存されたログ等の収集及び解析

ハードウェアの清掃、調整

要求仕様

非機能要件７．運用・保守要件 21


要求仕様

7 3 7定期点検の結果の報告と、その結果に伴う不良物品の交換等の措置については、必ず受託者が責任をもって実施すること。

7 3 8

サーバに接続する形で設置したUPSのバッテリーについては、不良を示す警告の表示や、交換時期が到来した場合、受託者が責任をもってバッテリーの調達、交換、処分を行うこと。なお、機器諸元で性能が保証できるとされた環境において、バッテリーが標準的な利用期間の半分にも満たないうちに交換を要する状態になったときは、受託者が速やかに交換に応じること。また交換の際には、システムを停止する必要が生じないこと。

7 4 運用要件

7 4 1バックアップ要件として以下の要件を満たすこと。

定期的なバックアップができる設計とすること。また、システム運用に影響の少ない夜間帯等に自動でバックアップが取得できるような運用方法を想定し、必要十分な記録媒体がシステム内に装填できるような形とするとともに、スケジューリング機能の実装についても考慮しておくこと。

部門システムまでも含めて画一的なバックアップ方式を想定するのではなく、業務やシステム構成により適正なバックアップ方式が採用できるようにしておくこと。

電源の異常時でも、バックアップに使用した記録媒体が取り出せるように考慮すること。

7 4 2リカバリ要件として以下の要件を満たすこと。

障害等の発生によって、データをリストアする必要が生じた場合に、システム停止時間を極力短くできるよう、バックアップ方法とあわせて十分な検討を行っておくこと。

データのリカバリ、及びリストア等に関するテストを必ず稼働前に実施しておき、バックアップを取得しておけば確実にデータが復旧できるよう十分な検証を行うこと。

リカバリ及びリストアに関する手順が明確かつ、単純になるようにし、マニュアルに沿って容易に実施できる仕組みとすること。

7 4 3その他保管等は以下の要件を満たすこと。

装填されている記録媒体の着脱や棚卸がしやすい仕組みとすること。

記録媒体について、システムのライフサイクルの間は利用できると推定されるものを採用すること。

データの保存期間については、システムの特性や各種の法令、規程等を遵守の上、適切な期間を設定できる仕組みとすること。

7 4 4

運用業務の扱いについて、以下6.5に示す作業を想定しているため、これらの作業が円滑に行えるようなシステム構成とすること。なお、これらの運用業務に係る全ての作業について、構築業者である受託者以外の業者が作業を行えるように教育が可能なシステムとすること。

7 5 運用業務

7 5 1

運用業務の実施にあたっては、各作業の概要、実施体制、実施スケジュール（タイミング等）を記載した運用手順書を作成すること。運用手順書は契約開始から4カ月以内に作成し、京都市立病院の承認を得た上で、納入すること。

7 5 2

運用業務としては以下を想定しており、平成27年4月末までに京都市立病院がオペレータ業務を委託する運用オペレータによる運用業務が可能となるよう、運用業務を引き継ぐこと。（引き継ぎにおいては各手順書を用意し、内容を現行オペレータと確認し、納品すること）

定期的な京都市立病院との運用会議の開催

サーバの起動、停止業務



要求仕様利用者のマスタメンテナンス支援

各システムのセキュリティ上必要な監視等

障害調査

端末等交換可能な機器の障害時の代替機との交換

端末管理（台帳修正）

障害機器の修理手配

納入した機器の移設（工事を伴うものは除く）

納入した機器の運用時の設置、調整（工事を伴うものは除く）

現場からの問合せ対応・管理（ヘルプデスク）

現場での簡単な操作支援

機器管理番号による機器管理

各システムで発生する定例的なバッチ処理

各種ファイルやデータベースのバックアップ処理

バッチ処理等に伴う大量帳票（レセプト等）の定期的な出力処理

各システムの正常稼働監視及び接続状況監視

定期的なファイル整理、性能改善のためのチューニング等

リソース利用状況の定期的な監視

各監視状況の定期的な担当職員への報告

各種ドキュメント更新（必要に応じて新規作成も含む）

利用者のデータ抽出の環境整備及びその維持

京都市立病院の指示によるデータ抽出作業及びデータ加工

標準マスタのバージョンアップ

各種マスタ設定作業（システム設定やシステム基幹の変更に関する設定は除く）

システムに係る利用者通知作成支援

ウィルスパターンファイルの更新

その他、各種動作パラメータ設定作業等、システムに付随する業務（システム設定やシステム基幹の変更に関する設定は除く）

7 5 3並行稼働より運用業務が開始できるよう、上記の個々の作業の手順書を作成し、平成27年3月末までに京都市立病院に提出し、中間検査を受けること。



要求仕様

7 5 4リハーサル時に運用オペレータの業務もリハーサルを実施するが、リハーサル時にスムーズに作業内容の確認ができるようリハーサル前に運用オペレータにも操作研修を実施して、システム操作、作業内容を習熟させておくこと。

7 6 保守業務

7 6 1

保守業務の実施にあたっては、作業概要、実施体制、実施スケジュール（タイミング等）を記載した保守業務マニュアルを作成すること。保守業務マニュアルは契約開始から4カ月以内に作成し、京都市立病院の承認を得た上で、納入すること。

7 6 2

保守業務の作業内容は以下の通り想定している。・ハードウェア維持管理・ミドルウェア維持管理・ソフトウェア維持管理・アプリケーション維持管理（医療法改正やその他法律改正等に伴うアプリケーションの変更、定期的なバージョンアップ）・障害対応・問合せ対応

7 6 3

導入したハードウェア、ミドルウェア、ソフトウェアについては、導入した製品一覧をそれぞれ作成し、メンテナンスの実施状況も記載の上、管理すること。また、一定周期で京都市立病院に実施状況を報告すること。報告周期については、別途協議とする。

7 6 4必要に応じ、サーバ等のセキュリティ等のパッチの適用とその検証作業を実施すること。

7 6 5

電子カルテシステムパッケージのアプリケーションについて、保守契約の範囲にて最新の機能を適用すること。受託者の中でアップデートがあった場合は、京都市立病院に報告、方針検討の上、適用範囲を決定すること。適用することとなった場合は受託者にて実施すること。作業にあたっては作業計画と作業手順書を作成し、京都市立病院の承認を取得すること。また、適用作業完了後に作業結果報告書を作成して提示すること。

7 6 6障害対応については、以下の要件を満たすこと。

システム障害に係る連絡先窓口は一本化すること。

システム運用中に障害が発生して、通常の使用ができなくなった場合、自らの検知の他、運用オペレータからの通報や京都市立病院からの連絡により、作業員が設置場所に出向いて修理を行うこと。基本的に24時間365日の対応をすること。

各種サーバ機器、レセプトプリンタ、診察券発行機、再来受付機、案内表示板、自動精算機、ＰＯＳレジ及び全てのミドルウェア・ソフトウェア

障害が発生した場合、病院業務に支障をきたす場合は、事象、想定原因、対応方法、病院側での業務代替運用及び対応事項をとりまとめて速やかに担当部署に報告の上、了承を得ること。

調達したシステムとの間で障害の所在が不明な場合であっても、当該システム担当者等と協力して障害原因の切り分けを行うこと。

電気、空調等の設備障害、接続している各病院での調達システムの連携障害等、本業務に含まれるシステム以外が原因であると考えられる障害においても、システムの緊急措置を行い、関係者との連携を密にして障害解決に当たること。

業務への支障を考慮し、一次報告から30分以内の現場到着と、60分以内のシステム復旧を実現するため、障害復旧や応急対応等について必要な措置を講じること。

即時の修理が不可能な場合、予備機の設置等（端末、プリンタ等）により速やかに障害対応や、その他の応急処置を行うこと。

病院側の誤操作による障害時の回復作業、及び原因不明時の回復作業についても支援すること。



要求仕様システム復旧後、速やかに原因を究明し、再発防止及び対応策を担当部署に文書にて報告すること。

発生した障害は障害管理表を使用して管理し、一定期間毎に障害発生状況を担当部署に報告すること。

7 6 7問合せ対応については、以下の要件を満たすこと。

問合せ受付窓口は一本化すること。

受け付けた問合せは問合せ管理簿を使用して管理し、一定期間毎に問合せ発生状況を分析して担当部署に報告すること。

7 6 8

保守業務の実施にあたっては、SLA（Service Level Agreement）を京都市立病院と締結すること。詳細については、保守業務実施計画書作成時に協議する。

7 6 9

障害等の原因によって、ハードウェア、ミドルウェア、ソフトウェア、アプリケーションに変更が発生した場合、変更日時、対応者、変更内容、変更要因、影響範囲等の内容を変更管理簿に使用して管理すること。また、一定期間毎に変更の発生状況を担当部署に報告すること。

7 6 10障害等の原因によって、アプリケーションをリリースした場合、リリース管理簿を使用してリリース日時、対応者、リリース内容、影響範囲等を管理すること。また、一定期間毎にリリースの発生状況を担当部署に報告すること。

7 6 11変更が発生した場合は、基本設計書、詳細設計書に変更内容を記載して最新化しておくこと。その際版管理を徹底し、デグレードのないようにすること。

7 6 12

病院内に導入されている各部門システムの業者も交えた全体運用・保守報告会を月次で開催すること。また、システムの運用状況が安定したと京都市立病院が認めるまでは、週次での運用・保守報告会を開催し、運用・保守状況の報告を行うこと。

7 5 2

各システムにおけるマスタメンテナンスの効率を考慮し、システム間におけるマスタ相関図を作成すること。マスタ相関図を確認することにより、あるマスタを変更した時に他システムに及ぼす影響範囲と、併せて変更が必要なマスタの範囲が明確に識別できること。

7 7 運用保守業務の教育・定着化

7 7 1

運用オペレータによる運用業務が定着するまでの間（概ね３ヶ月と想定）は、運用オペレータによる運用業務を支援し、受託者自らが運用業務を行うこと。この期間に運用・保守成果物の検証を行い、京都市立病院の指示に従い運用オペレータと協議を行いながら成果物の変更を行うこと。稼働後1ヶ月を経過した時点で京都市立病院と運用オペレータ業務が定着したことを確認・検証を行い、追加での支援の必要性について京都市立病院と協議を行うこと。

7 7 2受託者は運用・保守業務において京都市立病院に提示した成果物一式を運用オペレータに引き継ぎ、必要な説明を行うこと。

7 8 保守要員の常駐配置

7 8 1

受託者は、稼働後5年間にわたり、平日8時半から17時15分までの間、受託者と同会社における、医療システム専任の中堅クラスＳＥ（プロジェクトにおけるサブマネージャー相当者）を常時１名常駐させること。当該常駐ＳＥと会社を同じくし、管理する立場にある上級ＳＥ（プロジェクトマネージャー相当者）を含めたプロジェクト進捗会議を京都市立病院にて月２回開催し、進捗の管理を行うこと。プロジェクト進捗の遅れなど予想外の事態発生時においては、その程度に応じて頻度・回数を増すこととする。システム全体を熟知している保守要員1名を配置すること。

7 8 2体調不良等の要因により保守要員が業務を実施できない場合には、その旨を管理者が京都市立病院に連絡の上、対応について協議し、当該ＳＥと同等以上のＳＥを代替要員として確保するなど、京都市立病院の指示に従うこと。

7 8 3なお、要員の交代等については、2ヶ月以上前の時点で京都市立病院に文書で相談の上、事前に承認を得ること。



非機能要件8 ネットワーク・端末設計要件8 1 ネットワーク設計要件

8 1 1

ネットワーク業者は別途調達することを想定していることから、ネットワーク業者調達のための仕様書の最終化を行うこと。なお、設計においては、既存の配線・設計を活用することを前提とし、この設定に基づいて更新される機器類の調達仕様書の最終化を行うこと。

8 1 2モバイル端末の活用等、提案によって利用拡大が想定される無線環境においては、現状の設計内容で十分なパフォーマンスが得られるか否かを調査・確認し、その結果を踏まえてネットワーク業者調達仕様書を最終化すること。

8 1 3

ネットワーク上を流れるトラフィックがある一定の値(サービスレベル維持のための限界値)を超えないように監視する機能を設計すること。なお、限界値を超えた場合の適切な対応方法等についてマニュアルに明記する設計をすること。

8 1 4各部門ごとのネットワークを統合した運用設計を行うこと。

8 1 5全てのネットワークを統一的に管理・監視・設定変更ができる様に設計すること。

8 1 6

不正接続防止の観点から、設計時には以下の点に留意すること。・ネットワークに対してどのような情報機器が接続されたかを検知するため、接続ログ等を保存すること。・あらかじめ登録された情報機器以外はネットワークに接続できないこと。・登録されている情報機器についても、アクセスログ及び操作ログ等を保存すること。・ポリシーに準拠していない情報機器が、ネットワークに接続すること防止できるシステムであること。

8 1 7基本的に外部ネットワーク（インターネット系ネットワークを含む）とは物理的に接続しないこと。

8 1 8

設計時、院内の無線アクセスポイントを利用し、無線ネットワーク配下にある端末の位置を把握、また操作端末の施設平面図に位置を表示する、以下の機能を実現可能なように留意すること。・情報機器の位置が検索できること。・あらかじめ設定されたエリアを設定することで、そのエリア内にある情報機器の位置情報が表示出来ること。・情報機器紛失の際など、紛失した機器を追跡できるログや機能を有すること。・位置情報検知対象の端末に特別なクライアントソフト等を必要としないこと。

8 1 9ネットワークの更新作業の遅れ等が本業務に含まれるシステムの稼働スケジュールに影響を及ぼさないよう、ネットワーク業者の施工監理を行うこと。

8 1 10

京都市立病院、京北病院の病院間のネットワークは、「京都デジタル疏水ネットワーク」を利用することとするが、「京都デジタル疎水ネットワーク」がダウンした場合にも、各病院の業務・システム運用への影響を抑えられるシステム構成・ネットワーク構成を提案すること。

8 2 端末設計要件

8 2 1端末パソコン、プリンタ類、携帯端末、スキャナ、バーコードリーダ等に係るハードウェア及びソフトウェアは別途調達することを想定していることから、端末業者調達のための仕様書の最終化を行うこと。

8 2 2端末類の調達仕様の最終化にあたっては、現状の業務量を調査し、最適な端末構成を提案すること。

8 2 3

情報漏えい対策のため、端末設計においては以下の点に留意すること。・アプリケーションの動作及び認められていないアプリケーションの新規インストールを制御/防止できること。・USBメモリやCD-ROM等の外部リソースやディレクトリの利用、プリンタでの印刷を制限できること。・利用可能な外部デバイスの管理・棚卸ができること。

8 2 4別途調達する端末類に対して、本業務に含まれるシステムの稼働のために必要なソフトウェア（ライセンス費を含む）等の導入設定、運用管理（不具合時の切り分け、応急処置）の対応を行うこと。

8 2 5端末を追加調達する際の導入設定費用について、本業務の提案書においてあらかじめ明確化すること。

要求仕様

非機能要件８．ネットワーク・端末・部門システム設計要件 26


要求仕様

8 2 6端末調達作業の遅れ等が本業務に含まれるシステムの稼働スケジュールに影響を及ぼさないよう、端末調達業者の施工監理を行うこと。

8 2 7端末の導入設定・設置作業を行うこと。

8 2 8

稼働後の端末増設に対応するための、設定用ツール・マニュアルを整備し、京都市立病院に納入すること。また、当初導入した端末と同様のOSを搭載した端末増設が困難な場合には、ダウングレード等の対応を保守の範囲で対応すること。また、ダウングレードなどの対応が可能であるよう、当初導入端末のOS選定時に留意すること。

8 3 部門システム設計要件

8 3 1

京都市立病院が仕様書に定める部門システムについて、京都市立病院職員及び工程管理業者と協力の上、作成する業務フロー及び機能仕様書に基づき、部門システムの選定を支援し、機能分界及びインターフェースの定義を行うこと。

8 3 2

京都市立病院が工程管理業者の支援を得て選定した後、受託者は共通システム及び部門システムの機能仕様書及び非機能仕様書を充足しうるよう当該部門システムを提供する業者と契約を締結し、以後設計・開発・テスト等の業務を協業すること。契約締結の状況については、逐一京都市立病院に報告を行い、稼働及び全体計画に支障が生じないないよう留意すること。

8 3 3

部門システムの調達仕様の最終化にあたっては、現状の業務量を調査し、また部門システム毎の特性等を鑑み、仮想化技術を適用する等、性能、安全性・信頼性、費用等の面から最適なサーバ構成を提案すること。なお、京都市立病院は導入されたシステムを原則として7年利用することを想定している。

8 3 4

部門システムを調達する際の調達費用（初期導入費用及び保守費用）の参考見積りについて、本業務の提案書においてあらかじめ明確化すること。当該調達費用の参考見積りは、7.3.2の契約を締結する際の合計額の上限となることに留意されたい。

8 3 5部門システム業者との間の契約締結や調整等が本業務に含まれるシステムの稼働スケジュールに影響を及ぼさないよう、部門システム業者の施工監理を行うこと。

8 3 6

部門システムに関する運用検討、設定、開発及び単体テスト以降の各種テスト（結合テスト、総合テスト及び受入テスト）、リハーサル等の稼働準備、操作研修について、受託者は前項の施行監理の役務の範囲内で電子カルテシステム・共通システムと同様に対応すること。

8 3 7稼働後の部門システムの保守に必要な文書類を整備し、京都市立病院に納入すること。

8 3 8電子カルテと部門システムの連携がスムーズに取れるよう考慮し、かつ将来的な部門システムの追加に係る接続費用が安価となる仕組みを考慮すること。

8 3 9手術室システムにおいては、清潔な状態のまま電子カルテ端末の操作（フィンガージェスチャー等）ができるシステムであることを考慮すること。

非機能要件８．ネットワーク・端末・部門システム設計要件 27


非機能要件9 プロジェクト管理要件9 1 スケジュール管理

9 1 1作業計画の作成について、以下を満たすこと。

必要とする作業を最小の単位に分解し、作業項目の階層表（WBS）を作成すること。

作業工程毎に作業内容、成果物、レビュー方法、チェックポイント、開始／終了条件を明確にすること。

作業工程間の順序関係、依存関係を明確にし、必要作業量に基づいたスケジュール表を作成すること。

作業工程の完了は必ず当該部署に十分説明し双方了解のもと進めること。但し下流工程で明らかな機能不足・運用障害が発生した場合は、上流工程での作業を見直し、受託者が責任を持って対応すること。

これらの作業計画については、京都市立病院の承認を得ること。

9 1 2作業状況、進捗状況の報告と管理について、以下を満たすこと。

定期的な進捗報告会を開催し、作業状況の報告を行うこと。開催のタイミング・頻度等は、京都市立病院と協議のうえ決定すること。

進捗報告会で、対象とする作業期間に予定していた全作業について、計画、実績及び計画と実績の差異を報告すること。

各作業工程における成果物について受託者内でのレビュー等を実施した上で、京都市立病院とのレビュー等を実施し、承認を得ること。

特に、クリティカルパスの上の工程管理は、トップマネージメント事項として厳守すること。

計画からの遅れが生じた場合、原因を調査し、要員の追加、担当者の変更等の体制の見直しを含むリカバリプランを提示し、京都市立病院の承認を得たうえで、これを実施すること。

作業実績を把握し、計画との差異分析、傾向分析、及びアーンド・バリュー・マネジメント（以下、「EVM」という。）による分析等により、定量的な管理を行うこと。

プロジェクトの目的や範囲、成果物等について、定期的に状況との差異を分析し、見直しの必要性が生じた場合には、原因の分析と対応策の立案を行い京都市立病院へ報告を行うこと。関連ドキュメント等の具体的な変更作業は、京都市立病院の承認を得たうえで実施すること。

9 2 リスク管理

9 2 1

プロジェクトの遂行に影響を与えるリスクを識別し、その発生要因、発生確率、影響度、監視･評価方法等を整理し、京都市立病院の承認を得ること。リスクの監視・評価結果については、進捗報告会にて京都市立病院に報告すること。

9 2 2リスクを顕在化させないための対応策、リスクが顕在化した後の対応策を識別し、緊急時対応計画として具体化し、京都市立病院の承認を得ること。

9 3 品質管理

9 3 1作業工程毎の品質評価基準書（評価指標、判断基準）を作成し、京都市立病院の承認を得ること。作成にあたっては、受託者が通常使用する受託者の「品質方法論」に則ること。

9 3 2各作業工程の終了時点で、品質評価会議を開催し、品質評価基準書に沿った評価結果を報告すること。次の作業工程へ推移する際は、本会議において京都市立病院の承認を得ること。

9 3 3リハーサル終了時点で、稼働判定会議を開催し、京都市立病院と受託者が合意した稼働判定基準に則った稼働判定を実施すること。稼働にあたっては、本会議で承認を得ること。

要求仕様

非機能要件９．プロジェクト管理要件 28


要求仕様

9 3 4品質評価計画の立案、検証及び品質改善策の検討と実施を管理する体制を構築すること。また、各種の取り組みがしかるべき手続きに則って実施されていることを確認すること。

9 3 5受託者の関連会社や協力会社が参画する体制を構築する場合には、受託者が責任を持って契約上、実行上の品質要件を盛り込み、それに従ってコントロールすること。

9 3 6プロジェクト参画メンバ以外のものによる品質レビューを定期的に実施すること。

9 4 要員管理

9 4 1体制管理について、以下を満たすこと。

プロジェクトはチームで構成し、各チームの役割、作業分担、編成時期、状況報告関係等を明確にした組織(要員)管理計画書を作成すること。また、各チームの作業分担と作業量に応じて、適切な要員配置を行うこと。各作業工程、あるいは必要なタイミングにおいて、作業推進上の必要十分な組織（要員）の計画・編成を行い、体制を確立させること。

組織（要員）管理計画に基づく要員調達・配置を確実に実施すること。

構築作業全般を統括する管理責任者を専任で配置するとともに、別途本プロジェクト作業全ての管理統括責任者となるプロジェクトマネージャを配置すること。

プロジェクトマネージャは、医療システムにおいてプロジェクトマネージャとして5年以上の経験を有しており、「PMP」「上級医療情報技師」「（IPAの）PM」のいずれかの資格を有するものが望ましい。また、600床以上の病院における電子カルテの導入及び電子カルテから電子カルテへの移行の経験を有すること。さらに、京北病院への展開を念頭に、電子カルテ未導入の病院における電子カルテ導入経験と複数の病院を有する地方公共団体または地方独立行政法人等におけるシステム導入経験を有すること。

プロジェクトマネージャは、本プロジェクトに専任とすること。

上記の管理責任者や管理統括責任者（以下「責任者等」という。）を含め、受託者の全ての作業担当者について、原則としてその者が作業を開始する1週間前までに、各人の職務経歴、作業経験等を記した書面を京都市立病院に提出して構築体制を明確にするとともに、作業開始に伴う承認を得ること。また並行して受託者は、各作業担当者に対し任じた作業を始める前に、本仕様書に示した記載事項全てと、患者の個人情報保護の重要性について、十分に周知徹底を図ること。

個別業務や対象技術分野毎に各々構成されるワーキングチームに主体的に参画する、受託者の中心的な役割を担う担当者については特段の事情がない限り構築作業期間中の変更はしないようにするとともに、次回打合せ等ワーキングチームのメンバ全員に係わるスケジュールが、それらの者の都合に左右されないよう、十分な作業体制を確保すること。また、こうした中心的存在となる要員を変更するときは、京都市立病院と受託者間での別途協議とし、京都市立病院の承認を必ず得ること。

全ての参画要員については、参画時に保有スキル、実務経験（医療情報システムの経験年数及び担当病院）等の情報を提示することとし、事前に京都市立病院の承認を得ること。また、変更が生じる場合は、その旨を速やかに京都市立病院に提示し、承認を得ること。

受託者側の各作業担当者は、一般社団法人日本医療情報学会認定「医療情報技師」相当の知識を最低限有すること。

マルチベンダ構成による提案を行う場合、関係する業者間で十分な合意を得るとともに、チームを編成する参画業者の総責任者を決定し、体制を具体的に提案・説明すること。また、組織（要員）管理計画の作成や組織の編成時には、必ずこの位置づけを反映すること。

9 4 2外部委託管理について、以下を満たすこと。

本件の一部を第三者に委託する場合は、委託先及び根拠を明確にして京都市立病院の承認を得ること。



要求仕様受託者の関連会社や協力会社等、本件の受託者でない主体に本件に係る業務を再委託する場合や、派遣会社等を利用する場合は、事前に京都市立病院の承認を得ること。

9 5 課題管理

9 5 1プロジェクトで発生した課題については、その内容、発生日、担当者、検討状況、検討結果、解決日等の必要情報を一元的に管理すること。

9 5 2定期的に課題対応状況を監視し、解決を促す仕組みを確立すること。

9 5 3課題発生時には、速やかに京都市立病院に報告し、対応を検討すること。

9 6 コミュニケーション管理

9 6 1

プロジェクト参画者の中で、コミュニケーション計画書を作成し、そのための仕組みを構築すること。コミュニケーション計画書には以下の内容を含むこと。

・会議体の定義・議事録の取り回し・文書管理・成果物の共有方法　等

9 6 2報告フォームについては、EVM等の手法を取り入れる等して、現状、計画との差異、今後の予測、対応策等が盛り込まれていること等を必須として、状況把握、各種判断を容易に行えるものを実現すること。

9 6 3定期的、非定期的に関わらず、プロジェクトで実施すべき全ての会議・報告会等について、内容、出席者、開催頻度、提示情報、必要フォーム等を定義し、それを利用して主催すること。

9 6 4進捗報告会を週1回必ず開催すること。

9 6 5

受託者は、原則として最低でも週1回以上は必ず社内等で作業者間の連絡、調整の場を持つとともに、各作業者間で相互に関連する事項もしくは影響する事項や、京都市立病院に提示する資料等について十分な意識合わせ及びレビューを行うこと。

9 6 6

各会議後においては、議事録を作成し、会議内容を記録、報告し、京都市立病院の承認を得ること。また、議事録は速やかに京都市立病院へ提示すること。議事録には、可能な限りそのドキュメントが作成されるに至った考え方や経緯、背景等の資料も含めること。

9 6 7

会議の中で発生した課題やToDoは文書区分や付番等、分類上必要な整理項目や履歴管理すべき内容等をまとめた上で構築作業上のデータベースとして受託者が集中管理し、京都市立病院及び受託者双方の担当者が付与された権限内で自由に参照できるようにすること。なお、このデータベースは、構築作業期間終了後、参照できる環境とともに、京都市立病院に引き渡すこと。

9 7 スコープ管理

9 7 1本仕様書に記載した事項及び提案書に記載した事項に対して、プロジェクトにおける検討において変更が発生した場合、変更内容を管理すること。

9 7 2京都市立病院の中間検査時点から成果物に変更が発生した場合、変更内容を管理の上、成果物を修正すること。その際変更理由とともに明確な版管理を実施すること。



非機能要件10 業務の遂行にかかる要件10 1 一般的事項

10 1 1受託者が医療従事者と打合せを行うにあたっては、特別な事情がない限り、受託者の担当者は京都市立病院の指定した時間帯に極力スケジュールを合わせること。

10 1 2

受託者は、高品質なシステムの構築作業を効果的に進めるため、京都市立病院に対し、他病院における構築経験や、過去のトラブルや失敗事例に基づいて随時的確なアドバイスを行うとともに、創意工夫を凝らしてプロジェクト運営にあたること。

10 1 3

受託者側の各作業担当者は、厚生労働省、経済産業省、総務省、内閣府、関連団体等が公表した各種の方針や施策、ガイドラインや、病院や医療従事者が遵守すべき関連法令等について、その内容や動向を正しく理解して作業を行うこと。なお、遵守すべき法令やガイドラインについて、一覧化の上業務開始前に提出すること。

10 1 4

病院での作業時には、京都市立病院は24時間体制で運営されていることを踏まえ、病院の業務に支障が出たり患者に不快感を与えたりしないよう、その挙止や身なり、応対、発言等について十分注意を払うこと。また、作業を行う各担当者に、原則として病院内に貴重品を持ち込まない旨、そして仮に貴重品を持ち込んで紛失等があった場合に京都市立病院はその責を負えない旨を、周知徹底すること。

10 1 5原則として、受託者の各作業担当者は、各病院内において自らの所属等を証明するものを常時携帯するとともに、体の見やすい位置に名札を着用すること。なおこの様式については、作業開始前に別途協議とする。

10 1 6受託者側の作業担当者が病院内各室に立ち入って作業を行う際は、原則として、事前に京都市立病院の所管部署の責任者に確認を取り、その者の許可を得た上で作業を進めること。

10 1 7

本構築プロジェクトにかかわる機密事項や、患者情報、あるいは病院内で知り得た情報等を社内で取り扱うにあたって、受託者は、システム構築に携わる者以外にこれら一切の情報が漏洩しないよう、十分に配慮すること。

10 1 8

本システムの稼働年数は７年と想定している。各種ハードウェア及びクライアントのOSに関しては必要に応じて更新を行うことも想定しているが、ソフトウェアに関しては７年間の稼働に耐えることを前提とした設計を行うこと。」また、７年間の保守についても記載を追記する。

10 1 9上記の事項にあわせて、本構築作業が開始される前に京都市立病院と協議すると定めた事項について、十分な誠意をもって行うこと。

10 1 10

本件に係る成果物のうち、紙もしくは磁気媒体で納入するものについては、エコマークの認定を受けている製品、またはこれと同等のものを利用するように努めること。またこれは、受託者内部において本件に係る業務を行う場合においても同様の配慮を行うこととする。なお、導入するハードウェアについても、性能や機能の低下を招かない範囲で、消費電力の節減や発熱、騒音対策等の環境に配慮された製品を選定するよう心がけること。

10 2 構築作業が開始される前に協議する事項

10 2 1

受託者は、本仕様書に記載された項目について、読み合わせ等を通じて、京都市立病院と内容の確認作業を確実に行い、記載の意図も含めて十分理解しておくこと。なお、この対象は原則として全項目とする。また、本仕様書上において、同一または同義の内容が複数の箇所で記述されている場合に限っては、その旨及び運用上の支障がない旨を京都市立病院に確認した上で、適宜集約することは可能とする。

10 2 2

本業務を行う作業場所は、原則として受託者の責任において情報セキュリティを保持できる場所を確保すること。ただし、病院内に作業場所が必要な業務が発生する場合は事前に申し出て、京都市立病院の指定する場所で業務を行うこと。

要求仕様

非機能要件１０．業務の遂行にかかる要件 31


要求仕様

10 2 3

構築作業の遂行に際して発生する、資料作成のための用紙や交通費、通信費等一切の付帯費用は、原則として受託者が負担するものとするが、京都市立病院が指定する作業場所における光熱費等についての費用負担については、この事前協議の対象とする。

10 2 4

構築作業の期間中において、受託者が京都市立病院の指定する場所で使用する什器や備品、また必要な通信環境に関しては、原則として受託者が用意するものとするが、その持ち込みの可否や設置場所等の詳細については、この事前協議の対象とする。

10 2 5

受託者は、迅速な情報共有や、予定、実績管理等の作業進捗状況等の確認を目的としたツールやポータルサイト、メーリングリスト等の環境を構築し提供すること。これについては、契約日から2週間以内に京都市立病院と受託者双方のメンバ各位がアクセスできるような環境を開設し、構築作業期間中その運用を行うこと。なお、開設及び維持運用にかかる作業及び費用は受託者の負担とするが、設置する環境及び運用の詳細については、この事前協議の対象とする。

10 2 6

打合せや議論、検討の場において、受託者は、原則としてその席上で内容を即時に記録をまとめ、参加者で共有すべきポイントや重要事項についてすぐに確認できるような工夫を行うとともに、議事録作成等にかかる作業工数や、内容確認にかかる工数を省力化すること。また、議事録の提出は会議開催日から3営業日以内とすること。この進め方の詳細については、この事前協議の対象とする。

10 2 7

受託者による、京都市立病院に対する提出資料等の体裁や事前の提示、実際の協議方法等、設計、構築作業を円滑かつ、効率的に進めるために必要な内容の詳細については、この事前協議の対象とする。

10 2 8

京都市立病院及び受託者の間ではあらかじめ、履行場所となる病院への出入り、駐車場の利用、履行場所で作業できる時間帯の制限、飲食、喫煙、携帯電話やモバイル機器の利用等、受託者の作業に係わる諸般の事項について、この事前協議の対象とする。また、受託者は、作業担当者にこの決定事項を必ず遵守させることとし、これに違反した事実が認められた担当者の扱いについては、京都市立病院と受託者間での別途協議事項とする。

10 3 構築作業そのものに係る事項

10 3 1

受託者は、本構築作業におけるセキュリティ関連の管理体制及び責任を明確にし、書面で京都市立病院に提示すること。またその際、セキュリティ事故対策の責任者を事前に定めることに加えて、万一、コンピュータウィルスの検出を含む情報セキュリティ事故が発生した場合、ただちに京都市立病院に報告するとともに事故原因に係る調査について全面的に協力すること。

10 3 2

ハードウェア・ソフトウェア等の設置工事について、受託者は、京都市立病院に対し事前に必ず作業の内容の提示を行い、その承認を得ること。またその際受託者は、京都市立病院がこの承認を行うにあたって必要十分な精査を行うための期間を、作業を行う予定の日から逆算して確保できるようにすること。なお、受託者に帰すべき事由によりこのための期間が十分確保できない場合は、京都市立病院の承認は得られない場合がある旨を理解しておくこと。

10 3 3

京都市立病院及び受託者間の構築委託契約が締結された後で、受託者が、その保有するパッケージシステムの標準仕様では実現ができないことを理由に、本仕様書に記載された機能要件の実装を拒むことはできないものとする。

10 3 4

システム構築の際、受託者が利用する開発支援ツール等に代表されるソフトウェアの利用については、動作及びセキュリティ上の十分な検証を経て、販売者や著作権者の承諾を得られる場合に限るものとし、それ以外について京都市立病院は認めないものとする。また、理由の如何にかかわらず、無断で受託者の開発環境とインターネット環境を接続すること、及び受託者の開発環境において、ファイル交換ソフトウェアを利用することは厳禁とし、これに違反したことが明らかとなった場合、受託者は相応の責を負うものとする。

10 4 ハードウェア設置・工事に係る事項

10 4 1

各種ハードウェアの搬入、設置工事を行う前に、受託者は、設置場所の現状や環境調査を綿密に行うこと。なお、その進め方については、京都市立病院及び受託者間での別途協議とするが、事前にそのための準備を怠りなく行うこと。



要求仕様

10 4 2

これら各種ハードウェアの搬入、設置工事について、受託者は、事前に設置場所や作業日時、体制等を検討した上で施工計画を作成し、京都市立病院の承認を受けること。また、受託者がこの作業を行うにあたって、作業者にその際の決定、指示事項を遵守させるとともに、予測し得ない事象に対応できるようにするため、これらの決定事項や作業内容を十分把握している者を監督者として立会わせることとし、これらの内容について一通り書面にまとめて、事前に作業申請書として京都市立病院に提出すること。

10 4 3

各種ハードウェアの電源周りの作業について、電算室内のサーバ機器については分電盤より機器側の配線等を受託者の責任において行うこと。なお、具体的な作業内容については、京都市立病院及び受託者間での別途協議とする。

10 4 4

ハードウェアの搬入、設置作業に際しては、院内の他の職員の業務に支障が出ないよう、また患者に不快感を与えたり迷惑が掛からないように施工すること。またあわせて、既存の施設や機器設備を毀損することのないよう、適切な養生等を含め、十分に注意を行うこと。なお、これに反して生じた既存施設や機器設備の毀損にかかる一切の責は、受託者が負うものとする。

10 4 5

ハードウェアの設置について、地震による移動転倒防止措置や、盗難防止のためのセキュリティワイヤ等の取り付け等の措置を必ず行うこと。また、これらの部材にかかる一切の費用は受託者の負担とするため、事前に内訳として明記されているか否かを問わず、導入経費の見積もり額に含めること。

10 4 6

設置されるハードウェアには、機器管理番号や、IPアドレス、サブネットマスク、VLANのIDといったネットワーク定義情報等を明示することとし、原則として着脱可能なマグネットシールやタグ等を貼付すること。また、これらの準備及び貼付にかかる一切の費用は受託者の負担とするため、事前に内訳として明記されているか否かを問わず、導入経費の見積もり額に含めること。なお、明示する情報の内容については、京都市立病院及び受託者間での別途協議とする。

10 4 7

作業終了後に、機器の設置場所及び作業項目、検査内容、関連図面等の詳細を示した報告書を必ず作成し、原則としてその作業終了後1週間以内に、作成した電子ファイルを京都市立病院に提出し、承認を受けること。なおその際、作業前及び作業終了後に当該設置場所の撮影を行い、その画像をファイルとして報告書に添付すること。ただし、写真撮影に際しては、報告書を作成する旨を明示した上で、その部門の責任者に了解を得ること。

10 4 8

端末や機器の具体的な設置場所については、現行システムの機器との併設をどのように行うかも含めて京都市立病院及び受託者間での別途協議とするが、その際、受託者は、設置場所として想定される現場について、十分な下見や調査を行うこと。

10 5 ソフトウェアの導入、セットアップに係る事項

10 5 1

オペレーティングシステム、データベース管理ソフトウェア、Webブラウザソフトウェア、Office系スイートソフトウェア、各種ミドルウェア、ウィルス対策等セキュリティ保護のためのソフトウェア、UPS等のハードウェア装置に依存する管理ユーティリティ等、業務アプリケーションプログラム以外の動作基盤となるソフトウェアの初期設定項目と、サーバ機器のBIOS設定のうち、セットアップ時の既定値を変更した方が性能上や運用上好ましいと思われる項目等については、機器製品の搬入以前に、受託者がその検討のたたき台を用意した上で京都市立病院に提示し、両者間で協議を行うものとする。また受託者は、その協議を経て合意した内容を設定手順書としてまとめ、チューニング等を経て最新の状態にアップデートした上で納入すること。

10 5 2

ソフトウェアのセットアップについて、受託者は、その対象がオペレーティングシステムであるか業務アプリケーションプログラムであるかを問わず、インストールするソフトウェアに関する最新のパッチプログラムを全て適用することを前提として、必要な動作検証や動作保証できるソフトウェアバージョンの確認等を事前に行っておき、納入時点で極力、安定的、かつ最新なバージョンの提供を行うこと。

10 5 3

ソフトウェアのセットアップを行うにあたり、受託者は、端末にインストールするソフトウェアのうち利用者登録が必要なもの全てについて、当該ソフトウェアの製造会社に対する利用者登録の手続きを京都市立病院に代わって行うことを念頭におき、ソフトウェアライセンスの提供方法について事前に京都市立病院と協議すること。なお、ソフトウェアの使用に際し、その製造会社と京都市立病院の間で使用許諾権契約が必要なものについても同様の扱いとするが、この契約締結に際し、京都市立病院の代表者印や電子メールアドレス等が必要な場合や電子メールアドレス等の取り扱いについては、両者間での別途協議とする。



要求仕様

10 5 4

ソフトウェアのインストールに際し、受託者は、パッケージに同梱されているライセンスキーやインストール時に必要となるキー等を全て別紙に控えておき、セットアップする端末の管理番号と設置場所との関連付けを明らかにした一覧のファイルを作成した上で、京都市立病院に納入すること。なお、利用者登録に必要な使用者名義や連絡先、またインストール時に必要となる利用者名等については、受託者によるインストール作業を開始する前に、両者間での別途協議とする。

10 5 5

受託者は、全てのソフトウェアの初期インストールが終了した時点で、その端末上に作成されたテンポラリのフォルダ、ファイル等のクリーンアップ作業を行うとともに、テスト等、使用を開始する前に必ず、ハードディスクやレジストリ等の最適化作業を行っておくこと。

10 5 6

受託者が、ソフトウェアのインストール作業を効率化する目的で、ハードディスクイメージのバックアップ、リカバリ専用ソフトウェア等を利用する場合、その前提として、製造シリアル番号のみが異なる全く同型及び同仕様の複数の端末に、全く同じ設定内容でソフトウェアをセットアップするような組合せパターンを有する場合に限定すること。この場合、当該ソフトウェアの利用にあたっては、京都市立病院にその旨の了承を得るとともに、受託者の不在時に京都市立病院がこのソフトウェアを利用してセットアップを行うことを考慮し、別途、組合せパターン毎の実行環境や作業手順書等を用意しておき、これにかかる一切の費用は導入経費の見積もり額に含めること。またあわせて、バックアップ元マスタとなる端末については、上記9.5.5で提示した作業を必ず行っておくこと。

10 5 7

上記9.5.6で挙げたような、ソフトウェアのインストール作業を効率化するための専用ソフトウェアを利用するか否かを問わず、通常のインストール作業の方法を記した手順書を別に用意し、京都市立病院に別途納入すること。なおこの際、記載する内容については京都市立病院及び受託者間で別途協議とする。

10 6 成果物の納入に係る事項

10 6 1

受託者は、成果物の作成及び納入にあたり、特に各種ドキュメントについては、その作成者が同一人物か否かを問わず、それらの様式や体裁、装丁、語句の表記方法等、原則として全て京都市立病院が定める様式に基づいて統一を図るとともに、その質を監査する為の要員を受託者内部に配置して十分な品質管理を行うこと。

10 6 2納入するドキュメントのファイルや、それを格納するディレクトリ（フォルダ）の作成にあたって、受託者は、以下の基準を遵守すること。

その名称に日本語を用いてもよいが、電子メールにファイルを添付する場合があることを念頭において、半角カナ文字の他、①、Ⅰ、㍻、㈱等の機種依存文字は含めないこと。

先頭もしくは途中に半角または全角の空白文字を入れないようにすること。

ソート順を意識した命名を行うこと。

10 6 3

受託者がドキュメントを作成する際、文書のタイトルや作成者名、会社名といった属性情報についてどのように設定した上で作成すべきか、受託者としての案を用意した上で、必ず京都市立病院に確認すること。受託者の担当者が作業で使用するパソコン及びソフトウェアの初期設定のままで成果物を作成しないこと。

10 6 4

成果物のうち、京都市立病院が要望する業務機能要件を実現する為に、受託者が個別に対応した部分を含む機能の実現に関する情報が記載されたシステム設計書、データベース定義書等のドキュメントについては、後でそれを参照した際に、個別対応した箇所が識別できるようなものを別途添付する等の措置を講じておくとともに、その個別対応に及んだ背景や、システム機能実装上の制約事項等、ソフトウェア保守の際に重要となる関連情報について、必ず追記して明示した上で納入すること。なお、この詳細については、京都市立病院及び受託者間での別途協議とする。

10 6 5導入に必要な機器、及び商用ソフトウェアの納入にあたって、製品に添付されるマニュアルやCD-ROM等の他の同梱品の扱いについて、受託者は以下の通り作業を行うこと。



要求仕様インストールキーや製品のシリアル番号等、マニュアルやCD-ROMに製品個々の独立性を表意する情報の印字、刻印等がなされている場合は、後々探しやすいよう、それらにインデクスシールを貼付して整然とまとめておくようにするとともに、機器管理番号等との関連を明記した一覧表のファイルを必ず作成し、どの端末に付随したマニュアル、CD-ROMかどうかわかるようにしておくこと。

一方、上記のように、製品個々による独立性を表意する情報が添付されていないマニュアルやCD-ROMについては、同じ種類のものを同じ場所に整然とまとめておくようにするか、京都市立病院と協議の上で、廃棄ができるものは一定部数のみ保存することとし残りは廃棄処分とする等、適切な措置を講じること。

上記に係わらず、ソフトウェア製品の開梱に伴う廃棄物が発生する場合は、その処理や分別等について、受託者は京都市立病院の指示に従うか、指示がない場合は京都市立病院にその旨を確認することとし、業務履行場所に廃棄物をそのまま放置しないこと。

10 6 6設計工程に係る成果物は以下の通りとする。契約開始から4カ月以内に作成し、京都市立病院の中間検査を受けること。

アプロジェクト実施計画書（品質評価計画、要員管理計画、コミュニケーション計画を含む）イ要件定義書・設計・開発計画書ウ基本設計書（業務フロー、機能、画面、インタフェース、データベース、ハードウェア/ソフトウェアに係る構成、配置図等）エ詳細設計書（機能、インタフェース、データベース、モジュール、ハードウェア/ソフトウェア設定値等）オテスト計画書（全体テスト計画書、単体テスト（パッケージ標準部分を除く）計画書、結合テスト計画書、総合テスト計画書、受入れテスト計画書（案））カ業務フローキリハーサル計画書クデータ移行計画書、システム移行計画書、業務移行計画書ケ研修計画書コ運用・保守計画書サ機器の設置作業等による施工計画書シ設計工程品質結果報告書ス品質評価基準書セ各種検討報告書ソ協議に関する記録等

10 6 7開発工程に係る成果物は以下の通りとする。平成26年11月末までに作成し、京都市立病院の中間検査を受けること。ただし、イ、ウについては平成26年11月末までとする。

ア単体テスト仕様書（パッケージ標準部分を除く）、テストデータ、テスト結果報告書イ結合テスト仕様書、テストデータ、テスト結果報告書ウ移行プログラムテスト仕様書、テストデータ、テスト結果報告書エマスタ作成手順書オ操作マニュアル、業務マニュアル、並行稼働時の特別業務運用マニュアルカシステム運用マニュアルキ各種運用作業手順書（サーバ管理手順、運用スケジュール、メンテナンス手順、バッチ処理手順、他システムとの相互依存、連絡体制図、利用者管理手順、データバックアップ手順、その他運用上必要な手順等を含む）ク保守作業手順書ケリハーサル手順書コ機器管理番号を含むハードウェア一覧表、構成図等サ各種検討報告書シ協議に関する記録等スＦＡＱ一覧表等セ開発工程品質評価結果報告書

10 6 8稼働前準備工程に係る成果物は以下の通りとする。平成27年3月末までに作成し、京都市立病院の検収を受けること。



要求仕様ア総合テスト仕様書、テストデータ、テスト結果報告書イ受入テスト仕様書、テストデータウ稼働判定基準、稼働判定結果エ問合せ管理簿、課題一覧オ操作研修で使用した資料一式カ習熟度テスト結果報告書（追加対応があればその資料及び実施結果）キリハーサル結果報告書ク総合テスト工程品質評価結果報告書ケ稼働前品質評価結果報告書（品質保証書）

その他、必要と考えられる資料一式

10 6 9京北病院への展開に係る成果物は以下の通りとする。

設計工程に係る成果物は9.6.6と同様の内容とし、平成26年12月末までに作成した上で京北病院の中間検査を受けること。開発工程に係る成果物は9.6.7と同様の内容とし、平成27年3月末までに作成した上で京北病院の中間検査を受けること。稼働前準備工程に係る成果物は9.6.8と同様の内容とし、平成27年6月末までに作成した上で京北病院の中間検査を受けること。

その他、必要と考えられる資料一式

10 7 瑕疵担保に関する取り扱い

10 7 1

納入するソフトウェアに係る瑕疵担保期間は、原則として京都市立病院におけるシステムの運用開始から1年間とする。また、京北病院におけるインターフェース機能等京北病院固有の機能については京北病院におけるシステムの運用開始から1年間とする。ただし、明らかに仕様上不具合のある内容や、テスト不足によりバグとして顕在化したものについては、瑕疵担保期間を超えてもこれに対応すること。

10 7 2

業務アプリケーションの稼働に必要となる各種ソフトウェア及びハードウェアの稼働については、受託者がそれらの製造者や販売者となっているかどうかを問わず、受託者がトータルシステムとして最終的な稼働の責任を負うこと。またこれに関連して、入札説明書に示した通り、受託者の関連会社、または協力会社が構築作業に参画する体制を採用することも可能とするが、その場合は受託者が責任をもって契約上及び実行上の品質確保要件を盛り込み、それに従ってそれら関連会社、協力会社のコントロールを行うこと。なお、このように受託者の関連会社、または協力会社が構築作業に参画する体制を採用する場合は、それら関連会社、協力会社に対し、本章における業務遂行にかかる要件の周知徹底等を十分に図ること。

10 8 知的財産権に関する取扱い

10 8 1

本件業務により受託者に生じた特許権がある場合、特許権の帰属は受託者が保有するものとするが、特許権に関して、委託者が本契約及び個別契約に基づき本件ソフトウェアを使用するのに必要な範囲について、当該特許権等の通常実施権を許諾するものとする（なお、本件ソフトウェアに、一定の第三者に使用せしめる旨を個別契約の目的として特掲した上で開発されたソフトウェア（以下「特定ソフトウェア」という。）が含まれている場合は、当該個別契約に従った第三者による当該ソフトウェアの使用についても同様とする。なお、かかる許諾の対価は、委託料に含まれるものとする）。

10 8 2

納入物に関する著作権（著作権法第27条及び第28条の権利を含む。）は、委託者または第三者が従前から保有していた著作物の著作権を除き、受託者に帰属するものとする。ただし、委託者は、納入物のうちプログラムの複製物を、著作権法第47条の2に従って自己利用に必要な範囲で、当該著作物について複製、翻案することができるものとする。また、本件ソフトウェアに特定ソフトウェアが含まれている場合は、本契約及び個別契約に従い第三者に対し利用を許諾することができる。受託者は、かかる利用について著作者人格権を行使しないものとする。


Documents

電子カルテシステム調達仕様書 非機能要件 · 2019-06-25 · 電子カルテシステム調達仕様書 非機能要件 要求仕様 2 1 2 2 管理者権限で更新を伴う操作を行う場合は、確認画面を表示できること。

電子カルテシステム調達仕様書非機能要件 · 2019-06-25 · 電子カルテシステム調達仕様書非機能要件要求仕様 2 1 2 2 管理者権限で更新を伴う操作を行う場合は、確認画面を表示できること。