diff options
Diffstat (limited to 'doc/rfc/rfc3881.txt')
| -rw-r--r-- | doc/rfc/rfc3881.txt | 2635 |
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc3881.txt b/doc/rfc/rfc3881.txt new file mode 100644 index 0000000..f9bf6a3 --- /dev/null +++ b/doc/rfc/rfc3881.txt @@ -0,0 +1,2635 @@ + + + + + + +Network Working Group G. Marshall +Request for Comments: 3881 Siemens +Category: Informational September 2004 + + + Security Audit and Access Accountability Message + XML Data Definitions for Healthcare Applications + +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. + + + + + + + + + + + + + + + + + + +Marshall Informational [Page 1] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +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 + + + + + + +Marshall Informational [Page 2] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + + + +Marshall Informational [Page 3] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + + + +Marshall Informational [Page 4] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + + + +Marshall Informational [Page 5] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + +Marshall Informational [Page 6] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + +Marshall Informational [Page 7] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + +Marshall Informational [Page 8] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +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. + + + + + + + + + + +Marshall Informational [Page 9] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +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. + + + + + + +Marshall Informational [Page 10] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +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 + + + + + + + +Marshall Informational [Page 11] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +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 + + + + +Marshall Informational [Page 12] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +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 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 + + + + +Marshall Informational [Page 13] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + + + + + + +Marshall Informational [Page 14] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + +Marshall Informational [Page 15] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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: + + + + + + + + +Marshall Informational [Page 16] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + +Marshall Informational [Page 17] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + + + + + +Marshall Informational [Page 18] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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: + + + + + + + +Marshall Informational [Page 19] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + +Marshall Informational [Page 20] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + + +Marshall Informational [Page 21] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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. + + + + + + +Marshall Informational [Page 22] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + + +Marshall Informational [Page 23] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + + +Marshall Informational [Page 24] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + + + + + + + +Marshall Informational [Page 25] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + 14 Security Granularity 2 - System Object + Definition + 15 Provider 1 - Person + 3 - Organization + 16 Data Destination 2 - System Object + 17 Data Repository 2 - System Object + 18 Schedule 2 - System Object + 19 Customer 3 - Organization + 20 Job 2 - System Object + 21 Job Stream 2 - System Object + + + +Marshall Informational [Page 26] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 22 Table 2 - System Object + 23 Routing Criteria 2 - System Object + 24 Query 2 - System Object + + A "Security Resource" is an abstract securable object, e.g., a + screen, interface, document, program, etc. -- or even an audit + data set or repository. + + Rationale + + For some detailed audit analysis it may be necessary to indicate a + more granular type of participant, based on the application role + it serves. + +5.5.3. Participant Object Data Life Cycle + + Description + + Identifier for the data life-cycle stage for the participant + object. This can be used to provide an audit trail for data, over + time, as it passes through the system. + + Optionality: Optional + + Format/Values + + Enumeration: + + Value Meaning + ----- -------------------------------------- + 1 Origination / Creation + 2 Import / Copy from original + 3 Amendment + 4 Verification + 5 Translation + 6 Access / Use + 7 De-identification + 8 Aggregation, summarization, derivation + 9 Report + 10 Export / Copy to target + 11 Disclosure + 12 Receipt of disclosure + 13 Archiving + 14 Logical deletion + 15 Permanent erasure / Physical destruction + + + + + + +Marshall Informational [Page 27] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + 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 + + Describes the identifier that is contained in Participant Object + ID. + + Optionality: Required + + Format / Values + + Coded-value enumeration, specific to Participant Object Type Code, + using attribute-name "code". The codes below are the default set. + + Value Meaning Participant Object Type Codes + ----- ---------------------- ----------------------------- + 1 Medical Record Number 1 - Person + 2 Patient Number 1 - Person + 3 Encounter Number 1 - Person + 4 Enrollee Number 1 - Person + 5 Social Security Number 1 - Person + 6 Account Number 1 - Person + 3 - Organization + 7 Guarantor Number 1 - Person + 3 - Organization + 8 Report Name 2 - System Object + 9 Report Number 2 - System Object + 10 Search Criteria 2 - System Object + 11 User Identifier 1 - Person + 2 - System Object + 12 URI 2 - System Object + + User Identifier and URI [RFC2396] text strings are intended to be + used for security administration trigger events to identify the + objects being acted-upon. + + The codes may be the default set stated above, implementation- + defined, or reference a standard vocabulary enumeration, such as + HL7 version 2.4 table 207 or DICOM defined media types. For + implementation defined codes or references to standards, the XML + schema defines these optional attributes: + + + + +Marshall Informational [Page 28] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + Attribute Value + -------------- -------------------------------------------- + CodeSystem OID reference + CodeSystemName Name of the coding system; strongly recommended + to be valued for locally-defined code-sets. + DisplayName The value to be used in displays and reports + OriginalText Input value that was translated to the code + + Rationale + + Required to distinguish among various identifiers that may + synonymously identify a participant object. + +5.5.5. Participant Object Sensitivity + + Description + + Denotes policy-defined sensitivity for the Participant Object ID + such as VIP, HIV status, mental health status, or similar topics. + + Optionality: Optional + + Format / Values + + Values are institution- and implementation-defined text strings. + +5.5.6. Participant Object ID + + Description + + Identifies a specific instance of the participant object. + + Optionality: Required + + Format / Values + + Text string. Value format depends on Participant Object Type Code + and the Participant Object ID Type Code. + + 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. + + + +Marshall Informational [Page 29] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +5.5.7. Participant Object Name + + Description + + An instance-specific descriptor of the Participant Object ID + audited, such as a person's name. + + Optionality: Optional + + Format / Values + + Text string + + Rationale + + This field may be used in a query/report to identify audit events + for a specific person, e.g., where multiple synonymous Participant + Object IDs (patient number, medical record number, encounter + number, etc.) have been used. + +5.5.8. Participant Object Query + + Description + + The actual query for a query-type participant object. + + Optionality: Optional + + Format / Values + + Base 64 encoded data + + Rationale + + For query events it may be necessary to capture the actual query + input to the query process in order to identify the specific + event. Because of differences among query implementations and + data encoding for them, this is a base 64 encoded data blob. It + may be subsequently decoded or interpreted by downstream audit + analysis processing. + +5.5.9. Participant Object Detail + + Description + + Implementation-defined data about specific details of the object + accessed or used. + + + + +Marshall Informational [Page 30] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + Optionality: Optional + + Format + + Type-value pair. The "type" attribute is an implementation- + defined text string. The "value" attribute is a base 64 encoded + data. + + Rationale + + Specific details or values from the object accessed may be desired + in specific auditing implementations. The type-value pair enables + the use of implementation-defined and locally-extensible object + type identifiers and values. For example, a clinical diagnostic + object may contain multiple test results, and this element could + document the type and number and type of results. + + Many possible data encodings are possible for this elements, so + the value is a base 64 encoded data blob. It may be subsequently + decoded or interpreted by downstream audit analysis processing. + +6. XML Schema + + This section contains the actual XML schema definition for the data + defined in section 5. It also provides brief guidance for specifying + schema localizations for implementation purposes. + + The XML schema specified in section 6.1 conforms with the W3C + Recommendations for XML Schema structure [W3CXML-1] and data types + [W3CXML-2]. + +6.1. XML Schema Definition + +<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + <xs:element name="AuditMessage"> + <xs:complexType> + <xs:sequence> + <xs:element name="EventIdentification" + type="EventIdentificationType"/> + <xs:element name="ActiveParticipant" maxOccurs="unbounded"> + <xs:complexType> + <xs:complexContent> + <xs:extension base="ActiveParticipantType"/> + </xs:complexContent> + </xs:complexType> + </xs:element> + <xs:element name="AuditSourceIdentification" + + + +Marshall Informational [Page 31] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + type="AuditSourceIdentificationType" maxOccurs="unbounded"/> + <xs:element name="ParticipantObjectIdentification" + type="ParticipantObjectIdentificationType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + </xs:element> + <xs:complexType name="EventIdentificationType"> + <xs:sequence> + <xs:element name="EventID" type="CodedValueType"/> + <xs:element name="EventTypeCode" type="CodedValueType" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="EventActionCode" use="optional"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:enumeration value="C"> + <xs:annotation> + <xs:appinfo>Create</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="R"> + <xs:annotation> + <xs:appinfo>Read</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="U"> + <xs:annotation> + <xs:appinfo>Update</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="D"> + <xs:annotation> + <xs:appinfo>Delete</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="E"> + <xs:annotation> + <xs:documentation>Execute</xs:documentation> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + <xs:attribute name="EventDateTime" type="xs:dateTime" + use="required"/> + <xs:attribute name="EventOutcomeIndicator" use="required"> + <xs:simpleType> + + + +Marshall Informational [Page 32] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:restriction base="xs:integer"> + <xs:enumeration value="0"> + <xs:annotation> + <xs:appinfo>Success</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="4"> + <xs:annotation> + <xs:appinfo>Minor failure</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="8"> + <xs:annotation> + <xs:appinfo>Serious failure</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="12"> + <xs:annotation> + <xs:appinfo>Major failure; action made unavailable + </xs:appinfo> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + </xs:complexType> + <xs:complexType name="AuditSourceIdentificationType"> + <xs:sequence> + <xs:element name="AuditSourceTypeCode" minOccurs="0" + maxOccurs="unbounded"> + <xs:complexType> + <xs:complexContent> + <xs:restriction base="CodedValueType"> + <xs:attribute name="code" use="required"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:enumeration value="1"> + <xs:annotation> + <xs:appinfo>End-user display device, diagnostic + display</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="2"> + <xs:annotation> + <xs:appinfo>Data acquisition device or + instrument</xs:appinfo> + </xs:annotation> + </xs:enumeration> + + + +Marshall Informational [Page 33] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:enumeration value="3"> + <xs:annotation> + <xs:appinfo>Web server process</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="4"> + <xs:annotation> + <xs:appinfo>Application server process</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="5"> + <xs:annotation> + <xs:appinfo>Database server process</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="6"> + <xs:annotation> + <xs:appinfo>Security server, e.g., a domain + controller</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="7"> + <xs:annotation> + <xs:documentation>ISO level 1-3 network + component</xs:documentation> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="8"> + <xs:annotation> + <xs:appinfo>ISO level 4-6 operating software</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="9"> + <xs:annotation> + <xs:appinfo>External source, other or unknown + type</xs:appinfo> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + </xs:restriction> + </xs:complexContent> + </xs:complexType> + </xs:element> + </xs:sequence> + <xs:attribute name="AuditEnterpriseSiteID" type="xs:string" + use="optional"/> + + + +Marshall Informational [Page 34] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:attribute name="AuditSourceID" type="xs:string" + use="required"/> + </xs:complexType> + <xs:complexType name="ActiveParticipantType"> + <xs:sequence minOccurs="0"> + <xs:element name="RoleIDCode" type="CodedValueType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="UserID" type="xs:string" use="required"/> + <xs:attribute name="AlternativeUserID" type="xs:string" + use="optional"/> + <xs:attribute name="UserName" type="xs:string" use="optional"/> + <xs:attribute name="UserIsRequestor" type="xs:boolean" + use="optional" default="true"/> + <xs:attribute name="NetworkAccessPointID" type="xs:string" + use="optional"/> + <xs:attribute name="NetworkAccessPointTypeCode" use="optional"> + <xs:simpleType> + <xs:restriction base="xs:unsignedByte"> + <xs:enumeration value="1"> + <xs:annotation> + <xs:appinfo>Machine Name, including DNS name</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="2"> + <xs:annotation> + <xs:appinfo>IP Address</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="3"> + <xs:annotation> + <xs:appinfo>Telephone Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + </xs:complexType> + <xs:complexType name="ParticipantObjectIdentificationType"> + <xs:sequence> + <xs:element name="ParticipantObjectIDTypeCode"> + <xs:complexType> + <xs:complexContent> + <xs:restriction base="CodedValueType"> + <xs:attribute name="code" use="required"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:enumeration value="1"> + + + +Marshall Informational [Page 35] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:annotation> + <xs:appinfo>Medical Record Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="2"> + <xs:annotation> + <xs:appinfo>Patient Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="3"> + <xs:annotation> + <xs:appinfo>Encounter Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="4"> + <xs:annotation> + <xs:appinfo>Enrollee Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="5"> + <xs:annotation> + <xs:appinfo>Social Security Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="6"> + <xs:annotation> + <xs:appinfo>Account Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="7"> + <xs:annotation> + <xs:appinfo>Guarantor Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="8"> + <xs:annotation> + <xs:appinfo>Report Name</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="9"> + <xs:annotation> + <xs:appinfo>Report Number</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="10"> + <xs:annotation> + <xs:appinfo>Search Criteria</xs:appinfo> + </xs:annotation> + + + +Marshall Informational [Page 36] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + </xs:enumeration> + <xs:enumeration value="11"> + <xs:annotation> + <xs:appinfo>User Identifier</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="12"> + <xs:annotation> + <xs:appinfo>URI</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value=""/> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + </xs:restriction> + </xs:complexContent> + </xs:complexType> + </xs:element> + <xs:choice minOccurs="0"> + <xs:element name="ParticipantObjectName" type="xs:string" + minOccurs="0"/> + <xs:element name="ParticipantObjectQuery" type="xs:base64Binary" + minOccurs="0"/> + </xs:choice> + <xs:element name="ParticipantObjectDetail" + type="TypeValuePairType" minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="ParticipantObjectID" type="xs:string" + use="required"/> + <xs:attribute name="ParticipantObjectTypeCode" use="optional"> + <xs:simpleType> + <xs:restriction base="xs:unsignedByte"> + <xs:enumeration value="1"> + <xs:annotation> + <xs:appinfo>Person</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="2"> + <xs:annotation> + <xs:appinfo>System object</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="3"> + <xs:annotation> + <xs:appinfo>Organization</xs:appinfo> + </xs:annotation> + </xs:enumeration> + + + +Marshall Informational [Page 37] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:enumeration value="4"> + <xs:annotation> + <xs:appinfo>Other</xs:appinfo> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + <xs:attribute name="ParticipantObjectTypeCodeRole" use="optional"> + <xs:simpleType> + <xs:restriction base="xs:unsignedByte"> + <xs:enumeration value="1"> + <xs:annotation> + <xs:appinfo>Patient</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="2"> + <xs:annotation> + <xs:appinfo>Location</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="3"> + <xs:annotation> + <xs:appinfo> Report</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="4"> + <xs:annotation> + <xs:appinfo>Resource</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="5"> + <xs:annotation> + <xs:appinfo>Master file</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="6"> + <xs:annotation> + <xs:appinfo>User</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="7"> + <xs:annotation> + <xs:appinfo>List</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="8"> + <xs:annotation> + + + +Marshall Informational [Page 38] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:appinfo>Doctor</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="9"> + <xs:annotation> + <xs:appinfo>Subscriber</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="10"> + <xs:annotation> + <xs:appinfo>Guarantor</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="11"> + <xs:annotation> + <xs:appinfo>Security User Entity</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="12"> + <xs:annotation> + <xs:appinfo>Security User Group</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="13"> + <xs:annotation> + <xs:appinfo>Security Resource</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="14"> + <xs:annotation> + <xs:appinfo>Security Granualarity Definition</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="15"> + <xs:annotation> + <xs:appinfo>Provider</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="16"> + <xs:annotation> + <xs:appinfo>Report Destination</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="17"> + <xs:annotation> + <xs:appinfo>Report Library</xs:appinfo> + </xs:annotation> + </xs:enumeration> + + + +Marshall Informational [Page 39] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:enumeration value="18"> + <xs:annotation> + <xs:appinfo>Schedule</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="19"> + <xs:annotation> + <xs:appinfo>Customer</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="20"> + <xs:annotation> + <xs:appinfo>Job</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="21"> + <xs:annotation> + <xs:appinfo>Job Stream</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="22"> + <xs:annotation> + <xs:appinfo>Table</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="23"> + <xs:annotation> + <xs:appinfo>Routing Criteria</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="24"> + <xs:annotation> + <xs:appinfo>Query</xs:appinfo> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + <xs:attribute name="ParticipantObjectDataLifeCycle" use="optional"> + <xs:simpleType> + <xs:restriction base="xs:unsignedByte"> + <xs:enumeration value="1"> + <xs:annotation> + <xs:appinfo>Origination / Creation</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="2"> + <xs:annotation> + + + +Marshall Informational [Page 40] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + <xs:appinfo>Import / Copy from original </xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="3"> + <xs:annotation> + <xs:appinfo>Amendment</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="4"> + <xs:annotation> + <xs:appinfo>Verification</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="5"> + <xs:annotation> + <xs:appinfo>Translation</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="6"> + <xs:annotation> + <xs:appinfo>Access / Use</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="7"> + <xs:annotation> + <xs:appinfo>De-identification</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="8"> + <xs:annotation> + <xs:appinfo>Aggregation, summarization, + derivation</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="9"> + <xs:annotation> + <xs:appinfo>Report</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="10"> + <xs:annotation> + <xs:appinfo>Export / Copy to target</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="11"> + <xs:annotation> + <xs:appinfo>Disclosure</xs:appinfo> + </xs:annotation> + + + +Marshall Informational [Page 41] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + </xs:enumeration> + <xs:enumeration value="12"> + <xs:annotation> + <xs:appinfo>Receipt of disclosure</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="13"> + <xs:annotation> + <xs:appinfo>Archiving</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="14"> + <xs:annotation> + <xs:appinfo>Logical deletion</xs:appinfo> + </xs:annotation> + </xs:enumeration> + <xs:enumeration value="15"> + <xs:annotation> + <xs:appinfo>Permanent erasure / Physical destruction + </xs:appinfo> + </xs:annotation> + </xs:enumeration> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + <xs:attribute name="ParticipantObjectSensitivity" type="xs:string" + use="optional"/> + </xs:complexType> + <xs:complexType name="CodedValueType"> + <xs:attribute name="code" type="xs:string" use="required"/> + <xs:attributeGroup ref="CodeSystem"/> + <xs:attribute name="displayName" type="xs:string" use="optional"/> + <xs:attribute name="originalText" type="xs:string" use="optional"/> + </xs:complexType> + <xs:complexType name="TypeValuePairType"> + <xs:attribute name="type" type="xs:string" use="required"/> + <xs:attribute name="value" type="xs:base64Binary" use="required"/> + </xs:complexType> + <xs:attributeGroup name="CodeSystem"> + <xs:attribute name="codeSystem" type="OID" use="optional"/> + <xs:attribute name="codeSystemName" type="xs:string" + use="optional"/> + </xs:attributeGroup> + <xs:simpleType name="OID"> + <xs:restriction base="xs:string"> + <xs:whiteSpace value="collapse"/> + </xs:restriction> + </xs:simpleType> + + + +Marshall Informational [Page 42] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +</xs:schema> + +6.2. XML Schema Localization + + The schema specified in section 6.1 may be extended and restricted to + meet local implementation-specific requirements. W3C Recommendation + for XML Schema structure [W3CXML-1], section 4, is the governing + standard for accomplishing this. + + As of the current version of this document, a public reference URI + for the base schema has not been established. + + Local definitions reference the common audit message base schema. + For example, here is a schema with a local vocabulary restriction for + "Audit Enterprise Site ID" plus an extension adding a new "Audit + Source Asset Number" element. + + The URI used to identify this schema (http://audit-message-uri) is a + syntactically valid example that does not represent an actual schema. + Schema validators might report an error when attempting to import a + schema using this URI. + +<xs:schema xmlns:audit="http://audit-message-URI" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + <xs:import schemaLocation="http://audit-message-URI"/> + <xs:complexType name="LocaAuditSourceIdentificationType"> + <xs:complexContent> + <xs:restriction base="AuditSourceIdentificationType"> + <xs:attribute name="AuditEnterpriseSiteID" use="required"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:enumeration value="Main"/> + <xs:enumeration value="Clinic1"/> + <xs:enumeration value="Clinic2"/> + <xs:enumeration value="Radiology"/> + <xs:enumeration value="Lab"/> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + </xs:restriction> + </xs:complexContent> + </xs:complexType> + <xs:element name="LocalAuditSourceIdentification"> + <xs:complexType> + <xs:complexContent> + <xs:extension base="LocaAuditSourceIdentificationType"> + <xs:attribute name="AuditSourceAssetNumber" type="xs:string" + + + +Marshall Informational [Page 43] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + use="required"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + </xs:element> +</xs:schema> + +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 [E2147] states, in paragraph + 5.3.10, "Prohibit use for other reasons than to enforce security and + to detect security breaches in record health information systems, for + example, the audits are not to be used to explore activity profiles + or movement profiles of employees." + + Some audit data arises from security-relevant processes other than + data access. These are the trigger events listed in section 4.1 and + 4.2 of this document. Audit data, defined in this document, can + record the accountabilities for the results of these processes, as + part of a complete security implementation. A discussion of the + associated authorities, reference standards, and implementation + technology choices for the processes is outside the scope of this + document. + +8. References + +8.1. Normative References + + [E2147] "E2147-01 Standard Specification for Audit and + Disclosure Logs for Use in Health Information Systems", + ASTM International, June 2002. + + [ISO15408-2] "ISO/IEC 15408:1999 Common Criteria for Information + Technology Security Evaluation, Part 2: Security + Functional Requirements", ISO, August 1999. + + [ISO8601] "ISO 8601:2000 Data elements and interchange formats -- + Information interchange -- Representation of dates and + times", ISO, December 2000. + + + + +Marshall Informational [Page 44] + +RFC 3881 Security Audit & Access Accountability September 2004 + + + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation", RFC 1305, March 1992. + + [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [W3CXML-1] W3C Recommendation "XML Schema Part 1: Structures", + version 1.0, May 2001. + + [W3CXML-2] W3C Recommendation "XML Schema Part 2: Datatypes," + version 1.0, May 2001. + +8.2. Informative References + + [HL7SASIG] Marshall, G. and G. Dickinson, "Common Audit Message", + HL7 Security and Accountability Special Interest Group, + November 2001. + + [IHETF-3] "IHE Technical Framework", Volume III, HIMMS/RSNA, April + 2002. + + [NEMASPC] "Security and Privacy Auditing in Health Care + Information Technology", Joint NEMA/COCIR/JIRA Security + and Privacy Committee, 26 June 2001. + +Acknowledgments + + The author gratefully acknowledges the advice and assistance of the + following people during the preparation of this document: + + Carmela Couderc, Siemens Medical Solutions + Michael Davis, SAIC + Gary Dickinson + Christoph Dickmann, Siemens Medical Solutions + Daniel Hannum, Siemens Medical Solutions + Robert Horn, Agfa + James McAvoy, Siemens Medical Solutions + John Moehrke, General Electric Medical Systems + Jennifer Puyenbroek, McKesson Information Solutions + Angela Ray, McKesson Information Solutions + Lawrence Tarbox, Siemens Corporate Research + + + + + + + + + +Marshall Informational [Page 45] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +Author's Address + + Glen Marshall + Siemens Medical Solutions Health Services + 51 Valley Stream Parkway + Malvern, PA 19312 + USA + + Phone: (610) 219-3938 + EMail: glen.f.marshall@siemens.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Marshall Informational [Page 46] + +RFC 3881 Security Audit & Access Accountability September 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and at www.rfc-editor.org, and except as set + forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the ISOC's procedures with respect to rights in ISOC Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Marshall Informational [Page 47] + |