5) Participant Object Identification - to what record
5.1. Event Identification
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.
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
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.
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.
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
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.
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
The network access point identifies the logical network location for
application activity. These data are paired 1:1 with the Active
Participant Identification data.
5.3.1. Network Access Point Type Code
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
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.
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.
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
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.
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
Description
Logical source location within the healthcare enterprise network,
e.g., a hospital or other provider location within a multi-entity
provider group.
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.
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.
5.4.2. Audit Source 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
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.
5.4.3. Audit Source Type Code
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:
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.
5.5. Participant Object Identification
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.
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
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
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