[要約] RFC 3881は、医療アプリケーションのセキュリティ監査とアクセスの説明を提供するためのXMLデータ定義です。このRFCの目的は、医療情報のセキュリティとアクセスの追跡を向上させることです。

Network Working Group                                        G. Marshall
Request for Comments: 3881                                       Siemens
Category: Informational                                   September 2004
        

Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications

セキュリティ監査およびアクセス説明責任メッセージXMLデータの定義ヘルスケアアプリケーション

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004).

著作権(c)The Internet Society(2004)。

IESG Note

IESGノート

This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and notes that it has not had IETF review. The RFC Editor has chosen to publish this document at its discretion.

このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、IETFのレビューがなかったことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。

Abstract

概要

This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data.

このドキュメントでは、収集するデータの形式と、ヘルスケアアプリケーションシステムでのセキュリティ監査のためにキャプチャする必要がある属性の最小セットを定義します。この形式は、ヘルスケア標準開発者およびアプリケーションデザイナーのリファレンスとして意図されたXMLスキーマとして定義されます。ヘルスケアデータのセキュリティ監査に関するいくつかの以前の文書を統合します。

Table of Contents

目次

   1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.1.  Data Collection . . . . . . . . . . . . . . . . . . . . .  4
      2.2.  Anticipated Data End-uses . . . . . . . . . . . . . . . .  5
      2.3.  Conformance . . . . . . . . . . . . . . . . . . . . . . .  6
   3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      3.1.  Effective Data Gathering. . . . . . . . . . . . . . . . .  6
      3.2.  Efficiency. . . . . . . . . . . . . . . . . . . . . . . .  7
   4. Trigger Events. . . . . . . . . . . . . . . . . . . . . . . . .  8
      4.1.  Security Administration . . . . . . . . . . . . . . . . .  8
      4.2.  Audit Administration and Data Access. . . . . . . . . . .  9
      4.3.  User Access . . . . . . . . . . . . . . . . . . . . . . . 10
   5. Data Definitions. . . . . . . . . . . . . . . . . . . . . . . . 13
      5.1.  Event Identification. . . . . . . . . . . . . . . . . . . 13
      5.2.  Active Participant Identification . . . . . . . . . . . . 17
      5.3.  Network Access Point Identification . . . . . . . . . . . 20
      5.4.  Audit Source Identification . . . . . . . . . . . . . . . 22
      5.5.  Participant Object Identification . . . . . . . . . . . . 24
   6. XML Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
      6.1.  XML Schema Definition . . . . . . . . . . . . . . . . . . 31
      6.2.  XML Schema Localization . . . . . . . . . . . . . . . . . 43
   7. Security Considerations . . . . . . . . . . . . . . . . . . . . 44
   8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
      8.1.  Normative References. . . . . . . . . . . . . . . . . . . 44
      8.2.  Informative References. . . . . . . . . . . . . . . . . . 45
   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 45
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47
        
1. Purpose
1. 目的

To help assure healthcare privacy and security in automated systems, usage data needs to be collected. This data will be reviewed by administrative staff to verify that healthcare data is being used in accordance with the healthcare provider's data security requirements and to establish accountability for data use. This data collection and review process is called security auditing.

自動化されたシステムのヘルスケアのプライバシーとセキュリティを保証するには、使用データを収集する必要があります。このデータは、管理スタッフによってレビューされ、医療提供者のデータセキュリティ要件に従ってヘルスケアデータが使用されていることを確認し、データ使用の説明責任を確立します。このデータ収集とレビュープロセスは、セキュリティ監査と呼ばれます。

This document defines the format of the data to be collected and minimum set of attributes that need to be captured by healthcare application systems for subsequent use by an automation-assisted review application. The data includes records of who accessed healthcare data, when, for what action, from where, and which patients' records were involved. The data definition is an XML schema to be used as a reference by healthcare standards developers and application designers.

このドキュメントでは、収集されるデータの形式と、自動化支援レビューアプリケーションによってその後使用されるために、ヘルスケアアプリケーションシステムによってキャプチャする必要がある属性の最小セットを定義します。データには、WHOがヘルスケアデータにアクセスした人、いつ、どこから、どこから、どの患者の記録が関与していたかの記録が含まれています。データ定義は、ヘルスケア標準開発者およびアプリケーションデザイナーによるリファレンスとして使用されるXMLスキーマです。

This document consolidates previously disjointed viewpoints of security auditing from Health Level 7 (HL7) [HL7SASIG], Digital Imaging and Communications in Medicine (DICOM) Working Group 14, Integrating the Healthcare Enterprise (IHE) [IHETF-3], the ASTM International Healthcare Informatics Technical Committee (ASTM E31) [E2147], and the Joint NEMA/COCIR/JIRA Security and Privacy Committee [NEMASPC]. It is intended as a reference for these groups and other healthcare standards developers.

この文書は、ヘルスレベル7(HL7)[HL7SASIG]、医学におけるデジタルイメージングとコミュニケーション(DICOM)ワーキンググループ14からのセキュリティ監査の以前にばらばらの視点を統合し、ヘルスケアエンタープライズ(IHE)[IHETF-3]、ASTM International Healthcareを統合します情報学技術委員会(ASTM E31)[E2147]、および共同NEMA/COCIR/JIRAセキュリティおよびプライバシー委員会[NEMASPC]。これらのグループおよび他のヘルスケア標準開発者のリファレンスとして意図されています。

The purposes the document fulfills are to:

ドキュメントが果たす目的は次のとおりです。

1) Define data to be communicated for evidence of compliance with, or violations of, a healthcare enterprise's security and privacy policies and objectives.

1) ヘルスケア企業のセキュリティおよびプライバシーポリシーと目的の順守または違反の証拠のために伝達されるデータを定義します。

This document defines the audit message format and content for healthcare application systems. The focus of auditing is to retrospectively detect and report security/privacy breaches. This includes capturing data that supports individual accountability for patient record creation, access, updates, and deletions.

このドキュメントでは、ヘルスケアアプリケーションシステムの監査メッセージ形式とコンテンツを定義します。監査の焦点は、セキュリティ/プライバシー侵害を遡及的に検出および報告することです。これには、患者の記録の作成、アクセス、更新、削除のための個々の説明責任をサポートするデータのキャプチャが含まれます。

This document does not define healthcare security and privacy policies or objectives. It also does not include real-time access alarm actions since there is a perception in the healthcare community that security measures that inhibit access may also inhibit effective patient care, under some circumstances.

このドキュメントは、ヘルスケアのセキュリティとプライバシーポリシーまたは目標を定義していません。また、ヘルスケアコミュニティには、アクセスを阻害するセキュリティ対策が効果的な患者ケアを阻害する可能性があるという認識があるため、リアルタイムアクセスアラームアクションも含まれません。

2) Depict the data that would potentially reside in a common audit engine or database.

2) 潜在的に一般的な監査エンジンまたはデータベースに存在するデータを描写します。

Privacy and security audit data is to be collected on each hardware system, and there are likely to be separate local data stores for system-level and application-level audits. Collating these records and providing a common view - transcending hardware system boundaries - is seen as necessary for cost-effective security and privacy policy administration.

プライバシーおよびセキュリティ監査データは、各ハードウェアシステムで収集される予定であり、システムレベルとアプリケーションレベルの監査のために、個別のローカルデータストアがある可能性があります。これらのレコードを照合し、共通の見解を提供する - ハードウェアシステムの境界を超越する - は、費用対効果の高いセキュリティとプライバシー政策管理に必要であると見なされます。

The data definitions in this document support such a collation, but the technical implementation alternatives are not covered in this document.

このドキュメントのデータ定義は、このような照合をサポートしていますが、技術的な実装の代替案はこのドキュメントでは説明されていません。

3) Depict data that allows useful queries against audited events.

3) 監査されたイベントに対する有用なクエリを可能にするデータを描写します。

Audit data, in its raw form, reflects a sequential view of system activity. Useful inquiries for security and privacy administration need workflow, business process, organizational, role, and person-oriented views. Data definitions in this document anticipate and support creating those views and queries, but do not define them.

監査データは、生の形式で、システムアクティビティの連続的なビューを反映しています。セキュリティおよびプライバシー管理のための有用な問い合わせには、ワークフロー、ビジネスプロセス、組織、役割、および人指向の見解が必要です。このドキュメントのデータ定義は、これらのビューとクエリの作成を予測およびサポートしますが、それらを定義しません。

4) Provide a common reference standard for healthcare IT standards development organizations.

4) ヘルスケアIT標準開発組織に共通の参照基準を提供します。

By specifying an XML schema, this document anticipates extensions to the base schema to meet requirements of healthcare standards bodies and application developers.

XMLスキーマを指定することにより、このドキュメントは、ヘルスケア基準の団体とアプリケーション開発者の要件を満たすために、基本スキーマへの拡張を予測します。

2. Scope
2. 範囲
2.1. Data Collection
2.1. データ収集

This document specifies audit data to be collected and communicated from automated systems. It does not include non-automated processes.

このドキュメントは、自動化されたシステムから収集および伝達される監査データを指定します。自動化されていないプロセスは含まれていません。

Data for events in the above categories may be selectively collected, based on healthcare organization policy. This document does not specify any baseline or minimal policies.

上記のカテゴリのイベントのデータは、ヘルスケア組織のポリシーに基づいて、選択的に収集される場合があります。このドキュメントでは、ベースラインまたは最小限のポリシーを指定しません。

For each audited event, this document specifies the minimal data requirements plus optional data for the following event categories:

監査済みイベントごとに、このドキュメントは、最小データ要件と次のイベントカテゴリのオプションデータを指定します。

1) Security administrative events - establishing and maintaining security policy definitions, secured object definitions, role definitions, user definitions, and the relationships among them. In general, these events are specific to the administrative applications.

1) セキュリティ管理イベント - セキュリティポリシーの定義、保護されたオブジェクト定義、ロール定義、ユーザー定義、およびそれらの間の関係の確立と維持。一般に、これらのイベントは管理アプリケーションに固有です。

2) Audit access events - reflecting special protections implemented for the audit trail itself.

2) 監査アクセスイベント - 監査証跡自体に実装された特別な保護を反映しています。

3) Security-mediated events - recording entity identification and authentication, data access, function access, nonrepudiation, cryptographic operations, and data import/export for messages and reports. In general, these events are generic to all protected resources, without regard to the application data content.

3) セキュリティを介したイベント - エンティティの識別と認証、データアクセス、機能アクセス、非表現、暗号化操作、メッセージおよびレポートのデータインポート/エクスポートを記録します。一般に、これらのイベントは、アプリケーションデータコンテンツに関係なく、すべての保護されたリソースにとって一般的です。

4) Patient care data events - documenting what was done, by whom, using which resources, from what access points, and to whose medical data. In general, these audits are application-specific since they require knowledge of the application data content.

4) 患者ケアデータイベント - 何が行われたのか、誰がどのリソースを使用して、どのアクセスポイントから、およびその医療データに記録します。一般に、これらの監査はアプリケーションデータコンテンツの知識が必要なため、アプリケーション固有です。

Security subsystems found in most system infrastructures include a capability to capture system-level security relevant events like log-on and security object accesses. This document does not preclude such functions being enabled to record and supply the data defined in this document, but transformation of the collected data to the common XML schema definition may be necessary to support requirements consolidated auditing views.

ほとんどのシステムインフラストラクチャにあるセキュリティサブシステムには、ログオンやセキュリティオブジェクトアクセスなどのシステムレベルのセキュリティ関連イベントをキャプチャする機能が含まれます。このドキュメントは、このドキュメントで定義されたデータを記録および提供するようにそのような関数を排除することはできませんが、収集されたデータを一般的なXMLスキーマ定義に変換する必要がある場合があります。

Application-level events, such as patient record access, are not captured by system-level security audits. The defined data support applications' record access auditing for healthcare institutional security and privacy assurance plus related policy administration functions.

患者の記録アクセスなどのアプリケーションレベルのイベントは、システムレベルのセキュリティ監査ではキャプチャされません。定義されたデータは、ヘルスケア機関のセキュリティとプライバシー保証と関連する政策管理機能のための記録的なアクセス監査をサポートしています。

System-local data definitions for collection and storage of audit data, prior to transformation to a common schema and transmission to a common repository, are not included in this document.

共通のスキーマへの変換と共通リポジトリへの送信の前に、監査データの収集とストレージのシステム定義は、このドキュメントには含まれていません。

2.2. Anticipated Data End-uses
2.2. 予想されるデータエンドUSE

This document anticipates, but does not define, end-uses for the data collected.

このドキュメントは、収集されたデータのエンドUSEを予測しますが、定義しません。

The typical healthcare IT environment contains many systems from various vendors and developers who have not implemented common or interoperable security administrative functions. This document anticipates a requirement to transmit data from several unrelated systems to a common repository. It also anticipates the aggregated data which may then be queried and viewed in a variety of ways.

典型的なヘルスケアIT環境には、一般的または相互運用可能なセキュリティ管理機能を実装していないさまざまなベンダーや開発者の多くのシステムが含まれています。このドキュメントでは、いくつかの無関係なシステムから共通のリポジトリにデータを送信する要件が予想されます。また、集約されたデータが予想されており、その後、さまざまな方法で照会および表示される可能性があります。

There are distinctions of detail granularity, specificity, and frequency between audit data required for surveillance versus forensic purposes. While some surveillance data may be useful for forensics, the scope of this document is limited to surveillance.

監視と法医学目的に必要な監査データ間には、詳細な粒度、特異性、および頻度の違いがあります。一部の監視データは法医学に役立つ場合がありますが、このドキュメントの範囲は監視に限定されています。

This document does not address access real-time policy violation alarm actions. There is a perception in the healthcare community that security measures which inhibit access may also inhibit effective patient care, under some circumstances.

このドキュメントは、アクセスリアルタイムのポリシー違反アラームアクションには対応していません。ヘルスケアコミュニティでは、アクセスを阻害するセキュリティ対策も、状況によっては効果的な患者ケアを阻害する可能性があるという認識があります。

This document does not define any data for patient care consents or patients' permissions for data disclosure. It is conceivable that the proposed audit data could be input to such applications, however, assuming strict access controls for audit data have been established.

このドキュメントは、患者ケアの同意またはデータ開示の患者の許可に関するデータを定義しません。提案された監査データがそのようなアプリケーションに入力できると考えられますが、監査データの厳格なアクセス制御が確立されていると仮定します。

This document does not define system-specific or application-specific data that may be collected and reported in addition to the defined elements. For example, it is conceivable that audit mechanisms may be useful for tracking financial or payroll transactions. At the same time, this document does not preclude extending the XML schema to incorporate additional data.

このドキュメントは、定義された要素に加えて収集および報告される可能性のあるシステム固有またはアプリケーション固有のデータを定義しません。たとえば、監査メカニズムが金融または給与取引の追跡に役立つ可能性があると考えられます。同時に、このドキュメントは、XMLスキーマを拡張して追加データを組み込むことを妨げるものではありません。

There is a potential requirement for a set of administrative messages to be sent from a central source to each participating system to uniformly specify, control, enable, or disable audit data collection. Such messages are not included in this document.

中央のソースから各参加システムに一連の管理メッセージを送信するための潜在的な要件があり、監査データ収集を均一に指定、制御、有効化、または無効にします。このようなメッセージはこのドキュメントに含まれていません。

2.3. Conformance
2.3. 適合

This document does not include any definitions of conformance practices. Instead, it anticipates that standards development organizations that reference this document may specify their own conformance requirements.

このドキュメントには、適合慣行の定義は含まれていません。代わりに、この文書を参照する標準開発組織は、独自の適合要件を指定する可能性があると予想されます。

3. Goals
3. 目標
3.1. Effective Data Gathering
3.1. 効果的なデータ収集

The process of assuring that security policies are implemented correctly is essential to information security administration. It is a set of interrelated tasks all aimed at maintaining an acceptable level of confidence that security protections are, in fact, working as intended. These tasks are assisted by data from automated instrumentation of system and application functions.

セキュリティポリシーが正しく実装されていることを保証するプロセスは、情報セキュリティ管理に不可欠です。これは、セキュリティ保護が実際に意図したとおりに機能しているという許容レベルの信頼を維持することを目的とした相互に関連する一連のタスクです。これらのタスクは、システムおよびアプリケーション機能の自動化された機器からのデータによって支援されます。

Data gathered from a secured environment is used to accumulate evidence that security systems are working as intended and to detect incidents and patterns of misuse for further actions. Once messages have been collected, various reports may be created in support of security assurance and administration information requirements.

安全な環境から収集されたデータは、セキュリティシステムが意図したとおりに機能しているという証拠を蓄積し、さらなる行動のために誤用のパターンを検出するために使用されます。メッセージが収集されると、セキュリティ保証と管理情報の要件をサポートするために、さまざまなレポートが作成される場合があります。

When a site runs multiple heterogeneous applications, each application system may have its own security mechanisms - user log-on, roles, access right permissions and restrictions, etc. Each application system also has its own security log file that records security relevant events, e.g., log-in, data access, and updates to the security policy databases. A system administrator or security auditor must examine each of these log files to find security relevant incidents. Not only is it difficult to examine each of these files separately, the format and contents of each file may be confusingly different.

サイトが複数の不均一アプリケーションを実行すると、各アプリケーションシステムには独自のセキュリティメカニズムがあります - ユーザーログオン、ロール、アクセスの正しいアクセス許可、制限など。各アプリケーションシステムには、セキュリティ関連のイベントを記録する独自のセキュリティログファイルもあります。、ログイン、データアクセス、およびセキュリティポリシーデータベースの更新。システム管理者またはセキュリティ監査人は、これらの各ログファイルを調べて、セキュリティ関連のインシデントを見つける必要があります。これらの各ファイルを個別に調べることが難しいだけでなく、各ファイルの形式と内容が紛らわしいほど異なる場合があります。

Resolving these issues requires a framework to:

これらの問題を解決するには、以下のフレームワークが必要です。

- Maximize interoperability and the meaningfulness of data across applications and sites - Minimize ambiguity among heterogeneous systems - Simplify and limit the costs of administrative audit tasks.

- アプリケーションとサイト全体のデータの相互運用性と意味を最大化する - 不均一なシステム間の曖昧さを最小限に抑える - 管理監査タスクのコストを簡素化し、制限します。

3.2. Efficiency
3.2. 効率

One of the leading concerns about auditing is the potential volume of data gathering and its impact on application system performance. Although this document does not prescribe specific implementations or strategies, the following are meant as informative guidance for development.

監査に関する主要な懸念の1つは、データ収集の潜在的な量と、アプリケーションシステムのパフォーマンスへの影響です。このドキュメントは特定の実装や戦略を規定していませんが、以下は開発のための有益なガイダンスとして意図されています。

1) Audits should be created for transactions or record-level data access, not for individual attribute-level changes to data.

1) データの個々の属性レベルの変更ではなく、トランザクションまたはレコードレベルのデータアクセスに対して監査を作成する必要があります。

2) This document does not discourage locally optimized gathering of audit data on each application system. Instead, it anticipates implementation-defined periodic gathering and transmission of data to a common repository. This common repository would be optimized for after-the-fact audit queries and reporting, thus unburdening each application system of those responsibilities. It is also important to keep the message size compact so that audit data will not penalize normal network operation.

2) このドキュメントは、各アプリケーションシステム上の監査データの現地で最適化された収集を阻止しません。代わりに、実装定義の定期的な周期的な収集と一般的なリポジトリへのデータの送信が予想されます。この共通リポジトリは、事後の監査クエリとレポートのために最適化されるため、これらの責任の各アプリケーションシステムに負担をかけません。また、監査データが通常のネットワーク操作に罰せられないように、メッセージサイズをコンパクトに保つことも重要です。

3) On each application system, a variety of policy-based methods could be employed to optimize data gathering and storage, e.g., selective auditing of only events defined as important plus workload buffering and balancing. Data gathering itself should be stateless to avoid the overhead of transactional semantics. In addition, prior to transmission, some filtering, aggregation, and summarization of repeated events would reduce the number of messages. Audit data storage and integrity on each application system need only be scaled for relatively low-volume and short-duration requirements, yet be consistent with implementation-defined minimums for holding the data for subsequent collection.

3) 各アプリケーションシステムでは、さまざまなポリシーベースの方法を使用して、データ収集とストレージ、たとえば重要なワークロードバッファリングとバランスとして定義されたイベントのみの選択的監査を最適化するために使用できます。収集するデータ自体は、トランザクションセマンティクスのオーバーヘッドを避けるために無国籍でなければなりません。さらに、伝送の前に、繰り返しのイベントのフィルタリング、集約、および要約により、メッセージの数が減ります。各アプリケーションシステムの監査データストレージと整合性は、比較的少ない容量と短時間の要件に対してのみスケーリングする必要がありますが、後続のコレクションのデータを保持するための実装定義の最小値と一致する必要があります。

4) Leveraging existing data collection should be considered. For example, most commercial security subsystems record events in a local common log file, so the log file data can be extracted for communication to a common repository. Also, it is common in some systems' designs to have a transaction log for data reconstruction in event of database loss, so collecting data-update audit data within this subsystem could reduce impact on application system performance.

4) 既存のデータ収集を活用する必要があります。たとえば、ほとんどの商用セキュリティサブシステムは、ローカル共通のログファイルにイベントを記録するため、ログファイルデータを抽出して、共通リポジトリへの通信を抽出できます。また、一部のシステムの設計では、データベース損失が発生した場合にデータ再構築のためのトランザクションログを持つことが一般的であるため、このサブシステム内でデータアップデート監査データを収集すると、アプリケーションシステムのパフォーマンスへの影響を減らすことができます。

5) A security audit repository would gather all audit message data from the different applications in one database with one standard structure. This would allow easier evaluation and querying. Once a suspicious pattern has been found in the audit log repository, investigation might proceed with more detail in the application specific audit log. The presence of a common repository also simplifies and streamlines the implementation of policies for audit data storage, integrity, retention, and destruction.

5) セキュリティ監査リポジトリは、1つの標準構造を持つ1つのデータベース内のさまざまなアプリケーションからすべての監査メッセージデータを収集します。これにより、評価とクエリが簡単になります。監査ログリポジトリで疑わしいパターンが見つかったら、アプリケーション固有の監査ログで詳細を調査することができます。共通リポジトリの存在は、監査データストレージ、整合性、保持、および破壊のためのポリシーの実装を簡素化および合理化します。

4. Trigger Events
4. イベントをトリガーします

The following identifies representative trigger events for generating audit messages. This is not a complete list of trigger events.

以下は、監査メッセージを生成するための代表的なトリガーイベントを識別します。これは、トリガーイベントの完全なリストではありません。

For those events arising in the security infrastructure the "minimal" and "basic" level of auditing as outlined in the Common Criteria [ISO15408-2] should be used as a reference standard.

セキュリティインフラストラクチャで発生するイベントでは、共通基準[ISO15408-2]で概説されている「最小」および「基本」レベルの監査を参照標準として使用する必要があります。

4.1. Security Administration
4.1. セキュリティ管理

This group includes all actions that create, maintain, query, and display definitions for securing data, functions, and the associated access policies. For each trigger type, the creation, update or amendment, deletion, and activation or deactivation are auditable.

このグループには、データ、関数、および関連するアクセスポリシーを保護するための定義を作成、維持、クエリ、および表示するすべてのアクションが含まれます。各トリガータイプについて、作成、更新または修正、削除、アクティベーションまたは非アクティブ化が監査可能です。

4.1.1. Data Definition
4.1.1. データ定義

This includes creation, modification, deletion, query, and display of security attributes for data sets, data groups, or classes plus their atomic data elements or attributes.

これには、データセット、データグループ、またはクラスのセキュリティ属性の作成、変更、削除、クエリ、および原子データ要素または属性の作成が含まれます。

4.1.2. Function Definition
4.1.2. 関数定義

This includes, for example, creation, modification, deletion, query, or display of security attributes and auditable events for the application functions used for patient management, clinical processes, registry of business objects and methods, program creation and maintenance, etc.

これには、たとえば、患者管理、臨床プロセス、ビジネスオブジェクトとメソッドのレジストリ、プログラムの作成とメンテナンスなどに使用されるアプリケーション機能のセキュリティ属性および監査可能なイベントの作成、変更、削除、クエリ、または表示が含まれます。

4.1.3. Domain Definition
4.1.3. ドメイン定義

This includes all activities to create, modify, delete, query, or display security domains according to various organizational categories such as entity-wide, institutional, departmental, etc.

これには、エンティティ全体、機関、部門などのさまざまな組織カテゴリに従って、セキュリティドメインを作成、変更、削除、クエリ、または表示するすべてのアクティビティが含まれます。

4.1.4. Classification Definition
4.1.4. 分類定義

This includes all activities that create, modify, delete, query or display security categories or groupings for functions and data such as patient management, nursing, clinical, etc.

これには、患者管理、看護、臨床などの機能やデータのセキュリティカテゴリまたはグループを作成、変更、削除、クエリ、または表示するすべてのアクティビティが含まれます。

4.1.5. Permission Definition
4.1.5. 許可定義

This includes all activities that create, modify, delete, query or display the allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods.

これには、特定の機能ユニットまたはオブジェクトアクセスまたは操作方法の作成、読み取り、更新、削除、および実行など、関数とデータに関連付けられた許容アクセス許可を作成、変更、削除、クエリ、または表示するすべてのアクティビティが含まれます。

4.1.6. Role Definition
4.1.6. ロール定義

This includes all activities that create, modify, delete, query or display security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control.

これには、セキュリティ管理、入学机、看護師、医師、臨床専門家などのさまざまなタスクグループのカテゴリに従って、セキュリティの役割を作成、変更、削除、クエリ、または表示するすべてのアクティビティが含まれます。ロールベースのアクセス制御。

4.1.7. User Definition
4.1.7. ユーザー定義

This includes all activities that create, modify, delete, query, or display user accounts. It includes password or other authentication data. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control.

これには、ユーザーアカウントを作成、変更、削除、クエリ、または表示するすべてのアクティビティが含まれます。パスワードまたはその他の認証データが含まれています。また、役割ベースのアクセス制御のためのユーザーとの役割の関連付け、またはユーザーベースのアクセス制御のユーザーとのアクセスも含まれます。

4.2. Audit Administration and Data Access
4.2. 監査管理とデータアクセス

This category includes all actions that determine the collection and availability of audit data.

このカテゴリには、監査データの収集と可用性を決定するすべてのアクションが含まれます。

4.2.1. Auditable Event Enable or Disable
4.2.1. 監査可能なイベントを有効または無効にします

This reflects a basic policy decision that an event should or should not be audited. Some, but not necessarily all, triggers or use cases must create an audit record. The selection of what to audit depends on administrative policy decisions. Note that, for integrity, this event should always be audited.

これは、イベントを監査すべきであるか、すべきではないという基本的なポリシー決定を反映しています。必ずしもすべてではありませんが、トリガーまたはユースケースは監査レコードを作成する必要があります。監査対象の選択は、管理ポリシーの決定に依存します。整合性のために、このイベントは常に監査する必要があることに注意してください。

4.2.2. Audit Data Access
4.2.2. 監査データアクセス

This includes instances where audit data is viewed or reported for any purpose. Since the audit data itself may include data protected by institutional privacy policies and expose the implementation of those policies, access to the data is highly sensitive. This event should therefore always be audited.

これには、監査データがあらゆる目的で表示または報告されるインスタンスが含まれます。監査データ自体には、機関のプライバシーポリシーによって保護されたデータが含まれ、それらのポリシーの実装を公開する可能性があるため、データへのアクセスは非常に敏感です。したがって、このイベントは常に監査する必要があります。

4.2.3. Audit Data Modify or Delete
4.2.3. 監査データの変更または削除

This includes instances where audit data is modified or deleted. While such operations are sometimes permitted by systems policies, modification or destruction of audit data may well be the result of unauthorized hostile systems access. Therefore, this type of event should always be audited.

これには、監査データが変更または削除されるインスタンスが含まれます。このような操作はシステムポリシーによって許可されることがありますが、監査データの変更または破壊は、不正な敵対的なシステムアクセスの結果である可能性があります。したがって、このタイプのイベントは常に監査する必要があります。

4.3. User Access
4.3. ユーザーアクセス

This category includes events of access to secured data and functions for which audit data might be collected.

このカテゴリには、監査データが収集される可能性のある安全なデータと機能へのアクセスのイベントが含まれます。

4.3.1. Sign-On
4.3.1. 入社する

This includes successful and unsuccessful attempts from human users and automated system. It also includes re-authentication actions and re-issuing time-sensitive credentials such as Kerberos tickets.

これには、人間のユーザーと自動化されたシステムからの成功と失敗の試みが含まれます。また、再認証アクションと、Kerberosチケットなどの時間に敏感な資格情報の再発行も含まれます。

4.3.2. Sign-Off
4.3.2. サインオフ

This includes explicit sign-off events and session abandonment timeouts from human users and automated systems.

これには、明示的なサインオフイベントと、人間のユーザーと自動化されたシステムからのセッション放棄のタイムアウトが含まれます。

4.3.3. Function Access
4.3.3. 機能アクセス

This includes user invocation of application or system functions that have permission definitions associated with them. Note that in a Discretionary Access Control environment not all functions require permissions, especially if their impact is benign in relation to security policies.

これには、アプリケーションに関連付けられた許可定義があるアプリケーションまたはシステム機能のユーザー呼び出しが含まれます。裁量的アクセス制御環境では、特にセキュリティポリシーに関連してその影響が良性である場合、すべての関数が許可を必要とするわけではないことに注意してください。

The following are examples of trigger events relevant to healthcare privacy. The actual triggers for institutional data access, policies for non-care functions, and support regulatory requirements need to be identified by application-domain standards developers and system implementers.

以下は、ヘルスケアのプライバシーに関連するトリガーイベントの例です。機関のデータアクセスのための実際のトリガー、非ケア機能のポリシー、およびサポート規制要件は、アプリケーションドメイン標準開発者およびシステム実装者によって特定する必要があります。

4.3.3.1. Subject of Care Record Access
4.3.3.1. ケア記録アクセスの対象

This includes all functions which manipulate basic patient data:

これには、基本的な患者データを操作するすべての機能が含まれます。

- Create, e.g., demographics or patient profile - Assign identifier, e.g., medical record number - Update, amend - Merge/unmerge, e.g., combine multiple medical records for one patient - Import/export of data from/to an external source, including printing and creation of portable media copies. - Delete, e.g., invalid creation of care record

- たとえば、人口統計または患者プロファイルを作成 - 識別子を割り当て、医療記録番号 - 更新、修正 - マージ/マルジング、例えば、1人の患者の複数の医療記録を組み合わせて - 印刷を含む外部ソースからのデータの輸入/エクスポートポータブルメディアコピーの作成。 - たとえば、ケア記録の無効な作成を削除する

4.3.3.2. Encounter or Visit
4.3.3.2. 出会いや訪問

This includes all functions which associate a subject of care with an instance of care:

これには、ケアの主題をケアのインスタンスに関連付けるすべての機能が含まれます。

- Create, e.g., demographics or patient profile - Assign encounter identifier - Per-admit - Admit - Update, amend - Delete, e.g., invalid creation of encounter record, breakdown of equipment, patient did not arrive as expected

- たとえば、人口統計や患者プロファイルを作成 - 遭遇識別子を割り当てる - アドバイムごと - アドバイス - 更新、修正 - 削除、例えば、エンカウンター記録の無効な作成、機器の内訳、患者は期待どおりに到着しませんでした

4.3.3.3. Care Protocols
4.3.3.3. ケアプロトコル

This includes all functions which associate care plans or similar protocols with an instance or subject of care:

これには、ケアプランまたは同様のプロトコルをインスタンスまたはケアの主題に関連付けるすべての機能が含まれます。

- Schedule, initiate - Update, amend - Complete - Cancel

- スケジュール、開始 - 更新、修正 - 完了 - キャンセル

4.3.3.4. Episodes or Problems
4.3.3.4. エピソードまたは問題

This includes specific clinical episodes within an instance of care. Initiate:

これには、ケアのインスタンス内の特定の臨床エピソードが含まれます。開始する:

- Update, amend - Resolve, complete - Cancel

- 更新、修正 - 解決、完了 - キャンセル

4.3.3.5. Orders and Order Sets
4.3.3.5. 注文と注文セット

This includes clinical or supplies orders within an instance or episode of care:

これには、ケアのインスタンスまたはエピソード内の臨床または供給の注文が含まれます。

- Initiate - Update, amend - Check for contraindications - Verify - Deliver/complete - including instructions - Cancel

- 開始 - 更新、修正 - 禁忌のチェック - 検証 - 配信/完了 - 手順を含む - キャンセル

4.3.3.6. Health Service Event or Act
4.3.3.6. ヘルスサービスイベントまたはACT

This includes various health services scheduled and performed within an instance or episode of care:

これには、ケアのインスタンスまたはエピソード内で予定され、実行されるさまざまな医療サービスが含まれます。

- Schedule, initiate - Update, amend - Check for contraindications - Verify - Perform/complete - including instructions - Cancel

- スケジュール、開始 - 更新、修正 - 禁忌の確認 - 検証 - 実行/完了 - 指示を含む - キャンセル

4.3.3.7. Medications
4.3.3.7. 薬

This includes all medication orders and administration within an instance or episode of care:

これには、ケアのインスタンスまたはエピソード内でのすべての薬物の注文と管理が含まれます。

- Order - Check - Check for interactions - Verify - Dispense/deliver - including administration instructions - Administer - Cancel

- 注文 - チェック - インタラクションのチェック - 検証 - 分配/配信 - 管理指示を含む - 管理 - キャンセル

4.3.3.8. Staff/Participant Assignment
4.3.3.8. スタッフ/参加者の割り当て

This includes staffing or participant assignment actions relevant to an instance or episode of care:

これには、ケアのインスタンスまたはエピソードに関連する人員配置または参加者の割り当てアクションが含まれます。

- Assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. - Change in assigned role or authorization, e.g., relative to healthcare status change. - De-assignment

- 医療専門家、医師、居住者、医学生、コンサルタントなどの介護者の割り当て - 例えば、ヘルスケアの状況の変更に関連して、割り当てられた役割または承認の変更。 - 割り当て解除

5. Data Definitions
5. データ定義

This section defines and describes the data in the XML schema. The actual XML schema definition is in section 6.

このセクションでは、XMLスキーマのデータを定義および説明します。実際のXMLスキーマ定義はセクション6にあります。

The proposed data elements are grouped into these categories:

提案されたデータ要素は、これらのカテゴリにグループ化されます。

1) Event Identification - what was done 2) Active Participant Identification - by whom 3) Network Access Point Identification - initiated from where 4) Audit Source Identification - using which server 5) Participant Object Identification - to what record

1) イベントの識別 - 行われたこと

5.1. Event Identification
5.1. イベント識別

The following data identifies the name, action type, time, and disposition of the audited event. There is only one set of event identification data per audited event.

次のデータは、監査イベントの名前、アクションタイプ、時間、および処分を識別します。監査済みイベントごとにイベント識別データのセットは1つだけです。

5.1.1. Event ID
5.1.1. イベントID

Description

説明

Identifier for a specific audited event, e.g., a menu item, program, rule, policy, function code, application name, or URL. It identifies the performed function.

特定の監査済みイベントの識別子、たとえば、メニュー項目、プログラム、ルール、ポリシー、機能コード、アプリケーション名、またはURL。実行された関数を識別します。

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

Coded value, either defined by the system implementers or as a reference to a standard vocabulary. The "code" attribute must be unambiguous and unique, at least within Audit Source ID (see section 5.4). Examples of Event IDs are program name, method name, or function name.

システム実装者によって定義されるか、標準語彙への参照としてコード化された値。「コード」属性は、少なくとも監査ソースID内では、明確で一意でなければなりません(セクション5.4を参照)。イベントIDの例は、プログラム名、メソッド名、または機能名です。

For implementation defined coded values or references to standards, the XML schema defines these optional attributes:

実装が定義されたコード化された値または標準への参照について、XMLスキーマはこれらのオプションの属性を定義します。

         Attribute      Value
         -------------- --------------------------------------------
         CodeSystem     OID reference
         CodeSystemName Name of the coding system; strongly recommended
                        to be valued for locally-defined code-sets.
         DisplayName    The value to be used in displays and reports
         OriginalText   Input value that was translated to the code
        

To support the requirement for unambiguous event identification, multiple values may not be specified.

明確なイベント識別の要件をサポートするために、複数の値を指定しない場合があります。

Rationale

根拠

This identifies the audited function. For "Execute" Event Action Code audit records, this identifies the application function performed.

これにより、監査された関数が識別されます。「実行」イベントアクションコード監査レコードの場合、これは実行されたアプリケーション機能を識別します。

5.1.2. Event Action Code
5.1.2. イベントアクションコード

Description

説明

Indicator for type of action performed during the event that generated the audit.

監査を生成したイベント中に実行されるアクションの種類の指標。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Enumeration:

列挙:

         Value Meaning               Examples
         ----- --------------------- ----------------------------------
           C   Create                Create a new database object, such
                                     as Placing an Order.
           R   Read/View/Print/Query Display or print data, such as a
                                     Doctor Census
           U   Update                Update data, such as Revise
                                     Patient Information
           D   Delete                Delete items, such as a doctor
                                     master file record
           E   Execute               Perform a system or application
                                     function such as log-on, program
                                     execution, or use of an object's
                                     method
        

Rationale

根拠

This broadly indicates what kind of action was done on the Participant Object.

これは、参加者オブジェクトでどのようなアクションが行われたかを広く示しています。

Notes

ノート

Actions that are not enumerated above are considered an Execute of a specific function or object interface method or treated two or more distinct events. An application action, such as an authorization, is a function Execute, and the Event ID would identify the function.

上記のアクションは、特定の関数またはオブジェクトインターフェイスメソッドの実行または2つ以上の異なるイベントの実行と見なされます。認証などのアプリケーションアクションは関数実行であり、イベントIDは関数を識別します。

For some applications, such as radiological imaging, a Query action may only determine the presence of data but not access the data itself. Auditing need not make as fine a distinction.

放射線イメージングなどの一部のアプリケーションでは、クエリアクションはデータの存在のみを決定するだけでなく、データ自体にアクセスしない場合があります。監査は、それほどうまく区別する必要はありません。

Compound actions, such as "Move," would be audited by creating audit data for each operation - read, create, delete - or as an Execute of a function or method.

「移動」などの複合アクションは、各操作の監査データを作成することにより監査されます - 読み取り、作成、削除 - または関数またはメソッドの実行として。

5.1.3. Event Date/Time
5.1.3. イベント日/時刻

Description

説明

Universal coordinated time (UTC), i.e., a date/time specification that is unambiguous as to local time zones.

ユニバーサル調整時間(UTC)、つまり、現地時間ゾーンについては明確な日付/時刻の仕様。

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

A date/time representation that is unambiguous in conveying universal coordinated time (UTC), formatted according to the ISO 8601 standard [ISO8601]

ISO 8601標準[ISO8601]に従ってフォーマットされた、ユニバーサル調整時間(UTC)を伝える際に明確な日付/時刻表現

Rationale

根拠

This ties an event to a specific date and time. Security audits typically require a consistent time base, e.g., UTC, to eliminate time-zone issues arising from geographical distribution.

これは、イベントを特定の日付と時刻に結び付けます。セキュリティ監査では、通常、地理的分布から生じる時間帯の問題を排除するために、UTCなどの一貫した時間ベースが必要です。

Notes

ノート

In a distributed system, some sort of common time base, e.g., an NTP [RFC1305] server, is a good implementation tactic.

分散システムでは、ある種の一般的な時間ベース、たとえばNTP [RFC1305]サーバーは、優れた実装戦術です。

5.1.4. Event Outcome Indicator
5.1.4. イベント結果インジケーター

Description

説明

Indicates whether the event succeeded or failed.

イベントが成功したか失敗したかを示します。

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

Enumeration:

列挙:

      Value Meaning
       ---- ----------------------------------------------------
        0   Success
        4   Minor failure; action restarted, e.g., invalid password
            with first retry
        8   Serious failure; action terminated, e.g., invalid
            password with excess retries
       12   Major failure; action made unavailable, e.g., user
            account disabled due to excessive invalid log-on attempts
        

Rationale

根拠

Some audit events may be qualified by success or failure indicator. For example, a Log-on might have this flag set to a non-zero value to indicate why a log-on attempt failed.

一部の監査イベントは、成功または失敗の指標によって資格がある場合があります。たとえば、ログオンには、このフラグが非ゼロ値に設定されている場合があり、ログオンの試みが失敗した理由を示します。

Notes

ノート

In some cases a "success" may be partial, for example, an incomplete or interrupted transfer of a radiological study. For the purpose of establishing accountability, these distinctions are not relevant.

場合によっては、「成功」が部分的になる可能性があります。たとえば、放射線研究の不完全または中断された転送などです。説明責任を確立するために、これらの区別は関連していません。

5.1.5. Event Type Code
5.1.5. イベントタイプコード

Description

説明

Identifier for the category of event.

イベントのカテゴリの識別子。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Coded value enumeration, either defined by the system implementers or as a reference to a standard vocabulary. For implementation defined codes or references to standards, the XML schema defines these optional attributes:

システムの実装者によって定義されるか、標準語彙への参照としてコード化された値列挙。定義されたコードまたは標準への参照の実装については、XMLスキーマはこれらのオプションの属性を定義します。

         Attribute      Value
         -------------- --------------------------------------------
         CodeSystem     OID reference
         CodeSystemName Name of the coding system; strongly recommended
                        to be valued for locally-defined code-sets.
         DisplayName    The value to be used in displays and reports
         OriginalText   Input value that was translated to the code
        

Since events may be categorized in more than one way, there may be multiple values specified.

イベントは複数の方法で分類される可能性があるため、複数の値が指定されている場合があります。

Rationale

根拠

This field enables queries of messages by implementation-defined event categories.

このフィールドは、実装定義のイベントカテゴリによるメッセージのクエリを有効にします。

5.2. Active Participant Identification
5.2. アクティブな参加者の識別

The following data identify a user for the purpose of documenting accountability for the audited event. A user may be a person, or a hardware device or software process for events that are not initiated by a person.

次のデータは、監査済みイベントの説明責任を文書化する目的でユーザーを識別します。ユーザーは、人によって開始されないイベントの人、またはハードウェアデバイスまたはソフトウェアプロセスである場合があります。

Optionally, the user's network access location may be specified.

オプションで、ユーザーのネットワークアクセスの場所を指定できます。

There may be more than one user per event, for example, in cases of actions initiated by one user for other users, or in events that involve more than one user, hardware device, or system process. However, only one user may be the initiator/requestor for the event.

たとえば、1人のユーザーが他のユーザーに対して開始したアクションの場合、または複数のユーザー、ハードウェアデバイス、またはシステムプロセスを含むイベントなど、イベントごとに複数のユーザーが存在する場合があります。ただし、イベントのイニシエーター/リクエスト因子になる可能性のあるユーザーのみです。

5.2.1. User ID
5.2.1. ユーザーID

Description

説明

Unique identifier for the user actively participating in the event

イベントに積極的に参加するユーザーのためのユニークな識別子

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

User identifier text string from the authentication system. It is a unique value within the Audit Source ID (see section 5.4).

認証システムからのユーザー識別子テキスト文字列。これは、監査ソースID内の一意の値です(セクション5.4を参照)。

Rationale

根拠

This field ties an audit event to a specific user.

このフィールドは、監査イベントを特定のユーザーに結び付けます。

Notes

ノート

For cross-system audits, especially with long retention, this user identifier will permanently tie an audit event to a specific user via a perpetually unique key.

クロスシステム監査、特に長期にわたる保持の場合、このユーザー識別子は、永久にユニークなキーを介して特定のユーザーに監査イベントを永久に結びます。

For node-based authentication -- where only the system hardware or process, but not a human user, is identified -- User ID would be the node name.

ノードベースの認証の場合 - システムハードウェアまたはプロセスのみが人間のユーザーではない場合、ユーザーIDはノード名になります。

5.2.2. Alternative User ID
5.2.2. 代替ユーザーID

Description

説明

Alternative unique identifier for the user

ユーザー向けの代替ユニークな識別子

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

User identifier text string from authentication system. This identifier would be one known to a common authentication system (e.g., single sign-on), if available.

認証システムからのユーザー識別子テキスト文字列。この識別子は、利用可能な場合は、共通の認証システム(シングルサインオンなど)で知られているものです。

Rationale

根拠

In some situations a user may authenticate with one identity but, to access a specific application system, may use a synonymous identify. For example, some "single sign on" implementations will do this. The alternative identifier would then be the original identify used for authentication, and the User ID is the one known to and used by the application.

状況によっては、ユーザーは1つのIDで認証する場合がありますが、特定のアプリケーションシステムにアクセスするには、同義語識別を使用できます。たとえば、いくつかの「シングルサインオン」実装がこれを行います。代替識別子は、認証に使用される元の識別子となり、ユーザーIDはアプリケーションで既知および使用されているものです。

5.2.3. User Name
5.2.3. ユーザー名

Description

説明

The human-meaningful name for the user

ユーザーの人間の意味のある名前

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Text string

テキスト文字列

Rationale

根拠

The User ID and Alternative User ID may be internal or otherwise obscure values. This field assists the auditor in identifying the actual user.

ユーザーIDおよび代替ユーザーIDは、内部またはその他の不明瞭な値である場合があります。このフィールドは、監査人が実際のユーザーを特定するのを支援します。

5.2.4. User Is Requestor
5.2.4. ユーザーはrequestorです

Description

説明

Indicator that the user is or is not the requestor, or initiator, for the event being audited.

ユーザーが監査対象のイベントのリクエスター、またはイニシエーターであるか、イニシエーターではないことを示す指標。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Boolean, default/assumed value is "true"

ブール、デフォルト/想定値は「真」です

Rationale

根拠

This value is used to distinguish between requestor-users and recipient-users. For example, one person may initiate a report-output to be sent to a another user.

この値は、リクエスターユーザーとレシピエントユーザーを区別するために使用されます。たとえば、1人の人が別のユーザーに送信されるレポート出力を開始する場合があります。

5.2.5. Role ID Code
5.2.5. ロールIDコード

Description

説明

Specification of the role(s) the user plays when performing the event, as assigned in role-based access control security.

ロールベースのアクセス制御セキュリティに割り当てられているように、イベントを実行するときにユーザーが再生するロールの仕様。

Optionality: Optional; multi-valued

オプション:オプション。多値

Format / Values

フォーマット /値

Coded value, with attribute "code" valued with the role code or text from authorization system. More than one value may be specified.

認証システムからのロールコードまたはテキストで評価される属性「コード」を備えたコード化された値。複数の値が指定される場合があります。

The codes may be implementation-defined or reference a standard vocabulary enumeration. For implementation defined codes or references to standards, the XML schema defines these optional attributes:

コードは、実装定義であるか、標準の語彙列挙を参照する場合があります。定義されたコードまたは標準への参照の実装については、XMLスキーマはこれらのオプションの属性を定義します。

         Attribute      Value description
         -------------- --------------------------------------------
         CodeSystem     OID reference
         CodeSystemName Name of the coding system; strongly recommended
                        to be valued for locally-defined code-sets.
         Display Name   The value to be used in displays and reports
         OriginalText   Input value that was translated to the code
        

Rationale

根拠

This value ties an audited event to a user's role(s). It is an optional value that might be used to group events for analysis by user functional role categories.

この値は、監査されたイベントをユーザーの役割に結び付けます。これは、ユーザー機能の役割カテゴリによる分析のためにイベントをグループ化するために使用される可能性のあるオプションの値です。

Notes

ノート

Many security systems are unable to produce this data, hence it is optional.

多くのセキュリティシステムはこのデータを作成できないため、オプションです。

For the common message, this identifier would be the one known to a common authorization system, if available. Otherwise, it is a unique value within the Audit Source ID (see section 5.4). Consider using a globally unique identifier associated with the role to avoid ambiguity in auditing data collected from multiple systems.

一般的なメッセージの場合、この識別子は、利用可能な場合、一般的な認証システムに知られているものです。それ以外の場合は、監査ソースID内の一意の値です(セクション5.4を参照)。複数のシステムから収集されたデータの監査のあいまいさを避けるために、役割に関連付けられたグローバルに一意の識別子を使用することを検討してください。

Role ID is not a substitute for personal accountability.

役割IDは、個人的な説明責任に代わるものではありません。

Ambiguities arise from composite roles and users with multiple roles, i.e., which role within a composite is being used or what privilege was a user employing?

あいまいさは、複数の役割を持つ複合役割とユーザーから生じます。つまり、コンポジット内のどの役割が使用されていますか、またはユーザーが採用している特権は何ですか?

5.3. Network Access Point Identification
5.3. ネットワークアクセスポイント識別

The network access point identifies the logical network location for application activity. These data are paired 1:1 with the Active Participant Identification data.

ネットワークアクセスポイントは、アプリケーションアクティビティの論理ネットワークの場所を識別します。これらのデータは、アクティブな参加者識別データと1:1のペアリングされています。

5.3.1. Network Access Point Type Code
5.3.1. ネットワークアクセスポイントタイプコード

Description

説明

An identifier for the type of network access point that originated the audit event.

監査イベントを発信したネットワークアクセスポイントのタイプの識別子。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Enumeration:

列挙:

         Value Meaning
         ----- --------------------------------
           1   Machine Name, including DNS name
           2   IP Address
           3   Telephone Number
        

Rationale

根拠

This datum identifies the type of network access point identifier of the user device for the audit event. It is an optional value that may be used to group events recorded on separate servers for analysis of access according to a network access point's type.

このデータムは、監査イベントのユーザーデバイスのネットワークアクセスポイント識別子のタイプを識別します。これは、ネットワークアクセスポイントのタイプに従ってアクセスを分析するために、個別のサーバーに記録されたイベントをグループ化するために使用できるオプションの値です。

5.3.2. Network Access Point ID
5.3.2. ネットワークアクセスポイントID

Description

説明

An identifier for the network access point of the user device for the audit event. This could be a device id, IP address, or some other identifier associated with a device.

監査イベントのユーザーデバイスのネットワークアクセスポイントの識別子。これは、デバイスID、IPアドレス、またはデバイスに関連付けられたその他の識別子である可能性があります。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Text may be constrained to only valid values for the given Network Access Point Type, if specified. Recommendation is to be as specific as possible where multiple options are available.

テキストは、指定されている場合、指定されたネットワークアクセスポイントタイプの有効な値のみに制約される場合があります。推奨事項は、複数のオプションが利用可能な場合、可能な限り具体的にすることです。

Rationale

根拠

This datum identifies the user's network access point, which may be distinct from the server that performed the action. It is an optional value that may be used to group events recorded on separate servers for analysis of a specific network access point's data access across all servers.

このデータムは、ユーザーのネットワークアクセスポイントを識別します。これは、アクションを実行したサーバーとは異なる場合があります。これは、特定のネットワークアクセスポイントのデータアクセスをすべてのサーバーで分析するために、個別のサーバーに記録されたイベントをグループ化するために使用できるオプションの値です。

Note

注記

Network Access Point ID is not a substitute for personal accountability. Internet IP addresses, in particular, are highly volatile and may be assigned to more than one person in a short time period.

ネットワークアクセスポイントIDは、個人的な説明責任の代わりではありません。特に、インターネットIPアドレスは非常に不安定であり、短期間で複数の人に割り当てられる場合があります。

Examples

Network Access Point ID: SMH4WC02 Network Access Point Type: 1 = Machine Name

ネットワークアクセスポイントID:SMH4WC02ネットワークアクセスポイントタイプ:1 =マシン名

Network Access Point ID: 192.0.2.2 Network Access Point Type: 2 = IP address

ネットワークアクセスポイントID:192.0.2.2ネットワークアクセスポイントタイプ:2 = IPアドレス

Network Access Point ID: 610-555-1212 Network Access Point Type: 3 = Phone Number

ネットワークアクセスポイントID:610-555-1212ネットワークアクセスポイントタイプ:3 =電話番号

5.4. Audit Source Identification
5.4. 監査ソースの識別

The following data are required primarily for application systems and processes. Since multi-tier, distributed, or composite applications make source identification ambiguous, this collection of fields may repeat for each application or process actively involved in the event. For example, multiple value-sets can identify participating web servers, application processes, and database server threads in an n-tier distributed application. Passive event participants, e.g., low-level network transports, need not be identified.

次のデータは、主にアプリケーションシステムとプロセスに必要です。マルチ層、分散、または複合アプリケーションがソースの識別を曖昧にするため、このフィールドのコレクションは、イベントに積極的に関与する各アプリケーションまたはプロセスに対して繰り返される場合があります。たとえば、複数のバリューセットは、N層分散アプリケーションで参加するWebサーバー、アプリケーションプロセス、およびデータベースサーバースレッドを識別できます。パッシブイベント参加者、たとえば低レベルのネットワークトランスポートを特定する必要はありません。

Depending on implementation strategies, it is possible that the components in a multi-tier, distributed, or composite applications may generate more than one audit message for a single application event. Various data in the audit message may be used to identify such cases, supporting subsequent data reduction. This document anticipates that the repository and reporting mechanisms will perform data reduction when required, but does not specify those mechanism.

実装戦略に応じて、マルチ層、分散、または複合アプリケーションのコンポーネントが、単一のアプリケーションイベントに対して複数の監査メッセージを生成する可能性があります。監査メッセージのさまざまなデータを使用して、そのようなケースを識別し、その後のデータ削減をサポートする場合があります。このドキュメントは、リポジトリとレポートのメカニズムが必要な場合にデータ削減を実行するが、それらのメカニズムを指定しないことを予測しています。

5.4.1. Audit Enterprise Site ID
5.4.1. 監査エンタープライズサイトID

Description

説明

Logical source location within the healthcare enterprise network, e.g., a hospital or other provider location within a multi-entity provider group.

Healthcare Enterprise Network内の論理ソースの場所、たとえば、多施設プロバイダーグループ内の病院やその他のプロバイダーの場所。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Unique identifier text string within the healthcare enterprise. May be unvalued when the audit-generating application is uniquely identified by Audit Source ID.

ヘルスケア企業内の一意の識別子テキスト文字列。監査生成アプリケーションが監査ソースIDによって一意に識別される場合、無視される場合があります。

Rationale

根拠

This value differentiates among the sites in a multi-site enterprise health information system.

この値は、マルチサイトエンタープライズヘルス情報システムのサイト間で区別されます。

Notes

ノート

This is defined by the application that generates the audit record. It contains a unique code that identifies a business organization (owner of data) that is known to the enterprise. The value further qualifies and disambiguates the Audit Source ID. Values may vary depending on type of business. There may be levels of differentiation within the organization.

これは、監査レコードを生成するアプリケーションによって定義されます。エンタープライズに知られているビジネス組織(データの所有者)を識別する一意のコードが含まれています。この値は、監査ソースIDをさらに適格に分類します。値は、ビジネスの種類によって異なる場合があります。組織内に区別のレベルがある場合があります。

5.4.2. Audit Source ID
5.4.2. 監査ソースID

Description

説明

Identifier of the source where the event originated.

イベントが発生したソースの識別子。

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

Unique identifier text string, at least within the Audit Enterprise Site ID

少なくとも監査エンタープライズサイトID内で、一意の識別子テキスト文字列

Rationale

根拠

This field ties the event to a specific source system. It may be used to group events for analysis according to where the event occurred.

このフィールドは、イベントを特定のソースシステムに結び付けます。イベントが発生した場所に従って、分析のためのイベントをグループ化するために使用できます。

Notes

ノート

In some configurations, a load-balancing function distributes work among two or more duplicate servers. The values defined for this field thus may be considered as an source identifier for a group of servers rather than a specific source system.

一部の構成では、負荷バランス関数が2つ以上の複製サーバー間で作業を分散します。したがって、このフィールドで定義された値は、特定のソースシステムではなく、サーバーのグループのソース識別子と見なされる場合があります。

5.4.3. Audit Source Type Code
5.4.3. 監査ソースタイプコード

Description

説明

Code specifying the type of source where event originated.

イベントが発生したソースのタイプを指定するコード。

Optionality: Optional Format / Values

オプション:オプションの形式 /値

Coded-value enumeration, optionally defined by system implementers or a as a reference to a standard vocabulary. Unless defined or referenced, the default values for the "code" attribute are:

オプションでシステム実装者によって定義されているか、標準語彙への参照としてコード化された値の列挙。定義または参照されない限り、「コード」属性のデフォルト値は次のとおりです。

         Value  Meaning
         -----  ------------------------------------------------------
           1    End-user interface
           2    Data acquisition device or instrument
           3    Web server process tier in a multi-tier system
           4    Application server process tier in a multi-tier system
           5    Database server process tier in a multi-tier system
           6    Security server, e.g., a domain controller
           7    ISO level 1-3 network component
           8    ISO level 4-6 operating software
           9    External source, other or unknown type
        

For implementation defined codes or references to standards, the XML schema defines these optional attributes:

定義されたコードまたは標準への参照の実装については、XMLスキーマはこれらのオプションの属性を定義します。

         Attribute      Value
         -------------- --------------------------------------------
         CodeSystem     OID reference
         CodeSystemName Name of the coding system; strongly recommended
                        to be valued for locally-defined code-sets.
         DisplayName    The value to be used in displays and reports
         OriginalText   Input value that was translated to the code
        

Since audit sources may be categorized in more than one way, there may be multiple values specified.

監査ソースは複数の方法で分類される可能性があるため、複数の値が指定されている場合があります。

Rationale

根拠

This field indicates which type of source is identified by the Audit Source ID. It is an optional value that may be used to group events for analysis according to the type of source where the event occurred.

このフィールドは、監査ソースIDによってどのタイプのソースが識別されるかを示します。これは、イベントが発生したソースのタイプに従って分析のためのイベントをグループ化するために使用できるオプションの値です。

5.5. Participant Object Identification
5.5. 参加者オブジェクト識別

The following data assist the auditing process by indicating specific instances of data or objects that have been accessed.

次のデータは、アクセスしたデータまたはオブジェクトの特定のインスタンスを示すことにより、監査プロセスを支援します。

These data are required unless the values for Event Identification, Active Participant Identification, and Audit Source Identification are sufficient to document the entire auditable event. Production of audit records containing these data may be enabled or suppressed, as determined by healthcare organization policy and regulatory requirements.

これらのデータは、イベントの識別、アクティブな参加者の識別、および監査ソース識別の値が監査可能なイベント全体を文書化するのに十分でない限り必要です。これらのデータを含む監査記録の生産は、医療機関のポリシーと規制要件によって決定されるように、有効または抑制される場合があります。

Because events may have more than one participant object, this group can be a repeating set of values. For example, depending on institutional policies and implementation choices:

イベントには複数の参加者オブジェクトがある可能性があるため、このグループは繰り返しの値になる可能性があります。たとえば、制度のポリシーと実装の選択に応じて:

- Two participant object value-sets can be used to identify access to patient data by medical record number plus the specific health care encounter or episode for the patient. - A patient participant and his authorized representative may be identified concurrently. - An attending physician and consulting referrals may be identified concurrently. - All patients identified on a worklist may be identified. - For radiological studies, a set of related participant objects identified by accession number or study number, may be identified.

- 2人の参加者オブジェクトバリューセットを使用して、医療記録数と患者の特定のヘルスケアの遭遇またはエピソードで患者データへのアクセスを識別できます。 - 患者の参加者と彼の許可された代表者が同時に特定される場合があります。 - 主治医とコンサルティング紹介が同時に特定される場合があります。 - ワークリストで特定されたすべての患者が特定される場合があります。 - 放射線研究では、アクセッション番号または調査番号によって識別される関連する参加者オブジェクトのセットが特定される場合があります。

Note, though, that each audit message documents only a single usage instance of such participant object relationships and does not serve to document all relationships that may be present or possible.

ただし、各監査メッセージには、そのような参加者オブジェクト関係の単一の使用インスタンスのみが文書化されており、存在または可能な可能性のあるすべての関係を文書化するのに役立たないことに注意してください。

5.5.1. Participant Object Type Code
5.5.1. 参加者オブジェクトタイプコード

Description

説明

Code for the participant object type being audited. This value is distinct from the user's role or any user relationship to the participant object.

監査中の参加者オブジェクトタイプのコード。この値は、ユーザーの役割や参加者オブジェクトとのユーザー関係とは異なります。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Enumeration:

列挙:

         Value Meaning
         ----- -------------
           1   Person
           2   System Object
           3   Organization
           4   Other
        

Rationale

根拠

To describe the object being acted upon. In addition to queries on the subject of the action in an auditable event, it is also important to be able to query on the object type for the action.

作用中のオブジェクトを説明する。監査可能なイベントでのアクションのテーマに関するクエリに加えて、アクションのオブジェクトタイプを照会できることも重要です。

5.5.2. Participant Object Type Code Role
5.5.2. 参加者オブジェクトタイプコードの役割

Description

説明

Code representing the functional application role of Participant Object being audited

監査中の参加者オブジェクトの機能的アプリケーションの役割を表すコード

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Enumeration, specific to Participant Object Type Code:

参加者オブジェクトタイプコードに固有の列挙:

         Value Meaning              Participant Object Type Codes
         ----- -------------------- ----------------------------------
           1   Patient              1 - Person
           2   Location             3 - Organization
           3   Report               2 - System Object
           4   Resource             1 - Person
                                    3 - Organization
           5   Master file          2 - System Object
           6   User                 1 - Person
                                    2 - System Object (non-human user)
           7   List                 2 - System Object
           8   Doctor               1 - Person
           9   Subscriber           3 - Organization
          10   Guarantor            1 - Person
                                    3 - Organization
          11   Security User Entity 1 - Person
                                    2 - System Object
          12   Security User Group  2 - System Object
          13   Security Resource    2 - System Object
          14   Security Granularity 2 - System Object
               Definition
          15   Provider             1 - Person
                                    3 - Organization
          16   Data Destination     2 - System Object
          17   Data Repository      2 - System Object
          18   Schedule             2 - System Object
          19   Customer             3 - Organization
          20   Job                  2 - System Object
          21   Job Stream           2 - System Object
                   22   Table                2 - System Object
          23   Routing Criteria     2 - System Object
          24   Query                2 - System Object
        

A "Security Resource" is an abstract securable object, e.g., a screen, interface, document, program, etc. -- or even an audit data set or repository.

「セキュリティリソース」は、画面、インターフェイス、ドキュメント、プログラムなど、監査データセットまたはリポジトリなど、抽象的な証券化可能なオブジェクトです。

Rationale

根拠

For some detailed audit analysis it may be necessary to indicate a more granular type of participant, based on the application role it serves.

いくつかの詳細な監査分析では、それが提供するアプリケーションの役割に基づいて、より詳細なタイプの参加者を示す必要がある場合があります。

5.5.3. Participant Object Data Life Cycle
5.5.3. 参加者オブジェクトデータライフサイクル

Description

説明

Identifier for the data life-cycle stage for the participant object. This can be used to provide an audit trail for data, over time, as it passes through the system.

参加者オブジェクトのデータライフサイクルステージの識別子。これは、システムを通過するときに、時間の経過とともにデータの監査証跡を提供するために使用できます。

Optionality: Optional

オプション:オプション

Format/Values

フォーマット/値

Enumeration:

列挙:

         Value Meaning
         ----- --------------------------------------
           1   Origination / Creation
           2   Import / Copy from original
           3   Amendment
           4   Verification
           5   Translation
           6   Access / Use
           7   De-identification
           8   Aggregation, summarization, derivation
           9   Report
          10   Export / Copy to target
          11   Disclosure
          12   Receipt of disclosure
          13   Archiving
          14   Logical deletion
          15   Permanent erasure / Physical destruction
        

Rationale

根拠

Institutional policies for privacy and security may optionally fall under different accountability rules based on data life cycle. This provides a differentiating value for those cases.

プライバシーとセキュリティのための制度的ポリシーは、データのライフサイクルに基づいて、オプションで異なる説明責任ルールに該当する場合があります。これは、これらのケースに差別化値を提供します。

5.5.4. Participant Object ID Type Code
5.5.4. 参加者オブジェクトIDタイプコード

Description

説明

Describes the identifier that is contained in Participant Object ID.

参加者オブジェクトIDに含まれる識別子について説明します。

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

Coded-value enumeration, specific to Participant Object Type Code, using attribute-name "code". The codes below are the default set.

属性名「コード」を使用して、参加者オブジェクトタイプコードに固有のコード化値列挙列挙。以下のコードはデフォルトセットです。

         Value Meaning                Participant Object Type Codes
         ----- ---------------------- -----------------------------
           1   Medical Record Number  1 - Person
           2   Patient Number         1 - Person
           3   Encounter Number       1 - Person
           4   Enrollee Number        1 - Person
           5   Social Security Number 1 - Person
           6   Account Number         1 - Person
                                      3 - Organization
           7   Guarantor Number       1 - Person
                                      3 - Organization
           8   Report Name            2 - System Object
           9   Report Number          2 - System Object
           10  Search Criteria        2 - System Object
           11  User Identifier        1 - Person
                                      2 - System Object
           12  URI                    2 - System Object
        

User Identifier and URI [RFC2396] text strings are intended to be used for security administration trigger events to identify the objects being acted-upon.

ユーザー識別子とURI [RFC2396]テキスト文字列は、セキュリティ管理トリガーイベントに使用され、実行されているオブジェクトを識別することを目的としています。

The codes may be the default set stated above, implementation-defined, or reference a standard vocabulary enumeration, such as HL7 version 2.4 table 207 or DICOM defined media types. For implementation defined codes or references to standards, the XML schema defines these optional attributes:

コードは、上記のデフォルトセット、実装定義のデフォルトセットであるか、HL7バージョン2.4表207やDICOM定義されたメディアタイプなどの標準的な語彙列挙を参照する場合があります。定義されたコードまたは標準への参照の実装については、XMLスキーマはこれらのオプションの属性を定義します。

         Attribute      Value
         -------------- --------------------------------------------
         CodeSystem     OID reference
         CodeSystemName Name of the coding system; strongly recommended
                        to be valued for locally-defined code-sets.
         DisplayName    The value to be used in displays and reports
         OriginalText   Input value that was translated to the code
        

Rationale

根拠

Required to distinguish among various identifiers that may synonymously identify a participant object.

参加者オブジェクトを同義語的に識別する可能性のあるさまざまな識別子を区別するために必要です。

5.5.5. Participant Object Sensitivity
5.5.5. 参加者オブジェクトの感度

Description

説明

Denotes policy-defined sensitivity for the Participant Object ID such as VIP, HIV status, mental health status, or similar topics.

VIP、HIVステータス、メンタルヘルスステータス、または同様のトピックなど、参加者オブジェクトIDに対するポリシー定義の感度を示します。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Values are institution- and implementation-defined text strings.

値は、機関および実装定義のテキスト文字列です。

5.5.6. Participant Object ID
5.5.6. 参加者オブジェクトID

Description

説明

Identifies a specific instance of the participant object.

参加者オブジェクトの特定のインスタンスを識別します。

Optionality: Required

オプション性:必須

Format / Values

フォーマット /値

Text string. Value format depends on Participant Object Type Code and the Participant Object ID Type Code.

テキスト文字列。値形式は、参加者オブジェクトタイプコードと参加者オブジェクトIDタイプコードに依存します。

Rationale

根拠

This field identifies a specific instance of an object, such as a patient, to detect/track privacy and security issues.

このフィールドは、プライバシーとセキュリティの問題を検出/追跡するために、患者などのオブジェクトの特定のインスタンスを識別します。

Notes

ノート

Consider this to be the primary unique identifier key for the object, so it may be a composite data field as implemented.

これをオブジェクトの主要な一意の識別子キーであると考えてください。そうすれば、実装された複合データフィールドになる可能性があります。

5.5.7. Participant Object Name
5.5.7. 参加者オブジェクト名

Description

説明

An instance-specific descriptor of the Participant Object ID audited, such as a person's name.

人の名前など、参加者オブジェクトID監査のインスタンス固有の記述子。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Text string

テキスト文字列

Rationale

根拠

This field may be used in a query/report to identify audit events for a specific person, e.g., where multiple synonymous Participant Object IDs (patient number, medical record number, encounter number, etc.) have been used.

このフィールドは、特定の人の監査イベントを特定するためにクエリ/レポートで使用できます。

5.5.8. Participant Object Query
5.5.8. 参加者オブジェクトクエリ

Description

説明

The actual query for a query-type participant object.

クエリタイプの参加者オブジェクトの実際のクエリ。

Optionality: Optional

オプション:オプション

Format / Values

フォーマット /値

Base 64 encoded data

ベース64エンコードデータ

Rationale

根拠

For query events it may be necessary to capture the actual query input to the query process in order to identify the specific event. Because of differences among query implementations and data encoding for them, this is a base 64 encoded data blob. It may be subsequently decoded or interpreted by downstream audit analysis processing.

クエリイベントの場合、特定のイベントを識別するために、クエリプロセスへの実際のクエリ入力をキャプチャする必要がある場合があります。クエリの実装とそれらのデータエンコードの違いがあるため、これはベース64エンコードデータブロブです。その後、ダウンストリーム監査分析処理によって解釈または解釈される場合があります。

5.5.9. Participant Object Detail
5.5.9. 参加者オブジェクトの詳細

Description

説明

Implementation-defined data about specific details of the object accessed or used.

アクセスまたは使用されたオブジェクトの特定の詳細に関する実装定義データ。

Optionality: Optional

オプション:オプション

Format

フォーマット

Type-value pair. The "type" attribute is an implementation-defined text string. The "value" attribute is a base 64 encoded data.

タイプ値ペア。「タイプ」属性は、実装定義のテキスト文字列です。「値」属性は、ベース64エンコードデータです。

Rationale

根拠

Specific details or values from the object accessed may be desired in specific auditing implementations. The type-value pair enables the use of implementation-defined and locally-extensible object type identifiers and values. For example, a clinical diagnostic object may contain multiple test results, and this element could document the type and number and type of results.

アクセスしたオブジェクトからの特定の詳細または値は、特定の監査の実装で望まれる場合があります。タイプ値ペアは、実装定義と局所的に拡張可能なオブジェクトタイプの識別子と値を使用することを可能にします。たとえば、臨床診断オブジェクトには複数のテスト結果が含まれている場合があり、この要素は結果の種類と数とタイプを文書化できます。

Many possible data encodings are possible for this elements, so the value is a base 64 encoded data blob. It may be subsequently decoded or interpreted by downstream audit analysis processing.

この要素では多くの可能なデータエンコーディングが可能であるため、値はベース64エンコードデータブロブです。その後、ダウンストリーム監査分析処理によって解釈または解釈される場合があります。

6. XML Schema
6. XMLスキーマ

This section contains the actual XML schema definition for the data defined in section 5. It also provides brief guidance for specifying schema localizations for implementation purposes.

このセクションには、セクション5で定義されているデータの実際のXMLスキーマ定義が含まれています。また、実装目的でスキーマのローカリゼーションを指定するための簡単なガイダンスも提供します。

The XML schema specified in section 6.1 conforms with the W3C Recommendations for XML Schema structure [W3CXML-1] and data types [W3CXML-2].

セクション6.1で指定されたXMLスキーマは、XMLスキーマ構造[W3CXML-1]およびデータ型[W3CXML-2]のW3C推奨事項に準拠しています。

6.1. XML Schema Definition
6.1. XMLスキーマ定義
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="AuditMessage">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="EventIdentification"
     type="EventIdentificationType"/>
    <xs:element name="ActiveParticipant" maxOccurs="unbounded">
     <xs:complexType>
      <xs:complexContent>
       <xs:extension base="ActiveParticipantType"/>
      </xs:complexContent>
     </xs:complexType>
    </xs:element>
    <xs:element name="AuditSourceIdentification"
        
     type="AuditSourceIdentificationType" maxOccurs="unbounded"/>
    <xs:element name="ParticipantObjectIdentification"
     type="ParticipantObjectIdentificationType" minOccurs="0"
     maxOccurs="unbounded"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
 <xs:complexType name="EventIdentificationType">
  <xs:sequence>
   <xs:element name="EventID" type="CodedValueType"/>
   <xs:element name="EventTypeCode" type="CodedValueType"
    minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="EventActionCode" use="optional">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:enumeration value="C">
      <xs:annotation>
       <xs:appinfo>Create</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="R">
      <xs:annotation>
       <xs:appinfo>Read</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="U">
      <xs:annotation>
       <xs:appinfo>Update</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="D">
      <xs:annotation>
       <xs:appinfo>Delete</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="E">
      <xs:annotation>
       <xs:documentation>Execute</xs:documentation>
      </xs:annotation>
     </xs:enumeration>
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="EventDateTime" type="xs:dateTime"
   use="required"/>
  <xs:attribute name="EventOutcomeIndicator" use="required">
   <xs:simpleType>
        
    <xs:restriction base="xs:integer">
     <xs:enumeration value="0">
      <xs:annotation>
       <xs:appinfo>Success</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="4">
      <xs:annotation>
       <xs:appinfo>Minor failure</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="8">
      <xs:annotation>
       <xs:appinfo>Serious failure</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="12">
      <xs:annotation>
       <xs:appinfo>Major failure; action made unavailable
          </xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
 </xs:complexType>
 <xs:complexType name="AuditSourceIdentificationType">
  <xs:sequence>
   <xs:element name="AuditSourceTypeCode" minOccurs="0"
    maxOccurs="unbounded">
    <xs:complexType>
     <xs:complexContent>
      <xs:restriction base="CodedValueType">
       <xs:attribute name="code" use="required">
        <xs:simpleType>
         <xs:restriction base="xs:string">
          <xs:enumeration value="1">
           <xs:annotation>
            <xs:appinfo>End-user display device, diagnostic
             display</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="2">
           <xs:annotation>
            <xs:appinfo>Data acquisition device or
             instrument</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
        
          <xs:enumeration value="3">
           <xs:annotation>
            <xs:appinfo>Web server process</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="4">
           <xs:annotation>
            <xs:appinfo>Application server process</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="5">
           <xs:annotation>
            <xs:appinfo>Database server process</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="6">
           <xs:annotation>
            <xs:appinfo>Security server, e.g., a domain
             controller</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="7">
           <xs:annotation>
            <xs:documentation>ISO level 1-3 network
             component</xs:documentation>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="8">
           <xs:annotation>
            <xs:appinfo>ISO level 4-6 operating software</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="9">
           <xs:annotation>
            <xs:appinfo>External source, other or unknown
             type</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
         </xs:restriction>
        </xs:simpleType>
       </xs:attribute>
      </xs:restriction>
     </xs:complexContent>
    </xs:complexType>
   </xs:element>
  </xs:sequence>
  <xs:attribute name="AuditEnterpriseSiteID" type="xs:string"
   use="optional"/>
        
  <xs:attribute name="AuditSourceID" type="xs:string"
   use="required"/>
 </xs:complexType>
 <xs:complexType name="ActiveParticipantType">
  <xs:sequence minOccurs="0">
   <xs:element name="RoleIDCode" type="CodedValueType" minOccurs="0"
    maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="UserID" type="xs:string" use="required"/>
  <xs:attribute name="AlternativeUserID" type="xs:string"
   use="optional"/>
  <xs:attribute name="UserName" type="xs:string" use="optional"/>
  <xs:attribute name="UserIsRequestor" type="xs:boolean"
   use="optional" default="true"/>
  <xs:attribute name="NetworkAccessPointID" type="xs:string"
   use="optional"/>
  <xs:attribute name="NetworkAccessPointTypeCode" use="optional">
   <xs:simpleType>
    <xs:restriction base="xs:unsignedByte">
     <xs:enumeration value="1">
      <xs:annotation>
       <xs:appinfo>Machine Name, including DNS name</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="2">
      <xs:annotation>
       <xs:appinfo>IP Address</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="3">
      <xs:annotation>
       <xs:appinfo>Telephone Number</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
 </xs:complexType>
 <xs:complexType name="ParticipantObjectIdentificationType">
  <xs:sequence>
   <xs:element name="ParticipantObjectIDTypeCode">
    <xs:complexType>
     <xs:complexContent>
      <xs:restriction base="CodedValueType">
       <xs:attribute name="code" use="required">
        <xs:simpleType>
         <xs:restriction base="xs:string">
          <xs:enumeration value="1">
        
           <xs:annotation>
            <xs:appinfo>Medical Record Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="2">
           <xs:annotation>
            <xs:appinfo>Patient Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="3">
           <xs:annotation>
            <xs:appinfo>Encounter Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="4">
           <xs:annotation>
            <xs:appinfo>Enrollee Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="5">
           <xs:annotation>
            <xs:appinfo>Social Security Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="6">
           <xs:annotation>
            <xs:appinfo>Account Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="7">
           <xs:annotation>
            <xs:appinfo>Guarantor Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="8">
           <xs:annotation>
            <xs:appinfo>Report Name</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="9">
           <xs:annotation>
            <xs:appinfo>Report Number</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="10">
           <xs:annotation>
            <xs:appinfo>Search Criteria</xs:appinfo>
           </xs:annotation>
        
          </xs:enumeration>
          <xs:enumeration value="11">
           <xs:annotation>
            <xs:appinfo>User Identifier</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value="12">
           <xs:annotation>
            <xs:appinfo>URI</xs:appinfo>
           </xs:annotation>
          </xs:enumeration>
          <xs:enumeration value=""/>
         </xs:restriction>
        </xs:simpleType>
       </xs:attribute>
      </xs:restriction>
     </xs:complexContent>
    </xs:complexType>
   </xs:element>
   <xs:choice minOccurs="0">
    <xs:element name="ParticipantObjectName" type="xs:string"
     minOccurs="0"/>
    <xs:element name="ParticipantObjectQuery" type="xs:base64Binary"
     minOccurs="0"/>
   </xs:choice>
   <xs:element name="ParticipantObjectDetail"
    type="TypeValuePairType" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="ParticipantObjectID" type="xs:string"
   use="required"/>
  <xs:attribute name="ParticipantObjectTypeCode" use="optional">
   <xs:simpleType>
    <xs:restriction base="xs:unsignedByte">
     <xs:enumeration value="1">
      <xs:annotation>
       <xs:appinfo>Person</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="2">
      <xs:annotation>
       <xs:appinfo>System object</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="3">
      <xs:annotation>
       <xs:appinfo>Organization</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
        
     <xs:enumeration value="4">
      <xs:annotation>
       <xs:appinfo>Other</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="ParticipantObjectTypeCodeRole" use="optional">
   <xs:simpleType>
    <xs:restriction base="xs:unsignedByte">
     <xs:enumeration value="1">
      <xs:annotation>
       <xs:appinfo>Patient</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="2">
      <xs:annotation>
       <xs:appinfo>Location</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="3">
      <xs:annotation>
       <xs:appinfo> Report</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="4">
      <xs:annotation>
       <xs:appinfo>Resource</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="5">
      <xs:annotation>
       <xs:appinfo>Master file</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="6">
      <xs:annotation>
       <xs:appinfo>User</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="7">
      <xs:annotation>
       <xs:appinfo>List</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="8">
      <xs:annotation>
        
       <xs:appinfo>Doctor</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="9">
      <xs:annotation>
       <xs:appinfo>Subscriber</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="10">
      <xs:annotation>
       <xs:appinfo>Guarantor</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="11">
      <xs:annotation>
       <xs:appinfo>Security User Entity</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="12">
      <xs:annotation>
       <xs:appinfo>Security User Group</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="13">
      <xs:annotation>
       <xs:appinfo>Security Resource</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="14">
      <xs:annotation>
       <xs:appinfo>Security Granualarity Definition</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="15">
      <xs:annotation>
       <xs:appinfo>Provider</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="16">
      <xs:annotation>
       <xs:appinfo>Report Destination</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="17">
      <xs:annotation>
       <xs:appinfo>Report Library</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
        
     <xs:enumeration value="18">
      <xs:annotation>
       <xs:appinfo>Schedule</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="19">
      <xs:annotation>
       <xs:appinfo>Customer</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="20">
      <xs:annotation>
       <xs:appinfo>Job</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="21">
      <xs:annotation>
       <xs:appinfo>Job Stream</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="22">
      <xs:annotation>
       <xs:appinfo>Table</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="23">
      <xs:annotation>
       <xs:appinfo>Routing Criteria</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="24">
      <xs:annotation>
       <xs:appinfo>Query</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="ParticipantObjectDataLifeCycle" use="optional">
   <xs:simpleType>
    <xs:restriction base="xs:unsignedByte">
     <xs:enumeration value="1">
      <xs:annotation>
       <xs:appinfo>Origination / Creation</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="2">
      <xs:annotation>
        
       <xs:appinfo>Import / Copy from original </xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="3">
      <xs:annotation>
       <xs:appinfo>Amendment</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="4">
      <xs:annotation>
       <xs:appinfo>Verification</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="5">
      <xs:annotation>
       <xs:appinfo>Translation</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="6">
      <xs:annotation>
       <xs:appinfo>Access / Use</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="7">
      <xs:annotation>
       <xs:appinfo>De-identification</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="8">
      <xs:annotation>
       <xs:appinfo>Aggregation, summarization,
        derivation</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="9">
      <xs:annotation>
       <xs:appinfo>Report</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="10">
      <xs:annotation>
       <xs:appinfo>Export / Copy to target</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="11">
      <xs:annotation>
       <xs:appinfo>Disclosure</xs:appinfo>
      </xs:annotation>
        
     </xs:enumeration>
     <xs:enumeration value="12">
      <xs:annotation>
       <xs:appinfo>Receipt of disclosure</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="13">
      <xs:annotation>
       <xs:appinfo>Archiving</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="14">
      <xs:annotation>
       <xs:appinfo>Logical deletion</xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
     <xs:enumeration value="15">
      <xs:annotation>
       <xs:appinfo>Permanent erasure / Physical destruction
       </xs:appinfo>
      </xs:annotation>
     </xs:enumeration>
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="ParticipantObjectSensitivity" type="xs:string"
   use="optional"/>
 </xs:complexType>
 <xs:complexType name="CodedValueType">
  <xs:attribute name="code" type="xs:string" use="required"/>
  <xs:attributeGroup ref="CodeSystem"/>
  <xs:attribute name="displayName" type="xs:string" use="optional"/>
  <xs:attribute name="originalText" type="xs:string" use="optional"/>
 </xs:complexType>
 <xs:complexType name="TypeValuePairType">
  <xs:attribute name="type" type="xs:string" use="required"/>
  <xs:attribute name="value" type="xs:base64Binary" use="required"/>
 </xs:complexType>
 <xs:attributeGroup name="CodeSystem">
  <xs:attribute name="codeSystem" type="OID" use="optional"/>
  <xs:attribute name="codeSystemName" type="xs:string"
   use="optional"/>
 </xs:attributeGroup>
 <xs:simpleType name="OID">
  <xs:restriction base="xs:string">
   <xs:whiteSpace value="collapse"/>
  </xs:restriction>
 </xs:simpleType>
        
</xs:schema>
        
6.2. XML Schema Localization
6.2. XMLスキーマローカリゼーション

The schema specified in section 6.1 may be extended and restricted to meet local implementation-specific requirements. W3C Recommendation for XML Schema structure [W3CXML-1], section 4, is the governing standard for accomplishing this.

セクション6.1で指定されたスキーマは、拡張され、ローカルの実装固有の要件を満たすために制限される場合があります。XMLスキーマ構造[W3CXML-1]のW3C推奨、セクション4は、これを達成するための管理基準です。

As of the current version of this document, a public reference URI for the base schema has not been established.

このドキュメントの現在のバージョンの時点で、基本スキーマのパブリックリファレンスURIは確立されていません。

Local definitions reference the common audit message base schema. For example, here is a schema with a local vocabulary restriction for "Audit Enterprise Site ID" plus an extension adding a new "Audit Source Asset Number" element.

ローカル定義は、一般的な監査メッセージベーススキーマを参照します。たとえば、「監査エンタープライズサイトID」と新しい「監査ソースアセット番号」要素を追加する拡張機能のローカル語彙制限を備えたスキーマがあります。

The URI used to identify this schema (http://audit-message-uri) is a syntactically valid example that does not represent an actual schema. Schema validators might report an error when attempting to import a schema using this URI.

このスキーマ(http:// audit-message-uri)を識別するために使用されるURIは、実際のスキーマを表していない構文的に有効な例です。スキーマバリエーターは、このURIを使用してスキーマをインポートしようとするときにエラーを報告する場合があります。

<xs:schema xmlns:audit="http://audit-message-URI"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:import schemaLocation="http://audit-message-URI"/>
 <xs:complexType name="LocaAuditSourceIdentificationType">
  <xs:complexContent>
   <xs:restriction base="AuditSourceIdentificationType">
    <xs:attribute name="AuditEnterpriseSiteID" use="required">
     <xs:simpleType>
      <xs:restriction base="xs:string">
       <xs:enumeration value="Main"/>
       <xs:enumeration value="Clinic1"/>
       <xs:enumeration value="Clinic2"/>
       <xs:enumeration value="Radiology"/>
       <xs:enumeration value="Lab"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 <xs:element name="LocalAuditSourceIdentification">
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="LocaAuditSourceIdentificationType">
      <xs:attribute name="AuditSourceAssetNumber" type="xs:string"
        
       use="required"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>
</xs:schema>
        
7. Security Considerations
7. セキュリティに関する考慮事項

Audit data must be secured at least to the same extent as the underlying data and activities being audited. This includes access controls as well as data integrity and recovery functions. This document acknowledges the need for, but does not specify, the policies and technical methods to accomplish this.

監査データは、少なくとも基礎となるデータとアクティビティが監査されているのと同じ程度まで保護する必要があります。これには、アクセス制御とデータの整合性と回復機能が含まれます。このドキュメントは、これを達成するためのポリシーと技術的方法の必要性を認めていますが、指定していません。

It is conceivable that audit data might have unintended uses, e.g., tracking the frequency and nature of system use for productivity measures. ASTM standard E2147-01 [E2147] states, in paragraph 5.3.10, "Prohibit use for other reasons than to enforce security and to detect security breaches in record health information systems, for example, the audits are not to be used to explore activity profiles or movement profiles of employees."

監査データには意図しない用途がある可能性があると考えられます。たとえば、生産性測定のためのシステム使用の頻度と性質を追跡することです。ASTM標準E2147-01 [E2147]は、5.3.10項で、「セキュリティを実施し、記録的な健康情報システムのセキュリティ侵害を検出する以外の理由で使用を禁止しています。たとえば、監査はアクティビティを探索するために使用されません従業員のプロファイルまたは動きプロファイル。」

Some audit data arises from security-relevant processes other than data access. These are the trigger events listed in section 4.1 and 4.2 of this document. Audit data, defined in this document, can record the accountabilities for the results of these processes, as part of a complete security implementation. A discussion of the associated authorities, reference standards, and implementation technology choices for the processes is outside the scope of this document.

一部の監査データは、データアクセス以外のセキュリティ関連プロセスから生じます。これらは、このドキュメントのセクション4.1および4.2にリストされているトリガーイベントです。このドキュメントで定義されている監査データは、完全なセキュリティ実装の一部として、これらのプロセスの結果の説明責任を記録できます。関連する当局、参照基準、およびプロセスの実装技術の選択に関する議論は、このドキュメントの範囲外です。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[E2147] "E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems", ASTM International, June 2002.

[E2147]「E2147-01健康情報システムで使用するための監査および開示ログの標準仕様」、ASTM International、2002年6月。

[ISO15408-2] "ISO/IEC 15408:1999 Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements", ISO, August 1999.

[ISO15408-2]「ISO/IEC 15408:1999情報技術セキュリティ評価のための共通基準、パート2:セキュリティ機能要件」、ISO、1999年8月。

[ISO8601] "ISO 8601:2000 Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO, December 2000.

[ISO8601] "ISO 8601:2000データ要素と交換形式 - 情報交換 - 日付と時間の表現」、2000年12月ISO。

[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.

[RFC1305] Mills、D。、「ネットワークタイムプロトコル(バージョン3)仕様、実装」、RFC 1305、1992年3月。

[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers(URI):Generic Syntax」、RFC 2396、1998年8月。

[W3CXML-1] W3C Recommendation "XML Schema Part 1: Structures", version 1.0, May 2001.

[W3CXML-1] W3C推奨「XMLスキーマパート1:構造」、バージョン1.0、2001年5月。

[W3CXML-2] W3C Recommendation "XML Schema Part 2: Datatypes," version 1.0, May 2001.

[W3CXML-2] W3C推奨「XMLスキーマパート2:データ型」、バージョン1.0、2001年5月。

8.2. Informative References
8.2. 参考引用

[HL7SASIG] Marshall, G. and G. Dickinson, "Common Audit Message", HL7 Security and Accountability Special Interest Group, November 2001.

[HL7Sasig] Marshall、G。およびG. Dickinson、「Common Auditメッセージ」、HL7セキュリティおよび説明責任特別利益グループ、2001年11月。

[IHETF-3] "IHE Technical Framework", Volume III, HIMMS/RSNA, April 2002.

[IHETF-3]「IHE技術フレームワーク」、Volume III、Himms/RSNA、2002年4月。

[NEMASPC] "Security and Privacy Auditing in Health Care Information Technology", Joint NEMA/COCIR/JIRA Security and Privacy Committee, 26 June 2001.

[NEMASPC]「ヘルスケア情報技術におけるセキュリティとプライバシー監査」、共同NEMA/COCIR/JIRAセキュリティおよびプライバシー委員会、2001年6月26日。

Acknowledgments

謝辞

The author gratefully acknowledges the advice and assistance of the following people during the preparation of this document:

著者は、この文書の準備中に、次の人々のアドバイスと支援に感謝します。

Carmela Couderc, Siemens Medical Solutions Michael Davis, SAIC Gary Dickinson Christoph Dickmann, Siemens Medical Solutions Daniel Hannum, Siemens Medical Solutions Robert Horn, Agfa James McAvoy, Siemens Medical Solutions John Moehrke, General Electric Medical Systems Jennifer Puyenbroek, McKesson Information Solutions Angela Ray, McKesson Information Solutions Lawrence Tarbox, Siemens Corporate Research

Carmela Couderc、Siemens Medical Solutions Michael Davis、Saic Gary Dickinson Christoph Dickmann、Siemens Medical Solutions Daniel Hannum、Siemens Medical Solutions Robert Horn、Agfa James McAvoyMcKesson Information Solutions Lawrence Tarbox、Siemens Corporate Research

Author's Address

著者の連絡先

Glen Marshall Siemens Medical Solutions Health Services 51 Valley Stream Parkway Malvern, PA 19312 USA

グレンマーシャルシーメンスメディカルソリューションヘルスサービス51バレーストリームパークウェイマルバーン、ペンシルベニア州19312アメリカ

Phone: (610) 219-3938 EMail: glen.f.marshall@siemens.com

電話:(610)219-3938メール:glen.f.marshall@siemens.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004).

著作権(c)The Internet Society(2004)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78およびwww.rfc-editor.orgに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織(もしあれば)が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。ISOCドキュメントの権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。