JAHIS標準 06-002

ヘルスケア分野における監査証跡のメッセージ
標準規約

２００６年１２月
保健医療福祉情報システム工業会
セキュリティ委員会

ヘルスケア分野における監査証跡のメッセージ標準規約
ま

え

が

き

平成 17 年 4 月の個人情報保護法完全施行に伴い、保健医療福祉分野において２つのガイドラインが出された。これらの中で医療機関に対して、個人情報の取り扱いに関する「説明責任」が求められている。これを果たすためには、システムが適切に運用されていることを証拠として示すことが重要であり、そのためには第三者が検証可能なレベルの監査証
跡を残すことが重要である。医療機関に医療情報システムを提供しているベンダとしては、
技術的対策としてシステムに監査証跡を残す機能を実装し、医療機関の運用において余計な負荷がかからないようにする必要がある。そこで JAHIS としては、日本の現状および国際的な監査証跡の標準化の動向を踏まえ、RFC3881 をベースとした標準的な監査証跡のメ
ッセージ規約を制定することとした。
本規約は、監査証跡に関し、システムが技術的に担保しなければならない監査ログメッ
セージの規約を定めたものであり、メッセージの生成タイミングや通信手段などの実装方式については規定していない。また、監査ログメッセージの内容については、必要最小限の基準を定めたものとなっている。
２００６年１２月
保健医療福祉情報システム工業会
セキュリティ委員会＜＜ 告知事項 ＞＞
本規約は関連団体の所属の有無に関わらず、規約の引用を明示することで自由に使用することができるものとします。ただし、一部の改変を伴う場合は個々の責任において行い本規約に準拠する旨を表現することは厳禁するものとします。
本規約ならびに本規約に基づいたシステムの導入・運用についてのあらゆる障害や損害について、本規約作成者は何らの責任を負わないものとします。ただし、関連団体
所属の正規の資格者は本規約についての疑義を作成者に申し入れることができ、作成者はこれに誠意をもって協議するものとします。
Copyright 2006

保健医療福祉情報システム工業会

i

ii

目次
第１章 はじめに................................................................................................................... 1
第２章 目的と策定方針 ........................................................................................................ 2
２.１ 目的 ......................................................................................................................... 2
２.２ 策定方針.................................................................................................................. 2
第３章 適用範囲................................................................................................................... 3
３.１ 対象モデル .............................................................................................................. 3
３.２ 適用範囲外 .............................................................................................................. 5
３.３ 参照規格.................................................................................................................. 5
３.４ 単語及び略語........................................................................................................... 6
第４章 監査ログの生成 ........................................................................................................ 8
４.１ 概要 ......................................................................................................................... 8
４.２ 個人情報へのアクセスイベント .............................................................................. 8
４.３ 個人情報への検索イベント ..................................................................................... 8
第５章 イベント別メッセージ ............................................................................................. 9
５.１ 個人情報へのアクセスイベントメッセージ ............................................................ 9
５.２ 個人情報への検索イベントメッセージ ................................................................. 11
５.３ イベントＩＤおよびコード表................................................................................ 13
付録１．「RFC3881：Security Audit & Access Accountability XML Data Definitions for
Healthcare Applications」 ５章 Data Definitions 翻訳.............................................. 14
付録２．作成者名簿（五十音順） ...................................................................................... 29

iii

iv

第１章

第１章

はじめに

はじめに

平成 17 年 4 月の個人情報保護法完全施行に伴い、保健医療福祉分野においても「医療・介護関係事業者における個人情報の適切な取扱のためのガイドライン」（平成１６年１２月）が厚生労働省より発行された。さらに、医療情報システムを導入する場合には厚生労働省発行の「医療情報システムの安全管理に関するガイドライン」（平成１７年３月）に従うことが求められている。「医療情報システムの安全管理に関するガイド
ライン」の 4 章において「電子情報を扱う医療機関等における責任のあり方」に関する説明がなされており、「説明責任」、「管理責任」、「結果責任」を果たすことが医療機関に対して求められている。特に説明責任については以下のような詳細かつ具体的な記載
により、きちんとした対応を求めている。
説明責任を果たすためには、システムの仕様や運用計画を明確に文書化する必要がある。また仕様や計画が当初の方針の通りに機能しているかどうかを定期的に監査し、その結果もあいまいさのない形で文書化し、また監査の結果問題があった場合は、真摯に対応するのはもちろんのこと、その対応の記録も文書化し、第三者が検証可能な状況にすることが必要である。
「医療情報システムの安全管理に関するガイドライン」より
この説明責任を果たすためには、システムが適切に運用されていることを証拠として示すことが重要であり、第三者が検証可能なレベルの監査証跡を残すことが重要になっている。監査証跡とは、監査対象システムの入力から出力に至る過程を追跡できる一連の仕組みと記録のことをさす。監査証跡はオペレーティングシステム、データベースマ
ネジメントシステム、業務アプリケーションシステムなどのシステムが出力するログだ
けでなくメンテナンス履歴や障害報告などの監査対象システムの運用に関係する報告書も含んだ概念である。
医療機関に対する行政側からの説明責任の要請に対し、個人情報保護法施行前に開発されたシステムにおいては、監査証跡に関する個人情報保護の観点からの要件が明確でなかったことから、十分な機能を実装していないシステムが殆どである。また、大規模病院においては、マルチベンダ化の進展により複数のベンダのシステムを統合管理している事例が多くなっている。日々発生する大量のデータに対する基幹系、部門系の数多
くのシステムの監査証跡を管理する必要があるが、監査証跡については各社が独自の実装を行っているため、統合管理を行うことが難しい状況にある。これに対しベンダとしては、技術的対策としてシステムに監査証跡を残す機能を実装し、医療機関の運用において余計な負荷がかからないようにする必要がある。
こうした状況の中で、医療情報システムの監査証跡に関する国際標準化の動きが進展しつつあり、RFC3881 といった医療情報システムに適用可能な監査証跡の規格が策定され、実際に DICOM の Supplement95 として DICOM 規格化が進められている。そこで JAHIS としては、日本の現状を踏まえ、「医療情報システムの安全管理に関するガ
イドライン」に対応した監査証跡の取扱について、国際的な監査証跡の標準化の動向を踏まえ、RFC3881 をベースとした標準的な監査証跡のメッセージ規約を制定することとした。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

1
２００６年１２月

第２章

目的と策定方針

第２章

目的と策定方針

２.１ 目的本規約においては監査証跡のうち「医療情報システムに関する安全管理のガイドラ
イン」において求められている業務アプリケーションの監査ログのログメッセージ規約を策定する。本規約において規定する監査ログは以下の目的で利用されることを想定している。
（１） 個人情報へのアクセス履歴の確認（２） 医療機関が説明責任を果たすために利用（３） 副次的効果としての目的外アクセスの抑止「個人情報へのアクセス履歴の確認」は、医療機関として管理責任を果たすために必要な管理を実施する際に行われるもので、問題の発生を検知するための利用や、セキュリティ対策の改善を検討するための利用などを想定している。
「医療機関が説明責任を果たすために利用」は、患者からの自己の情報の利用についての問い合わせに答える際にその証拠として利用する場合や、情報セキュリティ監
査を受ける際に運用状況を説明するための証拠として利用する場合などを想定している。
「副次的効果としての目的外アクセスの抑止」は監査証跡を取得していることを関係者に周知することで、不正行為や犯罪行為などの目的外行為を行った場合にそれが管理者に把握されやすいことを認識させ、目的外行為を心理的に抑止するなどの効果を狙っている。
２.２ 策定方針
本規約は、監査証跡に関し、システムが技術的に担保しなければならない監査ログ
メッセージの規約を定めたものであり、メッセージの生成タイミングや通信手段などの実装方式については規定しない。また、監査ログメッセージの内容については、必要最小限の基準を定めている。特に配慮したのは以下の二点である。
（１） 技術で担保する部分を明確にし、運用も含めた監査手法の確立を補助する。
（２） 監査証跡の粒度を明確にし、運用に余計な負荷がかからないようにする。
また、規約の策定に当たっては、標準的な形式を採用し、ユーザ側に不必要な手間が発生しないようにすることを重視し、以下の二点に注意して策定を行った。
（１） マルチベンダのシステムでも統一された監査証跡の管理が可能であること（２） 最低限の要件を明確にした上で、将来の拡張に対する自由度を持たせること2
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

第３章

第３章

適用範囲

適用範囲

３.１ 対象モデル
ここでは、本規約において対象とする情報システムのモデルを下記のように定義する。

（１） 機能的に独立した２つ以上の情報システムから構成された、複合型の情報システ
ムであること補足説明
この規格の目的は監査ログのメッセージを策定することにあるので、ここではメッ
セージの標準化が必要な２つ以上の情報システムからなる複合システムを対象とする。
もちろん、単一の情報システムで構成されるシステムにおいても、将来のシステム拡張を考慮したり、監査ログの標準化を考慮したりすると、この規格に従った監査ログを収集することは有意義であり、実装を妨げるものではない。
（２） 複合型の情報システムが、任意のシステム形態（トポロジ）の情報システムから構成されること
補足説明
ここでいうシステム形態とは、いわゆるスタンドアロン型、クライアント・サーバ型、
ホスト・端末型（Web 型もこの範疇のバリエーションと考えてよい）など、情報シス
テムを構成する要素の物理的・論理的な配置を意味している。
（３） それぞれの情報システムを構成する機能要素（端末、サーバ等）の物理的配置が、当該の医療機関の敷地内で閉じていることを前提としないこと
補足説明
医療機関の敷地外からのシステム利用、いわゆる遠隔利用を行なう場合、システム形
態によっては、遠隔地にある端末側で監査ログを収集するケースが想定される。本規約
は、そのような場合も対象とする。
（４） それぞれの情報システムにおいて、保護対象となる情報へのアクセスが行われた際に、それぞれの情報システムが監査ログを生成すること
補足説明
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

3
２００６年１２月

第３章

適用範囲

本規約では、監査ログの生成を調停、または代行するような機能の存在は想定しておらず、複合システムを構成する個々の情報システムが、それぞれ独自に監査ログを生成することを前提とする。それぞれの情報システムにおいて、どの機能要素（装置、ソフ
トウェアのプロセス等）が監査ログを出力するかは、その形態によって変わってくる。
ここでは、参考として代表的なシステム形態における監査ログの出力場所の例を示す。
スタンドアロン型の場合

装置
上位
プロセス

下位
プロセス

データ
ベース

ログ
・ 上位プロセスが下位プロセスに指示して保護対象情報アクセスするケースでは、上位プロセス側で監査ログを生成する
・ ただし、これは下位プロセスからの監査ログ出力を妨げるものではない
クライアント・サーバ型の場合

クライアント

サーバ

プロセス

プロセス

ログ

ログ

データ
ベース

・ 原則的にはクライアントとサーバ両方が監査ログを出力する
・ クライアントが出力できない場合はサーバだけが監査ログを出力する
・ サーバが出力する監査ログが有用でない場合（監査ログから利用者等が特定できない場合など）は、クライアントだけが出力する
ホスト・端末型（Web型）の場合

端末（クライアント）

ホスト（サーバ）

ダム端末（ブラウザ）

プロセス

データ
ベース

ログ
・ ホスト（サーバ）でのみ監査ログを出力する（５） 監査ログを生成した情報システム（以下、ログクライアントと呼ぶ）が、その内4
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

第３章

適用範囲

容を機能的に独立した情報保存用装置（以下、ログサーバと呼ぶ）に、何らかの方法を用いて伝達すること
補足説明
ログクライアントからログサーバに監査ログを渡す方法は、どのようなものであってもよい。オンライン処理（通信）によるメッセージ伝達でもよいし、オフラインで人の手を介したファイル渡しでもよい。オンラインであれば、ログクライアントからログサーバに送りつけてもよいし、逆にログサーバがログクライアントから回収してもよい。
（６） すべてのログクライアントとログサーバ間で、時刻同期が行われていること
補足説明
この規約では、複数のログクライアントで生成された監査ログをログサーバに集め、蓄積することを想定している。この蓄積された監査ログを調べて、何らかの事実を導き出すためには、任意の監査ログの時間的な前後関係が正確に保全されている必要がある。
情報システムを構成する機器間での時刻同期については、「医療情報システムの安全管理に関するガイドライン」でも言及されており、本規格ではこのガイドラインに沿った精度での時刻同期が行われていることを前提条件とする。
３.２

適用範囲外

ここでは本規約において適用範囲外とする項目を規定する。これらを規約の対象とする
ことについて、一定の意義を見出すこともできるが、現時点で実装を考えた場合、あまり制約が多いと普及を阻害する要因となることが懸念される。いずれ普及した時点で順次規格化を目指すものとする。
（１） 「いつ」「誰が」「誰の」「検索条件」以外の情報（２） ログクライアントとログサーバ間での情報伝達の方法（３） ログサーバでのデータ保存方法、およびその形式（４） 監査手法（５） オペレーティングシステムやミドルウェア（DBMS 等）が生成するログ（６） 装置間での時刻同期の方法
３.３

参照規格

（１） 個人情報の保護に関する法律
個人情報の適正な取扱いに関し、国及び地方公共団体の責務等を明らかにするとともに、個人情報を取り扱う事業者の遵守すべき義務等を定めることにより、個人情報の有用性に配慮しつつ、個人の権利利益を保護することを目的とする法律。平成 15 年 5 月 30日に公布、平成 17 年 4 月 1 日より完全施行された。
（２） 医療・介護関係事業者における個人情報の適切な取扱いのためのガイドライン
厚生労働省から平成 16 年 12 月 24 日に出されたガイドライン。上記個人情報保護法の対象となる病院、診療所、薬局、介護保険法に規定する居宅サービス事業を行う者等の事業者等が行う個人情報の適正な取扱いの確保に関する活動を支援するためのものであり、厚生労働大臣が法を執行する際の基準となるもの。
（３） 医療情報システムの安全管理に関するガイドライン
厚生労働省から平成 17 年 3 月 31 日に出されたガイドライン。医療情報システムの導入及びそれに伴う情報の外部保存を行う場合の取扱いについてのもの。
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

5
２００６年１２月

第３章

適用範囲

上記「医療・介護関係事業者における個人情報の適切な取扱いのためのガイドライン」
内「III.４.（４）（ｐ１８）」における「厚生労働省が別途定める指針」とは本ガイドラインのことである。
（４） DICOM Supplement 95：Audit Trail Messages
米国放射線学会（ACR）と北米電子機器工業会（NEMA）が開発した医用画像と通信の標準規格である DICOM（Digital Imaging and Communication in Medicine）は、病院内外で異なった製造業者の異なった種類、所謂「マルチベンダ」と「マルチモダリテ
ィ」のデジタル画像機器をネットワークまたは保存媒体をもって相互に接続し、患者の画像検査情報の送受信や、画像データの伝送を可能とすることを目指している。
DICOM の監査証跡に関する技術文書として、「Supplement 95：Audit Trail Messages（以下「Supplement 95」という。）」 が提唱されているが、現時点では Frozen Draft となっている。しかし、医療に特化したセキュリティとプライバシーの全体的なシステムの一部として監査機能を扱っており、監査メッセージの交換に関しての規定としては大変有効である。
Supplement 95 では、DICOM 規格に準じた装置が、監査証跡の収集およびロギングを行なうアプリケーションに監査メッセージを送るためのメカニズムについて説明している。セキュリティ管理者が各個別のノードから監査情報を抽出するのではなく、各ノードが監査情報を収集ポイントに送ることをモデル化しており、その目的は監査証跡メ
ッセージの収集を簡素にするためである。
（５） RFC3881：Security Audit & Access Accountability XML Data Definitions for
Healthcare Applications
Supplement 95 基本メッセージフォーマットは「RFC 3881：Security Audit & AccessAccountability XML Data Definitions for Healthcare Applications（以下「RFC 3881」という。）」で規定される XML スキーマを拡張させ、DICOM アプリケーションが XML
ベースの監査証跡メッセージを設定するために必要な語彙（DICOM 固有の監査メッセー
ジ）を定義している。具体的には、医療データに誰が、いつ、どのような操作に対して、
どこからアクセスし、どの患者のレコードが関係するかが監査メッセージに含まれる。
また、監査メッセージの伝送メカニズムは「RFC 3195：Reliable Delivery for syslog」
で規定される SYSLOG を使用して伝送ポイントに伝送される仕組みとなっており同時に、信頼できる伝送、バッファリング、確認応答、認証、識別、および暗号化のメカニズムを提供する。
Supplement 95 と RFC 3881 は、Health Level 7 （HL7） [HL7SASIG]、DICOM WG
14、IHE [IHETF-3]、ASTM E31 [E2147]、NEMA/COCIR/JIRA SPC [NEMASPC]の各々ばらばらな監査証跡についての視点を統合するリファレンスとして今後大いに活用されるべき規定であるといえる。
３.４

単語及び略語（１） （患者の）個人情報
当該情報に含まれる氏名、生年月日、その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。医療分野においては、死者に関する情報が、同時に、遺族等の生存する個人に関する情報でもある場合には、当該生存する個人に関する情報となる。
6
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

第３章

適用範囲

医療機関で利用される情報システムは、一般に患者の個人情報を含むと考えてよい。
この考え方からすると、情報システム内のすべての情報に対するアクセスの際に監査ログを収集することでフェイルセーフとしてよい。
（２） 説明責任
医療機関が、外部の利害関係者(患者など)に、自身の行動について事前・事後に説明する責任のこと。
（３） 管理責任
運用面の管理を施設が行う責任のこと。
（４） 結果責任発生した問題点や損失に対する責任のこと。
（５） 監査証跡
監査対象システムの入力から出力に至る過程を追跡できる一連の仕組みと記録のこと。
（６） 監査ログ「いつ」「誰が」「誰の」情報にアクセスしたかを記録した情報のこと。
「何の」や「何故」、「どこから」も重要な情報であるが、これらを記録することでシステムの負荷が高まることが予想され、本規約ではこれらを適用範囲外とする。
（７） ログクライアント
監査ログを生成した情報装置・プログラムのこと。利用者の識別と、アクセスする
情報単位を認識しており、その単位で監査証跡を生成する実体をさすものとする。
（８） ログサーバ
ログクライアントから監査ログを受け取り、保存する情報装置・プログラムのこと。
（９）セキュリティポリシ
医療機関における情報セキュリティに関する基本方針のこと。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

7
２００６年１２月

第４章

監査ログの生成

第４章

監査ログの生成４.１ 概要監査ログを生じさせるきっかけとなる監査イベント（トリガイベント）は、各々の医療情報システムの規模や用途、関係するスタッフ、セキュリティポリシの内容によって定義される。本規約では、個人情報へのアクセスの履歴の確認と、患者に対して医療機関が説明責任を果たすことができることを監査証跡の目的としているため、一般的な情報セキュ
リティが扱うシステム全体のセキュリティ監査のための監査証跡の範囲すべてを網羅する
ものではない。また、対象を業務アプリケーションに限定しているが、「医療情報システムの安全管理に関するガイドライン」が要求する「いつ」「誰が」「誰の」情報にアクセスしたかを満たす監査メッセージを生成するためには、以下の２つの監査イベントが必要である。
（１） 個人情報へのアクセスイベント（２） 個人情報への検索イベント
４.２ 個人情報へのアクセスイベント
本規約では、個人情報へのアクセスイベントを監査イベントとする。当該の保護データに対して「いつ」「誰が」「誰の情報にアクセスしたか」の情報がログの内容となる。

イベント
個人情報へのアクセスイベント

内容
いつ、
誰が、
誰の情報にアクセスしたか

４.３ 個人情報への検索イベント
個人情報へのアクセスを目的とした DB 等への検索イベントを監査イベントとする。当該の検索イベントについて「いつ」「誰が」「どのような条件で検索したか」の情報がログ内
容となる。

イベント

内容

個人情報への検索イベント

いつ、誰が、どのような条件で検索したか

8
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

第５章

第５章

イベント別メッセージ

イベント別メッセージ

本章ではイベント別の監査ログのメッセージの内容について記述する。記述するイベン
トは、（１） 個人情報へのアクセスイベント（２） 個人情報への検索イベントである。また、メッセージ内で記述されるイベントＩＤおよびコードについて表でまとめて記述する。
５.１ 個人情報へのアクセスイベントメッセージ
このメッセージでは、個人情報の作成、読み取り、変更、または削除に関するイベン
トの内容を記述する。オプション欄の文字は、M(Mandatory)は必須項目、U(User
Option)は実装者によるオプショナルな項目との意味である。
フィールド名イベント関連オプション

EventID

M

EventActionCode

M

値の制限
監査イベントのID。以下の値が入る。
EV (110110, DCM, “Patient Record”)
監査ログを生成したイベントで実行されたアクション。以下の値が入る。
EV: “C” (作成)
“R” (読み取り)“U” (更新)“D” (削除)

ユーザー関連(1..2)

EventDateTime

M

EventOutcomeIndicator

M

EventTypeCode

U

UserID

M

AlternateUserIDU

UserNameU

UserIsRequestor

U

イベントが発生した時刻。
RFC3881の規定に従う。
イベントの成功、失敗を示す。
RFC3881の規定に従う。
イベントのタイプ。
CID(ccc2)を使用してJAHISにより拡張した値が入る。
データを操作した人またはプロセスのID。両方ともわかっている場合は、人とプロセスの両方を含める。これは発生源（AuditSourceID）においてユニークな値である。
データを操作した人またはプロセスの別のID。
RFC3881の規定に従う。
データを操作した人またはプロセスの名前。
RFC3881の規定に従う。
データを操作した人またはプロセスが本イベントの要求者か否かを示す。以下の値が入る。
EV TRUE

RoleIDCodeU

イベントを実行するときのデータを操作した人またはプロセスの役割。
RFC3881の規定に従う。

NetworkAccessPointTypeCode

U

NetworkAccessPointID

U

ネットワークアクセスポイントのタイプ。
RFC3881の規定に従う。
ネットワークアクセスポイントに対するID。
RFC3881の規定に従う。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

9
２００６年１２月

第５章

イベント別メッセージ

発生源システム関連(1)関係者オブジェクト関連（アクセスされた患者情報）(1)

AuditEnterpriseSiteID

U

ネットワーク中の論理的な発生源システムの場所。
AuditSourceIDを修飾するために使う。

AuditSourceID

M

発生源システムのユニークなID。

AuditSourceTypeCode

U

ParticipantObjectTypeCode

M

ParticipantObjectTypeCodeRole

M

ParticipantObjectDataLifeCycle

U

ParticipantObjectIDTypeCode

M

ParticipantObjectSensitivity

U

ParticipantObjectID

M

ParticipantObjectName

U

ParticipantObjectDetailU

発生源システムのタイプ。
RFC3881の規定に従う。
関係者オブジェクトのタイプコード。以下の値が入る。
EV 1 (人)関係者オブジェクトの役割を示すコード。以下の値が入る。
EV 1 (患者)関係者オブジェクトのデータライフサイクルステージのID。
RFC3881の規定に従う。
ParticipantObjectIDに含まれるタイプ。以下の値が入る。
EV 2 (患者ID)
ParticipantObjectIDに対するポリシー定義の機微性。
RFC3881の規定に従う。
関係者オブジェクトのインスタンスID。
患者IDが入る。
関係者オブジェクトのインスタンスの名前。
患者名が入る。
関係者オブジェクトのインスタンスの詳細情報。
RFC3881の規定に従う。

10
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

第５章

イベント別メッセージ

５.２ 個人情報への検索イベントメッセージ
このメッセージでは、個人情報へのアクセスを目的としたＤＢ等への検索の発行および受信に関するイベントを記述する。メッセージには、検索に対する応答は記録されず、検索が発行された事実のみを記録する。オプション欄の文字は、M(Mandatory)は必須項目、U(User Option)は実装者によるオプショナルな項目との意味である。
フィールド名イベント関連オプション

EventID

M

EventActionCode

M

値の制限
監査イベントのID。以下の値が入る。
EV (110112, DCM, “Query”)
監査ログを生成したイベントで実行されたアクション。以下の値が入る。
EV “E” (実行)

問合せ元関連(1)

EventDateTime

M

EventOutcomeIndicator

M

EventTypeCode

U

UserID

M

AlternateUserIDU

UserNameU

UserIsRequestor

U

イベントが発生した時刻。
RFC3881の規定に従う。
イベントの成功、失敗を示す。
RFC3881の規定に従う。
イベントのタイプ。
RFC3881の規定に従う。
検索を発行したプロセスのID。これは発生源（AuditSourceID）
においてユニークな値である。
検索を発行したプロセスの別のID。
RFC3881の規定に従う。
検索を発行したプロセスの名前。
RFC3881の規定に従う。
検索を発行したプロセスが本イベントの要求者か否かを示す。
RFC3881の規定に従う。

RoleIDCode

M

イベントを実行するときの検索を発行したプロセスの役割。
以下の値が入る。
EV (110153, DCM, “Source”)

問合せ先関連(1)

NetworkAccessPointTypeCode

U

NetworkAccessPointID

U

UserID

M

AlternateUserIDU

UserNameU

UserIsRequestor

U

ネットワークアクセスポイントのタイプ。
RFC3881の規定に従う。
ネットワークアクセスポイントに対するID。
RFC3881の規定に従う。
検索に応答するプロセスのID。これは発生源（AuditSourceID）
においてユニークな値である。
検索に応答するプロセスの別のID。
RFC3881の規定に従う。
検索に応答するプロセスの名前。
RFC3881の規定に従う。
検索に応答するプロセスが本イベントの要求者か否かを示す。
RFC3881の規定に従う。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

11
２００６年１２月

第５章

イベント別メッセージ

RoleIDCode

M

イベントを実行するときの検索に応答したプロセスの役割。
以下の値が入る
EV (110152, DCM, “Destination”)

他の関係者関連(0..N)

NetworkAccessPointTypeCode

U

NetworkAccessPointID

U

UserID

M

AlternateUserIDU

UserNameU

UserIsRequestor

U

RoleIDCodeU

NetworkAccessPointTypeCode

U

NetworkAccessPointID

U

ネットワークアクセスポイントのタイプ。
RFC3881の規定に従う。
ネットワークアクセスポイントに対するID。
RFC3881の規定に従う。
関係しており認識されている他の関係者のID。特に要求者である人あるいはプロセスのID。これは発生源（AuditSourceID）
においてユニークな値である。
他の関係者の別のID。
RFC3881の規定に従う。
他の関係者の名前。
RFC3881の規定に従う。
他の関係者が本イベントの要求者か否かを示す。
RFC3881の規定に従う。
他の関係者の役割。
RFC3881の規定に従う。
ネットワークアクセスポイントのタイプ。
RFC3881の規定に従う。
ネットワークアクセスポイントに対するID。
RFC3881の規定に従う。

発生源関連(1)

関係者オブジェクト関連（問い
合わせ内容）(1)

AuditEnterpriseSiteID

U

ネットワーク中の論理的な発生源の場所。AuditSourceIDを修飾するために使う。

AuditSourceID

M

発生源のユニークなID。

AuditSourceTypeCode

U

ParticipantObjectTypeCode

M

ParticipantObjectTypeCodeRole

M

ParticipantObjectDataLifeCycle

U

ParticipantObjectIDTypeCode

M

ParticipantObjectSensitivity

U

ParticipantObjectID

M

ParticipantObjectName

U

ParticipantObjectQuery

M

ParticipantObjectDetailU

発生源のタイプ。
RFC3881の規定に従う。
関係者オブジェクトのタイプコード。以下の値が入る。
EV 2 (システム)
関係者オブジェクトの役割を示すコード。以下の値が入る。
EV 3 (レポート)
関係者オブジェクトのデータライフサイクルステージのID。
RFC3881の規定に従う。
ParticipantObjectIDに含まれるタイプ。
EV 10 (検索基準)
ParticipantObjectIDに対するポリシー定義の機微性。
RFC3881の規定に従う。
関係者オブジェクトのインスタンスのID。
RFC3881の規定に従う。
関係者オブジェクトのインスタンスの名前。
RFC3881の規定に従う。
base64で符号化された検索内容。本内容は本装置開発ベンダ
にて内容が分析できなければならない。
関係者オブジェクトのインスタンスの詳細情報。
RFC3881の規定に従う。

12
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

第５章

イベント別メッセージ

５.３ イベントＩＤおよびコード表
CID(ccc1) 監査イベントID
コンテキストID(ccc1)
監査イベント ID
タイプ: 拡張可能

バージョン: 2006xxxx

符号化体系指定子

コード値

コード意味

DCM

110110Patient Record（患者レコード）

DCM

110112

Query（問合せ）CID(ccc2) 監査イベントタイプコード
コンテキストID(ccc2)
イベントタイプコード
タイプ: 拡張可能

バージョン: 2006xxxx

符号化体系指定子

コード値

コード意味

JAHIS

110120Start（アクセス開始）

JAHIS

110121End（アクセス終了）

CID(ccc1) 役割ID
コンテキストID(ccc3)
役割 ID
タイプ: 拡張可能

バージョン: 2006xxxx

符号化体系指定子

コード値

コード意味

DCM

110152

Destination(送信先)DCM

110153

Source(送信元)

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

13
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳付録１．「RFC3881：Security Audit & Access Accountability XML Data
Definitions for Healthcare Applications」 ５章 Data Definitions 翻訳
本付録は、「RFC3881：Security Audit & Access Accountability XML Data Definitionsfor Healthcare Applications」における「５章 データ定義」を翻訳したものである。監査
ログメッセージ解釈の参考にしていただきたい。

5. データ定義
このセクションは XML スキームでデータを定義し記述する。
データ要素は、下記のように分類される：
1) イベント識別-何が行われたか
2) アクティブな関係者識別-誰によって
3) ネットワーク・アクセスポイント識別 -どこで始められたか
4) 発生源識別-どのサーバを使用したか
5) 関係オブジェクト識別-何に記録するか

5.1. イベント識別次のデータは名前、アクション・タイプ、時間、そして監査されたイベントの配列を識別する。
イベント識別データは、監査イベント毎に 1 つのセットが存在する。
5.1.1. イベント識別
説明
特定の監査されたイベント(例えばメニュー項目、プログラム、ルール、ポリシー、機能
コード、アプリケーション名、URL)のための識別子であり、実行された機能を識別する。
オプション性：必須

形式 / 値システム実装者によって定義されたか標準的な用語集を参照するためのコード化された値。「コード」属性は少なくとも発生源識別内で、曖昧なことなくユニークでなければならない（セクション 5.4 参照）。イベント識別の例はプログラム名、メソッド名あるいは関数名である。
コードとして定義、または標準の参照のため、XML スキーマは以下のオプション属性を定
義する。
属性
値
------------------------------------------------------------CodeSystem
OID 参照。
CodeSystemName コード化するシステムの名前；ローカルに定義されたコード
セットのための値であることを強く推奨する。
DisolayName
表示と報告書の中で使用される値
OriginalText コードに変換される入力値
14
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

あいまいでないイベント識別要求のサポートのため、複数の値の定義は禁止である。
原理
これは監査された機能を識別する。“実行”というイベント･アクション･コード監査記
録については、これがアプリケーション関数が実行されたことを示す。
5.1.2.

イベント･アクション･コード

説明
監査を生成するイベント実行中のアクション･タイプの指標
オプション性：オプション

形式 / 値一覧表：
値 意味-- ------------------C 生成
R
UDE

読む/見る/印刷/検索
更新
削除
実行

例
----------------------------------------------------あるオーダーを発行したときのような、新しいデータベース
オブジェクトの生成
医者監査のような、データの表示や印刷
患者情報の改訂のような、データの更新
医師マスター･ファイルのレコードのような、項目の削除
ログオン、プログラム実行、オブジェクト・メソッドの使用のような、システムやアプリケーション機能の実行原理
これは、関連オブジェクト上でどのような種類のアクションが行われたかを明示する。
注
上記に列挙されていないアクションは、特定の機能か、オブジェクト間メソッド、あるいは 2 つ以上の別個のイベントの実行と見なされる。
認可のようなアプリケーション･アクションは実行機能であり、イベント識別は機能を示す。
放射線画像のようなアプリケーションにとって、検索アクションはデータ自体にはアクセスせず、データの存在のみを確認します。監査は明確に区別する必要はない。
“移動”のような合成アクションは、読む・生成・削除のそれぞれの操作、または、関数やメソッドの実行によって監査データの生成により監査される。
5.1.3. イベント日付/時間
説明
世界標準時(UTC：Universal coordinated time)
例：現地時間の不明瞭性をなくすための日時の仕様
オプション性: 必須

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

15
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

形式/値
世界標準時(UTC)を明確に伝えるために、ISO8601 標準に従って形式化された日時の表現
原理
イベントを特定の日時に関連付ける。特にセキュリティ監査では、地理分布により発生
する時間差問題を排除するために、一貫した時間基準（例：UTC）を必要とする。
注
分散システムでは、幾つかの共通の時間基準（例：NTP[RFC1305] サーバー）を利用するのが良い実装の方策である。

5.1.4. イベント結果インジケータ
説明
イベントが成功したか、または失敗したかを表示する。
オプション性: 必須
形式／値
一覧表：
値
意味
---- -------------------------------------------------------------------------0
成功
4
小さい失敗 アクションを再実行（例：最初の誤入力によるパスワード無効）
8
重大な失敗 アクションを中断（例：過度の誤入力によるパスワード無効）12
主要な失敗 アクションによる実行不可（例：ユーザによる過度の無効ログオンの試みによるアカウント無効）原理
いくつかの監査イベントが、成功または失敗インジケータによって判定される。例えば、
なぜログインが失敗したかを表示するために、このフラグにゼロでない値をセットする。
注
いくつかの場合、放射線検査の不完全又は中断した転送のように、「成功」は部分的な可能性がある。責任を明確にするため、これらの区別は関係しない。
5.1.5. イベントタイプコード
説明
イベントのカテゴリのための識別子。
オプション性: オプション
形式／値
システムの実装者により定義された、または標準的な用語集に対する参照として定義された、コード化された値の一覧。
定義されたコード、または標準に対する参照を実装するため、XML スキーマが下記の任意
16
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳の属性を定義する。
属性
値------------- --------------------------------------------CodeSystem
OID 参照CodeSystemName コードシステムの名前。
ローカルで定義されたコードセットに意義を持たせるために強く推奨する。
DisplayName
表示とレポートに利用するために必要。
OriginalText コードに変換された入力値
イベントが 1 つ以上の方法で分類される可能性があるため、複数の値が指定されることがある。
原理
このフィールドは、実装で定義されたイベントカテゴリによって、メッセージの検索を可能にする。

5.2.

実使用者識別

以下のデータは、監査イベント記録を目的のためにユーザを識別する。ユーザは、人もしくは、人以外により起動された装置、あるいはソフトウェアプロセスである。 オプシ
ョンとして、ユーザのネットワークアクセスの場所が特定化される。
１つのイベントに対して複数のユーザが想定される。例えば、あるユーザが別の複数のユーザを起動したり、複数のユーザや装置、プロセスが関連するイベントがある。しかしながら、そのイベントを起動もしくは要求するのは単一のユーザであろう。
5.2.1.

ユーザ ID説明
そのイベントに実際に関係するユーザのユニークな ID
オプション性: 必須
形式／値
認証システムから提供される文字列としてのユーザ識別子。これは、発生源識別（5.4 参照）に含まれるユニークな値である。
原理
この項は監査イベントと特定のユーザを関連づける。
注
システム間の監査に対しては、特に長期間の保存の場合、このユーザ識別子は永久的にユニークなキーを用いることにより、監査イベントと特定ユーザとの関連付けを永久に行う。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

17
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

ノード単位の認証に対しては、人間以外の装置やプロセスを識別する場合に限り、ユー
ザ ID としてノード名が使われる。

5.2.2.

代理ユーザ ID

説明
ユーザに対する代わりのユニークな識別子
オプション性:オプション
形式／値
認証システムから提供される文字列としてのユーザ ID。この ID は、可能であれば、共通の認証システム（SSO など）によるものであろう。
原理
いくつかの状況では、ユーザは１つの ID で認証されるが、特定のアプリケーションシス
テムにアクセスするために、同義の ID を使うこともある。例えば、いくつかの SSO の実装
ではこうなるであろう。この代理識別子は、オリジナル識別子として認証に用いられ、ユーザ ID は、アプリケーションによって知られ使用される。

5.2.3.

ユーザ名

説明
ユーザに対する人にとって意味のある名前
オプション性: オプション
形式／値
文字列
原理
ユーザ ID と代理ユーザ ID は、内部的なものかどうか不明瞭な値である。この項目は、監査人に実際のユーザを識別させる役目をはたす。
5.2.4.

ユーザは要求者

説明
ユーザが、監査されるイベントの要求者もしくは起動者であるかどうかの指標。
オプション性：オプション
形式／値
論理値、省略時解釈は「真」原理
この値は、要求側ユーザと受容側ユーザとの識別に用いる。例えば、ある者が他のユー
18
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

ザへ送信されるレポート出力を起動する。
5.2.5.

役割 ID コード説明
イベントを実施する際のユーザの役割の仕様であり、役割ベースのアクセス制御のセキ
ュリティのために割り当てられる。
オプション性： オプション；複数値
形式／値
認証システムからの役割コードもしくは文字列が付与された「コード」属性を持つコー
ド値。複数の値を使用できる。
コードは実装において定義されるか標準的な用語集を参照する。実装における定義コードもしくは標準への参照に対して、XML スキーマはそれらのオプションの属性を定義する。
属性
値の説明--------------- ---------------------------------------------CodeSystem
OID の参照
CodeSystemName コーディングシステムの名称；局所的に定義された
コードセットを尊重することを強く推奨する
Display Name
ディスプレイとレポートで使用される値
Original Text
コードに変換される入力値
原理
この値は、監査イベントとユーザの役割を結びつける。ユーザの機能的役割カテゴリー
を用いてイベントの集合を解析するためのオプションの値である。
注
多くのセキュリティシステムではこのデータを生成することができないため、これはオプションとなる。
共通のメッセージに対して、可能であれば、この識別子は共通の認証システムにとって知られたものとなる。あるいは、これは発生源ＩＤ（4.4 節参照）に含まれるユニークな値である。複数のシステムから収集される監査データの曖昧さを防ぐために、役割に関連する広域でのユニークな識別子の採用を検討せよ。
役割 ID は、個人の説明責任の代わりにはならない。
複合的な役割と複数の役割を持つユーザにより曖昧さが生じる、例えば、複合的な中のどの役割が使用されたか、あるいは、どの権限を用いたのか？

5.3.

ネットワークアクセスポイント識別

ネットワークアクセスポイントは、アプリケーション動作時にネットワークの論理的位置を識別する。これらのデータは１：１に実使用者識別データと対応する。
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

19
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

5.3.1.

ネットワークアクセスポイント種類コード

説明
ネットワークアクセスポイントの種類、つまり監査イベントによってもたらされる識別子である。
オプション性：オプション
形式／値
一覧表：
値と意味
----- -------------------------------1 マシン名、DNS 名を含む
2
IP アドレス
3 電話番号原理
このデータは監査イベントにおけるユーザデバイスのネットワークアクセスポイント識
別子の種類を示す。この値はオプションであり、複数のサーバに記録されたイベント群を、
ネットワークアクセスポイントの種類ごとに分析する場合などに用いられる。

5.3.2.

ネットワーク・アクセスポイントＩＤ

説明
監査イベントのための、ユーザデバイスのネットワーク・アクセスポイントの識別子である。これは装置 ID、IP アドレス、または装置に関連した幾つかの識別子である。
オプション性：オプション
形式／値与えられたネットワーク・アクセスポイントの種類が特定されていれば、テキストは有効な値のみに規定される。特定に関しては、なるべく多くのオプションが使えることが望ましい。
原理
このデータはユーザのネットワーク・アクセスポイントを識別し、実行したサーバのネットワーク・アクセスポイントを明確にする。この値はオプションであり、複数のサーバに記録されたイベント群に対して、特定のネットワーク・アクセスポイントのデータアクセスを分析する場合などに用いられる。
注
ネットワークアクセスポイント ID は個人の説明責任の代りにはならない。特にインター
ネット IP アドレスは、変り易く、特に短い時間の中で 1 人以上に割り当てられる可能性がある。
例
20
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

Network Access Point ID: SMH4WC02
Network Access Point Type: 1 = Machine Name
Network Access Point ID: 192.0.2.2
Network Access Point Type: 2 = IP address
Network Access Point ID: 610-555-1212
Network Access Point Type: 3= Phone Number

5.4.

発生源識別

以下のデータは主としてアプリケーション・システムとプロセスに必要である。多層、分散、あるいは複合アプリケーション群は発生源識別が曖昧となるので、そのイベントに実際に係った各アプリケーションやプロセスによるフィールド収集が必要となる。 例えば、複数のセットされた値は、複数層に分散されたアプリケーションを構成しているウェ
ブサーバ、アプリケーションプロセスやデータベースサーバ処理を特定することができる。
低レベルのネットワーク転送等の受動的イベントは特定される必要はない。
実装戦略によって、多層、分散、あるいは複合アプリケーションを構成するコンポーネントが、一つのアプリケーションイベントに対し一つ以上の監査メッセージを生成することは可能である。その後のデータ整理は必要ではあるが、監査メッセージ内のさまざまなデータはそのようなケースの識別に利用されます。このドキュメントは、リポジトリと報告メカニズムにより必要時にデータ整理をされることを前提とするが、それらのメカニズムを特定しない。

5.4.1.企業サイト ID の監査
説明
ヘルスケア企業ネットワークの中の論理的な発生源の位置。例えば、複合企業の中の病院または他のプロバイダー位置。
オプション性：

オプション

形式／値
ヘルスケア事業体の中のユニークな識別テキストストリング。監査データを生成するア
プリケーションが発生源ＩＤによって唯一特定されるときは、値なしでよい。
原理
この値はマルチサイト企業健康情報システムのサイトの中で区別される。
注
これは監査記録を生成するアプリケーションで定義される。 それは、その企業とわかる
ビジネス組織（データ所有者）が識別できるユニークコードを含む。その値は、更に発生源ＩＤを特定し、曖昧さを除く。業種により、値は異なるかもしれない。 組織の中において、レベルの差があるかもしれない。
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

21
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

5.4.2.

発生源ＩＤの監査

説明
イベントの起源となる発生源の識別子。
オプション性：必須
形式／値
少なくとも監査される企業サイトＩＤの内のユニークな識別子テキストストリング原理
このフィールドはイベントを特定の発生源システムに結びつける。それは、発生場所によりイベントのグループ化の分析ために使用されるかもしれない。
注
いくつかの構成では、負荷分散機能は処理を 2 つまたはそれ以上の重複サーバに配分する。 このようにしてこのフィールドに定義された値は特定の発生源システムというよりむ
しろサーバのグループのための発生源識別子であるとみなされるかもしれない。

5.4.3.

発生源タイプコードの監査

説明
イベントの起源となる発生源のタイプを識別するコード
オプション性：オプション
形式／値
コード化された一覧表であり、任意にシステム実装者により定義されるか、標準用語集で参照される。 定義されていないか、参照される場合、「コード」属性のデフォルト値は以下の通りである。

値
意味----- -----------------------------------------------------1
エンドユーザーインターフェース
2
データ収集デバイスまたは端末
3
多層システムにおけるウェブサーバープロセス層
4
多層システムにおけるアプリケーションサーバー層
5
多層システムにおけるデータベースサーバー層
6
セキュリティサーバー、例）ドメインコントローラー
7
ISO level 1-3 ネットワークコンポーネント
8
ISO level 4-6 オペレーティングソフトウェア
9 外部発生源、または、その他定義されたコードか標準の参照の実装のために、XML スキーマはこれらの任意の属性を定
22
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

義する:
属性
値
-------------- -------------------------------------------CodeSystem
OID 参照CodeSystemName コーディングシステムの名前; ローカル定義コードの値を強く推奨する
DisplayName
ディスプレイやレポートの中で使われる値
OriginalText コードに変換された入力値
発生源は 1 つ以上の方法で分類されるかもしれないので、指定された複数の値があるかもしれない。
原理
このフィールドは、どのタイプの発生源が発生源ＩＤによって特定されるかを示す。イベントが起こった発生源のタイプに従って分析の為に使われるイベントグループは任意の値かもしれない。

5.5.

関係オブジェクト識別アクセスされたデータもしくはオブジェクトの特定のインスタンスを示すことにより、以下のデータが監査プロセスを補助する。
イベント識別の値を除いて、これらのデータは必須である。アクティブな関係者識別と監査元識別は監査可能なイベント全体を証明することができる。ヘルスケア組織のポリシ
ーや規制に従ってこれらのデータが含まれる監査レコードの生成が行われたり、抑止しされたりする。
イベントは１つ以上の関係オブジェクトを持つので、このグループは繰り返し型の値をとることができる。例えば、施設のポリシーと実装上の選択。
-

２つの関係者オブジェクト値のセットは医療記録番号と患者に対する特定のヘルスケアの発生や出来事で患者データへのアクセス確認をすることに使うことができる。

-

患者の関係者と患者の承認を受けた代理人は同時に識別される。

-

主治医と紹介先医師は同時に識別される。

-

ワークリストで確認されるすべての患者は、識別される。

-

放射線検査において、受付番号や撮影番号により識別される一連の関係者オブジェ
クトが識別される。

注
それぞれの監査メッセージは、そのような関係者オブジェクトの関係の１つの使い方を立証するだけで、存在するかあるいは可能であるすべての関係を立証するものではない。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

23
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

5.5.1.

関係するオブジェクトタイプコード

説明
監査された関係者オブジェクトタイプのコード。この値は、ユーザのロールや関係者オ
ブジェクトに対するどんなユーザ関係とも区別される。
オプション性：オプション
形式／値
一覧：
値 意味
----- ------------1 人
2 システムオブジェクト
3 組織
4 その他
原理
行為が行われるオブジェクトを記述するために、監査可能なイベントにおいて、行為の主題への照会を追加し、行為のオブジェクトタイプを問い合わせが可能であることも重要である。

5.5.2.

関係者オブジェクトコードの役割

説明
コードは監査された関係者オブジェクトの機能アプリケーションの役割を表す。
オプション性：オプション
形式／値
関係者オブジェクトタイプコードの一覧と仕様
値 意味
関係者オブジェクトタイプコード----- -------------------- ---------------------------------1：患者
1－人
2：場所
3－組織
3：レポート2－システムオブジェクト
4：情報源
1－人
3－組織
5：ﾏｽﾀﾌｧｲﾙ
2－システムオブジェクト
6：ユーザ
1－人
2－システムオブジェクト（人間のユーザではない）
7：リスト
2－システムオブジェクト
8：医師
1－人
9：署名者
3－組織
10：保証人1－人24
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

11：ｾｷｭﾘﾃｨﾕｰｻﾞｴﾝﾃｨﾃｨ
12：ｾｷｭﾘﾃｨﾕｰｻﾞｸﾞﾙｰﾌﾟ
13：ｾｷｭﾘﾃｨ資源
14：ｾｷｭﾘﾃｨ粒度定義
15：ﾌﾟﾛﾊﾞｲﾀﾞｰ
16：ﾃﾞｰﾀ送付先
17：ﾃﾞｰﾀ収納場所
18：スケジュール
19：顧客
20：仕事
21：仕事の流れ
22：テーブル
23：ルート基準
24：検索

3－組織
1－人
2－システムオブジェクト
2－システムオブジェクト
2－システムオブジェクト
2－システムオブジェクト
1－人
3－組織
2－システムオブジェクト
2－システムオブジェクト
2－システムオブジェクト
3－組織
2－システムオブジェクト
2－システムオブジェクト
2－システムオブジェクト
2－システムオブジェクト
2－システムオブジェクト

ｾｷｭﾘﾃｨ資源は、抽象的な機密オブジェクトであり、画面、インターフェース、文書、プ
ログラム等。監査ﾃﾞｰﾀｾｯﾄや収納先なども。
原理
詳細な監査分析のため、業務の役割に沿った関係者のより粒度の細かいタイプ表現をする必要がある。

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

25
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

5.5.4.

関係者オブジェクトＩＤのタイプコード

説明
関係者オブジェクトＩＤに含まれる識別子について記述する。
オプション性：必須

形式/ 値
属性名“コード”を使用して、特定の関係者オブジェクトタイプコードへの対応付けを以下の一覧表で示す。下のコードはデフォルトである。
値
---1
2
3
4
5
6

意味
------------------カルテ番号
患者番号
受付番号
登録番号
社会保障番号
会計番号

7

保証人番号

8
9
10
11

レポート名
レポート番号検索基準
ユーザーID12 発生源識別形式(URI)

関係者オブジェクトタイプコード--------------------------------1－人
1－人
1－人
1－人
1－人
1－人
3－組織
1－人
3－組織
1－組織
2－システムオブジェクト
2－システムオブジェクト
1－人
2－システムオブジェクト
2－システムオブジェクト

セキュリティ管理のトリガーイベントは実行されたオブジェクトを識別するためにユー
ザ識別子とテキストベースの URI が使用される。
このコードは上に示されたようなデフォルトであり、それは実装上定義されたもの、または、HL7 バージョン 2.4 の 207 表や DICOM のメディアタイプという標準用語集を参照している。定義されたコードまたは標準を参照した実装に対して、XML スキーマは以下のオプションとなる属性を定義している。
属性値-------------- ----------------------------------CodeSystem
OID 参照CodeSystemName
コーディングシステム名；ローカルに定義された値をとることを強く推奨
DisplayName
ディスプレイ、レポートに使用される値
OriginalText
コードに変換された値
原理
関係者オブジェクトを同義的に識別する様々な識別子を区別する必要がある。
26
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

5.5.6.関係者オブジェクトＩＤ
説明
関係者オブジェクトの特定の物を識別する
オプション性：

必須

形式／値
文字列。関係者オブジェクトタイプコード と関係者オブジェクトＩＤタイプコードに依存する値の形式。
原理
このフィールドは、例えば患者の様な、一つのオブジェクトを識別する特定のもので、プライバシーやセキュリティ問題を探し追跡する。
注
これは、オブジェクトを識別する主要なユニーク識別キーで、そのため、実装に際しては合成データフィールドとなろう。

5.5.7.

関係者オブジェクト名

説明
監査された関係者オブジェクトＩＤを特定の実体として記述するもので、氏名の様なもの。
オプション性：オプション
形式／値
文字列
原理
このフィードは監査の際に問合せや報告の中で特定の人物を識別するために使われる。
例えば、複数の同義の関係者オブジェクトＩＤ（患者番号、診療録番号、受付番号、その他）が使われる。

5.5.8.

関係者オブジェクト検索

説明
検索タイプの関係者オブジェクトによる実際の検索オプション性：

オプション

形式／値
Base64 コード化データ
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

27
２００６年１２月

付録１．「RFC2881」５章 Data Definitions 翻訳

原理
検索イベントでは、特定のイベントを識別するため、検索処理に実際に入力された値を把握することが必須であろう。それらの検索処理の実装とデータのコード化の差異のため、
これは Base64 でコード化される。そのため、その後、監査データ分析処理によって、復号
や翻訳がなされる。

5.5.9.

関係者オブジェクト詳細説明
特定のアクセス又は使用されたオブジェクトの詳細に関する実行定義データ。
オプション性：オプション
形式
タイプと値の組合せ。“タイプ”の属性は実行定義の文字列。“値”の属性は Base64 コー
ド化データ。
原理
特定の監査の遂行において、アクセスされたオブジェクトから特定の詳細情報や値が導出されることが望ましい。タイプと値の組合せにより、実行定義や局所的に拡張できるオブジェクトタイプ識別子や値の使用が可能となる。例えば、診療上の診断オブジェク
トは多様な検査結果を含み、この要素はタイプや数字や結果のタイプを文書化する。
多数のデータのコード化がこの要素にはあり得る。従って、その値 Base64 のコードデー
タとなる。それは、その後、監査データ分析処理で、デコードまたは翻訳される。

28
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

付録２．作成者名簿

付録２．作成者名簿（五十音順）
岡田
岸田
木村
桑野
佐野
永井
西田
深尾
藤咲
舟橋
松本
茗原
好村
吉村

康
幸博
景三
聡
聡
肇
慎一郎
卓司
喜丈
直美
義和
秀幸
啓史
仁

（東芝住電医療情報システムズ株式会社）（キッセイコムテック株式会社）（日本電気株式会社）（株式会社グッドマンヘルスケアＩＴソリューションズ）（パナソニック AVC メディカル株式会社）（日本システック株式会社）（株式会社島津製作所）（セコム株式会社）（日本光電工業株式会社）（日本オラクル株式会社）（株式会社グッドマンヘルスケアＩＴソリューションズ）（三菱電機株式会社）（横河電機株式会社）（コニカミノルタエムジー株式会社）

ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.

29
２００６年１２月

30
ヘルスケア分野における監査証跡のメッセージ標準規約
JAHIS © 2006 All rights reserved.
２００６年１２月

(JAHIS 標準

06-002)

２００６年１２月発行
ヘルスケア分野における監査証跡のメッセージ標準規約
発行元

保健医療福祉情報システム工業会〒105-0001 東京都港区虎ノ門１丁目１９－９（虎ノ門ＴＢＬビル６Ｆ）
電話 03-3506-8010 ＦＡＸ 03-3506-8070（無断複写・転載を禁ず）