ＪＡＨＩＳ標準 １３－００２

ＪＡＨＩＳ
保存が義務付けられた診療録等の電子保存ガイドライン（第３．１版）

２０１３年４月
一般社団法人 保健医療福祉情報システム工業会
医療システム部会 セキュリティ委員会

ＪＡＨＩＳ
保存が義務付けられた診療録等の電子保存ガイドライン
ま

え

が

き

「法令に保存義務が規定されている診療録及び診療諸記録の電子媒体による保存に関するガイドライン」（平成 11 年 4 月 22 日付け健政発第 517 号・医薬発第 587 号・保発第 82 号厚生省健康政策局長・医薬安全局長・保険局長連名通知に添付。）により、それまで紙でしか保存が許されなかった「法令に保存義務が規定されている診療録及び診療諸記録」の大半を電子的に保存できることとなった。その後「診療録等の外部保存に関するガイドライン」（平成 14 年 5 月 31 日付け
医政発第 0531005 号厚生労働省医政局長通知）により外部保存が可能になった。そして 2005 年 3月 31 日通知「民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律等の施行等について」ならびに 2005 年 3 月 31 日通知「『診療録等の保存を行う場所について』の一部
改正について」を受けて、2005 年 3 月に厚生労働省より「医療情報システムの安全管理に関するガイドライン」として個人情報保護、電子保存、外部保存、e 文書法対応を統合したガイドラインが発行された。
「医療情報システムの安全管理に関するガイドライン」では B 項の「考え方」において最新の技術動向を配慮した詳しい説明が行われているが、個別のベンダーが具体的に自社のシステムに実装するにおいては、実際にどのようなシステム製品がその要件を満たすのか、どのような仕様で開発したらよいのかが分かりにくかった。JAHIS としては電子保存を促進するためには、各要件を実際のシステムの機能を反映した「機能要件」や、その機能を補完する内容を含む「運用要件」を整理した、より具体的で実装寄りのガイドラインが必要と考え、同ガイドラ
インに対して、「技術的にどの範囲まで担保することが望ましいか、また技術的に対応しにくい要件を運用でどのように担保することが期待されるか」を具体的に示すことにより、診療録等の電子保存およびネットワークを介した送受信を適切に行うための基準を示すことを目的として、2007 年 5 月に本ガイドライン（第一版）をまとめた。
「医療情報システムの安全管理に関するガイドライン」は技術の進歩や周辺環境の変化を受けて改定が実施され、2007 年 3 月には第二版、2008 年 3 月には第三版が発行された。JAHIS の本ガ
イドラインについても、継続検討を行うこととしていたため、「医療情報システムの安全管理に関するガイドライン」の改定を受けて検討を実施、同ガイドライン第三版までの内容を反映し、2009
年 10 月に第二版として発行した。
「医療情報システムの安全管理に関するガイドライン」は 2009 年 3 月に第 4 版、2010 年 2 月に第 4．1 版が発行された。また、総務省の「ASP･SaaS 事業者が医療情報を取り扱う際の安全管理ガイドライン」（2009 年 7 月）及び、経済産業省の｢医療情報を受託管理する情報処理事業者向けガイドライン」（2008 年 7 月）も発行された。JAHIS の本ガイドラインについても、継続検討を行うこととしていたため、上記に発行された３つのガイドライン（更新版を含めると４つ）の内容を反映し、2011 年 4 月に第３版として発行した。
上記の後、総務省の「ASP･SaaS 事業者が医療情報を取り扱う際の安全管理ガイドライン」は 2010年 12 月に第 1.1 版、及び、経済産業省の｢医療情報を受託管理する情報処理事業者向けガイドラ
イン」は 2012 年 10 月に第 2 版が発行された。JAHIS の本ガイドラインについても、継続検討を行うこととしていたため、上記に発行された 2 つのガイドラインの内容を反映し、第３．１版として発行することとなった。
本ガイドラインは、JAHIS 会員各社の意見を集約し、「JAHIS 標準」の一つとして発行したものである。従って、会員各社がシステムの開発・更新に当たって、本ガイドラインに基づいた開発・改良を行い、本ガイドラインに準拠していることをその製品のカタログ・仕様書等に示し、さら© JAHIS 2013i

にその製品のユーザに運用で担保すべきことを説明する場合などに使われることを期待している。
また、本ガイドラインを、診療録及び診療諸記録の電子保存機能を持つシステムを導入しようとしている施設が参照し利用することは歓迎するところであるが、当該システムが厚生労働省通知及び総務省通知及び経済産業省通知に合致しているか否かの判断は、自己責任の下で自ら判断する必要があること、及び、上記の関係通知は今後も改定が行われる予想されるため、本ガイド
ラインにおいても必要に応じて改版を行う予定であるので、常に最新版を参照することにご留意いただきたい。
なお、本ガイドラインで扱うセキュリティ要件は、社会状況にあわせて常に変化するものであり、利用いただく時点で必ずしも適当ではない内容である可能性もある。我々としても継続的に検討を重ねてゆく所存であるが、本ガイドラインの利用者はその点もご留意頂くとともに、お気づきの点をフィードバックして頂けるとありがたい。
本ガイドラインが「法令に保存義務が規定されている診療録及び診療諸記録」を扱うシステムの、また関連する医療情報システムの開発に多少とも貢献できれば幸いである。
２０１３年４月
一般社団法人 保健医療福祉情報システム工業会
医療システム部会 セキュリティ委員会

＜＜

告知事項

＞＞

本規約は関連団体の所属の有無に関わらず、規約の引用を明示することで自由に使用することができるものとします。ただし一部の改変を伴う場合は個々の責任において行い、本規約に準拠する旨を表現することは厳禁するものとします。
本規約ならびに本規約に基づいたシステムの導入・運用についてのあらゆる障害や損害について、本規約作成者は何らの責任を負わないものとします。ただし、関連団体所属の正規の資格者は本規約についての疑義を作成者に申し入れることができ、作成者はこれに誠意をもって協議するものとします。

© JAHIS 2013

ii

目

次

1.

はじめに .................................................................................................................................... 1

2.

概要 ........................................................................................................................................... 2

3.

主な用語 .................................................................................................................................... 3

4.

適応範囲 .................................................................................................................................... 5
4.1.
4.2.
4.3.
4.4.
4.5.

5.

ベンダーの責任のあり方 .......................................................................................................... 9
5.1.
5.2.

6.

医療情報システムの安全管理に関するガイドラインとの関係 ......................................... 5
本ガイドラインの対象システム及び対象情報 .................................................................. 7
総務省のガイドライン及び、経済産業省のガイドラインとの関係.................................. 7
他の JAHIS 標準・技術文書との関係............................................................................... 7
引用規格・引用文献 .......................................................................................................... 8
医療機関の責任とベンダーの提供する医療情報システムの関係 ..................................... 9
ベンダーの責任 .................................................................................................................. 9

情報システムの基本的な安全管理 .......................................................................................... 10
6.1. 医療機関における情報セキュリティマネジメントシステム(ISMS）の実践 ................. 10
6.1.1. ISMS 構築の手順 ......................................................................................................11
6.1.2. 取扱い情報の把握 ..................................................................................................... 12
6.1.3. リスク分析 ................................................................................................................ 13
6.2. 技術的安全対策 ................................................................................................................ 14
6.3. 情報の破棄 ....................................................................................................................... 25
6.4. 情報システムの改造と保守.............................................................................................. 27
6.5. 情報および情報機器の持ち出しについて........................................................................ 32
6.6. 災害等の非常時の対応 ..................................................................................................... 34
6.7. 外部と個人情報を含む医療情報を交換する場合の安全管理 .......................................... 38
6.8. 法令で定められた記名・押印を電子署名で行うことについて ....................................... 46

7.

電子保存の要求事項について ................................................................................................. 53
7.1. 真正性の確保について ..................................................................................................... 54
7.1.1. 作成者の識別及び認証.............................................................................................. 54
7.1.2. 記録の確定手順の確立と、作成責任者の識別情報の記録 ....................................... 58
7.1.3. 更新履歴の保存 ........................................................................................................ 61
7.1.4. 代行操作 ................................................................................................................... 62
7.2. 見読性の確保について ..................................................................................................... 65
7.2.1. 情報の所在管理 ........................................................................................................ 65
7.2.2. 見読化手段の管理 ..................................................................................................... 66
7.2.3. 見読目的に応じた応答時間とスループット ............................................................. 67
7.2.4. システム障害対策としての冗長性の確保 ................................................................ 68
7.2.5. システム障害対策としてのバックアップデータの保存 .......................................... 69
7.3. 保存性の確保について ..................................................................................................... 70
7.3.1. 不適切な保管・取扱いによる情報の滅失、破壊の防止 .......................................... 70© JAHIS 2013iii

7.3.2.
8.

媒体・機器・ソフトウェアの整合性不備による復元不能の防止 ............................ 72

診療録及び診療諸記録を外部に保存する際の基準 ................................................................ 74
8.1. 厚生労働省の医療情報システムの安全管理に関するガイドラインに関する事項.......... 77
8.1.1. ネットワークを通じて医療機関等の外部に保存する場合の真正性の確保 ............. 77
8.1.2. ネットワークを通じて医療機関等の外部に保存する場合の見読性の確保 ............. 79
8.1.3. ネットワークを通じて医療機関等の外部に保存する場合の保存性の確保 ............. 80
8.2. 経済産業省の医療情報を受託管理する情報処理事業者向けのガイドラインに関する事項
81
8.2.1. 情報の分類 ................................................................................................................ 81
8.2.2. 情報処理装置及びソフトウェアの保守 .................................................................... 81
8.2.3. 悪意のあるコードに対する管理策 ........................................................................... 83
8.2.4. 情報交換に関するセキュリティ ............................................................................... 84
8.2.5. 情報処理システムに対するセキュリティ要求事項 .................................................. 85
8.2.6. アプリケーションに対するセキュリティ要求事項 .................................................. 85
8.2.7. 暗号による管理策 ..................................................................................................... 86
8.2.8. ログの取得及び監査 ................................................................................................. 86
8.2.9. アクセス制御方針 ..................................................................................................... 88
8.2.10.
作業者アクセス及び作業者 ID の管理.................................................................. 89
8.3. 総務省の ASP・SaaS 事業者が医療情報を取り扱う際の安全管理に関するガイドライン
に関する事項 .............................................................................................................................. 93
8.3.1. 真正性の確保における ASP・SaaS 事業者への要求事項 ....................................... 93
8.3.2. 外部保存における ASP・SaaS 事業者への要求事項............................................... 93
8.3.3. ASP・SaaS の提供終了における ASP・SaaS 事業者への要求事項 ...................... 94

9.

診療録等をスキャナ等により電子化して保存する場合について .......................................... 95
9.1.
9.2.

共通の要件 ....................................................................................................................... 95
診療等の都度スキャナ等で電子化して保存する場合 ..................................................... 99

付録―１．リスクアセスメントの実施例 .................................................................................... 100
１－１ リスクアセスメントの手法 ........................................................................................ 100
１－２ 情報セキュリティ基本方針 ........................................................................................ 100
１－３ リスクアセスメントの実施例 .................................................................................... 100
付録―２．参考文献 ...................................................................................................................... 111
ヘルスケア PKI 関連文書 .......................................................................................................... 111
タイムスタンプ及び長期保存に関する標準やガイドライン .................................................... 111
付録―３．作成者名簿 ..................................................................................................................113© JAHIS 2013iv

1. はじめに2005 年 3 月に、厚生労働省から「法令に保存義務が規定されている診療録及び診療諸記録」の電子保存に係るガイドラインとして「医療情報システムの安全管理に関するガイドライン」（以下、「安全管理のガイド
ライン」と記載）が発行された。このガイドラインは、従来のガイドラインと比較して、理解のしやすさを考慮して、現状で選択可能な技術にも具体的に言及するなど、細かな点にも踏み込んだ内容となっている。
しかしながら、実際に医療施設にシステムを導入するベンダーの立場から見た場合、一部の内容についてはより具体的な基準を示す必要がある状況である。
このような状況に対し、本ガイドラインでは JAHIS の立場から、現在のセキュリティ技術水準を前提に
ネットワークによって外部と接続されたシステム環境のセキュリティ保護に関して、「安全管理のガイドライン」から「法令に保存義務が規定されている診療録及び診療諸記録」に関する要件を技術的な対策と運用的な対策に分けてより細かく示すこととした。その上で、「技術的にどの範囲まで担保することが望ましいか、
また技術的に対応しにくい要件を運用でどのように担保することが期待されるか」を具体的に示すことにより、診療録等の電子保存およびネットワークを介した送受信を適切に行うための基準を示すことも目的とした。
本ガイドラインは、JAHIS 会員各社の意見を集約し、「JAHIS 標準」の一つとして発行したものである。
従って、会員各社がシステムの開発・更新に当たって、本ガイドラインに基づいた開発・改良を行い、本ガ
イドラインに準拠していることをその製品のカタログ・仕様書等に示し、さらにその製品のユーザに運用で担保すべきことを説明する場合などに使われることを期待している。
また本ガイドラインを、診療録及び診療諸記録の電子保存機能を持つシステムを導入しようとしている施設が参照し利用することは歓迎するところであるが、当該システムが厚生省通知に合致しているか否かの判
断は、自己責任の下で自ら判断する必要があることをご留意頂きたい。
なお、本ガイドラインで扱うセキュリティ要件は、社会状況にあわせて常に変化するものであり、利用い
ただく時点で必ずしも適当ではない内容である可能性もある。我々としても継続的に検討を重ねてゆく所存であるが、本ガイドラインの利用者はその点もご留意頂くとともに、お気づきの点をフィードバックして頂けると幸いである。

© JAHIS 20131

2. 概要本ガイドラインは３省ガイドラインのうち電子保存と外部保存のガイドラインについて、システムベンダ
ーの視点から解説を行った方が良いと思われる箇所について解説を行ったものである。
本ガイドラインの各節の構成であるが、まず、「安全管理ガイドライン」の「C.最低限のガイドライン」、「D.推奨されるガイドライン」の要求事項を表形式で示した。その後に、表の各行毎に技術的対策・運用的対策のそれぞれについて基準を示し、解説を行うこととした。本ガイドラインでは、内容を「最低限」と「推奨」の二つに分けることは行わず、JAHIS として満たすべき基準を示した。従って、「D.推奨されるガイド
ライン」の内容に該当する項目であっても、必要な場合にはガイドラインの項目として列挙した。また、技術的対策が実現困難な場合は、それを補完する運用的対策を示しており、技術的対策・運用的対策を組み合わせることによってセキュリティを確保できるようにした。なお、「技術的対策」、「運用的対策」以外に考慮
しなければならない事項がある場合は、「その他」に記載することとした。
基本的には上記の構成に従って、各節にて JAHIS としての基準と解説を行っているが、節の内容的にこの構成がそぐわない場合は、内容に応じて構成を変えることとした。

© JAHIS 20132

3. 主な用語
アカウント：特定のコンピュータ システム、もしくはネットワークにアクセスするために「認証」される人を表現しており、権限属性をもつことがある。

アクセス制御：コンピュータセキュリティにおいて、ユーザがコンピュータシステムの資源にアクセスすることができる権限・認可をコントロールすること。

アクセスログ：情報の作成、変更、参照、削除などの記録。

インシデント：情報セキュリティリスクが発現・現実化した事象。

改ざん：情報を管理者の許可を得ずに書き換える行為

外部保存：法令に基づく保存義務のある診療録ならびに診療に関する諸記録を、それらが作成された病院または診療所以外の施設に保存すること

監査証跡：監査対象システムの入力から出力に至る過程を追跡できる一連の仕組みと記録のこと。

見読性：電子媒体に保存された内容を、権限保有者からの要求に基づき必要に応じて肉眼で見読可能な状態にできること。

個人情報（患者の個人情報）：当該情報に含まれる氏名、生年月日、その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。
）をいう。
残存リスク（または残留リスク）：リスクマネジメントの結果、未対応部分として残るリスクのこと。
真正性：正当な人が記録し確認された情報に関し第三者から見て作成の責任の所在が明確であり、かつ、故意または過失による、虚偽入力、書き換え、消去、及び混同が防止されて
いること。

ぜい弱性

：コンピュータやネットワークといった情報システムに対し、アクセス許可のない第三者からの侵入など脅威となる行為に利用できる可能性のあるシステム上の欠陥。または仕様上の問題点。

相互運用性：異なったアプリケーションやシステム、構成コンポーネント間で情報の伝達または共有がなされ相互に接続、利用できる共通性を持つこと。

タイムスタンプ：電子データがタイムスタンプを付与した時刻から存在し、それ以降、改ざんされていないことを証明することができる電子情報。
タイムスタンプトークンとも呼ばれ、正確、かつ適切に管理された時刻情報を有し、ハッシュや公開鍵暗号技術を用いて対象データの非改ざん性を担保することができる。特に、タイムスタンプに高い信頼性が求められ© JAHIS 2013

3

る場合、
（財）日本データ通信協会の「タイムビジネス信頼・安心認定制度」の認定を受けたタイムスタンプが要求される。
デバイス：コンピュータに搭載あるいは接続されるハードウェア。

電子署名：電子データの正当性を保証するために付される電子的な署名情報。公開鍵暗号などを利用し、署名者本人が付与したものであることを確認することができ、また、署名対象
情報が改ざんされていないことを証明することができる情報。
公開鍵暗号方式を用いて生成した署名はデジタル署名ともいう場合もあるが、本ガイドラインでは、“電子署名“で統一した。

保存性：記録された情報が法令等で定められた期間に渡って真正性を保ち、見読可能にできる状態で保存されること。

リスクアセスメント ：本書においては、情報資産に対して、その情報がもつ重要度、発生確率、影響度などを評価・分析し、情報資産が内包するリスクを測定すること。
リスクマネジメント ：リスクアセスメントによって特定されたリスクに対して、そのリスクを低減させるプ
ロセス。
PDCA サイクル：Plan（計画）、Do（実施）、Check（検証）、Act（行動）のマネジメントサイクル。

（記号および略語 このガイドラインでは、次の記号および略語・表記を用いる。
）
HIPAA：The Health Insurance Portability and Accountability Act
米国の、医療保険の携行と責任に関する法律

ISMS：Information Security Management System
情報セキュリティマネジメントシステム

ISP：Internet Service Provider
インターネット・プロバイダ、インターネット・サービス・プロバイダ

JAHIS：Japanese Association of Healthcare Information Systems Industry
一般社団法人 保健医療福祉情報システム工業会 （http://www.jahis.jp)

JIPDEC：Japan Information Processing Development Corporation
財団法人 日本情報処理開発協会

JIRA：Japan Industries Association of Radiological Systems
日本画像医療システム工業会（http://www.jira-net.or.jp）

PKI：Public Key Infrastructure
公開鍵基盤

VPN

：Virtual Private Network
仮想的な専用通信回線© JAHIS 20134

4. 適応範囲4.1. 医療情報システムの安全管理に関するガイドラインとの関係
本ガイドラインは、「安全管理ガイドライン」で示されている三つのガイドライン（個人情報保護、電子保存、外部保存）のうち、電子保存と外部保存のガイドラインについて、ベンダーの視点からより詳細な解説を行った方が良いと思われる箇所について、技術的な対策と運用的な対策に分けて基準を示し、解説を行ったものである。

今回対象

今回対象
外部保存のガイドライン

今回
対象外

電子保存のガイドライン
個人情報保護のためのガイドライン
個人情報を扱う保存が義務付けシステム
られた記録を扱（医事システムや検体検査システムなどを含うシステム
む殆どの医療情報システム）（電子カルテシステム等）

保存が義務付けられた記録を扱うシステムで外部保存をする場合（電子カルテシステム等）

なお、本ガイドラインで詳細基準を定めた箇所は、「安全管理ガイドライン」の中で主に技術的基準を定めた部分であり、「安全管理ガイドライン」と本ガイドラインとの対応する章節は以下の通りである。
安全管理ガイドライン
本ガイドライン3章
本ガイドラインの対象システム及び対象情報
6.2. 医療機関における情報セキュリティマネジ
メントシステム(ISMS）の実践
6.5
技術的安全対策
6.7
情報の破棄
6.8
情報システムの改造と保守
6.9
情報および情報機器の持ち出しについて
6.10
災害等の非常時の対応© JAHIS 2013
5

４．
２ 本ガイドラインの対象システム及び対象情報
６．１ 医療機関における情報セキュリティマ
ネジメントシステム(ISMS）の実践
６．５ 技術的安全対策
６．３ 情報の破棄
６．８ 情報システムの改造と保守
６．
５ 情報および情報機器の持ち出しについて
６．６ 災害等の非常時の対応

安全管理ガイドライン

本ガイドライン6.11
外部と個人情報を含む医療情報を交換する場合
の安全管理
6.12
法令で定められた記名・押印を電子署名で行うこ
とについて
7.1
真正性の確保について
7.2
見読性の確保について
7.3
保存性の確保について
8.1
電子媒体による外部保存をネットワークを通じ
て行う場合
9.1
共通の要件
9.2
診療等の都度スキャナ等で電子化して保存する
場合

６．
７ 外部と個人情報を含む医療情報を交換する場合の安全管理© JAHIS 2013

6６．８ 法令で定められた記名・押印を電子署名で行うことについて
７．１ 真正性の確保について
７．２ 見読性の確保について
７．３ 保存性の確保について
８．１ 厚生労働省の医療情報システムの安全管理に関するガイドラインに関する事項
９．１ 共通の要件
９．
２ 診療等の都度スキャナ等で電子化して保存する場合4.2. 本ガイドラインの対象システム及び対象情報
本ガイドラインの対象システムは、医療機関に対し保存が義務付けられている診療録等の電子保存を行うシステムである。「安全管理ガイドライン」は医療に関わる情報を扱う全ての情報システムを対象としているが、本ガイドラインでは電子保存を行うシステムに限定している。ただし、電子保存を行わないシステムにも非常に有用な内容になっており、ぜひ参考にしていただきたい。以下に対象となる可能性が高いシステ
ムの例を示す。
・ 電子カルテシステム
・ オーダエントリシステム
・ 診療部門システム（看護支援システム、手術システムなど）
・ 臨床・病理検査システム
・ 医用画像システム
・ 放射線システム
また、対象情報については「安全管理ガイドライン」の「3 章 本ガイドラインの対象システム及び対象情報」を参照願いたい。

4.3. 総務省のガイドライン及び、経済産業省のガイドラインとの関係
本ガイドラインは、サービスを提供する事業者向けに発行された総務省及び経済産業省のガイドラインで要求されている項目の内、情報処理システムに関する要求と思われる部分について、ベンダーの視点から技術的な解説を行なったものである。

4.4. 他の JAHIS 標準・技術文書との関係
本ガイドラインの前提は「安全管理ガイドライン」であるが、他の JAHIS 標準や技術文書に規定されている規格やガイドラインがある場合には、相互運用性や見読性の確保などの観点から、技術的管理策などを選択する際に積極的に採用することを推奨している。また、現時点で JAHIS 標準や技術文書において規定されていない領域において、将来 JAHIS 標準や技術文書により規格やガイドラインが規定された場合にはそれらを優先的に採用することを妨げるものではない。

© JAHIS 20137

4.5. 引用規格・引用文献
・ 厚生労働省 保健医療福祉分野 PKI 認証局 証明書ポリシ（以降 HPKI 証明書ポリシと記述する）
http://www.mhlw.go.jp/shingi/2005/04/s0401-1.html
・ 厚生労働省 医療情報システムの安全管理に関するガイドライン第 4.1 版 2010 年 02 月（略称：安全管理ガイドライン）
http://www.mhlw.go.jp/shingi/2010/02/s0202-4.html
・ 経済産業省 医療情報を受託管理する情報処理事業者向けガイドライン第 2 版 2012 年 10 月
（略称：医療情報受託管理ガイドライン）
http://www.meti.go.jp/policy/it_policy/privacy/iryouglv2.pdf
・ 総務省 ASP・SaaS 事業者が医療情報を取り扱う際の安全管理に関するガイドライン第 1.1 版 2010年 12 月（略称：ASP・SaaS 医療情報ガイドライン）
http://www.soumu.go.jp/menu_news/s-news/02ryutsu02_000010.html© JAHIS 20138

5. ベンダーの責任のあり方
5.1. 医療機関の責任とベンダーの提供する医療情報システムの関係「安全管理ガイドライン」において、情報の取扱いについても医療機関の自己責任で行う必要がある旨が明記されている。自己責任は「説明責任」、「管理責任」、「結果責任」を果たすこととされており、特にその中でも「説明責任」と「管理責任」には特段の配慮が必要とされている。
医療機関は自らの責任で「結果責任」はもとより、「説明責任」と「管理責任」を果たさねばならないが、自らの責任の下に自己責任を果たすために技術的対策を施した製品を導入することや、業務を外部委託することが許されている。ベンダーは主として技術的対応を施した医療情報システムを提供することで、医療機関の「説明責任」、「管理責任」を全うすることを補助することが期待されている。医療機関はベンダーが提供する技術的対策と自らが実施する運用的対策と組み合わせて「安全管理ガイドライン」の求める基準に適合させる必要がある。
そのため、ベンダーは提供する医療情報システムにおいて（1）どのような技術的対策を実施しているのか。
（2）正しくシステムを利用するために注意すべきことは何か。
といったことを明らかにし、医療機関に正しく伝える必要がある。

5.2. ベンダーの責任
ベンダーは自らの提供する医療情報システムに対して民法上の責任と製造物責任法（PL 法）上の責任を果たさねばならない。
（ソフトウェア単独で提供を行う場合は PL 法の対象とはならないが、コンピュータなどの機器にあらか
じめ組み込んで全体をシステムとして提供した場合は動産になるので対象になるとされている）
PL 法では以下の三つの欠陥についてベンダーが責任を問われることとなっている。
（1）設計上の欠陥（安全法規や基準に適合していない場合など）（2）製造上の欠陥（不良な原材料や部品を利用した場合など）（3）表示上の欠陥（マニュアルなどに適切な注意事項の記載がない場合など）
これらについては欠陥がないことの立証責任がベンダー側にあるため、ベンダーがその旨を立証しなければならない。
また、民法の 709 条においては、「故意または過失によって他人の権利を侵害したる者はこれによって生じたる損害を賠償する責めに任ず」となっている。これについては権利侵害の立証責任は医療機関側にあるため、医療機関がその旨を立証しなければならない。
このような法律上の責任を問われないように、欠陥のない医療情報システムを提供することがベンダーにおける最も重要な責務である。

© JAHIS 20139

6. 情報システムの基本的な安全管理
本章では、「安全管理ガイドライン」の以下の節について JAHIS の視点から基準を示し、解説を行ったものである。
安全管理ガイドライン
本ガイドライン
6.2
医療機関における情報セキュリティマネジメ
ントシステム（ISMS）の実践
6.5
技術的安全対策
6.7
情報の破棄
6.8
情報システムの改造と保守
6.9
情報および情報機器の持ち出しについて
6.10
災害等の非常時の対応
6.11
外部と個人情報を含む医療情報を交換する場
合の安全管理6.12
法令で定められた記名・押印を電子署名で行うことについて

６．１
医療機関における情報セキュリティマネジメ
ントシステム(ISMS）の実践
６．２
技術的安全対策
６．３
情報の破棄
６．４
情報システムの改造と保守
６．５
情報および情報機器の持ち出しについて
６．６
災害等の非常時の対応
６．７
外部と個人情報を交換する場合の安全管理
６．８
法令で定められた記名・押印を電子署名で行うことについて6.1. 医療機関における情報セキュリティマネジメントシステム(ISMS）の実践
医療情報システムを安全にかつ有効に運用することに責任を負うのは医療機関である。ベンダーの責任は二次的なものになるが、医療機関が情報セキュリティ管理（以下、ISMS）を行う際に必要とする情報の提供に関する要望には、適切に応えられるようにしておかなければならない。
本ガイドラインでは、「安全管理ガイドライン」が医療機関に求める ISMS の実施レベルを実現するために、ベンダー側がどのような情報提供をできるように用意しておくべきか、という観点で記述する。

© JAHIS 201310

6.1.1. ISMS 構築の手順＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
項目なし

推奨されるガイドライン
項目なし

冒頭にも述べたように、ISMS を計画し、実際に導入する責任を負うのは医療機関であるが、情報システ
ムや情報機器を納入するベンダーからの正確な情報提供がなければ、実効力のある ISMS を企画し、構築することはできない。
参考までに、
JIS Q 27001:2006 で規定されている、
情報システムに直接関連すると考えられる管理項目（付
録－１による）の例を下記に示す。医療機関が JIS Q 27001:2006 に従って ISMS を構築する場合には、情報システムがこれらの管理策を採用する際にどのような機能を提供実現できるかを説明できるようにしておかなければならない。そうでない場合でも、同様の情報提供が求められることになると考えられる。
A.9.2
A.10.1
A.10.3A.10.4A.10.5
A.10.6
A.10.8A.10.10A.11.2
A.11.3A.11.4A.11.5A.11.6
A.11.7A.12.1
A.12.2
A.12.3A.12.4A.12.5A.12.6© JAHIS 2013

装置のセキュリティ
運用の手順及び責任システムの計画作成及び受け入れ
悪意のあるコードおよびモバイルコードからの保護
バックアップネットワークセキュリティ管理
情報の交換
監視
利用者アクセスの管理
利用者の責任ネットワークのアクセス制御
オペレーティングシステムのアクセス制御
業務用ソフトウェアのアクセス制御
モバイルコンピューティング及びテレワーキング
情報システムのセキュリティ要求事項
業務用ソフトウェアでの正確な処理
暗号による管理策
システムファイルのセキュリティ
開発及びサポートプロセスにおけるセキュリティ
技術的ぜい弱性管理116.1.2. 取扱い情報の把握＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
項目なし

推奨されるガイドライン
項目なし

情報セキュリティ管理を構築する場合には、まず守るべき対象（保護資産）を識別することから始めなけ
ればならない。ここでの保護対象資産は、医療機関に納入した情報システムに含まれる情報と考える。ベンダーは、自社が納入し、稼働している情報システムに含まれる情報を識別し、医療機関に説明できなければならない。
また、識別された情報は、安全管理上の観点での分類がなされている必要がある。これは次節で述べるリスク分析を行う際の重要な判断基準となる。
下記に識別されるべき情報の例、およびそれらを重要度によって分類した例を示す。
＜表＞ 情報の識別と分類の例
情報システム名
医事会計

オーダエントリ

情報
患者基本

重要度

備考

患者

大

業務

中

保険情報

患者

小

薬剤マスター

患者

小

業務

大

医療過誤につながる可能性

患者

大

機微な個人情報

業務

中

検査履歴

© JAHIS 2013

観点12

機微な個人情報

6.1.3. リスク分析＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
項目なし

推奨されるガイドライン
項目なし

リスク分析は ISMS の実施に際して医療機関が行うべきものであるが、ベンダーは医療機関が想定した脅威に対して、どの程度対抗できるか、またそのためにどのような機能を実装しているかについて、説明できなければならない。この説明を確実に行うために、あらかじめ顧客環境内での脅威を想定して、その対抗策
を、想定運用も含めて説明できるだけの用意をしておくことが望ましい。
下記に保護対象とする情報ごとに整理した例を示す。
(1)

想定リスク

当該の情報について想定されるリスクの一覧。たとえば、「ディスククラッシュによる破壊」、「端末をのぞき見されることによる漏えい」、「通常業務とは関係ない興味本位の情報アクセス」など。
(2)

管理策

想定リスクごとの管理策（対抗策）。たとえば、「ディスククラッシュによる破壊」であれば「バックアップ」、「端末をのぞき見されることによる漏えい」であれば「スクリーンセーバの設定」、「通常業務とは関係ない興味本位の情報アクセス」であれば「アクセスログの収集と日常的なログ解析による抑止」など。
(3)

利用できる機能管理策を実施するために、当該の情報システムで利用可能な機能や運用方法など。たとえば、「アクセスログの収集と日常的なログ解析による抑止」であれば、「収集可能なログ情報(4)

効果、残存リスク等

上記の管理策を実行した結果、どの程度のリスク低減効果があるか。また、残存リスクはどのようなものがあるか。
「付録－１ リスクアセスメントの実施例」にリスク分析の具体的な考え方と手順を示したので参考にされたい。

© JAHIS 201313

6.2. 技術的安全対策(1)

利用者の識別と認証＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

1． 情報システムへのアクセスにおける利用者 項目なしの識別と認証を行うこと。
技術的対策

(a)
(ア)
(イ)

運用的対策

(b)
(ア)
(イ)

(ウ)

(エ)

(2)

システム利用ユーザ登録の権限を持つ者以外によるユーザ登録が行われない仕組みを実装すること。
システム利用者の長期休職等により、長期間使用されない ID が有効になったままではパスワードが推測される可能性が高くなるため、ID を削除可能な仕組みを実装すること。
もし可能であれば、ID 無効化・有効化の仕組みを実装し、システム利用者が休職前と復職後で同一の ID を利用できることが望ましい。

システム利用者の ID・パスワードや IC カード、電子証明書、等の発行ルール、および、本人への配布手段を規定化するよう医療機関に推奨すること。
情報システムの短期利用者向けに ID を再利用する場合は、
ID 再利用までに一定の期間をおき、再利用初回に確実に本人のみが知りえる情報または持ちえる情報を識別情報として登録するよう医療機関に推奨すること。
また、ID の利用開始と終了日時を管理台帳等で管理・保管し、ある期間において誰が該当 IDを使用していたかを後日調査可能とするよう医療機関に推奨すること。
不要となった ID は速やかに削除するよう医療機関に推奨すること。
さらに、可能であればシステム利用者の勤務表等を用いて、勤務時間以外等の不審なアクセスが存在しないかを定期的に確認するよう医療機関に推奨することが望ましい。
一つの ID を複数人で共有しないよう医療機関に推奨すること。

パスワードを使用した認証＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

2． 本人の識別・認証にユーザ ID とパスワー 4． パスワードを利用者識別に使用する場合以ドの組み合わせを用いる場合には、それら下の基準を遵守すること。
の情報を、本人しか知り得ない状態に保つ(1) パスワード入力が不成功に終わった場合よう対策を行うこと。
の再入力に対して一定不応時間を設定すること。
10． パスワードを利用者識別に使用する場合、システム管理者は以下の事項に留意する(2) パスワード再入力の失敗が一定回数を超© JAHIS 201314

最低限のガイドライン
こと。
(1) システム内のパスワードファイルでパス
ワードは必ず暗号化(可能なら不可逆が望ましい)され、適切な手法で管理及び運用が行われること。(利用者識別に IC カード
等他の手段を併用した場合はシステムに応じたパスワードの運用方法を運用規程にて定めること)推奨されるガイドライン
えた場合は再入力を一定期間受け付けない機構とすること。

(2) 利用者がパスワードを忘れたり、盗用される恐れがある場合で、システム管理者がパスワードを変更する場合には、利用者の本
人確認を行い、どのような手法で本人確認を行ったのかを台帳に記載(本人確認を行った書類等のコピーを添付)し、本人以外が知りえない方法で再登録を実施すること。
(3) システム管理者であっても、利用者のパス
ワードを推定できる手段を防止すること。
(設定ファイルにパスワードが記載される等があってはならない。)
(a)
(ア)
(イ)

(ウ)
(b)
(ア)
(イ)
(ウ)

技術的対策
パスワード入力の失敗による不応答時間の設定を行うことが可能な機能を実装することが望ましい。不応答時間は医療機関の判断によって設定可能であることが望ましい。
一定回数以上のパスワード入力失敗が連続した場合に、アカウントの利用を停止可能な機能を実装することが望ましい。利用停止されたアカウントの回復は、権限があるユーザのみによって可能であることが望ましい。
交付時の初期パスワードの本人による変更や、パスワード変更を可能とする仕組みを実装する
こと 。
運用的対策
パスワード漏洩等の事故事案が見つかった場合の連絡を滞りなく行えるよう、連絡先や手順を明確にし、システム利用者に知らせるよう医療機関に推奨すること。
必ず本人しか知り得ない状態を保つよう、モニタ等へのパスワードが記載されたメモ書き等の張り紙行為を禁止するなどの対策を推奨すること。
定期的なパスワード変更がシステムで可能な場合は、利用者に定期的なパスワードの変更をさせること。

© JAHIS 2013

15

(3)

パスワード以外を使用した認証＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

5． 認証に用いられる手段としては、ID＋バイ
オメトリックスあるいは IC カード等のセキュリティ・デバイス＋パスワードまたは
バイオメトリックスのように利用者しか持ち得ない 2 つの独立した要素を用いて行う方式（2 要素認証）等、より認証強度が高い方式を採用することが望ましい。

項目なし

技術的対策

(a)
(ア)

認証にバイオメトリックスを使用する場合には、認証に使用する身体的特徴情報が読取装置の外部へ出ない構造か、身体的特徴情報を暗号化してから読取装置の外部へ送り出す構造のものを使用すること。
運用的対策

(b)
(ア)

(4)

推奨されるガイドライン

二つの独立した要素の組み合わせとして、公開情報となっている ID と取得すると誰でも利用できるUSBトークンのように比較的容易に他人が入手可能な要素同士のみの組み合わせは避ける
ことが望ましい。

利用者によるパスワード管理＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
10． パスワードを利用者識別に使用する場合、 項目なし
利用者は以下の事項に留意すること。
(1) パスワードは定期的に変更し（最長でも 2ヶ月以内）、極端に短い文字列を使用しな
いこと（8 バイト以上の可変長の文字列が望ましい）。
(2) 類推しやすいパスワードを使用しないこと。

© JAHIS 201316

推奨されるガイドライン

技術的対策

(a)
(ア)
(イ)

(ウ)

運用的対策

(b)
(ア)

(イ)

(5)

初期パスワードの変更をシステムが求める機能を実装することによって、初期パスワードが利用され続けることがないようにすることが望ましい。
一定期間パスワードが変更されていないシステム利用者の検索機能、不可逆変換を施したパス
ワード履歴を保持することによって同一のシステム利用者が同一パスワードを設定することの抑制機能等の管理機能を実装することが望ましい。
一定期間パスワードの変更が行われていないシステム利用者に対する警告機能が実装されていることが望ましい。

パスワードの設定時に、推測し易いパスワードを設定しないこと、パスワードを記載したメモを作成しても良いが他人に渡らないようにすること、入力するところを他の人に見られないよ
うに注意すること等を医療機関の責任者またはその代行者はシステム利用者に教育するよう医療機関に推奨すること。
事故事案が発生した場合には、速やかに責任者またはその代行者に連絡するよう教育することも医療機関に推奨すること。

情報の区分管理とアクセス制御＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

5． 医療従事者、関係職種ごとに、アクセスで 1． 情報の区分管理を実施し、区分単位でアクきる診療録等の範囲を定め、そのレベルにセス管理を実施すること。
沿ったアクセス管理を行うこと。
また、アクセス権限の見直しは、人事異動等による利用者の担当業務の変更等に合わせて適宜行うよう、運用管理規程で定めていること。
複数の職種の利用者がアクセスするシス
テムでは職種別のアクセス管理機能があることが求められるが、そのような機能がない場合は、システム更新までの期間、運用管理規程でアクセス可能範囲を定め、次項の操作記録を行うことで担保する必要
がある。
(a)
(ア)
(b)
(ア)

技術的対策
アクセス権を設定する職種等の種類は固定でなく、医療機関の業務実態に合わせて自由に設定できることが望ましい。
運用的対策
上記技術的対策を実現している場合には、情報がどのように分類されており、それぞれに対してどのような権限を設定可能であるかをシステム提供者は明記しておくこと。さらに、これらの設定方法についても明記すると共に、医療機関の適切な責任者に十分説明することによって、© JAHIS 2013

17

(イ)

(6)

医療機関独自の判断で任意のタイミングにおいて設定できるようにすることが望ましい。
不要になった権限に関しては即座に削除するよう医療機関に推奨すること。

アクセス記録及びログの確認＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

6． アクセスの記録及び定期的なログの確認を 項目なし
行うこと。アクセスの記録は少すくなくとも利用者のログイン時刻および時間、ならびにログイン中に操作した患者が特定できること。情報システムにアクセス記録機
能があることが前提であるが、ない場合は
業務日誌等で操作の記録（操作者及び操作内容）を必ず行うこと。
「安全管理ガイドライン」では、上記要求事項以外にもアクセスログに対する削除／改ざん／追加等を防止する対策を講じことが要求されている。また、アクセスログの記録に使用する時刻は精度の高いものが要求されている。
これらの対策については本ガイドライン「6.2.技術的安全対策」および「7.1.3.更新履歴の保存」の関連箇所を参照のこと。
(a)
(ア)

(b)

技術的対策
アクセス記録、より厳密には監査証跡（Audit Trail）の記録は、「個人情報へのアクセスの履歴の確認」、「医療機関が説明責任を果たすために利用」、「副次的効果としての目的外アクセスの抑止」などを目的としている。これらの目的を満たすように実装すること。なお、監査証跡の標準規約としては「ヘルスケア分野における監査証跡のメッセージ標準規約 Ver.1.1」（JAHIS
標準文書 09-003）を参照のこと。また、MEDIS-DC から出されている、医療における監査証跡について平易にかつ具体的に解説している「個人情報保護に役立つ監査証跡ガイド」(http://www.medical-it-link.jp/)も参考のこと。
運用的対策

追記事項なし。

© JAHIS 2013

18

(7)

時刻管理

＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

8． アクセスの記録に用いる時刻情報は信頼で 項目なし
きるものであること。医療機関等の内部で利用する時刻情報は同期している必要があり、また標準時刻と定期的に一致させる等の手段で標準時と診療事実の記録として問題のない範囲の精度を保つ必要があ
る。
(a)
(ア)

(イ)
(b)
(ア)
(イ)

(ウ)

技術的対策
保存が義務付けられている記録を作成する全てのシステムにおいて時刻同期が必要であるが、その中でも、ネットワークに接続されるシステムは、NTP 等を使用して基準となる時刻源と同期をとることが可能な仕組みを実装すること。
時刻源となりうるサーバにおいては、院外の信頼ある時刻源と同期をとることが出来る仕組み、
または、標準電波等を使用して自動的に調時を行う仕組みを実装することが望ましい。
運用的対策
管理台帳等を用いて時刻源となっているサーバを明記しておくことを推奨する。
時刻源となっているサーバを保守等で長期間停止させる場合は、代替の時刻源を用意すること。
また、障害等で長期間停止した状態で放置されないよう定期的な稼動確認を行うよう医療機関に推奨すること。
ネットワークに接続されず独立して記録を作成するシステムであっても、実際の時刻と大きな差が生じないよう定期的に点検を行うよう医療機関に推奨すること。点検の時期及び方法を明記し、また点検したことを示す台帳等を作成することを推奨する。

© JAHIS 2013

19

(8)

不正ソフトウェアの排除

ウィルス等の不正なソフトウェアの混入を防ぐためには、医療機関でのシステム構築・運用ではもちろん、開発ベンダー社内でのシステム開発時から対策を行う必要がある。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
9． システム構築時や、適切に管理されていな 項目なし
いメディアを使用したり、外部からの情報を受け取る際にはウィルス等の不正なソ
フトウェアの混入がないか確認すること。

技術的対策

(a)
(ア)

開発環境を構築する場合には、メールの閲覧等の一般業務を行う環境から独立した環境で構築することが望ましい。独立した環境を構築することが困難な場合には、ウィルス対策ソフトを最新の状態に保ち、かつ常時起動させた状態にしておくこと。その他にも必要に応じてファイ
アウォールの適切な設置や、IDS を利用すること。
適切に管理されていないデバイスやソフトウェアは原則として使用しないこと。やむを得ず適切に管理されていないデバイスやソフトウェアを使用する場合には、最新のウィルス対策ソフト等を利用して十分な確認を行うこと。確認を行う端末は、開発環境とは接続されていないものを使用すること。ただし、ウィルス対策ソフトを利用したとしてもすべてのウィルスを検出できるとは限らないことに注意すること。
システム提供ベンダーが許可していないソフトウェアが、医療機関で稼動するシステムにインストールされない仕組みが実装されるか設定されることが望ましい。
医療機関の LAN が外部のネットワークと接続されている場合には、ウィルス対策ソフトの導入とそのパターンファイルを常時最新の状態に保つことが出来るシステム構成にすること。

(イ)

(ウ)
(エ)

運用的対策

(b)
(ア)
(イ)

(9)

過去に誰がどのような用途で使用したかが不明なメディアは、適切に管理されていないメディ
アと判断し、使用しないこと。また、医療機関に対しても注意を促すこと。
OS バージョンアップやパッチ適用等によって、アプリケーションが影響を受ける可能性があるため、適用前に実験機にて十分なテストを実施すること。

不正アクセスの排除＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

3. 外部のネットワークとの接続点や DB サー
バ等の安全管理上の重要部分にはファイ
アウォール（ステートフルインスペクショ
ンやそれと同等の機能を含む）を設置し、ACL(アクセス制御リスト)等を適切に設定すること。

項目なし© JAHIS 2013

推奨されるガイドライン

20

技術的対策

(a)
(ア)

(イ)

(ウ)

運用的対策

(b)
(ア)

(イ)

(10)

ファイアウォールや ACL の設定をデフォルトのまま放置せず、権限を持つ者のみがアクセス可
能となるよう適切な設定を行うこと。これらを設定した後に脆弱性を診断し、その結果に基づ
いて修正または追加の対策を行うこと。
医療機関のネットワークがインターネットに接続されている環境では、ファイアウォールに加えて、不正アクセスを受けていることを早期に知るために IDS を併用し、不正アクセスを継続的に監視・報告することが望ましい。
医療機関のネットワークを外部と接続する経路として、
インターネット、
インターネット VPN、
IP-VPN、専用線がある。一般的に後者のものほど、送受信中のデータに対する盗聴や改ざんおよび医療機関のネットワークへの不正アクセスに対して強固なセキュリティを確保することが可能である反面、コストが大きくなるという特徴がある。複数の経路を確保し目的別に利用できることが技術的には望ましいが、コスト的かつ運用的に現実的ではないため、医療機関の接続目的から適切な経路を選択することが望ましい。

適切に設定されたネットワークやシステムの各種設定内容を記録しておき、その記録と設定内
容を定期的に突き合わせることによって、システム環境が脆弱な状態に変更されていないことを確認すること。
職員の退職等により不要となったアカウントは速やかに削除し、休職等により不用となったア
カウントは速やかに無効化するよう医療機関に推奨すること。

一時的離席の対応＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

3． 入力者が端末から長時間、離席する際に、 2． 離席の場合のクローズ処理等を施すこと
正当な入力者以外の者による入力の恐れ（クリアスクリーン：ログオフあるいはパがある場合には、クリアスクリーン等の防スワード付きスクリーンセーバ等）。
止策を講じること。

(a)
(ア)
(イ)
(ウ)
(b)
(ア)

技術的対策
クローズ処理等の機能を実装することが望ましい。実装することが困難な場合には、OS 附属のパスワード付きスクリーンセーバ等を利用できるように端末を設定することが望ましい。
医療行為を妨げない範囲で、利用者端末の自動スクリーンロックを設定すること
利用者が離席する際に、利用者自らがスクリーンロックまたはログアウトできる仕組みを実装
すること
運用的対策
ログイン中のユーザ以外の者が容易にアクセス可能な場所に設置してある端末に関しては、一定期間無操作後の自動ロックを利用するのではなく、離席時に手動でロックをかけるよう教育し徹底させるよう医療機関に推奨すること。基本的に一定期間無操作後の自動ロックは補助的に使用することが望ましく、ログイン中のユーザが離席時に明示的にロックすることが望ましい。

© JAHIS 2013

21

(11)

動作確認

＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

4． 動作確認等で個人情報を含むデータを使用 項目なし
するときは、漏洩等に十分留意すること。
技術的対策

(a)
(ア)
(イ)
(ウ)
(エ)

運用的対策

(b)
(ア)
(イ)

(12)

個人情報を含むデータは極力使用しないことが望ましい。
動作確認は原則としてオンサイトで実施することが望ましい。特に個人情報等を含むデータによる動作確認はオンサイトで実施し、データ漏洩等の可能性を極力減らすこと。
やむを得ずデータを外部へ持ち出す場合には、データを匿名化することが望ましいが、困難な場合は転送経路の暗号化または暗号化機能を有するデバイスを使用すること。
個人情報を含むデータを外部へ持ち出した場合には、持ち出しに使用したメモリやディスクへのランダムビットの複数回書込みや物理的な裁断等の手段をとることによって、確認後のデー
タがメモリやディスク上に残らない確実な削除を実施すること。

個人情報保護法等の法令を遵守することや、データの管理責任を有する機関から個人情報の利用許可を受けること。
動作確認に使用するシステムがウィルス感染していないことや、近年の情報漏洩原因になっているファイル共有ソフト等がインストールされていないことを、個人情報を取り込む前に確認すること。

無線 LAN の利用時の対策

無線 LAN は、ケーブルの敷設や接続の必要がないという利点があり、昨今の無線 LAN ルータの低価格化とノートパソコンへの無線 LAN アダプタの標準装備により医療機関内で一般的に使われる情報インフラとなっている。
ただし、適切に使用しない場合、「通信内容の傍受（盗聴）」、「不正利用」、「無線 LAN アクセスポイントのなりすまし」等の脅威がある。さらに、電波を利用しているため、ケーブル LAN に比較して電波干渉による通信の途絶や遅延など可用性に劣る面がある。
無線 LAN を利用するシステムを構築するベンダーは、医療機関のシステム管理者と協力し、これらのリスクに留意し適切な対策を行わなくてはならない。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
11．無線 LAN を利用する場合
システム管理者は以下の事項に留意すること。
(1) 利用者以外に無線 LAN の利用を特定されないようにすること。例えば、ステルスモード、ANY 接続拒否などの対策をとること。
(2) 不正アクセスの対策を施すこと。少な© JAHIS 201322

推奨されるガイドライン
6.無線LAN のアクセスポイントを複数設置して運用する場合等は、マネジメントの複雑さが増し、侵入の危険が高まることがある。
そのような侵入のリスクが高まるような設置をする場合、例えば 802.1x や電子証明書
を組み合わせたセキュリティ強化すること。

最低限のガイドライン

推奨されるガイドライン

くともSSIDやMACアドレスによるア
クセス制限を行うこと。
(3) 不正な情報の取得を防止すること。例
えば、WPA/TKIP、WPA2/AES 等により、通信を暗号化し情報を保護すること。
(4) 電波を発する機器（携帯ゲーム機等）
によって電波干渉が起こり得るため、医療機関等の施設内で利用可能とする
場合には留意すること。
(5) 適用に関しては、総務省発行の「安心して無線 LAN を利用するために」を参考にすること。
技術的対策

(a)
(ア)
(イ)

(ウ)

(エ)

ステルスモードおよび ANY 接続拒否により無線 LAN 利用を秘匿すること
SSID などによるアクセス制限を行うこと。MAC アドレスによる認証は、運用コストの増大要因になること、MAC アドレス詐称が可能であることから、単独での使用は推奨しない。運用負荷の増大を容認する場合は、追加的対策として MAC アドレスによるアクセス制限を行うことも可能である
WPA/TKIP、WPA2/AES 等により、通信を暗号化すること。これらの暗号化方式の違いについては総務省発行の無線 LAN のセキュリティに関するガイドラインである「安心して無線 LANを利用するために」を参考にすること認証方式としては、鍵管理方式により、事前配布方式(WPA- PSK、WPA2- PSK)と IEEE802.1X
認証を用いた認証サーバによる方式（WPA-EAP、WPA2-EAP）等がある。どの方式を選択す
るかは、無線基地局の数によるメンテナンスコストと認証サーバのシステム運用コストの差を算出し決定すること。無線基地局が多い場合は、認証サーバを用いる方式がトータルコストとして安上がりになる場合がある
運用的対策

(b)
(ア)

電波を発する機器（携帯ゲーム機、電子レンジ、デジタルコードレス電話、Bluetooth 利用機器
等）によって電波干渉が起こり得る。無線 LAN を利用するシステムのベンダーはこれらの機器が使われているかどうかをチェックするとともに、医療機関のシステム管理者に対して、これらの機器の利用に関する対策を規定し、運用管理規定に反映するようにアドバイスすること【コラム】
無線 LAN による電波が医療機器等へ及ぼす影響については、総務省のホームページに「電波の医療機器等への影響に関する調査」の報告書が公開されているので、参考にすること。
（http://www.tele.soumu.go.jp/j/ele/medical/index.htm）(13)

ログの真正性確保

個人情報を含むデータをやり取りする場合、全てのアクセスの記録（アクセスログ）を取得し、定期的にその内容を監査してシステムの不正な利用がないことを確認することが必要となる。このアクセスログは、© JAHIS 201323

セキュリティ事故などが発生した場合に、その調査のために重要な証拠性を確保していなければならないた
め、アクセスログ自体へのアクセス制限を行い、アクセスログの不当な削除や改ざんを防止する対策を講じなければならない。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

7． アクセスログへのアクセス制限を行い、 項目なし
アクセスログの不当な削除／改ざん／追加等を防止する対策を講じること。
(a)
(ア)
(イ)
(ウ)

(b)

技術的対策
アクセスログへのアクセス制御を行う仕組みを実装すること
アクセスログを制御できる管理者のアクセス記録を取得すること
アクセスログの改ざんや故意による削除などを防止するため、日または時間単位でのアクセスログに対するタイムスタンプを行うことが望ましい

運用的対策

追記事項なし。

© JAHIS 201324

6.3. 情報の破棄「情報の破棄」は、「個別情報の消去（レコードの削除等）」と「装置そのものの廃棄に伴うデータ記憶
装置・媒体の破棄（記憶装置自体の破棄等、修理時等における記憶装置交換等を含む）」が考えられるが、ここでは後者について示す。前者についてもこの内容を適応できる場合があるが、情報の格納方法が独立したファイルである場合からデータベース内の削除処理等様々な状況が考えられるので、実際の破棄に備えて個別に安全な管理・消去方法等の手順を明確化しておく必要がある。
(1)

情報種別ごとに破棄の手順を定める＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

1． 「6.1 方針の制定と公表」で把握した情報 項目なし
種別ごとに破棄の手順を定めること。手順には破棄を行う条件、破棄を行うことができる従業者の特定、具体的な破棄の方法を含めること。
2． 情報処理機器自体を破棄する場合、必ず専 項目なし
門的な知識を有するものが行うこととし、残存し、読み出し可能な情報がないことを確認すること。
3． 破棄を外部事業者に委託した場合は、「6.6 項目なし
人的安全対策 （2）事務取扱委託業者の監督及び守秘義務契約」に準じ、さらに委託
元の医療機関等が確実に情報の破棄が行なわれたことを確認すること。

4． 運用管理規程において下記の内容を定める 項目なし
こと。
(a) 不要になった個人情報を含む媒体の廃棄を定める規程の作成
(a)
(ア)

技術的対策
医療情報システムは、管理・保存している情報について、その格納領域にNULLデータを上書きするなど、完全消去を行う機能 1を持つことが望ましい。その際、消去のための手順を具体的

1 データ消去に関する各種規格のご紹介

JEITA ストレージ上のデータ消去に関するガイドライン
http://it.jeita.or.jp/infosys/committee/network/guIDeline0407/standard.html© JAHIS 201325

に明示すること。

(b)
(ア)

運用的対策
次の要件を含む手順書を作成すること。
①破棄を行う条件②破棄作業の従事者の特定③具体的な破棄方法④破棄の記録（項目、書式）(イ)

情報処理機器自体を破棄する場合は次の条件を満たすこと。
①外部業者に依頼するときは、「安全管理ガイドライン」「6.6 人的安全対策 （2）事務取扱委
託業者の監督及び守秘義務契約」に準じた委託先選定及び管理を行うとともに、確実に情報の破棄が行なわれたことを証明書等で確認すること(ウ)

運用管理規定に「不要になった個人情報を含む装置、媒体の破棄手順書の作成義務」を定めること。

© JAHIS 201326

6.4. 情報システムの改造と保守
医療情報システムを安全にかつ有効に運用するためには、定期的な保守が必要となる。保守には障害対応
や予防保守、ソフトウェアのアップデートなどがあるが、特にデータベースを扱う作業やサーバ等の再起動が必要とされる作業など、情報システムを一時的に停止する場合が生じることがある。また、オペレーショ
ンミスによるデータの紛失や消去など、セキュリティ面においても十分な対策が求められる。情報システムの改造と保守について、「安全管理ガイドライン」で挙げられている四つの脅威はデータそのものに対する代表的な脅威がほとんどで、さらに情報システムに対する脅威も多く存在する。改造や保守作業は、医療機関の適切な管理の下で実施されるものである。従って、保守ベンダーとの間で交わされる守秘義務契約や、保守要員の管理、作業内容の確認など、医療機関の運用面での対策が必要である。
(1)

保守作業で使用するデータ＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

1． 動作確認で個人情報を含むデータを使用す 項目なし
るときは、明確な守秘義務の設定を行うとともに、終了後は確実にデータを消去する
等の処理を行うことを求めること。
技術的対策

(a)

追記事項なし。
運用的対策

(b)
(ア)
(イ)

(2)

動作確認等で個人情報を含むデータを利用する場合には、明確な守秘義務を病院とベンダー間でルール化し明文化すること。
また、作業終了後には個人情報を含むデータが不要な場合は確実に当該データを消去すること。

保守要員の登録と管理①＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

2． メンテナンスを実施するためにサーバに保 1. 詳細なオペレーション記録を保守操作ロ
守会社の作業員がアクセスする際には、保グとして記録すること。
守要員個人の専用アカウントを使用し、個人情報へのアクセスの有無、およびアクセ
スした場合は対象個人情報を含む作業記
録を残すこと。これはシステム利用者を模して操作確認を行うための識別・認証についても同様である。

© JAHIS 201327

技術的対策

(a)
(ア)
(イ)

(ウ)

運用的対策

(b)
(ア)

(3)

保守要員は個人単位の専用アカウントでシステムにログインできること。
個人情報を含むデータへアクセスする場合、「いつ、誰が、誰の」を含む作業記録をシステムロ
グ等、自動的に作成する機能を有すること。この機能の実装が困難な場合には、運用的対策(ア)で補うこと。
作業記録には、アクセスした個人情報を含むデータの識別情報を時系列順に並べて表示し、かつ指定した時間間隔内でどの患者に何回のアクセスが行なわれたかが確認できることが望ましい。

個人情報を含むデータへアクセスする場合、「いつ、誰が、誰の」を含む作業記録を書面で作成し、作業後速やかに医療機関へ提出すること。保守要員の専用アカウントでシステム利用者に模して操作確認等を行う場合にも同等とする。

保守要員の登録と管理②＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

3． そのアカウント情報は外部流出等による不 項目なし
正使用の防止の観点から適切に管理することを求めること。
技術的対策

(a)
(ア)

運用的対策

(b)
(ア)

(4)

保守要員の専用アカウントが含まれるファイルは、適切な暗号化とアクセス制御等の管理により不正使用を防止できること。

保守要員の専用アカウントは、保守作業の目的以外には利用しないこと。

保守要員の登録と管理③＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
4． 保守要員の離職や担当変え等に対して速や 項目なし
かに保守用アカウントを削除できるよう、
保守会社からの報告を義務付けまた、それに応じるアカウント管理体制を整えてお
くこと。

(a)

技術的対策

追記事項なし。

© JAHIS 201328

推奨されるガイドライン

運用的対策(b)

追記事項なし。

(5)

作業申請書／作業報告書の提出＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

5． 保守会社がメンテナンスを実施する際に 2. 保守作業時には病院関係者立会いのもと
は、日単位に作業申請の事前提出をするこ
で行なうこと。
とを求め、終了時の速やかな作業報告書の提出を求めること。それらの書類は医療機関の責任者が逐一承認すること。
技術的対策

(a)

追記事項なし。
運用的対策(b)

追記事項なし。

(6)

守秘義務契約の締結＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

6． 保守会社と守秘義務契約を締結し、これを 3. 作業員各人と保守会社との守秘義務契約遵守させること。
を求めること。
(a)

技術的対策

追記事項なし。
(b)
(ア)
(イ)

運用的対策
保守ベンダーは当該医療機関と守秘義務契約を締結し、保守要員にその内容を遵守させること。
保守ベンダーは当該医療機関に保守要員各人を明示的に伝えておくことが望ましい。

© JAHIS 2013

29

(7)

個人情報を含むデータの組織外への持ち出し＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

7． 保守会社が個人情報を含むデータを組織外 4. 保守会社が個人情報を含むデータを組織に持ち出すことは避けるべきであるが、や外に持ち出すことは避けるべきであるが、むを得ない状況で組織外に持ち出さなけ
やむを得ない状況で組織外に持ち出さなればならない場合には、置き忘れ等に対すければならない場合には、詳細な作業記録
る十分な対策を含む取扱いについて運用を残すことを求めること。また必要に応じ管理規定を定めることを求め、医療機関等て医療機関等の監査に応じることを求めの責任者が逐一承認すること。
ること。
(a)

技術的対策

「安全管理ガイドライン」自体が、かなり技術的対策に踏み込んで記述されているので、ここではその内容を踏まえた上で、持出し機器の対策に鑑み追記の必要のある内容のみ記述する。
(ア)
持ち出し機器、媒体については、必ず内容を暗号化できるものを利用すること。
(イ)
持ち出し機器（PC 等を想定）については、必ず起動パスワードでロックがかかるようにすること。その設定ができない機器は利用しないこと。また、パスワードの要件は他の記述と同じく、容易に破られないような内容で設定すること。
(ウ)
持ち出し機器（PC 等を想定）には、必ずウィルス対策ソフトを導入し、最新のパターンファイ
ルを適用しておくこと。
(エ)
持ち出し媒体の利用に際しては、適切に管理された媒体で、ウィルス等の混入が無いことをチ
ェック済みのものを用いること。
(オ)パーソナルファイアウォールを適用できる機器であれば、その機能を有効に設定すること。
(カ)
覗き見防止フィルタは、装着することが望ましい。
(b)
(ア)
(イ)
(ウ)
(エ)
(オ)
(カ)
(キ)
(ク)
(ケ)

運用的対策
保守ベンダーは医療機関が定める運用管理規定を遵守すること。
個人情報を含むデータが保守の目的で院外に持ち出される場合には、可能な限り詳細な作業記録を残し、当該医療機関の監査に応じることができることが望ましい。
個人情報を含むテスト用データの扱いについては、「6.7 外部と個人情報を含む医療情報を交換する場合の安全管理」の「 (b) 運用的対策」 を参照すること。
持ち出しの可否について、医療機関で定める運用管理規程に従うこと。
当該の運用管理規程によって持ち出しを許可され、実際に持ち出す場合には、同様に運用管理規程に従うこと。
医療機関から持ち出した情報および情報機器の取り扱いについては、自組織内で運用管理規程を定め、遵守すること。
運用管理規程には、上記「安全管理ガイドライン」の少なくとも「最低限のガイドライン」の要求事項を盛り込むこと。
当該の運用管理規程は、医療機関の求めに応じて開示できるようにしておくこと。
必要に応じて、医療機関から持ち出した情報および情報機器を、当該の運用管理規程に従って取り扱う旨の契約を医療機関と締結すること。

© JAHIS 2013

30

(8)

リモート保守とメッセージログの採取＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

8． リモートメンテナンスによるシステムの改 5. 保守作業にかかわるログの確認手段とし造や保守が行なわれる場合には、必ずアクて、アクセスした診療録等の識別情報を時セスログを収集すると共に、当該作業の終系列順に並べて表示し、かつ指定時間内で了後速やかに作業内容を医療機関等の責
どの患者に何回のアクセスが行なわれた任者が確認すること。
かが確認できる仕組みが備わっているこ
と。
技術的対策

(a)
(ア)

詳細なオペレーション記録を保守操作ログとして記録することが望ましい。
詳細は、「6.2 技術的安全対策 (6) アクセス記録及びログの確認」を参照すること。

(b)

運用的対策

(ア)

その他

(c)
(ア)

(9)

オンサイトの保守作業のみならず、リモートによる保守においても作業の操作ログを採取し、作業終了後可及的速やかに操作ログの内容を当該医療機関に提出すること。

リモート保守に関する技術的および運用的安全管理については、JAHIS 技術文書「リモートサービスセキュリティガイド」および JAHIS 標準「リモートサービスセキュリティガイドライン
Ver.2.0」（JAHIS 標準 09-002）を参照すること。

保守作業の再委託＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
9． 再委託が行なわれる場合は再委託する事業 項目なし
者にも保守会社と同等の義務を課すこと。
(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

© JAHIS 201331

推奨されるガイドライン

6.5. 情報および情報機器の持ち出しについて「安全管理ガイドライン」の要求事項は、医療機関から見た業務委託先であるベンダーにも適用される。
ただし、ベンダーが医療機関から情報や情報機器を持ち出すケースは、そのほとんどが保守用途と考えられるため、ここでの記述は「6.4 システムの改造と保守」での記述に委ねるものとする。また、情報の持ち出し方法として、データ回線による電子的な移動も考えられるが、これについても同様とする。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

1. 組織としてリスク分析を実施し、情報およ 1. 外部での情報機器の覗き見による情報の露び情報機器の持ち出しに関する方針を運見を避けるため、ディスプレイに覗き見防用管理規程で定めること。
止フィルタ等を張ること。
2. 運用管理規程には、持ち出した情報および 2. 情報機器のログインや情報へのアクセス時
情報機器の管理方法を定めること。
には複数の認証要素を組み合わせて用いること。
3. 情報を格納した可搬媒体もしくは情報機器の盗難、紛失時の対応を運用管理規程に定 3. 情報格納用の可搬媒体や情報機器は全て登めること。
録し、登録されていない機器による情報の持ち出しを禁止すること。
4. 運用管理規程で定めた盗難、紛失時の対応
を従業者等に周知徹底し、教育を行うこと。
5. 医療機関等や情報の管理者は、情報が格納された可搬媒体もしくは情報機器の所在を台帳を用いる等して把握すること。
6. 情報機器に対して起動パスワードを設定すること。設定にあたっては推定しやすいパ
スワードなどの利用を避けたり、定期的にパスワードを変更する等の措置を行うこと。
7. 盗難、置き忘れ等に対応する措置として、情報に対して暗号化したりアクセスパス
ワードを設定する等、容易に内容を読み取られないようにすること。
8. 持ち出した情報機器をネットワークに接続
したり、他の外部媒体を接続する場合は、コンピュータウイルス対策ソフトの導入やパーソナルファイアウォールを用いる
等して、情報端末が情報漏えい、改ざん等の対象にならないような対策を施すこと。
なお、ネットワークに接続する場合は「6．
11 外部と個人情報を含む医療情報を交換© JAHIS 201332

最低限のガイドライン

推奨されるガイドライン

する場合の安全管理」の規定を順守すること。
9. 持ち出した情報を、例えばファイル交換ソ
フト（Winny 等）がインストールされた情報機器で取り扱わないこと。医療機関等が管理する情報機器の場合は、このようなソフトウェアをインストールしないこと。
10. 個人保有の情報機器（パソコン等）であっても、業務上、医療機関等の情報を取り扱ったり、医療機関等のシステムへアクセス
するような場合は、管理者の責任において上記の 6、7、8、9 と同様の要件を順守さ
せること。
(a)

技術的対策

技術的対策については、「6.4 情報システムの改造と保守 (7) 個人情報を含むデータの組織外への持ち出
し」の 「(a)技術的対策」を参照すること。
(b)

運用的対策

運用的対策については、「6.4 情報システムの改造と保守 (7) 個人情報を含むデータの組織外への持ち出
し」の 「(b)運用的対策」を参照すること。

© JAHIS 201333

6.6. 災害等の非常時の対応
非常時においても医療機関には患者安全に配慮した医療サービスの提供を優先することが求められる。こ
こでいう「非常時」とは、
１） 医療情報システムが異常動作あるいは停止した場合
２） システム運用環境が非定常状態になる場合の 2 種類の状態を言う。
1）の状態は、(ア) 広域災害
災害（地震、水害、落雷、火災等）による電力・通信途絶、施設・設備損壊、インフラ業者の
IT 機能不全(イ) 局所被害
サイバー攻撃による不正侵入・改ざんを検知、あるいはウィルス攻撃・DoS 攻撃によるサービ
ス不能(ウ) システム障害
ハードウェアの故障、プログラムの欠陥、操作ミスによるサービス不能などにより、医療情報システムが縮退運用や全面停止状態になる状態である。
2）の状態は、(ア) 災害時等に多数の患者が医療機関に殺到し、通常のアクセス制御下あるいは通常のフローでは運用が困難になる場合(イ) 災害時等の患者集中により、緊急処置が必要な状態にアクセス権限を持った利用者が不在か手が足りない、などの場合などに非定常のアクセス制御あるいはフローでシステムを運用する状態である。
医療機関は事前にこのような状況になった場合の事業継続計画(BCP : Business Continuity Plan)を策定し、それに従って対応することが安全管理ガイドラインで求められている。BCP 策定と運用のポイントとして、BCP 発動以降を、BCP 実行フェーズ、業務再開フェーズ、業務回復フェーズ、全面復旧フェーズの四つに分けている。尚、BCP の詳細な内容はガイドラインの「考え方」を参照願いたい。
医療情報システムベンダは、医療機関が策定する BCP の内容に沿った機能をシステムに装備することを求められる。あるいは、現状システムの機能を医療機関に明確に提示し、医療機関側の BCP 策定に協力することが求められる。また、広域災害時の復旧サポートなどを想定し、医療情報システムベンダ自身の BCPの整備も必要となる。

© JAHIS 2013

34

(1)

非常時における事業継続計画（BCP : Business Continuity Plan)＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

1． 医療サービスを提供し続けるための BCP 項目なしの一環として“非常時”と判断する仕組み、
正常復帰時の手順を設けること。すなわ
ち、判断するための基準、手順、判断者、をあらかじめ決めておくこと。

2． 正常復帰後に、代替手段運用した間のデー 項目なし
タ整合性を図る規約を用意すること。

4． サイバー攻撃で広範な地域での一部医療行 項目なし
為の停止など医療サービス提供体制に支障が発生する場合は、別途定める所管官庁への連絡を行うこと。
(a)
(ア)
(イ)

(ウ)
(エ)
(オ)

(b)
(ア)
(イ)
(ウ)

技術的対策
医療情報システムが非常状態になる可能性が高いと判断した場合、運用責任者や運用管理者な
ど BCP で定められた人、場所、システムに通知する機能を有することが望ましい。
原因に応じた技術的対策を有することが望ましい。例えば電力途絶の場合、非常用電力への自動的な切替機能や安全にシャットダウンする機能、ハードウェア故障時の代替機への切替機能や二重化が施されたハードウェアの採用など。コンピュータ本体関連だけでなくネットワーク
機器への対処も必要である。
非常状態に応じた運用切替機能および復旧後の平常運用への切替機能を有することが望ましい。
例えば一部の端末あるいは一部の機能のみの縮退運用可能にするなど。
非常時回復ツールの装備を有することが望ましい。例えばバックアップからの復旧ツール、データベースの整合性チェックツールなど。
復旧後の代替運用からの整合性処置をサポートする機能を有することが望ましい。例えば代替運用時の情報の取り込み機能や整合性確認機能など。
運用的対策
医療情報システム開発ベンダーは医療機関の BCP 策定、運用、見直しに協力すること
医療情報システム開発ベンダーは、広域災害時の復旧サポートなどを想定し、自身の BCP を整備すること。
更に定期的に BCP に基づく障害時のサポート訓練を実施して、その結果を踏まえて BCP の改善を行うこと。

© JAHIS 2013

35

(2)

医療システムの非常時運用への対応＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
3. 非常時の情報システムの運用推奨されるガイドライン
項目なし

・ 「非常時のユーザアカウントや非常時用機能」の管理手順を整備すること。
・ 非常時機能が定常時に不適切に利用されることがないようにし、もし使用された場
合には使用されたことが多くの人にわかるようにする等、適切に管理および監査をすること。
・ 非常時用ユーザアカウントが使用された
場合、正常復帰後は継続使用が出来ないよ
うに変更しておくこと。

(a)
(ア)
(イ)
(ウ)
(エ)
(オ)
(カ)

(キ)

(b)
(ア)

技術的対策
非常時用機能を有すること。具体的には、非常時用アカウント制御への切替機能、通常フローでない運用のサポートなど。
非常時用機能は、通常時には不必要に使用されないよう対策が取られていること。例えば、非常時用機能が使用されていることが多数の人にわかるようにするなど。
非常時用機能に切り替わっていることが利用者に明確にわかるようにすること。
非常時用機能が使用された場合、そのことを適当な人に通知する機能、非常時に切り替えたユーザを特定したり、利用記録が監査ログに残る機能を有すること。
非常時でなくなった場合、通常運用に速やかに切り替える機能。
非定常時に通常使用しない要員（例えば応援の医師など）が使うことを前提に患者番号、性別、年齢等で患者を簡単に選択し、最低限の診療記録を簡単に参照できる機能（操作性については、
全国共通仕様のようなものがあると望ましい）。
一時的に参照のアクセス権限をフリー（開放）する機能

運用的対策
非常用ユーザアカウントによる対応を行う場合、以下のような運用を行うこと① 非常用ユーザアカウント名は非常用であることが明らかにわかる入力しやすいものにすること。逆に非常用ユーザアカウントのパスワードは類推しにくいものにすること。ただし、緊急時に入力しにくいものにはしないこと。
② 非常用ユーザアカウントのパスワードの入手は比較的容易に行えるようにすること。利用したい端末から非常に離れた場所まで行かないと入手できないのでは意味がない。
③ 非常用ユーザアカウントが利用された場合、そのことが直ちに管理者だけでなく多数の人にわかるようにすること。また実際の利用者が誰かなのかが記録に残ること。これにより、安易な利用や否認を抑止できる。

© JAHIS 201336

④ 非常用ユーザアカウントの利用者は速やかにＩＤ、氏名、利用時刻、利用理由などを管理者に報告すること。
⑤ 非常用ユーザアカウントが利用された後、ポリシーに従った適切な運用であったかどうかを利用者の報告内容やログなどで確認すること。非常用アカウントでの利用の場合、ログレベ
ルを上げるのもよい。
⑥ 非常用ユーザアカウントが利用された場合、継続利用できないようにパスワードを変更すること。
⑦ 非常用ユーザアカウントでアクセスできる範囲は、リスク分析を行い、適切な範囲までとすること。
⑧ 定期的に非常用アカウントの動作確認を行うこと。

© JAHIS 201337

6.7. 外部と個人情報を含む医療情報を交換する場合の安全管理
外部と医療情報を外部ネットワークを利用して交換する場合、情報の送信元から送信先に確実に情報を送り届ける必要がある。その際、「送付すべき相手に」、「正しい内容を」、「内容を覗き見されない方法で」送付しなければならない。送信元の送信機器から送信先の受信機器までの間の通信経路において上記内容を担保する必要がある。この端末間の通信路のセキュリティをチャネル・セキュリティと呼び、情報の内容に対するセキュリティのことをオブジェクトセキュリティと呼ぶ。
オブジェクトセキュリティにおいては、医療情報をネットワークを通じて伝播させる場合に、「盗聴」、「改ざん」、「なりすまし」などの危険性に対する対応が必要とされる。
盗聴：パスワード盗聴、本文の盗聴など
改ざん：メッセージ挿入、ウィルス混入など
なりすまし：情報の流出・改ざんなどの原因となる
ガイドラインでは、改ざん検知のための電子署名や、PKI を利用したネットワーク接続時の認証の仕組み
により通信の起点と終点で医療機関を適切に識別できるように求めている。
チャネル・セキュリティにおいては、通信経路上での脅威への対策とともに、外部と医療機関との間の責任分界点を明確にするために、ガイドラインではネットワークにおけるセキュリティの責任分界点がネットワークを提供する事業者となるか、医療機関等になるか、もしくは分担となるかを契約等で明らかにする必要があるとしている。この際の考え方として、外部と医療機関を接続するために以下の二つの場合について類型化している。
•

回線事業者とオンラインサービス提供事業者がネットワーク経路上のセキュリティを担保する場
合：回線事業者とオンラインサービス提供事業者が提供するクローズドなネットワークや、インターネット回線を利用した Internet-VPN のような通信形体のうち、ネットワーク上のセキュリ
ティを上記業者が担保しているもの。

•

回線事業者とオンラインサービス提供事業者がネットワーク経路上のセキュリティを担保しない
場合：インターネットを用いて医療機関等同士が同意の上、ネットワーク接続機器を導入して双方を接続する場合などが考えられる。

(1)

外部との通信における脅威と対策

安全管理ガイドラインでは、外部と診療情報等を交換するケースとして、以下の五つのケースを元に解析し
ている。
•
•
•
•
•
•

地域医療連携で医療機関、薬局、検査会社等と相互に連携してネットワークで診療情報等をやり取りする場合
診療報酬の請求のために審査支払機関等とネットワークで接続する場合
ASP（Application Service Provider）型のサービスを利用する場合
医療機関等の従事者がノートパソコンの様なモバイル型の端末を用いて業務上の必要に応じて医療機関等の情報システムに接続する場合
従業者による外部からのアクセスに関する考え方
患者等による外部からのアクセスを許可する場合

このように、医療機関等において医療情報をネットワークを通じて交換しようとする場合には、提供サービ
ス形態の視点から責任分界点のあり方を理解した上でネットワークを選定する必要があるとし、また、医療© JAHIS 2013

38

機関は選択するセキュリティ技術の特性を理解し、リスクの受容範囲を認識した上で、必要に応じて説明責任の観点から患者等にもそのリスクを説明する必要があるとしている。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
1．ネットワーク経路でのメッセージ挿入、ウ 項目なし
ィルス混入などの改ざんを防止する対策をとること。施設間の経路上においてクラッカーによるパスワード盗聴、本文の盗聴を防止する対策をとること。セッション乗
っ取り、IP アドレス詐称などのなりすま
しを防止する対策をとること。上記を満たす対策として、
例えば IPSec と IKE を利用することによりセキュアな通信路を確保することがあげられる。チャネル・セキ
ュリティの確保を閉域ネットワークの採用に期待してネットワークを構成する場
合には、選択するサービスの閉域性の範囲を事業者に確認すること。
(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

(2)

外部との通信における認証

情報を送ろうとする医療機関等と、送信先の医療機関等は相互に適切な認証を採用して、相手が確かに通信しようとする相手なのか、また、送られて来た情報が確かに送信元の医療機関等の情報であるかを確認しなくてはならない。
そのため、例えば通信の起点と終点で相互を適切に識別するために、公開鍵方式や共有鍵方式等の確立された認証の仕組みを用いて認証する等の対応を取ることが考えられる。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
2．データ送信元と送信先での、拠点の出入り 項目なし
口・使用機器・使用機器上の機能単位・利用者の必要な単位で、相手の確認を行う必要がある。採用する通信方式や運用管理規程により、採用する認証手段を決めること。認証手段としては PKI による認証、Kerberos のような鍵配布、事前配布された共通鍵の利用、ワンタイムパスワードなどの容易に解読されない方法を用いるのが望ましい。

© JAHIS 2013

39

(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

(3)

外部との通信における成りすましの防止

通信のなりすまし防止については、情報の改ざん防止と併せて、適切な認証の仕組みとともに医療情報等に対して電子署名を組み合わせることも考えられる。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
3．施設内において、正規利用者へのなりすま 項目なし
し、許可機器へのなりすましを防ぐ対策をとること。これに関しては、医療情報の安全管理に関するガイドライン「6.5 技術的安全対策」で包括的に述べているので、それを参照すること。
(a)

技術的対策

技術的対策については、「6.2 技術的安全対策」の 「(a) 技術的対策」を参照すること。
(b)

運用的対策

運用的対策については、「6.2 技術的安全対策」の 「(b) 運用的対策」を参照すること。

(4)

外部との通信に利用する機器の選定＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
4．ルータなどのネットワーク機器は、安全性 項目なし
が確認できる機器を利用し、施設内のルータを経由して異なる施設間を結ぶ VPNの間で送受信ができないように経路設定されていること。安全性が確認できる機器とは、例えば、ISO15408 で規定されるセキュリティターゲットもしくはそれに類するセキュリティ対策が規定された文書が本ガイドラインに適合していることを確認できるものをいう。
(a)

技術的対策

追記事項なし。

© JAHIS 201340

推奨されるガイドライン

(b)

運用的対策

追記事項なし。

(5)

外部との通信における秘匿性の確保

適切な認証の仕組みとともに、情報の機密度に応じたネットワーク種別と情報そのものに対する暗号化を採用しなければならない。暗号化技術にはそのアルゴリズム特有の脆弱性や、鍵強度の問題など定期的な保守や対応が必要となるが、安全管理ガイドラインでは電子政府推奨暗号を使用することとなっている。
（参照：「暗号技術検討会」http://www.cryptrec.go.jp/method.html）＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
5．送信元と相手先の当事者間で当該情報その 項目なし
ものに対する暗号化などのセキュリティ対策を実施すること。たとえば、SSL/TLSの利用、S/MIME の利用、ファイルに対する暗号化などの対策が考えられる。その際、暗号化の鍵については電子政府推奨暗号のものを使用すること。
(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

(6)

外部との通信における責任分界＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
6．医療機関等の間の情報通信には、医療機関 項目なし
等だけでなく、通信事業者やシステムイン
テグレータ、運用委託事業者、遠隔保守を行う機器保守会社など多くの組織が関連する。そのため、次の事項について、これら関連組織の責任分界点、責任の所在を契約書等で明確にすること。
・ 診療情報等を含む医療情報を、送信先の医療機関等に送信するタイミングと一連の情報交換に係わる操作を開始する動作の決定・ 送信元の医療機関等がネットワークに接続© JAHIS 201341

推奨されるガイドライン

最低限のガイドライン
できない場合の対処
・ 送信先の医療機関等がネットワークに接続できなかった場合の対処
・ ネットワークの経路途中が不通または著しい遅延の場合の対処
・ 送信先の医療機関等が受け取った保存情報を正しく受信できなかった場合の対処
・ 伝送情報の暗号化に不具合があった場合の対処
・ 送信元の医療機関等と送信先の医療機関等の認証に不具合があった場合の対処・ 障害が起こった場合に障害部位を切り分ける責任・ 送信元の医療機関等または送信先の医療機
関等が情報交換を中止する場合の対処
また、医療機関内においても次の事項において契約や運用管理規程等で定めておくこと。
・ 通信機器、暗号化装置、認証装置等の管理責任の明確化。外部事業者へ管理を委託する場合は、責任分界点も含めた整理と契約の締結。
・ 患者等に対する説明責任の明確化。
・ 事故発生時における復旧作業・他施設やベンダーとの連絡に当たる専任の管理者の設置。
・ 交換した医療情報等に対する結果責任の明確化。
個人情報の取扱いに関して患者から照会等があった場合の送信元、送信先双方の医療機関等への連絡に関する事項、またその場合の個人情報の取扱いに関する秘密事
項。
(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。
© JAHIS 201342

推奨されるガイドライン

(7)リモート保守の限定＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

7．リモートメンテナンスを実施する場合は、 項目なし
必要に応じて適切なアクセスポイントの設定、プロトコルの限定、アクセス権限管理等を行って不必要なログインを防止すること。また、メンテナンス自体は「6.8 章
情報システムの改造と保守」を参照するこ
と。
(a)

技術的対策

技術的対策については、「6.2 技術的安全対策」の 「(a) 技術的対策」を参照すること。
(b)

運用的対策

運用的対策については、「6.2 技術的安全対策」の 「(b) 運用的対策」を参照すること。

(8)

責任範囲と品質保証＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

8．回線事業者やオンラインサービス提供事業 項目なし
者と契約を締結する際には、脅威に対する管理責任の範囲や回線の可用性等の品質に関して問題がないか確認すること。また
上記 1 および 4 を満たしていることを確認すること。
(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

(9)

患者の閲覧行為に関する安全対策

医療機関等の間における通信の安全管理とともに、医療機関等が患者との同意の上で情報提供を行うことは十分想定できる。ただし、診療録及び診療諸記録を外部に保存し、受託する事業者が独自に情報提供を行うことはあってはならないとされていることからも、情報を提供する医療機関等が患者の理解できる言葉で納得が行くまで十分に危険性を説明し、その提供の目的を明確にする責任があり、説明が不足している中で© JAHIS 201343

万が一情報漏えい等の事故が起きた場合は、その責任を逃れることはできないことを認識しなくてはならな
い。
また、患者等は自宅等からオープンなネットワークを利用して接続してくることが現実的であり、内部のシステムに不正な侵入等が起こらないように、システムやアプリケーションを切り分けしておく必要がある。
そのため、ファイアウォール、アクセス監視、通信の SSL 暗号化、PKI 個人認証等の技術を用いる必要がある。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
9．患者に情報を閲覧させる場合、情報を公開 項目なし
しているコンピュータシステムを通じて、医療機関等の内部システムに不正な侵入等が起こらないように、システムやアプリ
ケーションを切り分けし、ファイアウォー
ル、アクセス監視、通信の SSL 暗号化、
PKI 個人認証の技術を用いた対策を実施すること。また、情報の主体者となる患者等へ危険性や提供目的の納得できる説明を実施し、IT に係る以外の法的根拠等も含めた幅広い対策を立て、それぞれの責任を明確にすること。
(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

(10)

従業者による外部からのアクセスに関する安全対策

医療機関等の職員がテレワークを含めて自宅等から医療情報システムへのアクセスすることを許可する場合、アクセスに用いる PC 等の機器の安全管理も重要であり、私物の PC のような非管理端末であっても、一定の安全管理が可能な技術的対策を講じられなければならない。
外部からのアクセスに用いる機器の安全管理を運用管理規程で定める場合、以下のことに考慮する必要がある。
① PC 等の安全管理対策を確認するためには一定の知識と技能が必要で、職員にその知識と技能を要求す
ることは難しいこと。
② 運用管理規程で定めたことが確実に実施されていることを説明するためには適切な運用の点検と監査が必要であるが、外部からのアクセスの状況を点検、監査することは通常は困難なこと。
③ 医療機関等の管理が及ばない私物の PC や、極端な場合は不特定多数の人が使用する PC を使用する
場合はもちろん、医療機関等の管理下にある機器を必要に応じて使用する場合であっても、異なる環境で使用していれば想定外の影響を受ける可能性があること。
従って、通常は行うべきではないが、医師不足等に伴う医療従事者の過剰労働等に対応するために、やむを得ず行う場合は、PC の作業環境内に仮想的に安全管理された環境を VPN 技術と組み合わせて実現する
仮想デスクトップのような技術が普及しており、これらの導入を検討することが重要であるとともに、運用等の要件にも相当な厳しさが求められる。

© JAHIS 201344

＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

1． やむを得ず、従業者による外部からのアクセスを許可する場合は、PC の作業環境内に仮想的に安全管理された環境を VPN
技術と組み合わせて実現する仮想デスク
トップのような技術を用いるとともに運用等の要件を設定すること。

項目なし

(a)

技術的対策

追記事項なし。
(b)

運用的対策

追記事項なし。

© JAHIS 2013

推奨されるガイドライン

45

6.8. 法令で定められた記名・押印を電子署名で行うことについて「電子署名法」や「e-文書法」の整備を受け、厚生労働省の「安全管理ガイドライン（第 1 版）」から記
名・押印が義務づけられた医療関連文書等の電子保存が容認されることになった。また、電子署名済みの文書等は一定期間、署名を信頼性を持って検証できることが必要であるとされている。
尚、第４版からは、2014 年度に予定されている暗号アルゴリズム（SHA1、RSA1024）の移行問題にも触れ、電子証明書の有効期間や失効、また暗号アルゴリズムの脆弱化の有無によらず、法定保存期間などの一定の期間、電子署名の検証が継続できる必要がある事が明確に示された。さらに、これを実現する手段として、JIS の長期署名プロファイルによる方法を例示し、標準技術を用いることの重要性について述べられ
ている。
(1)

電子署名に用いる電子証明書について＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1) 認定特定認証事業者等の発行する電子証明 項目なし
書を用いて電子署名を施すこと
1． 電子署名法の規定に基づく認定特定認証事
業者の発行する電子証明書を用いなくてもＡ（制度上の要求事項）の要件を満たすことは可能であるが、少なくとも同様の厳密さで本人確認を行い、さらに、監視等を行う行政機関等が電子署名を検証可能である必要がある。
2． 「電子署名に係る地方公共団体の認証業務に関する法律」（平成 14 年法律第 153 号）に基づき、平成 16 年 1 月 29 日から開始
されている公的個人認証サービスを用いることも可能であるが、その場合、行政機関以外に当該電子署名を検証しなければならない者がすべて公的個人認証サービスを用いた電子署名を検証できることが必要である。
(a)

技術的対策

診療録等の電子保管においては、医師など一定の資格を持つ自然人が、その責任において文書に電子署名を施すことが、各種法令の遵守や証拠性の確保の観点から極めて重要な意味を持つ。医療関連文書等への電子署名を想定したときに、十分な厳密さで本人確認を行って発行される電子証明書を利用する必要がある。
また、医師等の国家資格を持つ者が電子署名した場合、署名者の国家資格属性が確認できる事が望ましい。
以下に、電子署名に用いる証明書を例示するが、本ガイドラインでは上記の理由により（イ）保健医療福祉分野 PKI（Healthcare PKI）の電子証明書を用いることを推奨する。

© JAHIS 201346

なお、JAHIS では、「安全管理ガイドライン」に示された電子署名、タイムスタンプを付与する際の具体的な実装技術を規定、解説した「ヘルスケア PKI を利用した医療文書に対する電子署名規格」を 2008 年 3月に策定、公開しているので合わせて参照されたい。
(ア)

認定特定認証事業者の発行する電子証明書
電子署名法（電子署名及び認証業務に関する法律）に基づく特定認証業務の認証を受けた事業者（認定特定認証事業者）が発行する証明書を利用する際は、証明書や私有鍵の利用目的に反していないことを、該当する認証局の証明書ポリシー（CP）を参照の上、確認する必要がある。（認定特定認証事業者の中には、公的な電子調達等、特定のアプリケーションに特化した利用を目的として証明書を発行している場合があるため。）
なお、認定特定認証事業者は、法務省の以下の URL で確認できる。
http://www.moj.go.jp/MINJI/minji32.html
また、本ガイドライン執筆時点では、標準的なポリシーに従って医師などの国家資格属性が証明書の中に記載された証明書を発行する認定認証局は存在しない。従って、その証明書を利用して電子署名を付与した場合、署名を検証するだけでは医師等の国家資格を有する個人が署名したものであるか判断出来ない。署名者の国家資格の確認が必要な場合、別に確認する必要がある。従って、一般的な認定特定認証事業者の証明書を利用することは推奨しない。

(イ)

保健医療福祉分野 PKI（Healthcare PKI）の電子証明書
本ガイドラインでは、認定特定認証事業者の発行する電子証明書と同様の厳密さで本人確認を行って発行される電子証明書として、厚生労働省によって整備される保健医療福祉分野 PKI（Healthcare PKI、以下 HPKI と呼ぶ）によって定められた認証局証明書ポリシー（付録－２参照）に準拠した電子証明書の利用を推奨する。
HPKI は、医療機関における連携・情報共有等を行うためのセキュリティ基盤として定義されるもので、医師等による電子署名を行うための証明書を発行する。HPKI の認証局証明書ポリシーによれば、証明書発行対象者は以下の自然人となる。
「保健医療福祉分野 PKI 認証局 証明書ポリシー1.1 版」より
・

保健医療福祉分野サービスの提供者及び利用者
上記の提供者である以下の者はその資格、役割を証明書内に記載することができる。

・・

保健医療福祉分野に関わる国家資格所有者
上記の提供者の内、以下の者がその有する資格において、あるいは管理者として署名を行う場
合は、「その資格を有していること」あるいは「管理者であること」を証明書に記載しなくてはならない。
・ 保健医療福祉分野に関わる国家資格を有する者
・ 医療機関等の管理者
また、証明書に国家資格（資格情報は、ISO IS17090 において定義される hcRole によって記述される。HPKI では X.509 電子証明書の標準拡張である subjectDirectoryAttribute の attrType 領域に、hcRole の属性値として資格情報を示す hcActor を記述する。hcActor の例としては、Medical
Doctor=医師、Dentist=歯科医師などが挙げられる。）を記載することが可能となっている。HPKI
は、保健医療福祉分野において、電子署名に利用する証明書として厚生労働省の定める証明書ポリシーにより標準化されている。記名・押印が必要な文書を電子的に作成する際に付与する電子署名に用いる証明書として適したものであるといえる。

© JAHIS 2013

47

(ウ)

公的個人認証サービスの電子証明書
公的個人認証サービスは、現時点では、行政機関や特定の法人・団体などに対してのみ電子証明書の失効情報が提供されている。従って、一般の民間事業者などは電子証明書の検証を行う事ができない。従って、行政機関以外に当該電子署名を検証しなければならない者が、すべてその電子署名を検証できることが可能となる時点まで、この証明書を利用することは困難であると言える。
また、公的個人認証サービスが発行する証明書には、署名者の基本 4 情報（住所、氏名、生年月日、性別）が記されている。一般に署名文書には署名者の証明書が添付されるため、これら基本 4 情報が署名対象の文書と共に流通・保管されることとなる。この事は医師等の国家資格を有する署名者の個人情報が広く開示されることになり、過剰な負担となる場合が考えられる。従って、公的個人
認証サービスが発行する証明書を利用する場合は、個人情報保護等の観点から、署名者の基本 4
情報の取扱いについて留意する必要があり、署名者に事前に充分に説明の上、同意を得る必要がある。
従って、公的個人認証サービスが発行する証明書の利用は推奨しない。

(b)

運用的対策

電子署名を扱う運用を行う際は、事前に上記(a)の認証局に、あらかじめ電子証明書発行を申請し、証明書及び対応する私有鍵を入手する必要がある。
また、本人の私有鍵は、本人の意図しない利用を防止するために厳格に管理される必要がある。私有鍵を格納した IC カードや PC 等は本人以外の利用を防止する対策がなされるべきである。

(2)

タイムスタンプの付与について＜安全管理ガイドラインの要求事項＞
最低限のガイドライン(2) 電子署名を含む文書全体にタイムスタンプ 項目なし
を付与すること
1． タイプスタンプは、「タイムビジネスに係る指針－ネットワークの安心な利用と電子データの 安全な長期保存のために－」（総務省、平成 16 年 11 月）等で示されている時刻認証業務の基準に準拠し、財団法人日本データ通信協会が認定した時刻
認証事業者のものを使用し、第三者がタイムスタンプを検証することが可能である事。
2． 法定保存期間中のタイムスタンプの有効性を継続できるよう、対策を講じること。
3． タイムスタンプの利用や長期保存に関しては、今後も、関係府省の通知や指針の内容に留意しながら適切に対策を講じる必要がある。

© JAHIS 201348

推奨されるガイドライン

(a)

技術的対策

電子署名がなされた文書にタイムスタンプを付与することで、その電子署名が行われた時刻（厳密には、
当該署名文書が存在した時刻）を証明することができる。一方、電子署名だけでは署名時刻を特定できないため、署名に用いた証明書が失効もしくは期限切れ等の理由によって検証不能となったとき、署名がなされた時点において当該証明書が有効であったかどうかを確認できない。そこでタイムスタンプを付与することで、そのタイムスタンプの有効期間内であれば、電子署名の有効性を常に確認することが可能となる。このように、電子署名とタイムスタンプは互いに機能を補完し合うことで、電子署名が付与された文書の証拠性（いつ・何を・誰が）を確実なものとすることができる。
実社会における「証拠」
ネット社会における「証拠」

どこで

いつ

何を

誰が

電子署名で実現可能これらを実現するのが「タイムスタンプ」－ある時刻にその文書が存在していた（存在証明）－その文書は改ざんされていない （完全性証明）

このとき、タイムスタンプを付与する対象として、①電子署名を含む文書全体（文書＋署名値）②文書全体に対してなされた電子署名の値③文書のみの 3 種類が挙げられる。最低限のガイドラインでは「電子署名を含む文書全体にタイムスタンプを付与すること」を定めており、①の方式は当該ガイドラインを満たす。さらに②についても、署名が文書から一意に生成されるハッシュ値に対して付与されたものであることから、
同ガイドラインを満足すると考えられる。
なお、③の方式は同ガイドラインを満足しない。
従って、タイムスタンプを付与する対象として、①電子署名を含む文書全体（文書＋署名値）または、②
対象文書全体に対してなされた電子署名の値、のどちらかの方式を採用する事。なお、タイムスタンプについての詳細や動向については、関係府省の通知や指針等（後述）を参照されたい。
(ア)

時刻認証事業者と第三者によるタイムスタンプの検証
財団法人日本データ通信協会が認定した時刻認証事業者は、本ガイドライン執筆時点において、以下の URL で公開されている。
http://www.dekyo.or.jp/tb/list/index.html
また、第三者がタイムスタンプを検証することが可能である必要があるので、タイムスタンプが付与された電子文書の受領者等の検証者がタイムスタンプを検証することが可能である必要がある。
デジタル署名技術を用いたタイムスタンプを検証する際は、タイムスタンプ局（TSA）の電子証明書(TSA 証明書)が、検証者にとって信頼できるルート認証局の証明書リストに基づいて検証可能なものであることを確認する必要がある。また当該 TSA 証明書について、最新の失効情報（CRL）© JAHIS 201349

等に基づく失効検証を行う必要がある。なお、TSA 証明書がタイムスタンプトークンに含まれない場合は、信頼のおけるリポジトリからそれを取得する必要がある。
タイムスタンプ検証サービスを用いて検証者がタイムスタンプを検証する際は、セキュリティ対策（なりすまし、改ざん、盗聴）が行われた通信路上で、利用者とタイムスタンプ検証サービス間の検証プロトコルを実行することが望ましい。
(イ)

法定保存期間中のタイムスタンプの有効性維持
本ガイドラインの執筆時点では、（財）日本データ通信協会が認定した時刻認証事業者のタイムス
タンプの有効期間は概ね 10 年間が一般的である。電子保存を行う文書の法定保存期間がタイムスタンプの有効期間を越える場合、タイムスタンプが有効な間に、新たにタイムスタンプを付与する
等の手段により、有効性を延長する必要がある。この処理を繰り返し行うことで、長期に渡ってタ
イムスタンプの有効性を継続させることが可能となる。この場合、新たなタイムスタンプの付与対
象には旧いタイムスタンプを含む必要があることに留意されたい。
こうした技術は一般に、長期署名（Long-term electronic signatures）と呼ばれる。法定保存期間
中（もしくはそれ以上の長期）においてタイムスタンプの有効性を継続し、電子署名の有効性を維持するためには、長期署名技術の利用が必要となる場合がある。（詳細は次の（3）を参照）(ウ)

関係府省の通知や指針
タイムスタンプの利用や長期保存に関する指針や標準の例として、「付録－２参考文献：タイムス
タンプ及び長期保存に関する標準やガイドライン」に一覧を記載した。なお、ここで紹介する文書
は 2006 年 3 月現在の最新版である。実際にこれら標準・規格を参考とする場合は、その時点での最新版を用いることを推奨する。

(b)

運用的対策

文書種別ごとの保存期間については、事前に医療機関の定める文書管理規定等を確認し、最低限、法定保存期間を満たしていることを確認する必要がある。また、法定保存期間を越えて保存する場合は、必ずしもタイムスタンプの有効性を維持する必要は無いが、その有効性をどの期間まで維持するか、事前に医療機関
等に確認し、再スタンプの必要性を明らかにすべきである。

(3)

電子証明書の有効性について＜安全管理ガイドラインの要求事項＞
最低限のガイドライン(3) 上記タイムスタンプを付与する時点で有効 項目なし
な電子証明書を用いること。
1． 当然ではあるが、有効な電子証明書を用いて電子署名を行わなければならない。本来法的な保存期間は電子署名自体が検証可能であることが求められるが、タイムスタンプが検証可能であれば、電子署名を含めて改変の事実がないことが証明されるために、タイムスタンプ付与時© JAHIS 201350

推奨されるガイドライン

最低限のガイドライン

推奨されるガイドライン

点で、電子署名が検証可能であれ
ば、電子署名付与時点での有効性を検証することが可能である。具体的には、電子署名が有効である間に、電子署名の検証に必要となる情報（関連する電子証明書や失効情報等）を収集し、署名対象文書と署名
値とともにその全体に対してタイムスタンプを付与する等の対策が必要である。

(a)

技術的対策

電子署名に用いる証明書は、署名時点において有効である必要があるが、タイムスタンプを付与する時点においても有効でなくてはならない。即ち、期限切れの証明書や失効された証明書を用いてはならない。また、法定保存期間中、署名検証を可能とさせるために、署名当時、証明書が有効で有ったことを後日に検証可能である必要がある。
法定保存期間中（もしくはそれ以上の長期）において有効な電子証明書を用いて電子署名を行ったことを検証可能とするためには、タイムスタンプ付与時点において電子署名が有効であったことを示すために、証明書検証に必要となる認証パス上の証明書や失効情報（CRL/ARL）などの情報を真正性を保って保存する必要がある。
このように署名文書の検証の継続性を確保して長期間保存するために、前述の長期署名技術の利用が有効である。長期署名では、署名値や証明書検証に必要な情報を付加し、タイムスタンプを付与したデータフォ
ーマットを形成する。
そのため、後日の検証時は長期署名フォーマット単独で第 3 者が署名検証可能であり、特定のシステムやサービスに依存することなく長期間署名の検証が維持可能となる。
下図は、長期署名の国際標準である「RFC 3126」によって定められたフォーマットの概念図である。タイムスタンプの有効性が切れる前に次のタイムスタンプを繰り返し付与することで、署名の有効性を延長するアプローチをとっている。この中には、タイムスタンプ付与時点において証明書が有効であったことを示すために、当該時点における証明書検証に必要な各種情報 が順番に記述されている。このように RFC 3126
では、署名、タイムスタンプ及び検証のための各種情報が完全性を保ったまま構成されており、現時点において署名されたデータの長期保存を実現するための最も確立された技術の一つであるといえる。本ガイドラ
インでは、電子署名が付与された文書を保存する場合、このような長期署名の標準技術の採用を推奨する。

© JAHIS 201351

RFC 3126 (Electronic Signature Formats for long term electronic signatures

)

ES-A
ES-X
ES-C
ES-T

Elect. Signature (ES)
基本署名フォーマット
署名ポリシー
OID

署名
属性

タイム
スタンプ

認証パス情報
と失効検証
データ

署名

ES-T：
Electronic Signature withTime stamp

ES-C：
Electronic Signature with
Complete validation data

証明書
チェーン
＋
CRL
ARL

タイム
スタンプ

ES-X：
Electronic SignatureeXtended

タイム
スタンプ

ES-A：
Electronic Signature
Archive

なお、長期署名技術についての詳細や動向については、「 付録－２：参考文献 タイムスタンプ及び長期保存に関する標準やガイドライン」を参照されたい。
また、上記のような長期署名技術を用いて電子署名、タイムスタンプを付与する場合、自ら保存義務がある文書については、ES-A フォーマットまで作成して保存する必要があるが、自らは保存義務がない外部提出用の文書については、ES-A フォーマットで渡すことが望ましいが、最低でも ES-T フォーマットまでは、
署名者側の責任範囲として作成すべき点に留意されたい。
(b)

運用的対策

有効期間が切れた証明書の利用を防止するため、証明書更新に関する本人への通知ルールが定められていることが望ましい。また、万一私有鍵を紛失した場合、速やかに認証局に証明書の失効を申請しなくてはならない。
証明書の取り扱いや、更新、失効に関するルールを医療機関等が策定し、証明書所持者にその運用が徹底されるよう支援することが望ましい。

(4)

9 章での電子署名、タイムスタンプの付し方

本章は記名・押印が必要な医療関連文書を電子保存する際の電子署名、タイムスタンプの付し方として解説されているが、「９．診療録等をスキャナ等により電子化して保存する場合について」にて、改ざんを防止するための措置として付与される電子署名、タイムスタンプも、本章の要件を満たす必要が有ることを留意されたい。

© JAHIS 201352

7. 電子保存の要求事項について
本章では、「医療情報システムの安全管理に関するガイドライン」の以下の節について JAHIS の視点か
ら基準を示し、解説を行ったものである。
安全管理ガイドライン
本ガイドライン
7.1 C (1)
作成者の識別及び認証
7.1 C (2)
記録の確定手順の確立と、作成責任者の識別情報の記録
7.1 C (3)
更新履歴の保存
7.1 C (4)
代行操作の承認機能
7.2 C (1)
情報の所在管理7.1.1.
作成者の識別及び認証
7.1.2.
記録の確定手順の確立と、作成責任者の識別情報の記録
7.1.3.
更新履歴の保存7.1.4.
代行操作
7.2.1.
情報の所在管理7.2 C (2)
見読化手段の管理

7.2.2.
見読化手段の管理

7.2 C (3)
見読目的に応じた応答時間

7.2.3.
見読目的に応じた応答時間とスループット

7.2 C (4)システム障害としての冗長性の確保

7.2.4.
システム障害対策としての冗長化の確保
7.2.5.
システム障害対策としてのバックアップデー
タの保存
7.3 C (2)7.3.1.
不適切な保管・取扱いによる情報の減失、破壊 不適切な保管・取扱いによる情報の滅失、破損の防止の防止
7.3 C (4)7.3.2.
媒体・機器・ソフトウェアの整合性不備による 媒体・機器・ソフトウエアの整合性不備による復元不能の防止復元不能の防止© JAHIS 201353

7.1. 真正性の確保について
7.1.1. 作成者の識別及び認証
ａ． 電子カルテシステム等、PC 等の汎用入力端末により記録が作成される場合(1)

本人認証、識別＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

1． 利用者を正しく識別し、認証を行うこと。 項目なし

(a)
(ア)

技術的対策
電子保存システムは利用者の識別・認証をシステムへのログイン時および必要な時点で以下のいずれかの方式で行えること。
① ID・パスワード方式② IC カード方式（電子証明書による認証）③ USB デバイス方式（電子証明書による認証）④ バイオメトリックス方式⑤ 上記①～④相当以上の識別・認証方式⑥ 上記の組み合わせ
ただし、④バイオメトリックス方式を用いる場合は、1 対 1 の照合となるように他の方式と合わせて用いること。また、①のみによる認証方式は、「安全管理ガイドライン」では推奨され
ていない。

(イ)

IC カード方式、USB デバイス方式等による電子証明書による認証を行う場合は、信頼されたCA が発行した証明書を用いて認証を行うこと。また、CRL を参照し、証明書の有効期限が切れていないか、または、失効していないかを確認すること。
(ウ)
利用者のログイン管理機能として以下のものが備わっていること。
・ システムへのログイン情報（ユーザ識別情報、ログイン時刻、使用時間）の採取・記録、および 1 ヶ月以上の期間のログイン情報を保持・管理する機能
・ 指定期間（年月日・時間帯）のログイン情報をサーチし、例えば以下のような事項の参照が容易に可能なこと－利用者別の日別ログイン時刻、使用時間と使用端末 ID－ログイン失敗者別のログイン操作時刻、失敗回数と使用端末 ID
(b)

運用的対策

(ア)

ID・パスワード方式で認証を行う場合は、以下のように運用すること。
・ パスワードを他者に教えないこと。
・ 他者にパスワードが漏れないようにすること。
・ パスワードは、8 桁以上でかつ数字、アルファベット、使用が許されている記号等を組み合わせて容易に推測できないものとすること。

© JAHIS 201354

2 ヶ月に 1 回以上の頻度でパスワード更新すること。
初期パスワードは必ず速やかに変更すること。
システム管理者は週 1 回以上、その期間の全利用者のログイン時刻、使用時間・回数から統計的に検出される非定常運用状況（例えば、ログイン時間が非常に長時間なケース、ログイン
回数が非常に多いケース、複数端末から同時ログインを行おうとしたケース等）を確認し、問題の発生がないか確認すること。
(イ)
IC カード方式の場合は、他者に貸与しないこと。また、紛失の恐れがあるので以下を義務づけること。
・ 毎日 1 回の所持確認をすること。
・ 所在不明となった場合は速やかに届け出ること。
(ウ)
電子証明書による認証を行う場合は、信頼された CA に証明書の発行を依頼し、失効させる場
合はその情報を CRL へ登録すること。大規模病院等において、院内で認証局を運用する場合、
CA 私有鍵の危殆化や、許可されない証明書発行の防止、私有鍵が本人以外の者に配布されない等の技術的対策や運用ルールを CP/CPS に定め、その通りの運用を実施すること。
(エ)
端末操作中にその場を離れる場合は、操作の終了手続きを取るなどにより、他の人が引き続いて（成り済まして）端末操作できないように運用で定めること。
・
・
・

(1)

アクセスコントロール＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン

2． システムへのすべての入力操作について、 項目なし
対象情報ごとに入力者の職種や所属等の必要な区分に基づいた権限管理（アクセ
スコントロール）を定めること。また、権限のある利用者以外による作成、追記、変更を防止すること。

(a)

技術的対策

(ア)

アクセス権の基本機能として以下のものが満たされること。
・ システムの業務メニュー単位でその業務の運用操作が可能か否かを職務および利用者単位に設定できること。
・ 必要に応じて、上記以上に細かいアクセス権を設定できること。例えば、情報の種類（区分）や内容に応じた参照・更新制限が必要に応じてできること。
(イ)
情報へのアクセス（参照・入力・更新）に際し、その処理内容をログ出力（アクセスログ）し、誰がどのような情報の入力・更新を行ったか識別できること。
(ウ)
アクセスログの解析機能として、例えば以下のものを備えること。
・ 情報の種別を指定し、その種別の情報にアクセスした実績（アクセス拒否やパスワード入力エラー等を含む処理内容）を指定した日時（時間帯）で時間軸に沿って画面等に表示する機能。
・ 利用者を指定し、その利用者がアクセスした実績（情報の種別とその処理内容）を指定した日時（時間帯）で時間軸に沿って画面等に表示する機能。
・ 端末 ID を指定し、その端末からアクセスした実績（情報の種別とその内容）を指定した日時（時間帯）で時間軸に沿って画面等に表示する機能。

© JAHIS 201355

・

管理上のスクリーニングチェック機能として、特殊な時間帯にアクセスした累積時間順の利用者リストや、指定期間内にアクセスした患者情報件数順の利用者リスト等を表示する機能。
・ 日時の順序性チェックなどにより、端末の不正な時刻変更を検出できる機能。
運用的対策

(b)
(ア)
(イ)
(ウ)

(エ)

(2)

システム管理者は、アクセス権の設定・更新を必要に応じて行うこと。
システム管理者は、アクセスログを必要な期間に渡って安全に保存し、後からの分析調査が行えるようにすること。
アクセスログ管理は、スクリーニングチェックに関しては 1 回／週以上の頻度で行い、その他の機能は必要に応じて実施すること。また、個室等の従業者の眼が届かない所に置かれる端末の操作状況については、更に十分な管理を行うこと。
抑制効果を高めるため、当該医療機関の責任者は違反者に対する罰則規程等を定め、利用者全員に予め通知しておくこと。

アクセス端末の制限＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
3． 業務アプリケーションが稼動可能な端末を管理し、権限を持たない者からのアクセスを防止すること。
(a)
(ア)
(b)
(ア)

推奨されるガイドライン
項目なし

技術的対策
業務アプリケーションが稼動可能な端末を IP アドレスなどにより識別し、それ以外の端末から
業務アプリケーションが稼動するサーバへのアクセスを拒否する仕組みを設けること。
運用的対策
業務アプリケーションが稼動可能な端末には、利用者毎に端末へのログインアカウントを作成すること。

© JAHIS 201356

b． 臨床検査システム、医用画像ファイリングシステム等、特定の装置もしくはシステムにより記録が作成
される場合
(3)

装置の操作者の制限＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
1. 装置の管理責任者や操作者が運営管理規
程で明確にされ、管理責任者、操作者以外による機器の操作が運用上防止されていること。

推奨されるガイドライン
項目なし

2. 当該装置による記録は、いつ・誰が行ったかがシステム機能と運営の組み合わせ
により明確になっていること。
(a)
(ア)
(b)
(ア)
(イ)

技術的対策
当該装置に対して、いつ記録が行なわれたかが分かるログを生成する仕組みを設けること。
運用的対策
当該装置に対して、紙などにより、システムで生成されるログと対応が取れる形式で、いつ・誰が記録を行ったかを残し管理すること。
いつ・誰が記録を行ったかの履歴情報に対しては、定期的に管理責任者がチェックを行い、その結果を残すこと。

© JAHIS 201357

7.1.2. 記録の確定手順の確立と、作成責任者の識別情報の記録
a． 電子カルテシステム等、PC 等の汎用入力端末により記録が作成される場合(1)

確定記録の登録＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
1． 診療録等の作成・保存を行おうとする場
合、システムは確定された情報が登録できる仕組みを備えること。その際、作成責任者の氏名等の識別情報、信頼できる時刻源を用いた作成日時が含まれること。

推奨されるガイドライン
項目なし

技術的対策

(a)
(ア)

登録対象の記録が確定記録であるか未確定な記録であるかを区別する仕組みと、それに従って
正確に登録を行う仕組みを実装すること。
(イ)
確定記録を登録する場合は、以下に示すいずれかの対策を行うこと。
・ 記録が確定された時点で確定範囲を明確に記録するために、その確定記録を単位として PDF
等のファイル形式で保存する仕組みを実装すること。このファイル内には、作成責任者の氏名等の識別情報、信頼できる時刻源を用いた作成日時が必ず含まれること。また、これらの情報の信頼性を高めるために電子署名やタイムスタンプを施す仕組みが実装されていることが望ましい。
・ 確定記録となったことを示すフラグをデータベース上で管理し、記録が確定された時点で適切にフラグを変更する仕組みを実装すること。この場合には、確定された記録の範囲が解るよう管理すること。かつ、その確定記録と結び付けられた作成責任者の氏名等の識別情報、信頼できる時刻源を用いた作成日時が必ず存在すること。
・ その他、実装上の仕組みから上記の対策が困難である場合には、上記と同等以上の技術的対策を行うこと。
(ウ)
確定時に記録される作成責任者の氏名等の識別情報は、確定者をシステム利用者が単純に入力
または申告するような手順で得られる信頼の低い識別情報は使用せず、確定処理の過程で本ガイドライン「作成者の識別及び認証」で示す認証を行うことによって得られた信頼ある識別情報に基づいて作成される仕組みを実装すること。
運用的対策

(b)
(ア)

(2)

システム障害の発生等により紙での運用等へ一時的に切り替える可能性がある場合には、確定
記録の登録が行えなかった記録に対して、システム復旧後の登録手順を規則化しておくことを医療機関に推奨すること。

確定記録の確認＜安全管理ガイドラインの要求事項＞© JAHIS 201358

最低限のガイドライン
2． 「記録の確定」を行うにあたり、作成責任者による内容の十分な確認が実施できるようにすること。

項目なし

技術的対策

(a)
(ア)

作成責任者による内容の十分な確認が実施できるよう、確定対象の記録の内容を明確に提示する仕組みを実装すること。
運用的対策

(b)
(ア)

(3)

推奨されるガイドライン

上記技術と合わせて、確定操作が何を意味するかについて医療機関の責任者（または代行者）
が利用者に確実に伝え、十分な確認を行わないうちに確定操作を行わないよう十分な説明を行うことを推奨すること。

確定記録の原状回復＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
3． 確定された記録が、故意による虚偽入力、書き換え、消去及び混同されることの防止対策を講じておくこと及び原状回復のための手順を検討しておくこと。

(a)
(ア)

(b)
(ア)
(イ)

(ウ)

推奨されるガイドライン
項目なし

技術的対策
確定された記録を保持しているファイルや DB 等にシステム利用者が直接アクセスできない仕組みを構築することによって不正行為を防ぐか、それが困難な場合にはハッシュ関数を用いて生成した確定記録のハッシュ値を保存し、定期的にこのハッシュ値との比較を行うか、これと同等の手法によって不正行為の検知を行う仕組みを実装すること。不正が検知された場合には、本ガイドライン「保存性の確保について」を参考にリストア可能とすること。
運用的対策
管理台帳等を用いてバックアップ媒体の保管先や媒体の耐久年次を管理することを医療機関に推奨すること。
確定記録がバックアップされる前に不正行為が行われた場合の原状回復方法や、不正行為が発覚するまでの間に不正行為が行われた確定記録に対して行われた追加及び訂正の確定記録の取扱い方法について規則化しておくことを医療機関に推奨すること。
システムの入替を行う場合には、その前にバックアップを行うことで入替中および入替後に障害が発生しても入替前の状態に戻せるようにすること。

© JAHIS 201359

b． 臨床検査システム、医用画像ファイリングシステム等、特定の装置もしくはシステムにより記録が作成
される場合
(4)

確定記録の取扱い＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
1. 運用管理規程等に当該装置により作成された記録の確定ルールが定義されていること。その際、作成責任者の氏名等の識別情報（または装置の識別情報）、信頼できる
時間源を用いた作成日時が記録に含まれること。

推奨されるガイドライン
項目なし

2. 確定された記録が、故意による虚偽入力、書き換え、消去及び混同されることの防止対策を講じておくこと及び原状回復のための手順を検討しておくこと。
(a)

技術的対策

本ガイドライン「7.1.2.記録の確定手順の確立と、作成責任者の識別情報の記録」の a に準じる。
(b)

運用的対策

本ガイドライン「7.1.2.記録の確定手順の確立と、作成責任者の識別情報の記録」の a に準じる。

© JAHIS 201360

7.1.3. 更新履歴の保存(1)

更新履歴の保存と参照＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
1． 一旦確定した診療録等を更新した場合、更新履歴を保存し、必要に応じて更新前と更新後の内容を照らし合せることができること。

推奨されるガイドライン
項目無し

2．同じ診療録等に対して更新が複数回行われた場合にも、更新の順序性が識別できるように参照できること。

(a)
(ア)

(イ)

(ウ)

(エ)
(b)
(ア)

技術的対策
更新時、それまでに確定し記録されている情報は変更せず、更新後の内容を別の記録単位として記録する機能を設けるか、又は、更新前の情報と更新後の情報の差分を記録する機能を設けること。
更新後の内容を別の記録単位として記録する場合は、更新経過を表示し確認する機能を設けること。具体的には、変更前の記録を確認することができて、かつ、更新後に何処が変わったかが把握できる機能を設けることが望ましい。
更新前の情報と更新後の情報の差分を記録する場合、例えば、更新前のデータを同時に表示する場合は更新前のデータに修正線を入れて更新後のデータと識別できる様にし、データを追加する場合は追加範囲を下線と更新日付で識別するような機能を設けること。
追記・書き換え・消去等の確定操作を行う際には、作成責任者の電子署名及び、信頼できる時
刻源を用いたタイムスタンプを付けることが望ましい。
運用的対策
確定操作にて電子署名を付ける場合は、必ず本人の証明書にて署名を行い、他者の証明書を用いることを禁止すること。

© JAHIS 201361

7.1.4. 代行操作
代行操作とは、本来は自ら操作を行うべき情報システムの利用者（以下、「依頼者」と呼ぶ）が、何らかの理由によって、その操作を第三者（以下、「代行操作者」と呼ぶ）に依頼して行ってもらう操作のことをいう。このような状況には下記のようなケースが考えられる。
・
依頼者が手術中等の理由で情報システムを操作できず、代行操作者に口頭等で直接指示を行うとき
・依頼者が医療現場におらず、代行操作者に電話等で指示を行うとき

・研修医等が主治医の指導の下に操作を行うとき医療機関において、代行操作が行われる際には、まずその基本方針および運用管理規程が明確に定まっていることが重要である。すなわち、「誰が」「誰を」「どういう場合に」行うことを認めるのか、そしてそれが「どのような手順で」行われるのかが周知徹底されており、情報システムがその規定に従って動作することが求められる。
(2)

代行プロシジャの定義

医療機関がその基本方針で代行操作を認める場合には、情報システムを利用したどういう手続き（以下、「代行プロシジャ」と呼ぶ）に対してそれを認めるのか、定義しなければならない。代行操作を行うためには、この代行プロシジャを定義する機能が、情報システムに実装されていることが望ましいが、必須ではな
く、実装されてない場合は運用で担保すること。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
1． 代行操作を運用上認めるケースがあれ
ば、具体的にどの医療に関する業務等に適用するか、また誰が誰を代行してよいかを運用管理規程で定めること。
(a)
(ア)
(イ)

(ウ)

(エ)

項目無し

技術的対策
情報システムは、ある利用者に実行権限が与えられた任意の操作について、その操作が第三者
によって代行可能かどうか（以下、「代行ポリシー」と呼ぶ）を定義する機能を有していること。
情報システムは、代行可能と定義された操作を、どの利用者（代行操作者）が代行権限を持つか、定義する機能を有していること。ここで、代行操作者を定義する際の属性として、
「特定の
利用者名」
、
「職種」などが考えられる。
情報システムは、権限のある代行操作者が代行操作を行う際には、「誰の」代行であるか（依頼者）を指定するための仕組みを備えていること。ここでいう「誰の」には、「主治医」等の特定の個人を識別できない属性や「医師」等の職種名等で行うのではなく、特定の利用者を指定すること。
情報システムは、当該の操作が代行操作者によるものであることを認識したときには、下記を確認する機能を有していること。
① 当該の操作が代行可能であること。
② 代行操作者が当該の操作の代行を行う権限を有していること。
③ 代行を依頼した者が、その操作を行う権限を有していること。

© JAHIS 201362

運用的対策(b)

情報システムが上記技術的対策の（ア）～（エ）の機能のすべて、もしくは一部を実装していない場合には、医療機関は、下記の運用を行わなければならない。
(ア)
当該の情報システムにおいて提供されるすべての代行操作に対して、代行ポリシーおよび運用管理規程を設定すること。

(3)

代行操作の記録代行が行われた場合には、必ずその事実が記録として残されなければならない。これは情報システムの機能として実装されることが望ましいが、必須ではなく、運用で担保することも可能である。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
2. 代行操作が行われた場合には、誰の代行が誰によっていつ行われたかの管理情報が、その代行操作の都度記録されるこ
と。

技術的対策

(a)
(ア)
(イ)

情報システムは、代行操作者による操作を許可し、実際にその操作が行われた際には、その旨を記録する機能を有していること。
記録には、「誰の指示によるものか」（依頼者）を示す情報が含まれること。
運用的対策

(b)
(ア)

(4)

項目なし

情報システムが、代行操作である旨を記録できないときは、その事実を他の方法（例えば記録簿など）に残すことで代用可能である。ただし、この場合には、情報システムが通常のアクセ
スログを収集する機能を備えていることが前提となる。

代行操作の承認

代行操作を行うにあたっては、承認操作が必要になる場合が想定され、医療機関の基本方針として規定される必要がある。代行操作を行うにあたっての承認プロセスとして、現実には次のケースが考えられる。
(1) 事前承認
代行操作者が行う操作がシステム的に有効になる前に、依頼者の承認を必要とする場合(2) 事後承認
代行操作者が行う操作は依頼者が承認を行う前に有効になるが、事後に依頼者の承認を必要とする場合(3) 承認不要

依頼者による承認を全く必要としない場合

実際の業務では、すべての代行プロシジャを、これらのうちのどれか一つに統一することは少ないと思われ、必然的に混在した形で行われると考えられる。情報システムの機能としては、任意の代行プロシジャに対し、どの承認プロセスを採用するのか、選択できることがベストであろうと考えられる。
ただ、すべての機能を実装することが困難な場合には、これらの承認プロセスの一部もしくは全部を運用で担保することも可能である。ここではすべてをシステムの機能として実装する場合を技術的対策として表© JAHIS 2013

63

し、それを実装しない場合の回避策を運用的対策で表すことにする。
＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
推奨されるガイドライン
3. 代行操作により記録された診療録等は、できるだけ速やかに作成責任者による「確定操作（承認）」が行われること。

項目なし

4． 一定時間後に記録が自動確定するような運用の場合は、作成責任者を特定する明確なルールを策定し運用管理規程に明記すること。
(a)
(ア)
(イ)

(ウ)
(エ)
(オ)

(カ)
(b)
(ア)

技術的対策
情報システムは、代行可能とした任意の操作について、その承認プロセス（事前承認、事後承認、承認不要）を定義できること。
情報システムは、「事前承認」とされた代行操作が要求されると、その操作を有効にする前に依頼者に対して通知を行う。情報システムは、この通知を依頼者が確認するための仕組みを備えること。
代行操作の事前承認を通知された依頼者は、内容を確認して承認操作を行う。情報システムは、
この承認操作のための仕組みを備えること。
情報システムは、依頼者の承認操作が行われた時点で、要求された操作を有効にすること。
情報システムは、「事後承認」とされた代行操作が要求されると、その操作を有効にすると同時に、依頼者に対して通知を行う。情報システムは、この通知を依頼者が確認するための仕組みを備えること。
代行操作の事後承認を通知された依頼者は、内容を確認して承認操作を行う。情報システムは、
この承認操作のための仕組みを備えること。
運用的対策
情報システムが「事前承認」の機能を持たない場合は、下記の運用を行うこと。
① 代行操作者は「事前承認」としたい操作を行う際に、その操作を行う前に何からの手段（口頭、メール、電話、書面等）で依頼者に操作の内容を確認する。
② この確認を行った記録を何らかの方法で残しておく。
③ 代行操作者は当該の代行操作を実施する。

(イ)

情報システムが「事後承認」の機能を持たない場合は、下記の運用を行うこと。
① 代行操作者は「事後承認」としたい代行操作を、依頼者への確認をせずに（してもよいが）実行する。
② 代行操作者は当該の操作を行った後、何からの手段（口頭、メール、電話、書面等）で依頼者に操作の内容を確認する。
③ この確認を行った記録は、何らかの方法で残しておく。

© JAHIS 201364

7.2. 見読性の確保について
7.2.1. 情報の所在管理＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
１.紙管理された情報を含め、各種媒体に分散管理された情報であっても、患者毎の情報のすべての所在が日常的に管理されて
いること。
(a)
(ア)

(b)
(ア)

推奨されるガイドライン
項目なし

技術的対策
電子カルテシステムや PACS など大量のデータを扱うシステムにおいて、記憶装置の容量の制約などから、通常のオンライン業務でアクセスできない媒体にデータを部分的に保管することがある。このように複数の媒体に分散してデータを保管する場合は、患者の情報がどの媒体（オンライン、オフライン（どの外部媒体））に保管されているのかを管理ができる必要がある。
運用的対策
紙カルテ、電子化されていない紹介状などの紙を含めた患者の情報の保管場所について、院内で各種情報の保管ルールを定め、必要な時間内に患者の情報の所在が判別でき、アクセスできるように管理する必要がある。

© JAHIS 201365

7.2.2. 見読化手段の管理＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
１.電子媒体に保存されたすべての情報とそ
れらの見読化手段は対応づけて管理されていること。また、見読手段である機器、
ソフトウェア、関連情報等は常に整備されていること。
(a)
(ア)
(イ)

(ウ)
(b)
(ア)
(イ)

推奨されるガイドライン
項目なし

技術的対策
業務システムのバージョンアップ等に伴って、データのフォーマット等に変更が発生する場合
でも、バージョンアップ前のデータの見読性を担保すること。
コード化されたデータがある場合は、データ本体が作成された際のコードデータの意味を表す
テーブルなどを合わせて管理するなどによりデータが作成された際の見読性を確保する仕組みを提供すること。
システム間のデータ移行を前提として、標準的な形式にてデータ出力する機能を有すること。
運用的対策
機器の更新などによって、保存しているデータの見読性が損なわれることがないように、機器等の維持管理を行うこと。
基本ソフトウェア、業務システムのバージョンアップや修正情報の適用などによって、保存しているデータの見読性が損なわれることがないように、ソフトウェア保守をする際は、試験シ
ステムなどで事前に影響がないことを確認した上で業務システムのバージョンアップを行うな
どの管理ルールを設け、運用すること。

© JAHIS 201366

7.2.3. 見読目的に応じた応答時間とスループット＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
１.目的に応じて速やかに検索表示もしくは書面に表示できること。
(a)
(ア)
(b)
(ア)

推奨されるガイドライン
項目なし

技術的対策
各医療機関の見読目的に対する見読化機能（手段）および平均的なスループットを提示できる
こと。
運用的対策
各医療機関では、導入システムの各種の見読目的に応じた見読化手段とスループットをあらかじめ確認した上で、運用を決定すること。

© JAHIS 201367

7.2.4. システム障害対策としての冗長性の確保＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
１.システムの一系統に障害が発生した場合
でも、通常の診療に差し支えない範囲で診療記録等を見読可能とするために、システムの冗長化や代替え的な見読手段を用意すること。
(a)

推奨されるガイドライン
項目なし

技術的対策

(ア)

医療機関の特性にあった可用性を確保するために、下記のような冗長性のあるシステムを構成とすることが望ましい。
・ デュアルシステム
・ デュプレックスシステム
・ サーバのクラスター化
・ サーバの RAID 構成など(イ)
通常の業務システムが停止した場合でも、最低限下記データが参照できる手段を提供できることが望ましい。
・ 外来診療における前回診療内容
・ 入院診療における前日までの入院期間中の診療内容
(b)
(ア)

(イ)

運用的対策
技術的な対策で保障できない診療内容について、紙などに残すことを含めたシステム障害時の運用を事前に検討し、障害時の運用マニュアルを整備すること。また、万一障害が発生した場
合に、その対応が確実かつ速やかに行えるように障害時運用の有効性を定期的に点検すること。
システム障害時の業務停止時間を短縮化するために、ハードウェア、ソフトウェアの保守サポ
ート契約を締結しておくことが望ましい。

© JAHIS 201368

7.2.5. システム障害対策としてのバックアップデータの保存＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)バックアップサーバ

項目なし

システムが停止した場合でも、バップアッ
プサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読することができること。
(2)見読性を確保した外部出力

項目なし

システムが停止した場合でも、見読目的に該当する患者の一連の診療記録を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力することができること。
(3)遠隔地のデータバックアップを利用した
見読機能

項目なし

大規模火災等の災害対策として、遠隔地に電子保存記録をバックアップし、そのバッ
クアップデータと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読することができること。
(a)
(ア)
(イ)
(ウ)

技術的対策
補助記憶装置の障害に備え、データのバックアップ機能を提供すること。バックアップ媒体については、特に規定しない。
システムに障害が発生した場合に備え、過去のデータを参照が可能なバックアップシステムを準備することが望ましい。
大規模災害に備えて、遠隔地にデータバックアップを行い、セキュリティを確保しつつそのデータを参照できる機能を提供することが望ましい。

(b)

運用的対策

(ア)

バックアップデータからの復旧を行う場合の復旧時間を考慮して、システム構成およびバック
アップ運用を決定すること。
・ バックアップデータ格納用サーバの確保
・ フルバックアップ、差分バックアップ、増分バックアップ© JAHIS 201369

7.3. 保存性の確保について
7.3.1. 不適切な保管・取扱いによる情報の滅失、破壊の防止＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
5．各保存場所における情報がき損した時に、バックアップされたデータを用いてき損前の状態に戻せること。もし、き損前と同じ状態に戻せない場合は、損なわれた範囲が容易に分かるようにしておく
こと。

(1)

推奨されるガイドライン
3．診療録等のデータのバックアップを定期的に取得し、その内容に対して改ざん等
による情報の破壊が行われていないことを検査する機能を備えること。

バックアップからの復旧

医療機関で利用される情報システムの多くは、データベース管理システム（DBMS）を利用しており、その機能は千差万別ではあるものの、システム障害からの復旧と情報保護を目的とした情報のバックアップについては、ほぼ共通した概念と機能を持つに至っていると考えて良い状況である。また、任意のバックアップ情報から、データベースの内容を復元することを、「リストア」と呼び、バックアップとリストアは常に対で考える必要がある。
バックアップ方法としては、下記の三つが一般的であり、情報システムの規模や情報の性質に応じて、適宜運用されている。
フルバックアップ対象とする情報システムが、ある時点で保持するすべての情報（オペレーティン
グシステムや、ソフトウェアの動作環境は除く）をバックアップするやり方。これはバックアップ作業の基本的な方法で、すべての情報をバックアップするので作業には一般的に時間を要し、かつ保存に必要なディスクスペースも大きくなる
が、1 回のリストア作業でディスクイメージを復元できるというメリットがある。

差分バックアップ

前回のフルバックアップを行った直後から、任意の時点（差分バックアップを実施する時点）までの差分を、差分バックアップとして管理する方法。フルバック
アップに差分バックアップをマージすることで、差分バックアップを実施した時点の状態にリストアできる。一般に差分バックアップで必要とするディスクサイ
ズはフルバックアップよりかなり小さいため、バックアップのために必要なディ
スク容量を節約できる。フルバックアップの後で差分バックアップを複数回実施
すると、後の差分バックアップにはそれ以前の差分バックアップの情報を包含するので、常に最新の差分バックアップだけを管理すればよい。

増分バックアップ

前回のフルバックアップ、または増分バックアップを実施した時点から、任意の時点（今回の増分バックアップ実施時点）までの差分（増分）を増分バックアップとして管理する方法。増分バックアップは、差分バックアップと違って情報の重複がないため、よりコンパクトに管理でき、バックアップに要する時間も短縮できる。また、任意の時点に復帰できるメリットもある。ただし、フルバックア
ップと実施した全ての増分バックアップを管理しなければならず、リストアの際にはそれらの全てを時系列に従ってマージする必要があるので、管理負荷と作業負荷は一般に差分バックアップによる方法よりも大きくなる傾向がある。

これらの情報の他に、「ジャーナル」や「更新ログ」などの名で知られる、データベースへの変更操作を© JAHIS 201370

記録した情報をバックアップ操作に利用する方法もある。
ここでは、「フルバックアップ」を基本として、上記に示した何らかの補助情報を使って、バックアップを管理する際の要件について記述する。操作は利用する DBMS によって詳細が異なるため、ある時点における「フルバックアップ」に補助情報を適用し、その後の時点に更新することを、「変更分を反映する」という言葉で表現することにする。
(a)
(ア)

(イ)
(ウ)

(エ)

(b)

技術的対策
情報システムは、フルバックアップを実施可能なシステム構成とすること。ここで「実施可能」とは、この作業が妥当な時間内に終了できること、という意味を含んでいる。情報システムのフルバックアップを行う際には、業務の停止を伴うことが多く、この時間が長く（例えば 1 日以上）なると、運用上作業の実施が困難になるので、そのようなシステム構成は推奨されない。
情報システムは、フルバックアップからのリストアが実施可能なシステム構成とすること。
情報システムは、フルバックアップされた情報について、改ざん、もしくは欠落を検知する仕組みを備えること。なお、これができない場合は、「(b)運用的対策」の（カ）項により、運用で担保すること。
情報システムは、前回のフルバックアップから次回のフルバックアップまでの間の差分情報を保持し、反映する機能を備えること。なお、これができない場合は、「(b)運用的対策」の（イ）項により、運用で担保すること。
運用的対策

(ア)

情報システムを運用する組織は、リスクアセスメントを行ってフルバックアップを計画（たとえば、1 週間前に戻せる、等）し、実施すること。
(イ)
前回のフルバックアップから次回のバックアップの間は、変更情報を収集すること。この収集間隔は当該組織の運用ルールで定めること。なお、情報システムに変更情報を収集する機能がない場合は、当該組織の運用ルールで、許容可能なフルバックアップの間隔を定め、そのとおり実施されるような管理を行うこと。
(ウ)
情報システムを運用する組織は、フルバックアップを少なくとも 2 世代は保持すること。
(エ)
情報システムを運用する組織は、作成したフルバックアップを保護し、改ざん、もしくは欠落が起きないように運用（たとえば、バックアップを作成した媒体に封をして、鍵のかかる保管庫へしまう、等）すること。
(オ)
情報システムを運用する組織は、テスト環境等を使ったフルバックアップからのリストア手順
を、少なくとも 1 年に 1 度は確認しておくことが望ましい（注 1）。
(カ)
情報システムがフルバックアップの改ざんを検知する仕組みを備えることができない場合は、
データベースの内容変更が通常のアプリケーションを介さない手段（管理ツールの利用等）でなされないような管理を行うこと。また、通常のアプリケーションを介した内容変更は、監査
ログにより追跡可能な運用を行うこと。
（注 1） データベースのフルバックアップをリストアし、その内容を検証することは、実際には極めて困難である場合が多いと想定される。これを行うには、検証用のプログラムを提供することに加えて、リストア用の環境を医療機関に用意していただく等、費用的な困難さも伴う場合がある。フルバックアップからのリストアを実際に行わなければならないような事態の発生自体を回避するような運用が望まれるが、本件に関しては医療機関にもリスクの大きさを理解いた
だいて、何とか実現するようにもって行くことが望まれる。

© JAHIS 201371

7.3.2. 媒体・機器・ソフトウェアの整合性不備による復元不能の防止(1)

標準的な形式での入出力＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
1．システム更新の際の移行を迅速に行える
ように、診療録等のデータを標準形式が存在する項目に関しては標準形式で、標準形式が存在しない項目では変換が容易なデータ形式にて出力及び入力できる機能を備えること。

推奨されるガイドライン
項目なし

技術的対策

(a)
(ア)

情報システムは、保持するすべての情報（オペレーティングシステムや、ソフトウェアの動作環境は除く）を標準的な形式（注 1）で出力する機能を備えること。
(イ)
情報システムは、保持する情報のうち、他のシステムから移行可能なものについては、標準的な形式で格納された情報から入力する機能を備えること。
（注 1）
ここでいう標準的な形式とは、格納情報の解析に特定のベンダーに固有の知識を必要としない、一般に知られた形式をいう。ここでいう「形式」は、情報コンテナとしての物理的なものを想定しており、情報の論理的な表現体系（病名等のマスタや HL7 等）については想定していない。下記に
このような形式の例を示す。
・CSV 形式のテキストファイル
・XML 形式のテキストファイル
・その他、ISO 等の国際標準や JIS 等の国内標準で定められた形式、または広く一般に知られた形式
運用的対策

(b)
(ア)
(イ)

(2)

情報システムのベンダーは、上記の形式で出力される情報のデータ構造を文書により開示すること。また、この文書の内容は、最新のデータ構造を反映したものであること。
情報システムのベンダーは、自社の情報システムが、標準的な形式で格納された情報から入力する機能を標準的に備えていない場合は、必要に応じて移行用のプログラムを提供すること。

マスタ変更への考慮＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
2． マスタデータベースの変更の際に、過去の診療録等の情報に対する内容の変更が起こらない機能を備えていること。

© JAHIS 201372

推奨されるガイドライン
項目なし

(a)
(ア)

(イ)

(b)
(ア)

技術的対策
薬剤、検査種別等を一意に識別するためのコード体系（いわゆるマスタ情報）を利用する情報システムは、その情報を変更した際に、以前に入力した情報の内容に影響を与えないようにすること。たとえば、「γ-GTP」という表記名をもつ検査項目に「0102」というコードを適用していた情報システムにおいて、表記名をそのままに、コードを「00000102」に変更するケースを考える。この変更後、以前にコード「0102」を用いて登録された情報を表示した場合にも、
正しく「γ-GTP」が表示されなければならない。
上記（ア）を実現する方法として、情報格納の際にコードではなく表記名を格納するという方法、情報格納の際にマスタ情報のバージョン番号を格納して複数のマスタ情報を管理する方法、などいろいろな方法が考えられるが、ここでは具体的な実現方法は問わない。
運用的対策
情報システムがマスタ情報の変更に際して、過去の情報が受ける影響を回避できない場合には、これによる混乱が生じないように運用に留意すること。

© JAHIS 201373

8. 診療録及び診療諸記録を外部に保存する際の基準
外部保存の形態として、下記の三つのパターンがあるが、（2）、（3）については、従来から行われていることであり、本ガイドラインでは、（1）に関しての対応について記述する。
(1) 電子媒体による外部保存をネットワークを通じて行う場合(2) 電子媒体による外部保存を磁気テープ、CD-R、DVD-R などの可搬型媒体で行う場合(3) 紙やフィルム等の媒体で外部保存を行う場合
本章では、厚生労働省の「医療情報システムの安全管理に関するガイドライン(第 4.1 版)」、経済産業省の「医療情報を受託管理する情報処理事業者向けのガイドラン（第 2 版）」、総務省の「ASP・SaaS 事業者が医療情報を取り扱う際の安全管理に関するガイドライン（第 1.1 版）」に関して以下の節（8.1 節 厚
生労働省、8.2 節 経済産業省、8.3 節 総務省）にてベンダーの視点から JAHIS の基準を示し、情報処理システムに関する要求と思われる部分について、技術的な解説を行なったものである。
本章は三省のガイドラインにおける技術的要求事項の内、システムベンダーが情報処理事業者及び ASP・
SaaS 事業者へシステムを提供する際に求められる技術的要求事項のみ（図 8-1 における網掛け部）を対象としている。三省のガイドラインの各要求事項はそれぞれのガイドラインが対象としている医療機関、シス
テムベンダー、サービスプロバイダー等を対応主体として記述されているが、本章ではそれぞれのガイドラ
インの対応主体がシステムベンダーとなることを意識願いたい。また、本章ではサービス提供事業者に求められる事項については範囲外としているので注意願いたい。

図 8-1 三省ガイドラインと本ガイドランの位置づけ© JAHIS 201374

以下に三省のガイドラインと本ガイドラインの記載章の対比を示す。
＜厚生労働省：安全管理ガイドラインとの対比＞
安全管理ガイドライン
7.1C【ネットワークを通じて医療機関等の外部に保存する場合】
7.2C【ネットワークを通じて医療機関等の外部に保存する場合】
7.3C【ネットワークを通じて医療機関等の外部に保存する場合】
7.3D

本ガイドライン8.1.1 ネットワークを通じて医療機関等の外部に保存する場合の真正性の確保
8.1.2 ネットワークを通じて医療機関等の外部に保存する場合の見読性の確保
8.1.3 ネットワークを通じて医療機関等の外部に保存する場合の保存性の確保

同上【ネットワークを通じて医療機関等の外部に保存する場合】
8.1.1 電子保存の 3 基準の遵守

8.1.1~8.1.3 として外部保存に関わる項目のみ
追記＜経済産業省：医療情報受託管理ガイドラインとの対比＞
医療情報受託管理ガイドライン

本ガイドライン7.2.2 情報の分類

8.2.1 情報の分類

7.6.1 情報処理装置及びソフトウェアの保守

8.2.2 情報処理装置及びソフトウェアの保守

7.6.3 悪意のあるコードに対する管理策

8.2.3 悪意のあるコードに対する管理策

7.6.8 情報交換に関するセキュリティ

8.2.4 情報交換に関するセキュリティ

7.6.9 情報処理システムに対するセキュリティ 8.2.5 情報処理システムに対するセキュリテ事項
ィ要求事項
7.6.10 アプリケーションに対するセキュリティ8.2.6 アプリケーションに対するセキュリテ
ィ要求事項
事項
7.6.11 暗号による管理策

8.2.7 暗号による管理策

7.6.12 ログの取得及び監査

8.2.8 ログの取得及び監査

7.6.13 アクセス制御方針

8.2.9 アクセス制御方針

7.6.14 作業者アクセス及び作業者 ID の管理 8.2.10 作業者アクセス及び作業者 ID の管理© JAHIS 201375

＜総務省：ASP・SaaS 医療情報ガイドラインとの対比＞
ASP・SaaS 医療情報ガイドライン

本ガイドライン3.3 外部保存における ASP・SaaS 事業者への要求事項

8.3. 総務省の ASP・SaaS 事業者が医療情報を取り扱う際の安全管理に関するガイ
ドラインに関する事項

3.3.2 真正性の確保における ASP・SaaS 事業 8.3.1 真正性の確保における ASP・SaaS 事業者への要求事項
者への要求事項
3.3.5 外部保存における ASP・SaaS 事業者へ 8.3.2 外部保存を受託する機関の選定基準及の要求事項
び情報の取り扱いに関する基準における ASP・SaaS 事業者への要求事項
3.4 ASP・SaaS の提供終了における ASP・
SaaS 事業者への要求事項© JAHIS 201376

8.3.3 ASP・SaaS の提供終了における ASP・
SaaS 事業者への要求事項

8.1. 厚生労働省の医療情報システムの安全管理に関するガイドラインに関する事項
本節では厚生労働省の「医療情報システムの安全管理に関するガイドライン」においてシステムベンダー
が電子媒体による外部保存をネットワークを通じて行う情報処理事業者及び ASP・SaaS 事業者へシステムを提供する際に求められる技術的要求事項を対象に解説を行う。

8.1.1. ネットワークを通じて医療機関等の外部に保存する場合の真正性の確保＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1) 通信の相手先が正当であることを認識す 項目なし
るための相互認証を行うこと
診療録等のオンライ外部保存の受託先の施設と外部保存の委託元の施設が、お互いに通信目的とする正当な相手かどうかを認識するための相互認証機能が必要である。
(2) ネットワーク上で「改ざん」されていない 項目なし
ことを保証すること
電気通信回線の転送途中で診療情報が改ざんされていないことを保証できること。
なお、可逆的な情報の圧縮・回復ならびに
セキュリティ確保のためのタグ付けや暗号化・平文化などは改ざんにはあたらない。
(3) リモートログイン機能を制限すること
保守目的などのどうしても必要な場合を除き、リモートログインが行えないように適切に管理されたリモートログインのみに制限する機能を設けなければならない。

© JAHIS 2013

77

項目なし

(a)技術的対策（ア） 外部保存をする場合のネットワークは、専用線や VPN 技術などを使用しデータの送信元と送信先のエンティティ間の認証を行うこと。認証手段としては PKI による認証、Kerberos のような鍵配布、事前配布された共通鍵の利用、ワンタイムパスワードなどの容易に解読されない方法を用いるのが望ましい。
（イ） ネットワーク経路での改ざんを防止するために SSL 等の暗号化通信を行うこと。その際、暗号方式については十分な強度のもの（電子政府推奨暗号に記載されているもの）を使用すること。
（ウ） 保守目的以外に、委託元の操作者以外がデータアクセスすることを制限できること。
(b)運用的対策(ア)

委託元医療機関内の電子カルテネットワークに接続されているシステムや機器経由で外部（保守ネットワークなど）からの侵入がないようネットワーク設計および管理を行う様に医療機関を指導すること。

© JAHIS 201378

8.1.2. ネットワークを通じて医療機関等の外部に保存する場合の見読性の確保＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン
(イ)

項目なし

緊急に必要になることが予測される診療録等の見読性の確保

緊急に必要になることが予測される診療録
等は、内部に保存するか、外部に保存しても複製又は同等の内容を医療機関等の内部に保持すること。
(ウ)

緊急に必要になるとまではいえない診療情報の見読性の確保

緊急に必要になるとまではいえない情報についても、ネットワークや施設の障害等に対応できるような措置を行っておくことが望ましい。
(a)技術的対策（ア） システム障害対策として、受託先のシステムは下記のような障害を回避できる冗長構成であること。
① ハードウェアの障害による長時間のシステム停止② OS やミドルウェアの障害による長時間のシステム停止（イ） ネットワークの障害対策として、セキュリティの確保された複数の通信経路を提供すること。
（ウ） 保存先のデータをアクセスできないことを想定して、診療に支障を来たさない最低限の診療記録を参照できるように委託元医療機関内に保存できること。
(b) 運用的対策（ア）委託元の医療機関内に電子データとして保存する場合は、保存データの改ざん、盗難等を防ぐための安全管理を行うこと。

© JAHIS 201379

8.1.3. ネットワークを通じて医療機関等の外部に保存する場合の保存性の確保＜安全管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1) データ形式および転送プロトコルのバー 項目なし
ジョン管理と継続性の確保を行うこと
保存義務のある期間中に、データ形式や転送プロトコルがバージョンアップまたは変更されることが考えられる。その場合、以前のデータ形式や転送プロトコルを使用している施設が存在する間は対応を維持しなくてはならない。
(2) ネットワークや外部保存を受託する施設 (1) ネットワークや外部保存を受託する施設の設備の劣化対策を行うことの設備の互換性を確保すること
ネットワークや外部保存を受託する機関の施設の設備の条件を考慮し、回線や設備が劣化した際にはそれらを更新する等の対策を行うこと。

回線や設備を新たなものに更新した場合、旧来のシステムに対応した機器が入手困難となり、記録された情報を読み出すことに支障が生じるおそれがある。従って､受託先の施設は、回線や設備の選定の際は将来の互換性を確保するとともに、システム更新の際には旧来のシステムに対応し､安全なデータ保存を保証できるような互換性のある回線や設備に移行すること。

(a) 技術的対策（ア） 受託先システムの OS、データベースマネージメントソフトなどのミドルウェアやアプリケーション
業務システムのバージョンアップがあった場合でも、旧バージョンのソフトウェアを使用している
委託元の業務に支障のないように、各委託元のバージョンに対応した機能を維持すること。
（イ） データ移行を前提として、標準的な形式（安全管理ガイドライン第 5 章参照）でのデータ出力が可能であること。
（ウ） データの破壊に対する保護対策として、保管先のシステムの外部記憶装置は RAID 構成やクラスター構成などの冗長構成を採用するとともに、万一のデータ破壊に備えてバックアップデータからの復旧ができる手段を備えていること。また、バックアップデータは 1 日単位で 1 週間以上前の状態に戻せるように保管すること。
（エ） 受託先は、耐震、防火、停電等の設備上の安全対策が施されていること。
(b) 運用的対策（ア） 定期的に安全対策が有効に機能することを点検するとともに、設備が良好に機能する状態を維持すること。

© JAHIS 201380

8.2. 経済産業省の医療情報を受託管理する情報処理事業者向けのガイドライン
に関する事項
本節では経済産業省の「医療情報を受託管理する情報処理事業者向けのガイドライン」においてシステム
ベンダーが電子媒体による外部保存をネットワークを通じて行う情報処理事業者及び ASP・SaaS 事業者へシステムを提供する際に求められる技術的要求事項を対象に解説を行う。

8.2.1. 情報の分類＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(5)分類がわかるように情報にラベルをつける 項目なし
こと（電磁的記録にラベルをつける方式には様々なものが考えられるので、実装する方式の詳細及び安全性について、医療機関
等側の確認、承認を得ること）。
(6)各ラベルに応じた処理方式（保存、配送、複 項目なし
製、廃棄等）を定めること。
(1)情報の処理について履歴を取得し、資産台帳等に記録することが望ましい。

項目なし(a) 技術的対策
追記事項なし(b) 運用的対策（ア）どのような情報が管理されているかを提示できること。
（イ）情報処理の履歴を資産台帳等に記録することは、電子カルテ等については変更履歴を採取することに含まれると考えられる。

8.2.2. 情報処理装置及びソフトウェアの保守＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)保守に伴う情報処理装置及びソフトウェア 項目なしの変更がもたらす影響の評価を行うこと。
(2)変更が既存の業務及び設備に悪影響を及ぼ 項目なし
す可能性がある場合には、安全なデータの保存を保証するため、影響を最小限に抑える方策を検討すること。
(3)医療情報を保存・交換するためのデータ形 項目なし

© JAHIS 201381

最低限のガイドライン
推奨されるガイドライン
式、プロトコルが変更される場合、変更前のデータ形式、プロトコルを使用する医療機関等が存在する間、以前のデータ形式、
プロトコルの利用をサポートすること。
(4)情報処理装置及びソフトウェアの保守作業 項目なし
については、情報処理業務の停止時間を最小限に留めるように計画をたてて実施すること。
(5)情報処理装置及びソフトウェアの適切な変 (1)変更手順に含まれる事項には次のようなも更手順を策定すること。保守作業についてのが考えられる。
は十分な余裕を持って事前に医療機関等に・変更についての影響が及ぶ関係者への通知プ
通知し承認を受けること。
ロセス・装置の変更申請書のフォーマット（申請者情報、承認者情報、対象機器情報、変更作業開始日時、変更作業期間、変更理由、機器に納められている情報の概要、変更に伴うリスク評価の結果、機器が損傷した場合の対応策、
等）
・申請承認プロセス・変更試験プロセス・変更作業に支障が発生した場合の復旧手順
・変更終了確認プロセス
・変更に伴う影響を監視するプロセス、等(6)不正な改ざんを受けていないことを検証す 項目なし
るため、定期的にソフトウェアの整合性検査（改ざん検知）を実施すること。
(7)医療情報システムに関連する技術的脆弱性 項目なし
については台帳等を利用して管理すること。
(8)潜在的な技術的脆弱性が特定された場合に 項目なし
は、リスク分析を行った上で必要な処置（パッチ適用、設定変更等）を決定すること。
(9)修正パッチの適用前にパッチが改ざんされ 項目なしていないこと及び有効性を検証すること。

(a) 技術的対策
追記事項なし(b) 運用的対策（ア） リリースに関する情報を適宜提供すること（イ） 変更履歴を管理すること（ウ） リリース時にリリースに伴う障害が発生したときの復旧手順を提供すること© JAHIS 201382

8.2.3. 悪意のあるコードに対する管理策＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)最新の脅威についての情報収集に努め、導入 項目なし
している悪意のあるコード対策ソフトウェ
アの対応範囲を確認し、対策漏れが無いことを確認すること。対応すべき脅威の例としては、コンピュータウイルス（ワーム）、
バックドア（トロイの木馬）、スパイウェ
ア（キーロガー）、ボットプログラム（ダウンローダー）等がある。
(2)悪意のあるコード対策ソフトウェアにおい 項目なして次の設定が行われていること。
・リアルタイムスキャン（ディスク書き出し・読み込み、ネットワーク通信）
・リスク評価の結果として必要であれば定期的にスキャンを実施
・電子媒体へのデータ書き出し・読み込み時におけるオンデマンドスキャン
・定義ファイル、スキャンエンジンの自動アップデート又は十分な頻度による手動での更新・管理者以外による設定変更やアンインストー
ルの禁止(3)一定期間、悪意のあるコードのチェックが行
われていない場合や定義ファイル、スキャ
ンエンジンが更新されていない機器については、利用者への警告を表示する、管理者への通知を行う、施設内ネットワーク接続の禁止または隔離措置をとるといった対策が行われていること。

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし© JAHIS 2013

83

項目なし

8.2.4. 情報交換に関するセキュリティ＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)次の情報交換方法について予め合意してお 項目なし
くこと。
・ 情報を電子媒体に記録して交換する際の手順・情報をネットワーク経由で文書ファイル形式にて交換する際の手順
・情報をネットワーク経由でアプリケーション
入力にて交換する際の手順
・情報に電子署名、タイムスタンプを付与する
場合、その方式及び検証手順(2)情報交換手順では搬送の形態によらず次の 項目なし
事項を確実にすること。
・発送者、受領者を識別し記録すること。
・発送者の行為を後に否定できないように、発送伝票の保存、文書ファイルへの電子署名、
アプリケーションログオン時の確実な認証を行うこと。
・交換する情報の機密レベルに関して合意すること（受領側で機密レベルが低くならないこと）。
・交換された情報に悪意のあるコードが含まれていないことを確実とすること。
(4)電子的に情報を転送する際には以下の対策を実施すること。

項目なし

・送信者、受信者は相互に電子的に認証を行って相手の正当性を検証すること。認証方式は接続形態、転送に利用するアプリケーション
によって異なるが、利用する機器同士及び利用者同士を認証することが望ましい。

(a)技術的対策
ベンダーは以下の４つの手順をユーザに提供すること。
・情報を電子媒体に記録して交換する際の手順
・情報をネットワーク経由で文書ファイル形式にて交換する際の手順
・情報をネットワーク経由でアプリケーション入力にて交換する際の手順
・情報に電子署名、タイムスタンプを付与する場合、その方式及び検証手順(b)運用的対策© JAHIS 201384

追記事項なし

8.2.5. 情報処理システムに対するセキュリティ要求事項＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(3)業務に供するソフトウェア及びオペレーテ 項目なし
ィングシステムソフトウェアについて、十分な試験を行った上で導入すること。
(4)運用システムに関わるライブラリプログラ 項目なし
ムの更新については監査に必要なログを取得すること。
(5)システム運用情報（システム及びサービス設 項目なし
定ファイル等）の複製及び利用については監査証跡とするためにログを取得すること。

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし8.2.6. アプリケーションに対するセキュリティ要求事項＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)提供するアプリケーションについては、アプ (1)アプリケーションの安全性診断は提供しているサービスに対して直接実施するのではリケーションの種別による特定の脆弱性検なく、別途、試験環境を用意して行うこと
出を含む安全性診断を定期的に行い、そのが望ましい。
結果に基づいて対策を行うこと。医療機関
等とのデータ送受信の際にはデータの完全性を検証する機構を導入すること。
(2)アプリケーション及びアプリケーション稼動に利用する第三者のソフトウェア（ライブラリ、サーバプロセス等）については、公開される最新の脆弱性情報を参照し、迅速に対応策をとること。

項目なし(3)アプリケーションにて情報の登録、編集、削 項目なし
除等を行う際には、ユーザを特定し、権限を確認するため、ログオンを行うよう設計
及び実装を行うこと。

© JAHIS 201385

最低限のガイドライン

推奨されるガイドライン(4)アプリケーションにて医療事業者側の作業 項目なし
者を認証する情報（ID／パスワード認証の際のパスワード）は、十分な強度を持ったハッシュ関数の出力値として保存する、あるいは暗号化して保存すること。
(5)アプリケーションによる情報操作について 項目なし
は、医療機関等の職務権限に応じたアクセ
ス管理を可能とし、正当なアクセス権限を持たないものによる情報の生成、編集、削除等を防止すること。

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし8.2.7. 暗号による管理策＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)暗号アルゴリズムは十分な安全性を有する 項目なし
ものを使用すること。選択基準としては電子政府推奨暗号リスト等を用いること。
(3)電子署名、ネットワーク接続等に電子証明書 項目なし
を利用する場合、電子証明書は信頼できる組織によって発行されたものとすること。
(4)暗号アルゴリズム及び暗号鍵の危殆化に備 項目なし
え、暗号アルゴリズムを切り替えることができるように配慮すること。

(a) 技術的対策（ア）

暗号に関しては、６．７節を参照のこと。

（イ）

電子署名に関しては、６．８節を参照のこと。

(b) 運用的対策
追記事項なし8.2.8. ログの取得及び監査＜医療情報受託管理ガイドラインの要求事項＞© JAHIS 201386

最低限のガイドライン

推奨されるガイドライン(1)作業者の活動、機器で発生したイベント、シ (2)監査ログに記録する事項としては次のよう
ステム障害、システム使用状況等を記録しなものが考えられる。
た監査ログを作成し、管理すること。
・作業者情報（作業者 ID、ログオンの可否、利用時刻及び時間、実行作業内容、ネットワ
ークアクセスの場合はアクセス元 IP アドレス）・ファイル及びデータへのアクセス、変更、削除記録（作業者 ID、アクセスの可否、利用時
刻及び時間、作業内容、対象ファイル又はデータ種類）
・データベース操作記録（作業者 ID、接続及び作業の可否、利用時刻及び時間、実施作業
内容、アクセス元 IP アドレス、設定変更時にはその内容）・修正パッチの適用作業（作業者 ID、変更されたファイル）・特権操作（特権取得者 ID、特権取得の可否、利用時刻及び時間、実行作業内容）
・システム起動、停止イベント
・ログ取得機能の開始、終了イベント
・外部デバイスの取り外し
・IDS・IPS 等のセキュリティ装置のイベント
ログ・サービス及びアプリケーションの動作により生成されたログ（時刻同期に関するログを含
む）(3)ログを利用して正確に事故原因等を検証するため、医療情報システムのすべてのサー
バ機器等の時刻を時刻サーバ等の提供する標準時刻に同期しておくこと。

ログを集中させ問題の検出を一箇所で確実に行うことを目的として、システムとして可能な場合は専用のログサーバにログデータを集約して分析管理することが望ましい。

(5)ログ情報を不正なアクセスから適切に保護 項目なし
するため以下の管理策を適用すること。
・ログデータにアクセスする作業者及び操作を制限すること。
・容量超過によりログが取得できない事態を避けるため、ログサーバの記憶容量を常時監視し、電子媒体への書き出し、容量の増強等の対策をとること。
・ ログデータに対する不正な改ざん及び削除行為に対する検出・防止策を施すこと。

© JAHIS 201387

最低限のガイドライン

推奨されるガイドライン(1)*監査ログを検証するため、作業者がアクセスした医療情報等を迅速に確認できるよう、作業者 ID と、情報の識別子（資産台
帳記載の番号等）、生成時系列、アクセス
時系列等、多様な指標での並び替え、情報の種別、アクセス時間等での絞り込み等が行うことができるようなシステムを整備することが望ましい。

項目なし*:医療情報受託管理ガイドライン P70 の(1)を指す(a) 技術的対策(ア) アクセス記録、より厳密には監査証跡（Audit Trail）の記録は、「個人情報へのアクセスの履歴の確認」、「医療機関が説明責任を果たすために利用」、「副次的効果としての目的外アクセスの抑止」などを目的としている。これらの目的を満たすように実装すること。なお、監査証跡の標準規約としては「ヘルスケア分野における監査証跡のメッセージ標準規約 Ver.1.1」（JAHIS 標準文書 09-003）を参照のこと。また、MEDIS-DC から出されている、医療における監査証跡について平易にかつ具体的に解説している「個人情報保護に役立つ監査証跡ガイド」(http://www.medical-it-link.jp/temporary/temp_1_445.pdf)も参考のこと。
(イ) アクセスログへのアクセス制御を行う仕組みを実装すること。
(ウ) アクセスログを制御できる管理者のアクセス記録を取得すること。
(エ) アクセスログの改ざんや故意による削除などを防止するため、日または時間単位でのアクセスログに対するタイムスタンプを行うことが望ましい。

(b) 運用的対策
追記事項なし8.2.9. アクセス制御方針＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(4)それぞれの情報にアクセスする権限を持つ 項目なし
作業者を最小限に抑えるよう、適切に情報のグルーピングを行い、情報のグループに対するアクセス制御を行うこと。
(5)業務内容を考慮した必要最小限のアクセス 項目なし
権限を設け、アプリケーションやオペレー
ションシステムでの権限を設定すること。
(1)作業者に与えられた権限外の情報や権限外の操作画面を表示しないよう権限管理を行うことが望ましい。

項目なし© JAHIS 201388

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし8.2.10.

作業者アクセス及び作業者 ID の管理

作業者 ID について実施すべき安全管理策＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(2)作業者 ID を発行する際に、既存の ID との重複を排除する仕組みを導入すること。

項目なし(3)複数作業者で共用するためのグループ IDの利用は原則として行わず、業務上必要であれば、ログ上で操作の実施者が特定できるように、作業者 ID でログオンしてからグループ ID に変更する仕組みを利用する
こと。

項目なし

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし特権 ID について実施すべき安全管理策＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(2)特権使用者に昇格可能な作業者 ID を制限
すること。

項目なし

(3)特権の使用時には作業実施内容を記録する
こと。

項目なし

(4)管理端末以外からの特権 ID による直接ログインを禁止すること。

項目なし(2)システムの機能として可能であれば、特権
ID で使用可能なコマンド及びユーティリ
ティについて業務上必要な最低限の範囲に制限し、重要なコマンド、ユーティリティ
及びログについて改ざん、削除など不正な行為を防止することが望ましい。

項目なし© JAHIS 201389

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なしパスワード管理について実施すべき安全管理策＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(2)医療情報システムログオン用のパスワード 項目なし
はハッシュ値での保存、暗号化等、パスワ
ードを容易に復元できない形で情報を保管すること。
(3)医療情報システムログオン用のパスワード 項目なしには有効期限の設定を行い、定期的な変更を作業者に強制すること。
(4)医療情報システムログオン用のパスワード 項目なしの履歴管理を導入し、変更時には一定数世
代のパスワードと同じパスワードを再設定することができないようにすること。
(5)パスワード変更時には変更前のパスワード 項目なしの入力を要求し、変更前のパスワード入力
を一定回数以上失敗した場合には、パスワ
ード変更を一定期間受けつけない機構とすること。
(6)パスワード発行時には、乱数から生成した仮 項目なしの医療情報システムログオン用のパスワードを発行し、最初のログオン時点で強制的に変更させる等パスワード盗難リスクに対する対策を実施すること。
(9)パスワードに関連するデータを保存するフ 項目なし
ァイルの真正性及び完全性を保つために、ファイルのハッシュ値の取得及び検証、ファイルに対するデジタル署名の付与及び検証、ファイルを暗号化して保存する等の保護策を採用すること。また、一般の作業者
による閲覧を制限すること。
(1)作業者が医療情報システムログオン用のパスワードを登録及び変更する際には、予め定めた品質を満たしていることを保証する
仕組み、乱数によりパスワードを生成するプログラム等の導入、作業者が設定しよう

項目なし© JAHIS 201390

最低限のガイドライン

推奨されるガイドラインとする品質の低いパスワードを認めないシ
ステムの導入等を検討することが望ましい。

(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし作業者のログオンについて実施すべき安全管理策＜医療情報受託管理ガイドラインの要求事項＞
最低限のガイドライン

推奨されるガイドライン(1)端末又はセッションの乗っ取りのリスクを 項目なし
低減するため、作業者のログオン後に一定の使用中断時間が経過したセッションを遮断、あるいは強制ログオフを行うこと。
(2)パスワード入力が不成功に終わった場合の 項目なし
再入力に対して一定の不応時間を設定すること。連続してログオンが失敗した場合は再入力を一定期間受付けない機構とすること。この場合には、警告メッセージをシス
テムの管理者に送出する仕組みを導入する
こと。
項目なし

(1)不正なアカウントの利用又は試みが行われたことを作業者自身で検出するため、作業者のログオン後に前回のログオンが成功していれば成功日時を表示し、前回のログオンが失敗していれば、第三者による不正なログオンの試みが行われた可能性があるという内容の警告メッセージとともに失敗日時を表示することが望ましい。

項目なし(2)不正なアカウントの利用を防ぐため、作業者のログオンを許可する曜日、時間帯は作業に必要な曜日、時間帯に制限することが望
ましい。

項目なし

(3)認可されていない作業者あるいは第三者がログオンを試みた際に「パスワードが異なります」と表示すると作業者 ID が存在していることを知る手がかりとなるため、「認証に失敗しました」、あるいは単にログオ
ンプロンプトを再表示するといった特段の© JAHIS 201391

最低限のガイドライン

推奨されるガイドライン
情報を与えないようなメッセージのみの表
現に留めることが望ましい。
(5)ログオン時に利用する認証要素としては、ハードウェアトークン又は IC カード等の認証デバイス、暗証番号（PIN）、パスワー
ド等の記憶要素、生体情報（バイオメトリクス）等を組み合わせることが望ましい。

項目なし(a) 技術的対策
追記事項なし(b) 運用的対策
追記事項なし© JAHIS 201392

8.3. 総務省の ASP・SaaS 事業者が医療情報を取り扱う際の安全管理に関するガイドラインに関する事項
本節では総務省の「ASP・SaaS 事業者が医療情報を取り扱う際の安全管理に関するガイドライン」においてシステムベンダーが電子媒体による外部保存をネットワークを通じて行う ASP・SaaS 事業者へシステムを提供する際に求められる技術的要求事項を対象に解説を行う。

8.3.1.

真正性の確保における ASP・SaaS 事業者への要求事項＜ASP・SaaS 医療情報ガイドライン 表 3-12＞
医療機関等以外に保存する際の要求事項（１）通信の相手先が正当であることを認識するための相互認証をおこなうこと最低限のガイドライン

推奨されるガイドライン①利用者及び管理者（情報システム管理者、ネットワーク管理者等）等のアクセスを管理するための適切な認証方法、特定の場所及び装置からの接続を認証する方法等により、アクセス制御となりすまし対策を行うこと。また、運用管理規程を作成すること。ID・パス
ワードを用いる場合は、その運用管理方法と、パスワードの有効期限を規定に含めること。（厚生労働省ｶﾞｲﾄﾞﾗｲﾝ 7.1c）

項目なし（注）項番は原文にはないが、順番に項番を付している。

(a)技術的対策（ア）アクセス制御機能及びなりすまし対策機能として利用者及び管理者（情報システム管理者、ネット
ワーク管理者等）等のアクセスを管理するための認証機能、特定の場所及び装置からの接続を認証機能等を提供すること。
(b)運用的対策
追記事項なし8.3.2. 外部保存における ASP・SaaS 事業者への要求事項＜ASP・SaaS 医療情報ガイドライン 表 3-15＞
最低限のガイドライン

推奨されるガイドライン

項目なし© JAHIS 2013

③利用者及び管理者（情報システム管理者、ネットワーク管理者等）
等のアクセスを管理するための適切な認証方法、
特定の場所及び装置からの接続を認証する方法等により、
アクセス制御となりすまし対策を行うこと。ま93最低限のガイドライン

推奨されるガイドライン
た、運用管理規程を作成すること。ID・パスワードを用いる場合は、その運用管理方法と、
パスワードの有効期限を規定に含めること。（厚生労働省ｶﾞｲﾄﾞﾗｲﾝ 8.1.2d(ｳ)）② 同上（厚生労働省ｶﾞｲﾄﾞﾗｲﾝ 8.1.2d(ｴ)）（注）項番は原文にはないが、順番に項番を付している。

(a)技術的対策（ア）アクセス制御機能及びなりすまし対策機能として利用者及び管理者（情報システム管理者、ネット
ワーク管理者等）等のアクセスを管理するための認証機能、特定の場所及び装置からの接続を認証する機能等を提供すること。
(b)運用的対策
追記事項なし8.3.3. ASP・SaaS の提供終了における ASP・SaaS 事業者への要求事項＜ASP・SaaS 医療情報ガイドライン 表 3-17＞
ガイドライン②利用者の利用状況、例外処理及び情報セキュリティ事象の記録（ログ等）を取得し、記録（ログ等）の保存期間を明示すること。（厚生労働省ｶﾞｲﾄﾞﾗｲﾝ 8.4.2）（注）項番は原文にはないが、順番に項番を付している。

(a)技術的対策（ア）利用者の利用状況、例外処理及び情報セキュリティ事象の記録（ログ等）機能を提供すること。
(b)運用的対策
追記事項なし© JAHIS 201394

9. 診療録等をスキャナ等により電子化して保存する場合について
9.1. 共通の要件(1)

スキャンによる情報量の低下、情報の欠落防止の手段＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
1. 医療に関する業務等に支障が生じることのないよう、スキャンによる情報量の低下を防ぎ、保存義務を満たす情報として必要な情報量を確保するため、光学解像度、センサ等の一定の規格・基準を満たすスキャナを用いること。またスキャン等を行う前に対象書類に他の書類が重なって貼り付けられていたり、スキャナ等が電子化可能な範囲外に情報が存在したりすることで、スキャンによる電子化で情報が欠落することがないことを確認すること。
・ 診療情報提供書等の紙媒体の場合、診療等の用途に差し支えない精度でスキャンを行うこと。
・ 放射線フィルム等の高精細な情報に関しては日本医学放射線学会電子情報委
員会が「デジタル画像の取り扱いに関するガイドライン 2.0 版（平成 18 年 4月）」を公表しており、参考にされたい。なお、このガイドラインではマン
モグラフィーは対象とされていないが、同委員会で検討される予定である。
・ このほか心電図等の波形情報やポラロ
イド撮影した情報等、さまざまな対象が考えられる。医療に関する業務等に差し支えない精度が必要であり、その点に十分配慮すること。
・ 一般の書類をスキャンした画像情報は汎用性が高く可視化するソフトウェアに困らない形式で保存すること。また
非可逆的な圧縮は画像の精度を低下させるために、非可逆圧縮を行う場合は医療に関する業務等に支障がない精度であること、及びスキャンの対象とな© JAHIS 201395

推奨されるガイドライン
項目なし

った紙等の破損や汚れ等の状況も判定可能な範囲であることを念頭に行う必要がある。放射線フィルム等の医用画像をスキャンした情報は DICOM 等の適切な形式で保存すること。
技術的対策

(a)
(ア)

スキャンによる情報量の低下を防止するため、スキャンの精度は（放射線フィルム等の特に高精細な画像が求められるもの以外）、医療に関する業務等に差し支えない程度とする。
(イ)
放射線フィルム等の特に高精細な画像が求められるものについては、日本医学放射線学会の「デジタル画像の取り扱いに関するガイドライン 2.0 版」に記載されている以下の精度でスキャンを行うこと。
① サンプリングピッチ：200μm 以下② 空間分解能：CTF(0.25)≧0.9、CTF(0.5)≧0.8、CTF(1.0)≧0.7
ここで CFT(n)は、n lp/㎜の Contrast Transfer Function を示す。
③ 濃度階調数：1024 以上（10 ビットグレイスケール以上）④ デジタイズ濃度範囲：0.0D－3.0D 以上
(ウ)

(エ)

(b)

スキャンした画像を非可逆圧縮する際は、画像再現時の画質劣化を医療の業務等に支障がない精度にすること。放射線フィルム等については日本医学放射線学会の「デジタル画像の取り扱
いに関するガイドライン 2.0 版」で、JPEG 非可逆圧縮の圧縮率 1/10 までは非圧縮画像と臨床上同等としている。
スキャンした画像は 5 年以上の長期に渡って保存する事が想定されるので、保存の形式は公開され広く活用されているフォーマットを選択することが必要であり、可視化するソフトウェアに困らないものとする。
運用的対策

追記事項なし。

(2)

改ざんの防止（スキャンされた画像の真正性担保の手段）＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
2. 改ざんを防止するため、医療機関等の管理責任者は以下の措置を講じること・ スキャナによる読み取りに係る運用管理規程を定めること・ スキャナにより読み取った電子情報ともとの文書等から得られる情報との同一性を担保する情報作成管理者を配置すること© JAHIS 201396

推奨されるガイドライン
項目なし

・ スキャナで読み取った際は、作業責任者(実施者または管理者)が電子署名法に適合した電子署名・タイムスタンプ
等を遅滞なく行い、責任を明確にすること。なお、電子署名については「6.12
法令で定められた記名・押印を電子署名で行うことについて」を参照するこ
と。
技術的対策

(a)

スキャンされた画像を長期に渡って保存するにあたり、スキャニング作業の責任の所在の明確化や、デー
タの改ざん防止や原本性確保を行うため、以下の機能を有する必要がある。
(ア)
真正性検証機能
スキャン作業の責任の明確化や、スキャン画像の改ざんを防止、改ざんの有無の検証のため署名作成機能を持つこと。
また、検証する機能を持つこと。
(イ)

作成時期検証機能
スキャンされた画像の作成日時を担保するため、電子署名済みのスキャン画像に対して「財団法人
日本データ通信協会」が認定するタイムスタンプを付与する機能を持つこと。
また、必要に応じて第三者が上記タイムスタンプを検証できる機能を持つこと。

なお、スキャン画像に対する、電子署名、タイムスタンプの付与やその検証に関しての詳細は「6.12. 法
令で定められた記名・押印を電子署名で行うことについて」を参照されたい。
運用的対策

(b)
(ア)

(3)

診療録記載（あるいは患者からの入手）からスキャンの実施、スキャン対象文書の保存（あるいは破棄）までの一連の運用について、スキャナによる読みとり作業が適正な手続きで確実に実施されるよう、運用管理規程を定め、情報作成管理者を配置すること。

スキャナによる読み取りに係る運用管理規程の遵守＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
3. 情報作成管理者は、上記運用管理規程に基づき、スキャナによる読み取り作業が、適正な手続で確実に実施される措置を講じること。
(a)

推奨されるガイドライン
項目なし

技術的対策

追記事項なし。
(b)
(ア)

運用的対策
スキャナによる読取作業については、読み込み書類の準備、作業単位に合わせたバッチ化、ス© JAHIS 201397

キャンし易くするための複写、スキャニングプロセスの詳細手順化、品質管理、スキャナ性能
検査、再スキャニングやイメージ処理などに関しては必要に応じてISO国際標準 2、JISや日本
画像情報マネジメント協会JIIMAのガイドライン 3などを参考にすると良い。

2 ISOTR15801「エレクトロニックイメージングー電子的に保存された情報―信頼度および信頼性の推奨事項」
3 JISZ6016「紙文書及びマイクロフイルム文書の電子化プロセス」

日本画像情報マネジメント協会（JIIMA)作成の「国税関係書類の電子化文書取扱ガイドライン案」(www.jiima.or.jp/pdf/050517zeipdf)© JAHIS 201398

9.2. 診療等の都度スキャナ等で電子化して保存する場合＜安全管理ガイドラインの要求事項＞
最低限のガイドライン
9.1 の対策に加えて、改ざんを防止するた
め情報が作成されてから、または情報を入手してから一定期間以内にスキャンを行うこと。

推奨されるガイドライン
項目なし

・ 一定期間とは改ざんの動機が生じないと考えられる 1～2 日程度以内の運用管理規定で定めた期間で、遅滞なくス
キャンを行わなければならない。時間外診療等で機器の使用ができない等の止むを得ない事情がある場合は、スキャンが可能になった時点で遅滞なく行うこととする。

(1)

改ざん防止のための情報作成後の迅速なスキャン

(a)

技術的対策

(ア) スキャンの対象となる診療録の日々の発生枚数を見積もり、日常の業務でスキャンが延滞無く行われるよう、スキャナ装置の読みとり速度やスキャナの設置台数などをシステム導入時に検討しておくこと。
(イ)
スキャナ装置のハードウェアトラブルに際しても延滞無くスキャンが行えるよう、予備機を用意しておくこと。
(b)
(ア)

運用的対策
診療録等の書類作成からスキャンまで遅滞なく完了するように運用を検討すること。ここでの「遅滞なく」とは 1 日を目処とする。

© JAHIS 201399

付録―１．リスクアセスメントの実施例
本付録の目的情報システムに実装されるべきセキュリティ機能と、その運用において実施されるべき管理策の選択は、
基本的にはリスクアセスメントを実施した結果から導出されるべきものである。これらがリスクアセスメン
トの結果に基づいていないと、セキュリティ対策に漏れ（セキュリティ・ホール）が発生したり、逆に過剰なセキュリティ対策によって運用上の可用性を損ねたり、対策費用が必要以上にかかったりする弊害が懸念される。
完全なリスクアセスメントを実施するためには、当該の情報システムの構成や機能、それを運用する組織の体制などがすべて正確に把握できている必要があるが、一度実施しておけば、運用の開始後に情報システ
ムの変更が行われたとしても、その変更部分についてのみリスクアセスメントを実施することで整合性を保つことができる。
採用するリスクアセスメントの手法と手順は、情報モデルに依存しないので、予め組織でこれを制定することが望ましい。これらを予め定めておくことにより、対象システムのリスクアセスメントを効果的、かつ効率的に行えるようになることが期待できる。
１－１ リスクアセスメントの手法
本付録で行うリスクアセスメントの手法は、「財団法人 日本情報処理開発協会（JIPDEC）」が発行している「ISMS ユーザーズガイド-JIS Q
27001:2006(ISO/IEC 27001:2005)対応--リスクマネジメント編-」（http://www.isms.jipdec.jp/doc/JIP-ISMS113-21.pdf）に記載された手法を参考とした。
１－２ 情報セキュリティ基本方針
リスクアセスメントを行う際には、評価の拠り所として当該組織の情報セキュリティ基本方針が重要となる。これらは組織が独自に決める必要がある。ここでは、どのような医療機関でも共通に有するような基本
方針、たとえば、「患者の個人情報とプライバシーの保護を重視する」や、「預託・管理している患者の診療情報の保護を重視する」といったところを念頭に置いて考察した。
これらの基本方針は、識別されたリスクを評価する際に重要になる。
１－３ リスクアセスメントの実施例
上記の前提条件に従って、本付録では、表 A．１のような訪問介護系の業務シナリオを例として、リスク
アセスメントを部分的に実施してみた例を示す。なお、この実施例は「平成 21 年度地域見守り支援システ
ム実証事業」の運用ガイドライン（暫定版）（http://www.nss-med.co.jp/mimamori/seika.html）の中で記述したものを引用ならびに改訂している。
(ア) 対象とする情報資産の抽出
下記のような業務シナリオのユースケースを想定する。
項目
1-1
連
携
調 1-2
整

表A．１ 訪問介護系業務シナリオのユースケース
イベント
アクター
シナリオ
提 供 記 録 本人、家族
訪問看護ステーションの看護師は、
訪問介護系情報システム
確認
看護師
を使って、
前日に訪問したホームヘルパーのサービス提供記
ケアマネ
録を確認している。
状態確認
本人、家族
Ａさんが「最近は、あまり体調が良くない。食欲がない」と看護師訴えていることを確認し、かりつけ医と相談してＡさんの病かかりつけ医気の状態を確認することにした。

© JAHIS 2013100

サービス提供

2-1

状況

2-2

報告・指示 本人、家族
依頼
看護師
かかりつけ医

2-3

指示受け

2-4

結果記録

3-1
課
題
対 3-2
応

本人、家族
看護師
かかりつけ医

本人、家族
看護師
かかりつけ医
専門医
専 門 医 に 本人、家族報告
かかりつけ医
専門医
精密検査
本人、家族
かかりつけ医
専門医

看護師がバイタルデータを測定したところ、血圧と血糖値が低下していることがわかった。Ａさんに、空腹感や身体のだるさがないかと確認したところ、「ある」との答えだったた
め、低血糖の症状が疑われた。
そのため、看護師が、携帯電話を使って、かかりつけ医にＡさんの症状とバイタルデータを伝え、指示を仰いだ。
かかりつけ医から「処方されているブドウ糖を飲ませるように。無ければ、砂糖水でも構わない」との指示があったために、Ａさんにブドウ糖の場所を聞き、飲めるように準備し、病状の変化を見守ることにした。
訪問看護師は、Ａさんのバイタルデータと症状、かかりつけ医からの指示などを看護記録に残し、
訪問介護系情報システ
ムを使って、かかりつけ医と中核病院の担当医からアクセスできるようにした。
後日、かかりつけ医が訪問診療し、テレビ電話を使って中核
病院の専門医にバイタルデータと現在の病状を報告。
念のために、中核病院で精密検査することになった。

まず、この業務シナリオの表現から「情報資産」を登場する順に抽出する。業務モデルの解釈により多少の揺らぎは想定されるが、ここでは下記のように抽出した。
資産番号
A1
A2
A3
A4
A5
A6
A7
A8

表A．２ 資産のリストアップ
情報資産名
種別
所在
訪問介護系情報システム
システム
データセンター
サービス提供記録
電子情報
訪問介護系情報システム
バイタルデータ測定機器
情報機器
訪問看護師が所持
バイタルデータ
電子情報
訪問介護系情報システム
携帯電話
情報機器
訪問看護師が所持
看護記録（紙）紙情報
訪問看護師が所持
看護記録（電子）電子情報
訪問介護系情報システム
テレビ電話
情報機器
患者の自宅

リスクアセスメントは、すべての情報資産について個別に行うことが理想であるが、情報システムの規模が大きくなるにつれて、情報資産の数は飛躍的に増大するため、非常に多大な作業となってしまう。これを省力化するために、グループ分けという概念を導入する。情報の種別（形態）や重要度、管理場所等によって分類し、同じグループに属する情報資産には、同じリスクが存在すると考えるのである。
ここではサンプル的に上記を「種別」と「所在」という観点でグループ分けすると、下記のようになる。
Gr 番号
G1
G2

種別
システム
電子情報

© JAHIS 2013

表A．３ グループ分けの例
所在
該当する情報資産
データセンターA1
訪問介護系情報システム
A2 A4 A7
101

G3
G4
G5

情報機器
紙情報
情報機器

訪問看護師が所持
訪問看護師が所持
患者の自宅

A3 A5
A6
A8

実際のグループ分けは、上記の観点だけでは粗すぎる可能性があり、もっと細かな観点（たとえば、個人情報を含むかどうか、現状施されている管理策の詳細な相違など）を加える必要があるかもしれないが、考え方としては同じである。
ここでのリスクアセスメントは、これらグループごとに実施した。

(イ) 想定される脅威
上記で抽出したそれぞれの情報資産（のグループ）に対し、想定される脅威を考える。情報セキュリティ
でのリスクの観点は、機密性（C）、完全性（I）、可用性（A）の３つである。地域見守り支援のビジネスとしては、患者の安全性、システム運用の経済性等、より広い観点でのリスクも考えられるが、ここではこれ
らは対象としない。
ここで留意すべきことは、脅威の抽出の際に評価をしないということである。すなわち、その脅威の発現の頻度が低いからと言って、最初から除外しないということである。
これはリスク分析を実施した担当者と、組織の経営陣のリスクに対する評価が異なる可能性があるからである。抽出の際に実施者によるフィルタリ
ングがかかっていると、リスク分析が正確に行われない可能性がある。したがって、このようなフィルタリ
ングの作業は後の「リスク評価」のところで行う。
脅威は、その情報資産の固有の管理状況に大きく依存するため、ここでは通常考えられる代表的なもののうち、ごく一部の抽出に留めた。実際に脅威を抽出する際には、それぞれの組織の実態に合わせて行う必要がある。
表A．４ 脅威のリストアップ
脅威番号
観点
脅威の内容
T1-I1
I
非作為的な事故により DB が壊れる
T1-A1
A
通信回線の定期保守により利用できない
T1-A2
A
利用者による負荷が集中しシステムの応答が遅くなる
G2
T2-C1
C
何者かに不正に閲覧される
T2-I1
I
何者かによって内容が削除または改ざんされる
T2-I2
I
利用者が操作を誤ってデータを消してしまう
T2-A1
A
システムの定期保守によりアクセスできなくなる
G3
T3-C1
C
何者かに不正に操作される
T3-I1
I
何らかの理由により正確な測定が行えない
T3-A1
A
機器の扱い方がわからない
T3-A2
A
紛失する
G4
T4-C1
C
何者かに不正に閲覧される
T4-I1
I
物理的に破損して読めなくなる
T4-A1
A
紛失する
G5
T5-I1
I
何らかの理由により通信ができない
T5-A1
A
機器の扱い方がわからない
ここでは「何らかの理由により」とか「何者かによって」という表現を使った部分があるが、これをより具体的な表現とすることで、リスク分析の精度はより向上する。
Gr 番号
G1

© JAHIS 2013102

(ウ) ぜい弱性
次に、上記で抽出した、想定される脅威に関して、現在の管理策（想定）を踏まえたぜい弱性の一部を、
下記のようにサンプル的に抽出した。
脅威
番号
T1-I1

表A．５ 脅威に対するぜい弱性のリストアップ
ぜい弱性

T1-A1

ぜい弱
性番号
F1-I1-1
F1-I1-2
F1-A1-1

T1-A2
T2-C1

F1-A2-1
F2-C1-1

DB を保存する記憶媒体が通常運用で壊れうる火災により焼失する
通信回線が使えないとシステムにアクセスできな
い
サーバの処理能力に限界がある
ぜい弱なパスワードを使用している

T2-I1

F2-I1-1

共有アカウントが利用されている

T2-I2
T2-A1

F2-I2-1
F2-A1-1

誤操作に対する警告機能がないシステムを定期的に停止しなければならない

T3-C1
T3-I1
T3-A1
T3-A2
T4-C1
T4-I1
T4-A1
T5-I1

F3-C1-1
F3-I1-1
F3-A1-1
F3-A2-1
F4-C1-1
F4-I1-1
F4-A1-1
F5-I1-1

パスワードを設定できない
定期的な補正が必要
使い方が複雑小型軽量なので簡単に持ち運びができる
通常の書架に保管しているため誰でも閲覧できる
原本しかない通常のバッグに入れて持ち歩いている
通信回線の定期メンテナンスがある

T5-A1

F5-A1-1

お年寄りが使っている

現在の管理策１日１回のバックアップ
サーバ室の消火設備
計画保守スケジュールを利用
者に周知
特になし
特になし（パスワードの設定ポ
リシーを定めず、ユーザに委ねている）
特になし（共有アカウントに関する規制がない）
特になし
計画保守スケジュールを利用
者に周知
特になし
特になし
操作マニュアルを配布
特になし
特になし
特になし
特になし
計画保守スケジュールを利用者に周知
操作マニュアルを配布(エ) リスク値の計算
上記で情報資産およびそれぞれに関する脅威とぜい弱性が抽出できたので、次はこれらを定量的に評価することで、リスクの大きさ（実際に脅威が発顕する可能性）を計算する。
ここでは JIPDEC の「ISMS ユーザーズガイド-JIS Q 27001:2006(ISO/IEC 27001:2005)対応--リスクマ
ネジメント編-」での例示を基に評価を行う。基本的には結果のみを示すので、そこに至った考え方などの詳細については、同書を参考して自組織の現状に合わせる必要がある。
① 情報資産の価値
上記にリストアップした情報資産について、その価値を算定する場合には、資産の価値を評価するよりも、資産の機密性（A）、完全性（I）、可用性（A）が損なわれた場合の事業上の影響（損害）を評価するとした方が考えやすい。
この考えに沿って、JIPDEC のガイドでは、下記のような例が示されている。自組織に合ったものを選択してそのまま使ってもよいし、適宜修正して使ってもよい。

© JAHIS 2013

103

資産価値
1
2
3
4

クラス
公開
社外秘
秘密
極秘

資産価値
1
2

影響度
非常に
小さい
小さい

3

中程度

4

大きい

5

非常に
大きい

表A．６ 機密性の評価基準例
説明
内容が漏えいした場合でも、ビジネスへの影響はほとんどない
内容が漏えいした場合、ビジネスへの影響は少ない
内容が漏えいした場合、ビジネスへの影響は大きい
内容が漏えいした場合、ビジネスへの影響は深刻かつ重大である
表A．７ 影響度の評価基準例
金銭・機会損失（短期） 金銭・機会損失（中長期）
当期経営にはほとんど 中長期的な経営には影響
影響はない
はない
当期経営に軽微な影響 中長期的な影響はない（追う気利益の 1%以下）を及ぼす当期経営に影響（当期利 中長期的な経営にはほと益の 3%以下）を及ぼす んど影響はない
当期経営に重大な影響 2 年程度の経営に影響が及（当期利益の 10%未 ぶ満）を及ぼす当期経営に極めて重大 3 年以上の経営に影響が及な 影 響 （ 当期 利 益 の ぶ
10%以上）を及ぼす

信用・ブランド損失
ほとんど影響はない
弦された人に対して悪い風評が及ぶ
多くの人に対して悪い風評が及ぶ
限定された人に長期的に悪いイメージが残る
多くの人に対し長期
的に悪いイメージが残る② 脅威の評価
脅威の評価に関しては、単純な発生頻度によるもの、脅威の発生用によるものが示されている。自組織に合ったものを選択してそのまま使ってもよいし、適宜修正して使ってもよい。

レベル

表A．８ 脅威の分類基準例（１）脅威
説明
発生する可能性は低い。発生頻度は 1 年に 1 回あるかないかである。
発生する可能性は中程度である。発生頻度は半年以内に１回あるかないかである。
発生する可能性は高い。発生頻度は１ヶ月に１回以上である。

1
2

区分
低い
中程度

3

高い

1

表A．９ 脅威の分類基準例（２）脅威
意図的（計画的）脅威
偶発的脅威
実施による利益はない
通常では発生しない

2

実施による利益はあまりない

3

実施による利益は多少ある

レベル© JAHIS 2013

104

環境的脅威
3 年以内に一度も発生しない
特定の状況下での発生が考え 3 年に一度程度発生する
られる
専門能力のあるものの不注意 1 年に一度程度発生する
で発生する

4
5

実施による利益がある
発生が具体的に予想される

一般者の不注意で発生する
通常の状態で発生する

1 ヶ月に一度程度発生する
1 ヶ月に一度以上発生する③ ぜい弱性の評価
ぜい弱性の評価は、その資産の持つ弱点がどの程度であるかを評価することになる。すなわち、現在実施されている対策を考慮して、ぜい弱性の評価を行うことになる。表現は脅威の場合と同様のものが示されている。
表A．１０

レベル
1
2
3

区分
低い
中程度
高い

ぜい弱性の分類基準例（１）
ぜい弱性説明
現状の対策でほぼ完全に防御できる。
現在の対策で、かなりの場合防御可能であるが、万全とは言えない。
現在の対策では、ほとんど防御できない。

表A．１１
レベル
1
2

意図的（計画的）脅威に対するぜい弱性
最高程度の対策を実施済み
高度な専門知識や設備を持つ者によって可能な状況

3

専門能力を持つ者によって可
能な状況

4

一般者が調査を実施すれば可能な状況
一般者が不通に実施可能な状
況

5

ぜい弱性の分類基準例（２）
ぜい弱性
偶発的脅威
に対するぜい弱性
最高程度の対策を実施済み
通常の利用状況ではほとんどリスクが顕在化する恐れがな
い状況
専門能力があるものの不注意によりリスクが顕在化する恐れがある状況
一般者の不注意によりリスクが顕在化する恐れがある状況
特段の対策を実施しておらず、いつリスクが顕在化してもおかしくない状況

環境的脅威に対するぜい弱性
最高程度の対策を実施済み
通常の利用状況ではほとんどリスクが顕在化する恐れがな
い状況
専門能力があるものの不注意によりリスクが顕在化する恐れがある状況
一般者の不注意によりリスクが顕在化する恐れがある状況
特段の対策を実施しておらず、いつリスクが顕在化してもおかしくない状況

ここでリストアップした資産（グループ）、脅威、ぜい弱性に対して、その環境を考慮して値を入れてみると下記のようになった。なお、ここでは脅威およびぜい弱性の評価に、３段階のもの（表 A．８、表 A．
１０）を利用した。どの評価尺度を使うかは、組織の実情を考慮して決めればよい。
Gr 番号
G1

G2

評価値
3

4

© JAHIS 2013

表A．１２
脅威番号
T1-I1
T1-A1
T1-A2
T2-C1
T2-I1
T2-I2
T2-A1
105

資産、脅威、ぜい弱性の評価値
評価値
ぜい弱性番号評価値
2
F1-I1-1
2
2
F1-I1-2
2
1
F1-A1-1
2
2
F1-A2-1
2
1
F2-C1-1
2
1
F2-I1-1
1
1
F2-I2-1
1
1
F2-A1-1
1

G3

1

G4

2

G5

1

T3-C1
T3-I1
T3-A1
T3-A2
T4-C1
T4-I1
T4-A1
T5-I1
T5-A1

1
1
3
1
2
2
2
1
2

F3-C1-1
F3-I1-1
F3-A1-1
F3-A2-1
F4-C1-1
F4-I1-1
F4-A1-1
F5-I1-1
F5-A1-1

3
1
2
2
2
2
2
1
2

リスクの値は、前の作業で明確になった「資産の価値」、「脅威の大きさ」、「ぜい弱性の度合い」を用いて、たとえば、簡易的に次のような式で算出することができる。

リスクの値 = 「資産の価値」×「脅威の大きさ」×「ぜい弱性の度合い」
この式を用いて、表 A．１２でリスク値を計算すると下記のようになった。
Gr 番号
G1

評価値
3

G2

4

G3

1

G4

2

G5

1

表A．１３
リスク値の計算結果
脅威番号
評価値
ぜい弱性番号
T1-I1
2
F1-I1-1
2
F1-I1-2
T1-A1
1
F1-A1-1
T1-A2
2
F1-A2-1
T2-C1
1
F2-C1-1
T2-I1
1
F2-I1-1
T2-I2
1
F2-I2-1
T2-A1
1
F2-A1-1
T3-C1
1
F3-C1-1
T3-I1
1
F3-I1-1
T3-A1
3
F3-A1-1
T3-A2
1
F3-A2-1
T4-C1
2
F4-C1-1
T4-I1
2
F4-I1-1
T4-A1
2
F4-A1-1
T5-I1
1
F5-I1-1
T5-A1
2
F5-A1-1

評価値
2
2
2
2
2
1
1
1
3
1
2
2
2
2
2
1
2

リスク値
12
12
6
12
8
4
4
4
3
1
6
2
8
8
8
1
4

(オ) リスクの評価計算して得られたリスク値は表 A．１３のとおりである。これでそれぞれの資産に対するリスクの相対的な大きさがわかった。次はこのうちのどこまでが受容可能であるかを評価する。この結果、受容できないとなったリスクについては対策を施し、リスクを受容できるレベルにまで低減する必要がある。
この際、次のようなリスク受容の一覧表を作成すると考えやすい。

© JAHIS 2013106

表A．１４
1
資産価値
1
2
3
4

1
1
2
3
4

2
2
4
6
8

3
3
6
8
12

1
2
4
6
8

リスク受容一覧表
脅威
2
ぜい弱性
2
3
4
6
8
12
12
18
16
24

3
1
3
6
9
12

2
6
12
18
24

3
9
18
27
36

ここで、組織の実情に合わせて、受容範囲を決める。下記のような例を参考にして決めるとよい。
受容範囲決定方針の例
資産価値が最大のものは、脅威とぜい弱性がともに最低レベルより上のものは受容しない。すなわち、＜資産価値＞＜脅威＞＜ぜい弱性＞の組み合わせが、４×２×１または４×１×２となるものとする。したがって、リスク値８未満は受容する。

上記の受容範囲決定方針に従って、表 A．１４に受容範囲を表現すると下記のようになる。

表A．１５

リスク受容範囲の例
脅威
1
2
ぜい弱性
資産価値
1
2
3
1
2
3
1
1
2
3
2
4
6
2
2
4
6
4
8
12
3
3
6
8
6
12
18
4
4
8
12
8
16
24
（灰色の網掛け部分が受容可能、それ以外は何らかの対策が必要）

3
1
3
6
9
12

2
6
12
18
24

3
9
18
27
36

この評価基準を用いて表 A．１３を評価すると下記のようになる。
Gr 番号
G1

評価値
3

G2

4

G3

1

© JAHIS 2013

表A．１６
リスク値の評価結果
脅威番号
評価値
ぜい弱性番号
T1-I1
2
F1-I1-1
2
F1-I1-2
T1-A1
1
F1-A1-1
T1-A2
2
F1-A2-1
T2-C1
1
F2-C1-1
T2-I1
1
F2-I1-1
T2-I2
1
F2-I2-1
T2-A1
1
F2-A1-1
T3-C1
1
F3-C1-1
T3-I1
1
F3-I1-1
107

評価値
2
2
2
2
2
1
1
1
3
1

リスク値
12
12
6
12
8
4
4
4
3
1

T3-A1
3
F3-A1-1
T3-A2
1
F3-A2-1
G4
2
T4-C1
2
F4-C1-1
T4-I1
2
F4-I1-1
T4-A1
2
F4-A1-1
G5
1
T5-I1
1
F5-I1-1
T5-A1
2
F5-A1-1（灰色の網掛け部分が受容可能、それ以外は何らかの対策が必要）

2
2
2
2
2
1
2

6
2
8
8
8
1
4

これによると、G1 の資産については完全性と可用性の観点での対策が、G2 については機密性観点での対策が、G4 については機密性・完全性・可用性すべての対策が必要であることがわかる。
(カ) 管理策とリスクの再評価
リスク評価で管理策が必要となった情報資産には、何らかの対策を施して、脅威もしくはぜい弱性のレベルを低減しなければならない。このため対策のことを「管理策」と呼び、ISMS として知られる JIS Q
27001:2006(ISO/IEC 27001:2005）および「安全管理ガイドライン」などで記述されているものが利用可能である。
一般的には、
脅威のレベルを下げることは難しく、管理策はぜい弱性のレベルを下げることが主体となる。
資産価値が大きく、かつ脅威のレベルが高いものについては、その資産自体を廃止する（「リスクの回避」という）といった対策を考慮せざるを得ないような場合も想定されるので、注意が必要である。
何らかの有効な管理策を採用することで、脅威またはぜい弱性のレベルが下がることがわかったら、その値を用いて再度リスクの評価を行う。これを「リスクの再評価」と呼ぶ。
表 A．１６で対策が必要となった資産のぜい弱性を下げる方策の例と、それによる効果を下記に示す。
表A．１７
リスク値の評価結果
Gr 番号
ぜい弱性番号
評価値
管理策
再評価値
G1
F1-I1-1
2
ディスク構成を RAID-6 に変更する
1
F1-I1-2
2
バックアップを別の建屋に保管する
1
F1-A2-1
2
高速なディスクに変更する
1
G2
F2-C1-1
2
パスワードの設定方針を定める
1G4F4-C1-1
2
鍵付きの書架に保管する
1
F4-I1-1
2
物理コピーを毎日とる
1
F4-A1-1
2携行する際のルールを定める
1
上記の管理策を施すことで、表 A．１６は下記のようなり、すべてのリスクが受容可能となったことがわ
かる。
Gr 番号
G1

評価値
3

G2

4

© JAHIS 2013

表A．１８
リスク値の再評価結果
脅威番号
評価値
ぜい弱性番号
T1-I1
2
F1-I1-1
2
F1-I1-2
T1-A1
1
F1-A1-1
T1-A2
2
F1-A2-1
T2-C1
1
F2-C1-1
T2-I1
1
F2-I1-1

108

評価値
1
1
2
1
1
1

リスク値
6
6
6
6
4
4

T2-A1

1
F2-A1-1
1
F2-A1-2
G3
1
T3-C1
1
F3-C1-1
T3-I1
1
F3-I1-1
T3-A1
3
F3-A1-1
T3-A2
1
F3-A2-1
G4
2
T4-C1
2
F4-C1-1
T4-I1
2
F4-I1-1
T4-A1
2
F4-A1-1
G5
1
T5-I1
1
F5-I1-1
T5-A1
2
F5-A1-1（灰色の網掛け部分が受容可能、それ以外は何らかの対策が必要）

1
1
3
1
2
2
1
1
1
1
2

4
4
3
1
6
2
4
4
4
1
4

(キ) 経営陣による残留リスクの承認
表 A．１８に示したように、新たな管理策を施すことで、すべてのリスクは受容可能なレベルに下がったことが確認できたが、リスクが全くなくなったわけではない。このように、対策を行ってもまだ残るリス
クのことを「残留リスク」という。
残留リスクが具体的にどのようなリスクであるかを下記に示す。
Gr 番号
G1

脅威番号
T1-I1

表A．１９
ぜい弱性番号
F1-I1-1

F1-I1-2

G2

G3

T1-A1

F1-A1-1

T1-A2

F1-A2-1

T2-C1

F2-C1-1

T2-I1

F2-I1-1

T2-I2

F2-I2-1

T2-A1

F2-A1-1

T3-C1

F3-C1-1

T3-I1

F3-I1-1© JAHIS 2013109

残留リスクの具体的な内容の例
リスク値
残留リスクの具体な内容
6
RAID-6 構成でも復旧できないディスク障害が発生し、障害発生時点から前日バックアップ時点
までのデータが失われる
6
同上、およびサービス再開までの時間と費用が大きなものになる
6
通信回線の復旧までに予想以上の時間がかかり、利用者への影響が大きくなる
6
混雑時にシステムの応答が遅くなり、利用者への影響が出る4
設定方針の遵守をシステム機能でなく運用ルー
ルで担保することで、ルールを遵守しない利用者のパスワードが破られて個人情報が漏えいする
4
利用方針の遵守をシステム機能でなく運用ルー
ルで担保することで、ルールを遵守しない利用者の操作が追跡できなくなる
4
誤ってデータを消してしまった利用者から、操作性の悪さに関するクレームが寄せられる
4
計画保守スケジュールの通知漏れにより、利用者からクレームが寄せられる
3
紛失もしくは盗難にあった機器からシステムに不正アクセスされる
1
機器の測定誤差により、不適切なバイタルデー
タをアップしてしまう

T3-A1

F3-A1-1

6

機器の操作に不慣れな操作員に対する利用者からのクレームが寄せられる
T3-A2
F3-A2-1
2
所定のサービスが行えず、利用者からのクレームが寄せられる、利用者の個人情報が漏えいす
る
G4
T4-C1
F4-C1-1
4
書類の置き忘れ、盗難等により利用者の個人情報が漏えいする
T4-I1
F4-I1-1
4
所定のサービスが行えず、利用者からのクレームが寄せられる
T4-A1
F4-A1-1
4
所定のサービスが行えず利用者からのクレームが寄せられる、または利用者の個人情報が漏え
いする
G5
T5-I1
F5-I1-1
1
所定のサービスが行えず利用者からのクレームが寄せられる
T5-A1
F5-A1-1
4
所定のサービスが行えず利用者からのクレームが寄せられる
これらの残留リスクは、リスクアセスメントの結果からは「発生頻度が十分に低い」もしくは「発生しても被害が小さい」等の理由で「受容可能」となったものであるが、内容を見る限りでは、必ずしも放置して良いものばかりとは言えないはずである。
経営陣は、これらの残留リスクが存在することを容認できるかどうか、再度検討しなければならない。容認できないと結論した場合には、さらなる対策を行い、容認できるレベルにまで低減する必要がある。中には効果的な低減策が立案できないものもあるであろう。そういう場合には、損害を見越して保険をかける（リスクファイナンス）ことや、資産そのものの利用をやめる（リスクの回避）などの方策を講じることも検討する必要がある。
そして、いったん容認した後には、万一それらが発現した際の責任と対応を考えておく必要がある。

© JAHIS 2013110

付録―２．参考文献
ヘルスケア PKI 関連文書
ここで紹介する文書は本ガイドライン執筆時点の最新版である。実際にこれら標準・規格を参考とする場
合は、その時点での最新版を用いることを推奨する。
・ 厚生労働省：保健医療福祉分野 PKI 認証局証明書ポリシー1.1 版（2006 年 3 月）
http://www.mhlw.go.jp/shingi/2006/03/dl/s0330-8a.pdf
・ ISO IS17090：Health Informatics Public Key Infrastructure（2008 年）
・ Part 1: Framework and overview（Health Care PKI の要件定義、アクセス制御のための属性証明書）
・ Part 2: Certificate profile（X.509 および RFC2459 に基づく証明書のプロファイル）・ Part 3: Policy Management of Certification Authority（ポリシーの規定）
タイムスタンプ及び長期保存に関する標準やガイドライン
・ タイムビジネス協議会(TBF)
http://www.dekyo.or.jp/tbf/tbf/index.html#TBF03
・ タイムスタンプ長期保証ガイドライン（2005 年）
タイムスタンプを用いた電子文書の完全性維持のための手法が詳細に紹介された上で、タイム
スタンプ局（TSA）、認証局（CA）の要件が整理されている。
・ 信頼されるタイムスタンプ技術・運用基準ガイドライン
トレーサビリティが確保され、信頼されるタイムスタンプを実現するための、各事業者における技術・運用基準について示されている。
・ 電子商取引推進協議会(ECOM)・ 電子文書の長期保存と見読性に関するガイドライン（2005 年）
http://www.ecom.jp/en/results/results2004/2004_07.pdf
長期保存のフォーマットだけでなく、電子文書のライフサイクルに関するモデル、保存媒体（メディア）の要件や運用上の留意点などについて広く記載されている。
・ ECOM 長期署名プロファイル
RFC 3126 や XAdES などの標準に基づく長期署名フォーマットを日本国内で普及定着させる
べく、データ構造や処理手順の必要条件をまとめた「長期署名フォーマットのプロファイル」を策定している。同プロファイルは、RFC 3126 や XAdES に基づく、実用的な長期署名のためのシンプルなものとなっている。
http://www.ecom.jp/report/electronic_signatures/CMSformat.pdf
http://www.ecom.jp/report/electronic_signatures/XAdESLong-TermSignatureFormatProfile_V0.6pub_.pdf
・ 長期署名フォーマットの相互運用性試験プロジェクト© JAHIS 2013111

ECOM 長期署名プロファイルこのプロファイルに基づいたテスト仕様を作成し、十数社の製品（一部プロトタイプを含む）の相互運用性テストを実施している。
http://www.ecom.or.jp/report/report.html
・ 日本 HL7 協会：CDA 文書電子署名規格（HL7J-CDA-002）
・ http://www.hl7.jp/intro/std/HL7J-CDA-002.pdf
CDA 文書に電子署名を付与する際に適用されるガイドライン。XML 文書に対する長期署名の標準である、XAdES（下記参照）を採用している。
・ 長期署名に関する国際標準等
・ RFC 3126 Electronic Signature Formats for long term electronic signatures
RFC によって定められた長期署名のためのフォーマット。タイムスタンプを繰り返し付与することで、署名の有効性を延長するアプローチをとっている。
・ ETSI TS 101 733 Electronic Signature Formats (CAdES)ETSI によって定められた長期署名のためのフォーマット。RFC 3126 とほぼ同じ内容となっている。
・ ETSI TS 101 903 XML Advanced Electronic Signatures (XAdES)ETSI によって定められた長期署名のための XML フォーマットを定義している。CAdES の
XML 版といえる。

・ 長期署名に関する JIS 規格
・ JIS X 5092:2008 CMS 利用電子署名(CAdES)の長期署名プロファイル
・ JIS X 5093:2008 XML 署名利用電子署名(XAdES)の長期署名プロファイル
前述の「ECOM 長期署名プロファイル」をベースとして ETSI の最新仕様との整合性を図り作成されたもの。
CMS ファイル形式と XML ファイル形式による二つのフォーマット規格がある。
http://www.ecom.jp/LongTermStorage/esprofile.html#getjis(参考 URL:JIS 規格を照会する ECOM の Web ページ)・JAHIS の電子署名規格
・ ヘルスケア PKI を利用した医療文書に対する電子署名規格「安全管理ガイドライン」に示されている電子署名・タイムスタンプの要件を受け、JAHIS
により具体的な技術規格を定めたもの。署名方式は ECOM 長期署名プロファイル、JIS X 5092、5093 を採用し、署名用の証明書は厚生労働省の「保健医療福祉分野 PKI 認証局証明書ポリシー」に基づくものを前提としている。

© JAHIS 2013112

付録―３．作成者名簿
第３．１版 作成者（社名五十音順）

下野 兼揮

株式会社グッドマン

竹村 徹也

株式会社シーイーシー

長谷川 英重ＪＡＨＩＳ特別委員

西田 慎一郎株式会社島津製作所

西山 晃

セコム株式会社

深尾 卓司

セコム株式会社岡田 康

東芝医療情報システムズ株式会社

江崎 智

日本電気株式会社

佐藤 恵一

日本光電工業株式会社

川村 眞知子富士通株式会社

三谷 浩造

富士フイルム株式会社

茗原 秀幸

三菱電機株式会社

吉田 隆司

菱洋エレクトロ株式会社© JAHIS 2013

113

日付
2007 年 5 月
2009 年 10 月
2011 年 4 月

バージョン

2013 年 xx 月

第 3.1 版

改定履歴
内容
初版
厚生労働省ガイドライン第二版・第三版に対応
厚生労働省ガイドライン第 4 版・第 4.1 版、総務省ガイドライン、及び経済産業省ガイドラインに対応
総務省ガイドライン第 1.1 版、及び経済産業省ガイド
ライン第 2 版に対応

第2版
第3版

（ＪＡＨＩＳ標準 １３－００２）
２０１３年４月発行
ＪＡＨＩＳ
保存が義務付けられた診療録等の電子保存ガイドライン（第３．１版）
発行元 一般社団法人 保健医療福祉情報システム工業会〒１０５－０００４ 東京都港区新橋２丁目５番５号（新橋２丁目ＭＴビル５階）
電話 03-3506-8010

FAX 03-3506-8070（無断複写・転載を禁ず）© JAHIS 2013114