Request for Comments: 3881 Siemens
Category: Informational September 2004
Security Audit and Access Accountability Message
XML Data Definitions for Healthcare Applications
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
IESG Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose, and notes that it has not had IETF review. The RFC Editor
has chosen to publish this document at its discretion.
Abstract
This document defines the format of data to be collected and minimum
set of attributes that need to be captured for security auditing in
healthcare application systems. The format is defined as an XML
schema, which is intended as a reference for healthcare standards
developers and application designers. It consolidates several
previous documents on security auditing of healthcare data.
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
To help assure healthcare privacy and security in automated systems,
usage data needs to be collected. This data will be reviewed by
administrative staff to verify that healthcare data is being used in
accordance with the healthcare provider’s data security requirements
and to establish accountability for data use. This data collection
and review process is called security auditing.
This document defines the format of the data to be collected and
minimum set of attributes that need to be captured by healthcare
application systems for subsequent use by an automation-assisted
review application. The data includes records of who accessed
healthcare data, when, for what action, from where, and which
patients’ records were involved. The data definition is an XML
schema to be used as a reference by healthcare standards developers
and application designers.
This document consolidates previously disjointed viewpoints of
security auditing from Health Level 7 (HL7) [HL7SASIG], Digital
Imaging and Communications in Medicine (DICOM) Working Group 14,
Integrating the Healthcare Enterprise (IHE) [IHETF-3], the ASTM
International Healthcare Informatics Technical Committee (ASTM E31)
[E2147], and the Joint NEMA/COCIR/JIRA Security and Privacy Committee
[NEMASPC]. It is intended as a reference for these groups and other
healthcare standards developers.
The purposes the document fulfills are to:
1) Define data to be communicated for evidence of compliance with, or
violations of, a healthcare enterprise’s security and privacy
policies and objectives.
This document defines the audit message format and content for
healthcare application systems. The focus of auditing is to
retrospectively detect and report security/privacy breaches. This
includes capturing data that supports individual accountability
for patient record creation, access, updates, and deletions.
This document does not define healthcare security and privacy
policies or objectives. It also does not include real-time access
alarm actions since there is a perception in the healthcare
community that security measures that inhibit access may also
inhibit effective patient care, under some circumstances.
2) Depict the data that would potentially reside in a common audit
engine or database.
Privacy and security audit data is to be collected on each
hardware system, and there are likely to be separate local data
stores for system-level and application-level audits. Collating
these records and providing a common view - transcending hardware
system boundaries - is seen as necessary for cost-effective
security and privacy policy administration.
The data definitions in this document support such a collation,
but the technical implementation alternatives are not covered in
this document.
3) Depict data that allows useful queries against audited events.
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.
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.
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
log-on and security object accesses. This document does not preclude
such functions being enabled to record and supply the data defined in
this document, but transformation of the collected data to the common
XML schema definition may be necessary to support requirements
consolidated auditing views.
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
systems to a common repository. It also anticipates the aggregated
data which may then be queried and viewed in 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 be useful for
forensics, the scope of this document is limited to surveillance.
This document does not address access real-time policy violation
alarm actions. There is a perception in the healthcare community
that security measures which inhibit access may also inhibit
effective patient care, under some circumstances.
This document does not define any data for patient care consents or
patients’ permissions for data disclosure. It is conceivable that
the proposed audit data could be input to such applications, however,
assuming strict access controls for audit data have been established.
This document does not define system-specific or application-specific
data that may be collected and reported in addition to the defined
elements. For example, it is conceivable that audit mechanisms may
be useful for tracking financial or payroll transactions. At the
same time, this document does not preclude extending the XML schema
to incorporate additional data.
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
incidents and patterns of misuse for further actions. Once messages
have been collected, various reports may be created in support of
security assurance and administration information requirements.
When a site runs multiple heterogeneous applications, each
application system may have its own security mechanisms - user log-
on, roles, access right permissions and restrictions, etc. Each
application system also has its own security log file that records
security relevant events, e.g., log-in, data access, and updates to
the security policy databases. A system administrator or security
auditor must examine each of these log files to find security
relevant incidents. Not only is it difficult to examine each of
these files separately, the format and contents of each file may be
confusingly different.
Resolving these issues requires a framework to:
- Maximize interoperability and the meaningfulness of data across
applications and sites
- Minimize ambiguity among heterogeneous systems
- Simplify and limit the costs of administrative audit tasks.
3.2. Efficiency
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-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. 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 filtering, aggregation, and
summarization of repeated events would reduce the number of
messages. Audit data storage and integrity on each application
system need only be scaled for relatively low-volume and short-
duration requirements, yet be consistent with implementation-
defined minimums for holding the data for subsequent collection.
4) Leveraging existing data collection should be considered. For
example, most commercial security subsystems record events in a
local common log file, so the log file data can be extracted for
communication to a common repository. Also, it is common in some
systems’ designs to have a transaction log for data reconstruction
in event of database loss, so collecting data-update audit data
within this subsystem could reduce impact on application system
performance.
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 representative trigger events for generating
audit messages. This is not a complete list of trigger events.
For those events arising in the security infrastructure the "minimal"
and "basic" level of auditing as outlined in the Common Criteria
[ISO15408-2] should be used as a reference standard.
4.1. Security Administration
This group includes all actions that create, maintain, query, and
display definitions for securing data, functions, and the associated
access policies. For each trigger type, the creation, update or
amendment, deletion, and activation or deactivation are auditable.
4.1.1. Data Definition
This includes creation, modification, deletion, query, and display of
security attributes for data sets, data groups, or classes plus their
atomic data elements or attributes.
4.1.2. Function Definition
This includes, for example, creation, modification, deletion, query,
or display of security attributes and auditable events for the
application functions used for patient management, clinical
processes, registry of business objects and methods, program creation
and maintenance, etc.
4.1.3. Domain Definition
This includes all activities to create, modify, delete, query, or
display security domains according to various organizational
categories such as entity-wide, institutional, departmental, etc.
4.1.4. Classification Definition
This includes all activities that create, modify, delete, query or
display security categories or groupings for functions and data such
as patient management, nursing, clinical, etc.
4.1.5. Permission Definition
This includes all activities that create, modify, delete, query or
display the allowable access permissions associated with functions
and data, such as create, read, update, delete, and execution of
specific functional units or object access or manipulation methods.
4.1.6. Role Definition
This includes all activities that create, modify, delete, query or
display security roles according to various task-grouping categories
such as security administration, admissions desk, nurses, physicians,
clinical specialists, etc. It also includes the association of
permissions with roles for role-based access control.
4.1.7. User Definition
This includes all activities that create, modify, delete, query, or
display user accounts. It includes password or other authentication
data. It also includes the association of roles with users for
role-based access control, or permissions with users for user-based
access control.
4.2. Audit Administration and Data Access
This category includes all actions that determine the collection and
availability of audit data.
4.2.1. Auditable Event 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.
4.2.3. Audit Data Modify or Delete
This includes instances where audit data is modified or deleted.
While such operations are sometimes permitted by systems policies,
modification or destruction of audit data may well be the result of
unauthorized hostile systems access. Therefore, this type of event
should always be audited.
4.3. User Access
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 system. It also includes re-authentication actions and
re-issuing 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 associated with them. Note that in a
Discretionary Access Control environment not all functions require
permissions, especially if their impact is benign in relation to
security policies.
The following are examples of trigger events relevant to healthcare
privacy. The actual triggers for institutional data access, policies
for non-care functions, and support regulatory requirements need to
be identified by application-domain standards developers and system
implementers.
4.3.3.1. Subject of Care Record Access
This includes all functions which manipulate basic patient data:
- Create, e.g., demographics or patient profile
- Assign identifier, e.g., medical record number
- Update, amend
- Merge/unmerge, e.g., combine multiple medical records for one
patient
- Import/export of data from/to an external source, including
printing and creation of portable media copies.
- Delete, e.g., invalid creation of care record
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
- 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 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
- 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
This includes staffing or participant assignment actions relevant to
an instance or episode of care:
- Assignment of healthcare professionals, caregivers attending
physician, residents, medical students, consultants, etc.
- Change in assigned role or authorization, e.g., relative to
healthcare status change.
- De-assignment
5. Data Definitions
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