RFC 3881

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

📅 published October 2004, from ietf

RFC 3881 🎀

okay bestie, this one is from G. Marshall at Siemens, filed in September 2004 🍓. It's an Informational doc, so it's just here to share knowledge with the internet crowd and isn't a standard. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own ✨. The title is Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications 💜.

Status of This Memo ✨

this memo gives info to the internet community. it doesn't specify an Internet standard of any kind 🙈. distribution is unlimited, so share it with your whole group chat 💅.

Copyright (C) The Internet Society (2004).

IESG Note 💀

ngl this one is a big disclaimer 😭. this RFC is not a candidate for any level of Internet Standard. the IETF says it doesn't know if this RFC is fit for any purpose, and it hasn't had IETF review. the RFC Editor chose to publish it at their own discretion 🫶.

Abstract 🦋

okay so this doc defines the format of the data you'd collect, plus the minimum set of attributes you need to capture for security auditing in healthcare application systems 🩺. the format is an XML schema, meant as a reference for healthcare standards developers and application designers 👑. it also brings together several earlier documents about security auditing of healthcare data, so it's basically the greatest hits album 🎶.

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 💖

okay so, to keep healthcare privacy and security safe in automated systems, you need to collect usage data 🔐. admin staff review this data to check that healthcare data is being used the way the provider's security rules say, and to make sure someone is accountable for how data gets used 🕵️‍♀️. this whole collect-and-review process is called security auditing ✨.

this document defines the format of the data to collect, plus the minimum set of attributes that healthcare application systems need to capture. the data is for later use by an automation-assisted review app 🤖. it covers who accessed healthcare data, when, for what action, from where, and which patients' records were involved 📋. the data definition is an XML schema, meant as a reference for healthcare standards developers and application designers 🎀.

this doc also brings together the different takes on 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's meant as a reference for these groups and other healthcare standards developers 🫶.

the purposes this document fulfills are:

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

this doc defines the audit message format and content for healthcare application systems 📝. auditing is all about looking back to detect and report security or privacy breaches 🔍. that includes capturing data that supports individual accountability for patient record creation, access, updates, and deletions 💜.

this doc does not define healthcare security and privacy policies or objectives 🙅‍♀️. it also doesn't include real-time access alarm actions. the healthcare community has a perception that security measures blocking access may also block effective patient care, under some circumstances 😬.

  1. Depict the data that would potentially reside in a common audit engine or database 🗄️.

privacy and security audit data is 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 into one common view, across hardware system boundaries, is seen as necessary for cost-effective security and privacy policy administration 💅.

the data definitions in this doc support that kind of collation, but the technical implementation alternatives are not covered here 🙈.

  1. Depict data that allows useful queries against audited events 🔎.

raw audit data is a sequential view of system activity 📜. useful inquiries for security and privacy admin need workflow, business process, organizational, role, and person-oriented views 🧩. the data definitions here anticipate and support creating those views and queries, but they don't define them 🦋.

  1. Provide a common reference standard for healthcare IT standards development organizations 👑.

by specifying an XML schema, this doc anticipates extensions to the base schema, so healthcare standards bodies and application developers can meet their own requirements 🌈.

2. Scope 🧚

2.1. Data Collection 🍓

this doc specifies the audit data to be collected and communicated from automated systems 🤖. it doesn't include non-automated processes 🙅‍♀️.

data for events in the categories below may be selectively collected, based on healthcare organization policy 🎯. this document doesn't specify any baseline or minimal policies 💅.

for each audited event, this doc specifies the minimal data requirements, plus optional data, for these event categories:

  1. Security administrative events: establishing and maintaining security policy definitions, secured object definitions, role definitions, user definitions, and the relationships among them 👑. generally, these events are specific to the administrative applications 🎀.
  2. Audit access events: reflecting special protections implemented for the audit trail itself 🔐.
  3. Security-mediated events: recording entity identification and authentication, data access, function access, nonrepudiation, cryptographic operations, and data import/export for messages and reports 🛡️. generally, these events are generic to all protected resources, no matter what the application data content is 🌸.
  4. Patient care data events: documenting what was done, by whom, using which resources, from what access points, and to whose medical data 🩺. generally, these audits are application-specific, since they need to know the application data content 💜.

security subsystems in most system infrastructures can capture system-level security relevant events, like log-on and security object accesses ✨. this document doesn't stop those functions from being turned on to record and supply the data defined here 🙌. but transforming the collected data into the common XML schema definition may be necessary to support consolidated auditing views 🔄.

application-level events, like patient record access, are not captured by system-level security audits 🙈. the defined data supports applications' record access auditing for healthcare institutional security and privacy assurance, plus related policy administration functions 🦋.

system-local data definitions for collecting and storing audit data, before it's transformed into a common schema and sent to a common repository, are not included in this document 📦.

2.2. Anticipated Data End-uses 🌈

this doc anticipates end-uses for the data collected, but doesn't define them 🔮.

the typical healthcare IT environment has lots of systems from different vendors and developers, and they haven't implemented common or interoperable security administrative functions 😭. this document anticipates a need to transmit data from several unrelated systems to a common repository 🗂️. it also anticipates that the aggregated data may then be queried and viewed in lots of different ways 👀.

there are differences in detail granularity, specificity, and frequency between audit data needed for surveillance and audit data needed for forensics 🔬. some surveillance data may be useful for forensics, but this document's scope is limited to surveillance 🎯.

this document doesn't address real-time policy violation alarm actions 🚫. the healthcare community has a perception that security measures which inhibit access may also inhibit effective patient care, under some circumstances 💅.

this document doesn't define any data for patient care consents or for patients' permissions to disclose data 📝. it's conceivable that the proposed audit data could be input to such applications, though, assuming strict access controls for audit data are in place 🔒.

this document doesn't define system-specific or application-specific data that might be collected and reported in addition to the defined elements 💡. for example, audit mechanisms may be useful for tracking financial or payroll transactions 💸. at the same time, this document doesn't stop the XML schema from being extended to add more data 🧩.

there's a potential need 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 📡. those messages aren't included in this document 🙅‍♀️.

2.3. Conformance 🎀

this document doesn't include any definitions of conformance practices ✨. instead, it expects that standards development organizations which reference this document may specify their own conformance requirements 👑.

3. Goals 🦋

to be continued in part 2, so stay tuned bestie 💜

3.1. Effective Data Gathering ✨

okay so security policies only matter if they're actually working, and checking that is a whole job 💅 It's a bunch of connected tasks, all aimed at keeping a solid level of confidence that the protections are really doing their thing. Automated instrumentation of system and application functions helps a ton with this 🔥

Data pulled from a secured environment is how you build up evidence that the security systems are working, and how you spot incidents and patterns of misuse so you can take action. Once the messages are collected, you can make all kinds of reports to support security assurance and admin needs 📊

Now, when a site runs several different applications, each one can have its own security stuff: user log-on, roles, access right permissions and restrictions, the works 🙈 Every app also keeps its own security log file that tracks security-relevant events, like log-in, data access, and updates to the security policy databases. A sysadmin or security auditor has to dig through every single one of those files to find the important incidents. Reading them one by one is exhausting, and the formats and contents can be confusingly different from file to file 😭

So we need a framework that can:

  • 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 🦋

okay the biggest worry with auditing is how much data you're gathering and how that hits application performance. This doc doesn't prescribe specific implementations or strategies, but the stuff below is informative guidance for development, bestie 🫶

  1. Audits should be created for transactions or record-level data access, not for individual attribute-level changes to data.
  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. That repository would be optimized for after-the-fact audit queries and reporting, so each application system doesn't have to carry those responsibilities. It's also important to keep the message size compact so audit data won't penalize normal network operation 🌸
  3. On each application system, a variety of policy-based methods could be used to optimize gathering and storage, like selectively auditing only events defined as important, plus workload buffering and balancing. Data gathering itself should be stateless to avoid the overhead of transactional semantics. Also, before transmission, filtering, aggregation, and summarization of repeated events would cut down the number of messages. Audit data storage and integrity on each application system only needs to be scaled for relatively low-volume and short-duration requirements, but it still has to be consistent with implementation-defined minimums for holding the data until it gets collected 💅
  4. Leveraging existing data collection should be considered. For example, most commercial security subsystems record events in a local common log file, so that log file data can be extracted and sent to a common repository. Also, a lot of systems have a transaction log for reconstructing data in case of database loss, so collecting data-update audit data inside that subsystem could reduce the impact on application system performance ✨
  5. A security audit repository would gather all audit message data from the different applications into one database with one standard structure. That makes evaluation and querying so much easier 🔥 Once a suspicious pattern shows up in the audit log repository, investigation might move on to more detail in the application-specific audit log. A common repository also simplifies and streamlines the implementation of policies for audit data storage, integrity, retention, and destruction 👑

4. Trigger Events 💜

Here are some representative trigger events for generating audit messages. This is not a complete list of trigger events, so don't treat it like one 🙈

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

4.1. Security Administration 🎀

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

4.1.1. Data Definition

This covers 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

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

4.1.3. Domain Definition

This covers all activities that create, modify, delete, query, or display security domains according to organizational categories like entity-wide, institutional, departmental, etc. 🌈

4.1.4. Classification Definition

This covers 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

This covers all activities that create, modify, delete, query, or display the allowable access permissions tied to functions and data, like create, read, update, delete, and execution of specific functional units or object access or manipulation methods 🦋

4.1.6. Role Definition

This covers all activities that create, modify, delete, query, or display security roles according to task-grouping categories like security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also covers associating permissions with roles for role-based access control 💖

4.1.7. User Definition

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

4.2. Audit Administration and Data Access 🍓

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

4.2.1. Auditable Event Enable or Disable

This is a basic policy decision about whether an event should or should not be audited. Some, but not necessarily all, triggers or use cases must create an audit record. What gets audited depends on administrative policy decisions. Note that, for integrity, this event should always be audited 🫶

4.2.2. Audit Data Access

This covers any instance where audit data is viewed or reported, for any purpose. The audit data itself may include data protected by institutional privacy policies and may expose how those policies are implemented, so access to it is highly sensitive. This event should therefore always be audited 👀

4.2.3. Audit Data Modify or Delete

This covers any instance where audit data is modified or deleted. Some systems policies do permit these operations, but modifying or destroying 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 🧚

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

4.3.1. Sign-On

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

4.3.2. Sign-Off

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

4.3.3. Function Access

This includes user invocation of application or system functions that have permission definitions attached. 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 for regulatory requirements need to be identified by application-domain standards developers and system implementers 💅

4.3.3.1. Subject of Care Record Access

This includes all functions that 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

4.3.3.2. Encounter or Visit

This includes all functions that 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

This includes all functions that 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

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

  • Update, amend
  • Resolve, complete
  • Cancel

4.3.3.5. Orders and Order Sets

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

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

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 ✨

okay so this one covers staffing or participant assignment actions that matter for an instance or episode of care 🩺 It's giving care team logistics, bestie:

  • 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 💅

okay this section is where the data gets defined and described in the XML schema 📋 The actual XML schema definition lives in section 6, so keep that in mind!

The data elements are grouped into five 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

5.1. Event Identification 🦋

this is the data that identifies the name, action type, time, and disposition of the audited event. There is only one set of event identification data per audited event, so no doubling up 🙅‍♀️

5.1.1. Event 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.

Optionality: Required

Format / Values

It's a coded value, either defined by the system implementers or 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.

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

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 💖

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.

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 ⭐

Description

Universal coordinated time (UTC), i.e., a date/time specification that is unambiguous as to local time zones. No time-zone confusion allowed, periodt 🌍

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]

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. ⏰

Notes

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

5.1.4. Event Outcome Indicator 🎀

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 🌈

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:

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 💜

this data identifies 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. 👑

5.2.1. User 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).

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. 🖥️

5.2.2. Alternative User 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. 🧩

5.2.3. User Name 💖

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. 🕵️‍♀️

5.2.4. User Is 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. 📨

5.2.5. Role ID Code 👑

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:

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. 🌍

Role ID is not a substitute for personal accountability. ⚠️

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 🌐

Okay so the network access point is the logical network location where the app activity is happening 📍. Every one of these is paired 1:1 with the Active Participant Identification data, so they always line up 💕.

5.3.1. Network Access Point Type Code

Description

This is 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 one tells you what kind of network access point identifier the user device has for the audit event. It's optional, but it can be used to group events recorded on separate servers so you can analyze access by the type of network access point. Very organized of it 🎀

5.3.2. Network Access Point ID

Description

This is the identifier for the network access point of the user device for the audit event 🖥️. It could be a device id, an IP address, or some other identifier tied to a device.

Optionality: Optional

Format / Values

Text may be constrained to only valid values for the given Network Access Point Type, if specified. The 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 different from the server that performed the action. It's optional, and it can be used to group events recorded on separate servers, so you can look at one specific network access point's data access across all the 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. Not the vibe for pinning something on one person, bestie 😭

Examples

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

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

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

5.4. Audit Source Identification 🔍

Okay, these data are required mainly for application systems and processes. Multi-tier, distributed, or composite apps can make the source kind of blurry, so this set of fields may repeat for each application or process actively involved in the event 🧩. For example, several value-sets can identify participating web servers, application processes, and database server threads in an n-tier distributed application. Passive event participants, like low-level network transports, don't need to be identified 🫶.

Depending on implementation strategies, the components in a multi-tier, distributed, or composite application may generate more than one audit message for a single application event. Various data in the audit message can be used to spot those cases so they can be reduced later 📊. This document expects the repository and reporting mechanisms to do data reduction when required, but it does not specify those mechanisms 🤷‍♀️.

5.4.1. Audit Enterprise Site ID

Description

This is the logical source location within the healthcare enterprise network, like a hospital or another provider location within a multi-entity provider group 🏥.

Optionality: Optional

Format / Values

A unique identifier text string within the healthcare enterprise. It may be unvalued when the audit-generating application is uniquely identified by Audit Source ID.

Rationale

This value tells apart 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 (the owner of the data) that is known to the enterprise. The value further qualifies and disambiguates the Audit Source ID. Values can vary depending on the type of business, and there may be levels of differentiation within the organization 🌸.

5.4.2. Audit Source ID

Description

This is the identifier of the source where the event originated 📡.

Optionality: Required

Format / Values

A unique identifier text string, at least within the Audit Enterprise Site ID.

Rationale

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

Notes

In some configurations, a load-balancing function spreads work across two or more duplicate servers. So the value defined for this field may be considered a source identifier for a group of servers, rather than one specific source system ⚖️.

5.4.3. Audit Source Type Code

Description

This is the code that specifies the type of source where the event originated 🏷️.

Optionality: Optional

Format / Values

This is a coded-value enumeration, optionally defined by system implementers or as a reference to a standard vocabulary. Unless it's 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:

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 can be categorized in more than one way, there may be multiple values specified 🎨.

Rationale

This field shows which type of source is identified by the Audit Source ID. It's optional, and it can be used to group events for analysis by the type of source where the event occurred 💜.

5.5. Participant Object Identification 🎯

The following data help the auditing process by showing the specific instances of data or objects that were accessed 👀.

These data are required unless the values for Event Identification, Active Participant Identification, and Audit Source Identification are enough to document the whole auditable event. Making audit records with these data can be turned on or off, depending on healthcare organization policy and regulatory requirements 📋.

Because events can 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 at the same time.
  • An attending physician and consulting referrals may be identified at the same time.
  • 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.

Note, though, that each audit message documents only a single usage instance of such participant object relationships. It doesn't document every relationship that may be present or possible 🙅‍♀️.

5.5.1. Participant Object Type Code

Description

This is the code for the participant object type being audited. It's separate 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

This describes the object being acted upon. Besides querying the subject of the action in an auditable event, it's also important to be able to query the object type for the action 🔎.

5.5.2. Participant Object Type Code Role

Description

This code represents the functional application role of the 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 🧚

Description

okay so this one is the "where has this data been??" field 💅 It's an identifier for the data life-cycle stage of the participant object, so you can build an audit trail for the data as it moves through the system over time. main character data journey, literally 🦋

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

ngl this is so useful 😭 Institutional privacy and security policies may optionally fall under different accountability rules based on the data life cycle, and this field gives those cases a differentiating value to work with 🎀

5.5.4. Participant Object ID Type Code 🔥

Description

This one describes the identifier that's contained in Participant Object ID, so you know what kind of ID you're even looking at 🙈

Optionality: Required

Format / Values

It's a coded-value enumeration that's specific to Participant Object Type Code, using the 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. so the admin stuff is where these two really shine ✨

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:

   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

This is required to distinguish among the various identifiers that may synonymously identify a participant object. like, the same person can have a bunch of different names in the system, and this is how you tell them apart 🫶

5.5.5. Participant Object Sensitivity 🌸

Description

This denotes policy-defined sensitivity for the Participant Object ID, such as VIP, HIV status, mental health status, or similar topics. very sensitive stuff, so handle with care 🤍

Optionality: Optional

Format / Values

Values are institution- and implementation-defined text strings 💜

5.5.6. Participant Object ID 💖

Description

This identifies a specific instance of the participant object 🎯

Optionality: Required

Format / Values

Text string. The value format depends on Participant Object Type Code and the Participant Object ID Type Code 🧁

Rationale

This field identifies a specific instance of an object, such as a patient, so privacy and security issues can be detected and tracked ✨

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 🎀

Description

This is an instance-specific descriptor of the Participant Object ID being audited, such as a person's name 🪪

Optionality: Optional

Format / Values

Text string 🌷

Rationale

This field may be used in a query or 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. so even when the IDs are all over the place, you can still find everything about one person 🕵️‍♀️💅

5.5.8. Participant Object Query 🦋

Description

This is the actual query for a query-type participant object 🔍

Optionality: Optional

Format / Values

Base 64 encoded data 🫧

Rationale

For query events it may be necessary to capture the actual query input to the query process, so the specific event can be identified 🎯 Because query implementations and data encodings differ from one another, this is a base 64 encoded data blob. It may be subsequently decoded or interpreted by downstream audit analysis processing 💀

5.5.9. Participant Object Detail 🧚‍♀️

Description

This is implementation-defined data about specific details of the object accessed or used 🍒

Optionality: Optional

Format

It's a type-value pair. The "type" attribute is an implementation-defined text string. The "value" attribute is base 64 encoded data 🌈

Rationale

Specific details or values from the object accessed may be wanted in certain auditing implementations 👀 The type-value pair lets you use 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 🧪

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

6. XML Schema 👑

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

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 Schema Definition 💜

<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"/>

okay bestie, we're deep in the XML schema now and it's giving drama 💅✨ The enums keep coming, and the last one is cut off mid-thought, so we'll pick up right there next part 🫶

  <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 🎀

okay so the schema in section 6.1 is totally extendable and restrictable so it fits your local setup 💅 the W3C XML Schema structure spec [W3CXML-1], section 4, is the rulebook for doing that bestie 📖

rn there's no public reference URI for the base schema yet 🥺

local definitions point back at the common audit message base schema 🦋 here's a super cute example that adds a local vocab restriction for "Audit Enterprise Site ID" AND an extension that adds a brand new "Audit Source Asset Number" element 🌸

the URI doing the identifying here (http://audit-message-uri) is just a syntactically valid example, it is NOT a real schema 🙈 so if your validator yells when it tries to import it, that's expected, not a bug, periodt 😭

<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 🔐

this part is SERIOUS bestie 😤 audit data must be secured at least as well as the stuff and activities it's auditing 🛡️ that includes access controls AND data integrity AND recovery functions 💜 this doc knows all of that matters but doesn't actually spell out the policies or the technical methods to pull it off 🥹

it's totally possible audit data gets used for stuff it was never meant for 👀 like tracking how often and how someone uses a system, just to measure productivity 💀 ASTM standard E2147-01 [E2147] says it best, 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." 🙅‍♀️ no spying on your coworkers' vibes, fr fr

some audit data comes from security-relevant processes that aren't about data access 🔑 those are the trigger events listed in section 4.1 and 4.2 of this document ✨ audit data (as defined here) can record who is accountable for the results of those processes, which is a big piece of a complete security setup 🫶 but the authorities, reference standards, and tech choices behind those processes? that's outside this document's scope, so go look elsewhere for that tea ☕

8. References 📚

8.1. Normative References 💖

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

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

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

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

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

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

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

8.2. Informative References 🌈

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

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

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

Acknowledgments 🫶

the author gratefully thanks these people for their advice and help while this doc was being prepared 💕

  • 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

Author's Address 🖊️

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

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

Copyright (C) The Internet Society (2004). 🌸

this doc is covered by the rights, licenses, and restrictions in BCP 78 (you can check www.rfc-editor.org for the details), and apart from what's set out there, the authors keep all their rights 💜

the document and the info in it come "AS IS," and the warranty stuff is serious, so here it is word for word 👇

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 doesn't take a side on whether any IP rights claimed around this tech are valid or how far they reach, and it doesn't claim to have done its own search for them either 🕵️‍♀️ if you want the ISOC rules on rights in ISOC Documents, check BCP 78 and BCP 79 📜

IPR disclosures sent to the IETF Secretariat, any promised licenses, and results of attempts to get a general license or permission for implementers and users are all in the IETF's online IPR repository at http://www.ietf.org/ipr 🗂️

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🙌 send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

funding for the RFC Editor function is currently coming from the Internet Society ✨

📦 where this page comes from