Internet Draft G. Marshall
Document: draft-marshall-security-audit-02.doc Siemens
Expires: September 2003 March 2003
Security Audit and Access Accountability Message
Data Definitions for Healthcare Applications
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026[1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
To help assure healthcare privacy and security in automated systems,
usage data need to be collected. These data will be reviewed by
administrative staff to verify that healthcare data is being used in
accordance with the healthcare provider's data security requirements
and to establish accountability for data use. This review process is
called security auditing.
This document defines the format of the data to be collected and
minimum set of attributes that need to be captured by healthcare
application systems for subsequent use by an automation-assisted
review application. The data includes records of who accessed
healthcare data, when, for what action, from where, and which
patients' records were involved. The data definition is an XML
schema to be used as a reference by healthcare standards developers
and application designers.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119[2].
Marshall Expires - September 2003 [Page 1]
Security Audit and Access Accountability Message March 2003
Table of Contents
1. Purpose.......................................................2
2. Scope.........................................................3
2.1 Data Collection...........................................3
2.2 Anticipated Data End-uses.................................4
2.3 Conformance...............................................5
3. Goals.........................................................5
3.1 Effective Data Gathering..................................5
3.2 Efficiency................................................6
4. Trigger Events................................................7
4.1 Security Administration...................................7
4.2 Audit Administration and Data Access......................8
4.3 User Access...............................................9
5. Data Definitions.............................................11
5.1 Event Identification.....................................11
5.2 Active Participant Identification........................14
5.3 Network Access Point Identification......................17
5.4 Audit Source Identification..............................18
5.5 Participant Object Identification........................20
6. XML Schema Definition........................................27
7. Security Considerations......................................36
References......................................................36
Draft Change History............................................37
Acknowledgments.................................................38
Author's Addresses..............................................38
1. Purpose
The purposes the document fulfills are to:
1) Define data to be communicated for evidence of compliance with,
and violations of, a healthcare enterpriseÆs security and privacy
policies and objectives.
The focus of auditing in this document is to retrospectively
detect and report security/privacy breaches, versus directly
inhibiting access. This includes capturing data that supports
individual accountability for patient record creation, access,
updates, and deletions. It does not include real-time access
alarm actions since there is a perception in the healthcare
community that security measures that inhibit access may also
inhibit effective patient care, under some circumstances.
This document does not define healthcare security and privacy
policies or objectives.
Marshall Expires - September 2003 [Page 2]
Security Audit and Access Accountability Message March 2003
2) Depict the data that would potentially reside in a common audit
engine or database.
Privacy and security audit data is to be collected on each
hardware system, and there are likely to be separate local data
stores for system-level and application-level audits. Collating
these records and providing a common view û transcending hardware
system boundaries û is seen as necessary for cost-effective
security and privacy policy administration.
The data definitions support such a collation, but the technical
implementation alternatives are not covered in this document.
3) Depict data that allows useful queries against audited events.
Audit data, in its raw form, reflects a sequential view of system
activity. Useful inquiries for security and privacy
administration need workflow, business process, organizational,
role, and person-oriented views. Data definitions in this
document anticipate and support creating those views and queries,
but do not define them.
4) Provide a common reference standard for healthcare IT standards
development organizations.
This document consolidates previously disjoint viewpoints from
Health Level 7 (HL7)[3], Digital Imaging and Communications in
Medicine (DICOM) Working Group 14, Integrating the Healthcare
Enterprise (IHE)[4], the ASTM International Healthcare Informatics
Technical Committee (ASTM E31)[5], and the Joint NEMA/COCIR/JIRA
Security and Privacy Committee[6]. It is intended as a reference
for these four groups and other healthcare standards developers.
By specifying an XML schema, this document anticipates extensions
to the base schema to meet requirements of healthcare standards
bodies and application developers.
2. Scope
2.1 Data Collection
This document specifies audit data to be collected and communicated
from automated systems. It does not include non-automated processes.
Data for events in the above categories may be selectively collected,
based on healthcare organization policy. This document does not
specify any baseline or minimal policies.
Marshall Expires - September 2003 [Page 3]
Security Audit and Access Accountability Message March 2003
For each audited event, this document specifies the minimal data
requirements plus optional data for the following event categories:
1) Security administrative events û establishing and maintaining
security policy definitions, secured object definitions, role
definitions, user definitions, and the relationships among them.
In general, these events are specific to the administrative
applications.
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. In general, these events are generic to all protected
resources, without regard to the application data content.
4) Patient care data events û documenting what was done, by whom,
using which resources, from what access points, and to whose
medical data. In general, these audits are application-specific
since they require knowledge of the application data content.
Security subsystems found in most system infrastructures include a
capability to capture system-level security relevant events like
logon and security object accesses. This document does not preclude
such functions being enabled to record and supply the data defined in
this document, but transformation to conform to the common XML schema
definition will be required.
Application-level events, such as patient record access, are not
captured by system-level security audits. The defined data support
applicationsÆ record access auditing for healthcare institutional
security and privacy assurance plus related policy administration
functions.
System-local data definitions for collection and storage of audit
data, prior to transformation to a common schema and transmission to
a common repository, are not included in this document.
2.2 Anticipated Data End-uses
This document anticipates, but does not define, end-uses for the data
collected.
The typical healthcare IT environment contains many systems from
various vendors and developers who have not implemented common or
interoperable security administrative functions. This document
anticipates a requirement to transmit data from several unrelated
Marshall Expires - September 2003 [Page 4]
Security Audit and Access Accountability Message March 2003
systems to a common repository. It also anticipates the aggregated
data may then be queried and viewed an a variety of ways.
There are distinctions of detail granularity, specificity, and
frequency between audit data required for surveillance versus
forensic purposes. While some surveillance data may useful for
forensics, the scope of this document is limited to surveillance.
This document does not address access real-time policy violation
alarm actions. There is a perception in the healthcare community
that security measures that inhibit access may also inhibit effective
patient care, under some circumstances.
This document does not define any data for patient care consents or
patients' permissions for data disclosure. It is conceivable that
the proposed audit data could be input to such applications, however,
assuming strict access controls for audit data have been established.
This document does not define system-specific or application-specific
data that may be collected and reported in addition to the defined
elements. For example, it is conceivable that audit mechanisms may
be useful for tracking financial or payroll transactions. At the
same time, this document does not preclude extending the XML schema
to incorporate additional data.
There is a potential requirement for a set of administrative messages
to be sent from a central source to each participating system to
uniformly specify, control, enable, or disable audit data collection.
Such messages are not included in this document.
2.3 Conformance
This document does not include any definitions of conformance
practices. Instead, it anticipates that standards development
organizations that reference this document may specify their own
conformance requirements.
3. Goals
3.1 Effective Data Gathering
The process of assuring that security policies are implemented
correctly is essential to information security administration. It is
a set of interrelated tasks all aimed at maintaining an acceptable
level of confidence that security protections are, in fact, working
as intended. These tasks are assisted by data from automated
instrumentation of system and application functions.
Data gathered from a secured environment is used to accumulate
evidence that security systems are working as intended and to detect
Marshall Expires - September 2003 [Page 5]
Security Audit and Access Accountability Message March 2003
incidents and patterns of misuse for further actions. Once messages
have been collected, various reports may be created in support of
security assurance and administration information requirements.
When a site runs multiple heterogeneous applications, each
application system may have its own security mechanisms - user logon,
roles, access right permissions and restrictions, etc. Each
application system also has its own security log file that records
security relevant events, e.g., login, data access, and updates to
the security policy databases. A system administrator or security
auditor must examine each of these log files to find security
relevant incidents. Not only is it difficult to examine each of
these files separately, the format and contents of each file may be
confusingly different.
Resolving these issues requires a framework to:
- Maximize interoperability and the meaningfulness of data across
applications and sites
- Minimize ambiguity among heterogeneous systems
- Simplify and limits costs for administrative audit tasks.
3.2 Efficiency
One of the leading concerns about auditing is the potential volume of
data gathering and its impact on application system performance.
Although this document does not prescribe specific implementations or
strategies, the following are meant as informative guidance for
development.
1) Audits should be created for transactions or record-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
periodic gathering and transmission of data to a common
repository. This common repository would be optimized for after-
the-fact audit queries and reporting, thus unburdening each
application system of those responsibilities. It is also
important to keep the message size compact so that audit data will
not penalize normal network operation.
3) On each application system, a variety of policy-based methods
could be employed to optimize data gathering and storage, e.g.,
selective auditing of only events defined as important plus
workload buffering and balancing. Data gathering itself should be
stateless to avoid the overhead of transactional semantics. In
addition, prior to transmission, some summarization of repeated
events would reduce the number of messages. Audit data storage
Marshall Expires - September 2003 [Page 6]
Security Audit and Access Accountability Message March 2003
and integrity on each application system need only be scaled for
relatively low-volume and short-duration requirements.
4) Leveraging existing data collection should be considered. For
example, it is common is some systemsÆ designs to provide a
transaction log for data reconstruction in event of database loss.
Collecting audit data within this subsystem could reduce impact on
system performance.
5) A security audit repository would gather all audit message data
from the different applications in one database with one standard
structure. This would allow easier evaluation and querying. Once
a suspicious pattern has been found in the audit log repository,
investigation might proceed with more detail in the application
specific audit log. The presence of a common repository also
simplifies and streamlines the implementation of policies for
audit data storage, integrity, retention, and destruction.
4. Trigger Events
The following identifies trigger events for generating audit
messages. These should be viewed as application-level events. For
those events arising in the security infrastructure the "minimal" and
"basic" level of auditing as outlined in the Common Criteria[7]
should be used as a reference standard.
4.1 Security Administration
This group includes all actions that create and maintain definitions
for securing data, functions, and the associated access policies.
For each trigger type, the creation, update or amendment, and
activation or deactivation are auditable.
4.1.1 Data Definition
This includes data definitions for data sets, data groups, or classes
plus the atomic data elements or attributes.
4.1.2 Function Definition
This includes, for example, application function definitions for
patient management and clinical processes, registry of business
objects and methods, program creation and maintenance, etc.
4.1.3 Domain Definition
This includes all activities that create or modify security domains
according to various organizational categories such as entity-wide,
institutional, departmental, etc.:
Marshall Expires - September 2003 [Page 7]
Security Audit and Access Accountability Message March 2003
4.1.4 Classification Definition
This includes all activities that create or modify security
categories or groupings for functions and data such as patient
management, nursing, clinical, etc.
4.1.5 Permission Definition
This includes all activities that create or modify the allowable
access permissions associated with functions and data, such as
create, read, update, delete, and execution of specific functional
units or object access or manipulation methods.
4.1.6 Role Definition
This includes all activities that create or modify security roles
according to various task-grouping categories such as security
administration, admissions desk, nurses, physicians, clinical
specialists, etc. It also includes the association of permissions
with roles for role-based access control.
4.1.7 User Definition
This includes all activities that create or modify user accounts. It
also includes the association of roles with users for role-based
access control, or permissions with users for user-based access
control.
4.2 Audit Administration and Data Access
This category includes all actions that determine the collection and
availability of audit data.
4.2.1 Audit Enable or Disable
This reflects a basic policy decision that an event should or should
not be audited. Some, but not necessarily all, triggers or use cases
must create an audit record. The selection of what to audit depends
on administrative policy decisions. Note that, for integrity, this
event should always be audited.
4.2.2 Audit Data Access
This includes instances where audit data is viewed or reported for
any purpose. Since the audit data itself may include data protected
by institutional privacy policies and expose the implementation of
those policies, access to the data is highly sensitive. This event
should therefore always be audited.
Marshall Expires - September 2003 [Page 8]
Security Audit and Access Accountability Message March 2003
4.2.3 Audit Data Modify or Delete
This includes instance where audit data is modified or deleted. This
is a signature event for unauthorized hostile systems access. This
event should therefore always be audited.
4.3 User Access
This category includes 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.
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 associated with them. Note that in a
Discretionary Access Control environment not all functions require
permissions, especially if their impact is benign in relation to
policies.
The following items enumerate audit triggers that are relevant to
patient privacy. Additional triggers for institutional data access,
policies for non-care functions, and support regulatory requirements
will need to be identified by system implementers.
4.3.3.1 Subject of Care Record Access
This includes all functions which manipulate basic patient data:
- Create, e.g., demographics or patient profile
- Assign identifier, e.g., medical record number
- Update, amend
- Merge/unmerge, e.g., combine multiple medical records for one
patient
- Import/export of data from/to an external source, including
printing and creation of portable media copies.
Marshall Expires - September 2003 [Page 9]
Security Audit and Access Accountability Message March 2003
4.3.3.2 Encounter or Visit
This includes all functions which associate a subject of care with an
instance of care:
- Create, e.g., demographics or patient profile
- Assign encounter identifier
- Per-admit
- Admit
- Update, amend
4.3.3.3 Care Protocols
This includes all functions which associate care plans or similar
protocols with an instance or subject of care:
- Schedule, initiate
- Update, amend
- Complete
- Cancel
4.3.3.4 Episodes or Problems
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
- Complete
- 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
- Perform, complete
- Cancel
Marshall Expires - September 2003 [Page 10]
Security Audit and Access Accountability Message March 2003
4.3.3.7 Medications
This includes all medication orders and administration within an
instance or episode of care. These are distinct from orders and
events in the need to check for adverse interactions and to verify
the medications prior to delivery.
- Order
- Check
- Cancel interactions
- Verify
- Dispense/deliver û including administration instructions
- Administer
4.3.3.8 Staff Assignment
This includes staffing actions relevant to an instance or episode of
care.
- Assignment of healthcare professionals, caregivers attending
physician, residents, medical students, consultants, etc.
- Change in assigned role or authorization, e.g., relative to
healthcare status change.
- De-assignment
5. Data Definitions
This section defines and describes the data in the XML schema. The
actual XML schema definition is in section 6.
The proposed data elements are grouped into these categories:
1) Event Identification û what was done
2) Active Participant Identification û by whom
3) Network Access Point Identification û initiated from where
4) Audit Source Identification û using which server
5) Participant Object Identification û to what record
5.1 Event Identification
The following data identify 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
Required
Marshall Expires - September 2003 [Page 11]
Security Audit and Access Accountability Message March 2003
Identifier for a specific audited event, e.g., a menu item,
program, rule, policy, function code, or application name, or URL.
It identifies the performed function.
Format / Values
Identifier string for the function. This should be an unambiguous
code, unique, at least within Audit Source ID. Examples of Event
IDs are program name, method name, or function name.
Rationale
This field identifies the audited function. For analyzing
ôExecuteö Event Action Code audit records, this identifies the
application function performed.
5.1.2 Event Action Code
Description
Optional. Default value is "E".
Indicator for type of action performed during the event that
generated the audit.
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 information such as Revise
Patient Information
D Delete Delete items from a master file
such as a Doctor Record
E Execute Perform a system or application
function such as logon, program
execution, or use of an objectÆs
method.
Rationale
This broadly indicates what kind of action was done on the
Participant Object.
Marshall Expires - September 2003 [Page 12]
Security Audit and Access Accountability Message March 2003
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 should
identify the function. For compound actions, such as ôMove,ö
should 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
Required
Universal coordinated time (UTC), i.e. a date/time specification
that is unambiguous as to local time zones.
Format / Values
A date/time representation that is unambiguous in conveying
universal coordinated time (UTC)
Rationale
This ties an event to a specific date and time. Security audits
typically require a consistent time base, e.g., UTC, to eliminate
time-zone issues arising from geographical distribution.
Notes
In a distributed system, some sort of common time base, e.g., an
NTP[8]server, is a good implementation tactic.
5.1.4 Event Outcome Indicator
Description
Required
Indicates whether the event succeeded or failed.
Format / Values
Enumeration:
Value Meaning
---- ----------------------------------------------------
0 Success
Marshall Expires - September 2003 [Page 13]
Security Audit and Access Accountability Message March 2003
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 logon attempts
Rationale
Some audit events may be qualified by success or failure
indicator. For example, a Logon might have this flag set to a
non-zero value to indicate why a logon attempt failed.
5.2 Active Participant Identification
The following data identify a user for the purpose of documenting
personal accountability for the audited event. Optionally, the
userÆs network access location may be specified. There may be more
than one user per event, e.g., in cases of actions initiated by one
user for other users, however only one user may be the
initiator/requestor for the event.
5.2.1 User ID
Description
Required
Unique identifier for the user performing the event
Format / Values
Key from authentication system. It is a unique value within the
Audit Source ID.
Rationale
This field ties an audit event to a specific user.
Notes
For cross-system audits, especially with long retention, this user
identifier should permanently tie an audit event to a specific
user via a perpetually unique key.
Marshall Expires - September 2003 [Page 14]
Security Audit and Access Accountability Message March 2003
5.2.2 Alternative User ID
Description
Optional
Alternative unique identifier for the user performing the event.
Format / Values
Key from authentication system. This identifier should 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
Optional
The human-meaningful name for the user
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
Optional
Indicator that the user is or is not the requestor-actor for the
audit event.
Marshall Expires - September 2003 [Page 15]
Security Audit and Access Accountability Message March 2003
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 request a report-
output to be sent to a another user.
5.2.5 Role ID Code
Description
Optional, multi-valued
Specification of the role(s) the user plays when performing the
event, as assigned in role-based access control security
Format / Values
Coded value, with attribute "code" valued with the role code or
text from authorization system.
This may reference a standard enumeration. For such cases the XML
schema defines these optional attribute values:
Attribute Value
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system
DisplayName 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 should be the one known to
a common authorization system, if available. Otherwise, it is a
unique value within the Audit Source ID. Consider using a
Marshall Expires - September 2003 [Page 16]
Security Audit and Access Accountability Message March 2003
globally unique identifier associated with the role to avoid
ambiguity in auditing heterogeneous 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
Optional
An identifier for the type of network access point that originated
the audit event.
Format / Values
Enumeration:
Value Meaning
----- ----------------
1 Machine 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
Optional
Marshall Expires - September 2003 [Page 17]
Security Audit and Access Accountability Message March 2003
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.
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, 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 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: 10.10.203.42
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 server 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.
Marshall Expires - September 2003 [Page 18]
Security Audit and Access Accountability Message March 2003
5.4.1 Audit Enterprise Site ID
Description
Optional
Logical source location within the healthcare enterprise network,
e.g., a hospital or other provider location within a multi-entity
provider group.
This is configurable and 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 [disambiguates] the Audit
Source ID. Values may vary depending on type of business. There
may be levels of differentiation within the organization.
Format / Values
Unique identifier within the healthcare enterprise. Null value
when the system is uniquely identified by Audit Source ID.
Rationale
This value differentiates among the sites in a multi-site
enterprise health information system.
5.4.2 Audit Source ID
Description
Required
Identifier of the source where the event originated.
Format / Values
Unique identifier, 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
Marshall Expires - September 2003 [Page 19]
Security Audit and Access Accountability Message March 2003
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
Optional
Code specifying the type of source where event originated.
Format / Values
Enumeration:
Value Meaning
----- ------------------------------------------
1 End-user device
2 Web server process
3 Application server process
4 Database server process
5 Security server, e.g., a domain controller
6 ISO level 1-3 network component
7 ISO level 4-6 operating software
8 External source, unknown type
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 optional if the values for Event Identification,
Active Participant Identification, and Audit Source Identification
are sufficient to documents the entire auditable event. In addition,
the production audit records containing these data may be enabled or
not, as determined by healthcare organization policy and regulatory
requirements.
Marshall Expires - September 2003 [Page 20]
Security Audit and Access Accountability Message March 2003
Because events may have more than one participant, this group should
be considered 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.
5.5.1 Participant Object Type Code
Description
Optional
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.
Format / Values
Enumeration:
Value Meaning
----- -------------
1 Person
2 System Object
3 Organization
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 of that action.
5.5.2 Participant Object Type Code Role
Description
Optional
Code representing the functional application role of Participant
Object being audited
Marshall Expires - September 2003 [Page 21]
Security Audit and Access Accountability Message March 2003
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
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 Report Destination 2 û System Object
17 Report Library 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" an abstract securable object, e.g., a
screen, interface, document, program, etc.
Rationale
For some audit analysis it may be necessary to indicate a more
granular type of participant, based on the application role it
serves.
Marshall Expires - September 2003 [Page 22]
Security Audit and Access Accountability Message March 2003
5.5.3 Participant Object Data Life Cycle
Description
Optional
Identifier for the data life-cycle stage for the participant
object. This can be used to provide an audit trail for data, over
time, as it passes through the system
Format/Values
Enumeration:
Value Meaning
----- --------------------------------------
1 Origination
2 Amendment
3 Verification
4 Translation
5 Access / use
6 De-identification
7 Aggregation, summarization, derivation
8 Report
9 Disclosure
10 Receipt
11 Archiving
12 Destruction
Rationale
Institutional policies for privacy and security may optionally
fall under different accountability rules based on data life
cycle. This provides a differentiating value for those cases.
5.5.4 Participant Object ID Type Code
Description
Required
Describes the identifier that is contained in Participant Object
ID.
Marshall Expires - September 2003 [Page 23]
Security Audit and Access Accountability Message March 2003
Format / Values
Coded-value enumeration, specific to Participant Object Type Code,
using attribute-name "code":
code Meaning Participant Object Type Codes
---- ---------------------- -----------------------------
1 Medical record number 1 û Person
2 Patient number 1 û Person
3 Enrollee number 1 û Person
4 Social Security Number 1 û Person
5 Account number 1 û Person
3 û Organization
6 Guarantor ID 1 û Person
3 û Organization
7 Report Name 2 - System Object
8 Report Number 2 - System Object
9 Search Criteria 2 - System Object
10 User Identifier 1 - Person
2 - System Object
11 URI 2 - System Object
User Identifier and URI[9] values are intended to be used for
security administration trigger events to identify the objects
being acted-upon.
This enumeration may be a coded-value reference to a standard
enumeration, e.g., HL7 version 2 table 207. For such cases the
XML schema defines these optional attribute values:
Attribute Value
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
Rationale
Required to distinguish among various identifiers that may
synonymously identify a participant object.
5.5.5 Participant Object ID Sensitivity
Description
Optional
Marshall Expires - September 2003 [Page 24]
Security Audit and Access Accountability Message March 2003
Denotes policy-defined sensitivities for the Participant Object ID
such as VIP, HIV status, mental health status, or similar topics.
Format / Values
Values are institution and implementation defined text-strings.
5.5.6 Participant Object ID
Description
Required
Identifies a specific instance of the participant object
Format / Values
Text. 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, to detect/track privacy and security issues.
Notes
Consider this to be the primary unique identifier key for the
object, so it may be a composite data field as implemented.
5.5.7 Participant Object Name
Description
Optional
An instance-specific descriptor of the Participant Object ID
audited, such as a personÆs name
Format / Values
Free text
Rationale
This field may be used in a query/report to identify audit events
for a specific person, especially if multiple synonymous
Participant Object IDs have been used for that person.
Marshall Expires - September 2003 [Page 25]
Security Audit and Access Accountability Message March 2003
5.5.8 Participant Object Query String
Description
Optional
The actual query string for a query-type participant object.
Format / Values
Base 64 encoded data
Rationale
For query events it may be necessary to capture the actual query
string input the query process in order to identify the specific
event. It is a data blob, relative to auditing, that may be
decoded and interpreted by downstream audit analysis processing
Marshall Expires - September 2003 [Page 26]
Security Audit and Access Accountability Message March 2003
6. 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="AuditSourceIdentification"
type="AuditSourceIdentificationType" maxOccurs="unbounded"/>
<xs:element name="ActiveParticipant" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="ActiveParticipantType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="ParticipantObjectIdentification"
type="ParticipantObjectIdentificationType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="EventIdentificationType">
<xs:attribute name="EventID" type="xs:string" use="required"/>
<xs:attribute name="EventActionCode" use="optional" default="E">
<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">
Marshall Expires - September 2003 [Page 27]
Security Audit and Access Accountability Message March 2003
<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:attribute name="AuditEnterpriseSiteID" type="xs:string"
use="optional"/>
<xs:attribute name="AuditSourceID" type="xs:string"
use="required"/>
<xs:attribute name="AuditSourceTypeCode" use="optional">
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:enumeration value="1">
<xs:annotation>
<xs:appinfo>End-user device</xs:appinfo>
</xs:annotation>
</xs:enumeration>
Marshall Expires - September 2003 [Page 28]
Security Audit and Access Accountability Message March 2003
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>Web server process</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Application server process</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Database server process</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:appinfo>Security server, e.g., a domain controller
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:documentation>ISO level 1-3 network component
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="7">
<xs:annotation>
<xs:appinfo>ISO level 4-6 operating software</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:appinfo>External source, unknown type</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="ActiveParticipantType">
<xs:sequence minOccurs="0">
<xs:element name="RoleIDCode" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="CodedValueType">
<xs:attribute name="code" use="required"/>
</xs:restriction>
</xs:complexContent>
Marshall Expires - September 2003 [Page 29]
Security Audit and Access Accountability Message March 2003
</xs:complexType>
</xs:element>
</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</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="ParticpantObjectIDTypeCode"
type="CodedValueType"/>
<xs:choice minOccurs="0">
<xs:element name="ParticipantObjectName" type="xs:string"
minOccurs="0"/>
<xs:element name="ParticipantObjectQueryString"
type="xs:base64Binary" minOccurs="0"/>
</xs:choice>
</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">
Marshall Expires - September 2003 [Page 30]
Security Audit and Access Accountability Message March 2003
<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: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>
Marshall Expires - September 2003 [Page 31]
Security Audit and Access Accountability Message March 2003
<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>
Marshall Expires - September 2003 [Page 32]
Security Audit and Access Accountability Message March 2003
<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</xs:appinfo>
</xs:annotation>
Marshall Expires - September 2003 [Page 33]
Security Audit and Access Accountability Message March 2003
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>Amendment</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Verification</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Translation</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:appinfo>Access / Use</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:appinfo>De-identification</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="7">
<xs:annotation>
<xs:appinfo>Aggregation, summarization, derivation
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:appinfo>Report</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="9">
<xs:annotation>
<xs:appinfo>Disclosure</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="10">
<xs:annotation>
<xs:appinfo>Receipt</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="11">
<xs:annotation>
<xs:appinfo>Archiving</xs:appinfo>
Marshall Expires - September 2003 [Page 34]
Security Audit and Access Accountability Message March 2003
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="12">
<xs:annotation>
<xs:appinfo>Destruction</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ParticipantObjectIDSensitivity"
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: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>
Marshall Expires - September 2003 [Page 35]
Security Audit and Access Accountability Message March 2003
7. Security Considerations
Audit data must be secured at least to the same extent as the
underlying data and activities being audited. This includes access
controls as well as data integrity and recovery functions. This
document acknowledges the need for, but does not specify, the
policies and technical methods to accomplish this.
It is conceivable that audit data might have unintended uses, e.g.,
tracking the frequency and nature of system use for productivity
measures. ASTM standard E2147-01[5] states, in paragraph 5.3.10,
"Prohibit use for other reasons than to enforce security and to
detect security breaches in record health information systems, for
example, the audits are not to be used to explore activity profiles
or movement profiles of employees.ö
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Marshall, G., and Dickinson, G., "Common Audit Message", HL7
Security and Accountability Special Interest Group, November 2001
4 "IHE Technical Framework", Volume III, HIMMS/RSNA, April 2002
5 "E2147-01 Standard Specification for Audit and Disclosure Logs for
Use in Health Information Systems", ASTM International, June 2002
6 ôSecurity and Privacy Auditing in Health Care Information
Technologyö, Joint NEMA/COCIR/JIRA Security and Privacy Committee,
26 June 2001
7 "ISO/IEC 15408:1999 Common Criteria for Information Technology
Security Evaluation, Part 2: Security Functional Requirements",
ISO, August 1999
8 Mills, D., Network Time Protocol (Version 3) Specification,
Implementation, March 1992.
9 Berners-Lee, et. al., "Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998
Marshall Expires - September 2003 [Page 36]
Security Audit and Access Accountability Message March 2003
Draft Change History
Version Date Description
00 12/02 Original draft publication
01 02/03 1) Reword the Abstract to be more understandable to a
wider audience.
2) Revise Purpose and Scope and Data definition
sections for clarity, in accordance with comments
from several reviewers.
3) Document default value for Event Action Code.
4) Add Alternate User ID and User Name fields.
4) Include participant object identifier support for
objects of security administration trigger events.
5) Update XML schema to agree with data definitions.
02 03/03 1) Updated schema to make the "code" attribute in
CodedValueType a required value.
2) Minor wording changes to the Abstract for clarity.
3) Added reference to ôSecurity and Privacy Auditing
in Health Care Information Technologyö, by the
Joint NEMA/COCIR/JIRA Security and Privacy
Committee.
Marshall Expires - September 2003 [Page 37]
Security Audit and Access Accountability Message March 2003
Acknowledgments
The author gratefully acknowledges the advice and assistance of the
following people during the preparation of this document:
Carmela Couderc, Siemens Medical Solutions Health Services
Michael Davis, SAIC
Gary Dickinson, Per-Se Technologies, Inc.
Robert Horn, Agfa
James McAvoy, Siemens Medical Solutions Health Services
Jennifer Puyenbroek, McKesson Information Solutions
Angela Ray, McKesson Information Solutions
Larry Tarbox, Siemens Corporate Research
Author's Addresses
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
Marshall Expires - September 2003 [Page 38]