Internet Draft G. Marshall Document: draft-marshall-security-audit-00.txt Siemens Expires: April 2003 December 2002 Security Audit and Access Accountability Message Data Definitions for Healthcare Applications Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026[1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines data for privacy and security policy assurance applications to be output from healthcare application systems. It supplements existing system-specific security audits with healthcare application-specific requirements. It also anticipates the existence of common repository systems that receive audit data from multiple application systems and the associated operating infrastructure components. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[2]. Marshall Expires - June 2003 [Page 1]
Security Audit and Access Accountability Message December 2002 Table of Contents 1. Purpose.......................................................2 2. Scope.........................................................3 2.1 Data Collection...........................................3 2.2 System Infrastructure.....................................4 2.3 Included Data End-uses....................................4 2.4 Excluded Data End Uses....................................4 2.5 Conformance...............................................5 3. Goals.........................................................5 3.1 Effective Data Gathering..................................5 3.2 Efficiency................................................6 4. Trigger Events................................................7 4.1 Security Administration...................................7 4.2 Audit Administration and Data Access......................8 4.3 User Access...............................................8 5. Data Definitions.............................................11 5.1 Event Identification.....................................11 5.2 Active Participant Identification........................14 5.3 Network Access Point Identification......................16 5.4 Audit Source Identification..............................17 5.5 Participant Object Identification........................19 6. XML Schema Definition........................................24 7. Security Considerations......................................33 References......................................................34 Acknowledgments.................................................34 Author's Addresses..............................................34 1. Purpose The purposes the document fulfills are to: 1) Define data to be communicated for evidence of compliance with, and violations of, a healthcare enterpriseÆs security and privacy policies. The focus of auditing in this document is to retrospectively detect and report security/privacy breaches, versus directly inhibiting access This includes capturing data that supports individual accountability for patient record creation, access, updates, and deletions. It does not include real-time access alarm actions since there is a perception in the healthcare community that security measures that inhibit access may also inhibit effective patient care, under some circumstances. Marshall Expires - June 2003 [Page 2]
Security Audit and Access Accountability Message December 2002 2) Depict the data that would reside in a common audit engine or database. Privacy and security audit data is to be collected on each hardware system, and there are likely to be separate local data stores for system-level and application-level audits. Collating these records and providing a common view û transcending hardware system boundaries û is seen as necessary for cost-effective security and privacy policy administration. The data definitions support such a collation, but the technical implementation alternatives are not covered in this document. 3) Allow 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. The data definitions support creating those views. 4) Provide a common reference standard for healthcare IT standards development organizations. This document consolidates previously disjoint viewpoints from Health Level 7 (HL7)[3], Integrating the Healthcare Enterprise (IHE)[4], and the ASTM International Healthcare Informatics Technical Committee (ASTM E31)[5]. It is intended as a reference for these three groups and other healthcare standards developers. 2. Scope 2.1 Data Collection This document covers audit data to be collected and communicated from automated systems. It does not include non-automated processes. For each audited event, this document specifies the minimal data requirements plus optional data for the following event categories: 1) 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. 2) 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 Expires - June 2003 [Page 3]
Security Audit and Access Accountability Message December 2002 3) 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. 4) Audit access events û reflecting special protections implemented for the audit trail itself. 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. 2.2 System Infrastructure Security subsystems found in most system infrastructures include a capability to capture system-level security relevant events like logon and security object accesses. We assume such functions are enabled and capable of recording and supplying the data defined in this document, although transformation to conform to the common XML schema definition will be required. 2.3 Included Data End-uses This document assumes that there is a requirement to transmit data from multiple systems to a common repository. This arises from the typical healthcare IT environment, containing many systems from various vendors and developers who have not implemented common or interoperable security administrative functions. Application-level events, like 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. 2.4 Excluded Data End Uses There are distinctions between audit data required for surveillance versus forensic purposes. While some surveillance data may useful for forensics, the scope of this document is limited to surveillance. This document does not address access real-time policy violation alarm actions. There is a perception in the healthcare community that security measures that inhibit access may also inhibit effective patient care, under some circumstances. This document does not define any data for patient care consents or patients' permissions for data disclosure. It is conceivable that Marshall Expires - June 2003 [Page 4]
Security Audit and Access Accountability Message December 2002 the proposed audit data could be input to such applications, however, assuming strict access controls for audit data have been established. 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. This document does not define system-specific or application-specific data that may be collected and reported in addition to the defined elements. At the same time it does not preclude such 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.5 Conformance This document does not include any definitions of conformance practices. 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 logon, roles, access right permissions and restrictions, etc. Each application system also has its own security log file that records security relevant events, e.g., login, data access, and updates to the security policy databases. A system administrator or security auditor must examine each of these log files to find security relevant incidents. Not only is it difficult to examine each of these files separately, the format and contents of each file may be confusingly different. Marshall Expires - June 2003 [Page 5]
Security Audit and Access Accountability Message December 2002 Resolving these issues requires a framework to: - Maximize interoperability and the meaningfulness of data across applications and sites - Minimize ambiguity among heterogeneous systems - Simplify and limits costs for administrative audit tasks. 3.2 Efficiency One of the leading concerns about auditing is the potential volume of data gathering and its impact on application system performance. Although this document does not prescribe specific implementations or strategies, the following are meant as informative guidance for development. 1) Audits should be created for transactions or record-access, not for individual attribute-level changes to data. 2) This document does not discourage locally optimized gathering of audit data on each application system. Instead, it anticipates periodic gathering and transmission of data to a common repository. This common repository would be optimized for after- the-fact audit queries and reporting, thus unburdening each application system of those responsibilities. It is also important to keep the message size compact so that audit data will not penalize normal network operation. 3) On each application system, a variety of policy-based methods could be employed to optimize data gathering and storage, e.g., selective auditing of only events defined as important plus workload buffering and balancing. Data gathering itself should be stateless to avoid the overhead of transactional semantics. In addition, prior to transmission, some summarization of repeated events would reduce the number of messages. Audit data storage and integrity on each application system need only be scaled for relatively low-volume and short-duration requirements. 4) Leveraging existing data collection should be considered. For example, it is common is some systemsÆ designs to provide a transaction log for data reconstruction in event of database loss. Collecting audit data within this subsystem could reduce impact on system performance. 5) A security audit repository would gather all audit message data from the different applications in one database with one standard structure. This would allow easier evaluation and querying. Once a suspicious pattern has been found in the audit log repository, investigation might proceed with more detail in the application specific audit log. The presence of a common repository also Marshall Expires - June 2003 [Page 6]
Security Audit and Access Accountability Message December 2002 simplifies and streamlines the implementation of policies for audit data storage, integrity, retention, and destruction. 4. Trigger Events The following identifies trigger events for generating audit messages. These should be viewed as application-level events. For those events arising in the security infrastructure the "minimal" and "basic" level of auditing as outlined in the Common Criteria[6] should be used as a reference standard. 4.1 Security Administration This group includes all actions that create and maintain definitions for securing data, functions, and the associated access policies. For each trigger type, the creation, update or amendment, and activation or deactivation are auditable. 4.1.1 Data Definition This includes data definitions for data sets, data groups, or classes plus the atomic data elements or attributes. 4.1.2 Function Definition This includes, for example, application function definitions for patient management and clinical processes, registry of business objects and methods, program creation and maintenance, etc. 4.1.3 Domain Definition This includes all activities that create or modify security domains according to various organizational categories such as entity-wide, institutional, departmental, etc.: 4.1.4 Classification Definition This includes all activities that create or modify security categories or groupings for functions and data such as patient management, nursing, clinical, etc. 4.1.5 Permission Definition This includes all activities that create or modify the allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods. Marshall Expires - June 2003 [Page 7]
Security Audit and Access Accountability Message December 2002 4.1.6 Role Definition This includes all activities that create or modify security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control. 4.1.7 User Definition This includes all activities that create or modify user accounts. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control. 4.2 Audit Administration and Data Access This category includes all actions that determine the collection and availability of audit data. 4.2.1 Audit Enable or Disable This reflects a basic policy decision that an event should or should not be audited. Some, but not necessarily all, triggers or use cases must create an audit record. The selection of what to audit depends on administrative policy decisions. Note that, for integrity, this event should always be audited. 4.2.2 Audit Data Access This includes instances where audit data is viewed or reported for any purpose. Since the audit data itself may include data protected by institutional privacy policies and expose the implementation of those policies, access to the data is highly sensitive. This event should therefore always be audited. 4.2.3 Audit Data Modify or Delete This includes instance where audit data is modified or deleted. This is a signature event for unauthorized hostile systems access. This event should therefore always be audited. 4.3 User Access This category includes events of access to secured data and functions for which audit data might be collected. Marshall Expires - June 2003 [Page 8]
Security Audit and Access Accountability Message December 2002 4.3.1 Sign-On This includes successful and unsuccessful attempts from human users and automated systems. 4.3.2 Sign-Off This includes explicit sign-off events and session abandonment timeouts from human users and automated systems. 4.3.3 Function Access This includes user invocation of application or system functions that have permission definitions associated with them. Note that in a Discretionary Access Control environment not all functions require permissions, especially if their impact is benign in relation to policies. The following items enumerate audit triggers that are relevant to patient privacy. Additional triggers for institutional data access, policies for non-care functions, and support regulatory requirements will need to be identified by system implementers. 4.3.3.1 Subject of Care Record Access This includes all functions which manipulate basic patient data: - Create, e.g., demographics or patient profile - Assign identifier, e.g., medical record number - Update, amend - Merge/unmerge, e.g., combine multiple medical records for one patient - Import/export of data from/to an external source, including printing and creation of portable media copies. 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 Marshall Expires - June 2003 [Page 9]
Security Audit and Access Accountability Message December 2002 4.3.3.3 Care Protocols This includes all functions which associate care plans or similar protocols with an instance or subject of care: - Schedule, initiate - Update, amend - Complete - Cancel 4.3.3.4 Episodes or Problems This includes specific clinical episodes within an instance of care. Initiate - Update, amend - Resolve, complete - Cancel 4.3.3.5 Orders and Order Sets This includes clinical or supplies orders within an instance or episode of care. - Initiate - Update, amend - Complete - Cancel 4.3.3.6 Health Service Event or Act This includes various health services scheduled and performed within an instance or episode of care - Schedule, initiate - Perform, complete - Cancel 4.3.3.7 Medications This includes all medication orders and administration within an instance or episode of care. These are distinct from orders and events in the need to check for adverse interactions and to verify the medications prior to delivery. - Order - Check - Cancel interactions - Verify - Dispense/deliver û including administration instructions Marshall Expires - June 2003 [Page 10]
Security Audit and Access Accountability Message December 2002 - Administer 4.3.3.8 Staff Assignment This includes staffing actions relevant to an instance or episode of care. - Assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. - Change in assigned role or authorization, e.g., relative to healthcare status change. - De-assignment 5. Data Definitions The proposed data elements are grouped into these categories: 1) Event Identification û what was done 2) User Identification û by whom 3) Audit Source Identification û using which server 4) Network Access Point Identification û initiated from where 5) Participant Object Identification û to what record 5.1 Event Identification The following data identify the name, action type, time, and disposition of the audited event. There is only one set of event identification data per audited event. 5.1.1 Event ID Description Required Identifier for a specific audited event, e.g., a menu item, program, rule, policy, function code, or application name, or URL. It identifies the performed function. Format / Values Identifier string for the function. This should be an unambiguous code, unique, at least within Audit Source ID. Examples of Event IDs are program name, method name, or function name. Rationale This field identifies the audited function. For analyzing ôExecuteö Event Action Code audit records, this identifies the application function performed. Marshall Expires - June 2003 [Page 11]
Security Audit and Access Accountability Message December 2002 5.1.2 Event Action Code Description Required Indicator for type of action performed during the event that generated the audit. Format / Values Enumeration: Value Meaning Examples ----- --------------------- --------------------------------- C Create Create a new database object such as Placing an Order. R Read/View/Print/Query Display or print data such as a Doctor Census U Update Update information such as Revise Patient Information D Delete Delete items from a master file such as a Doctor Record E Execute Perform a system or application function such as logon, program execution, or use of an objectÆs method. Rationale This broadly indicates what kind of action was done on the Participant Object. Notes Actions that are not enumerated above are considered an Execute of a specific function or object interface method or treated two or more distinct events. An application action, such as an authorization, is a function Execute, and the Event ID should identify the function. For compound actions, such as ôMove,ö should be audited by creating audit data for each operation û read, create, delete û or as an Execute of a function or method. 5.1.3 Event Date/Time Description Required Marshall Expires - June 2003 [Page 12]
Security Audit and Access Accountability Message December 2002 Universal coordinated time (UTC), i.e. a date/time specification that is unambiguous as to local time zones. Format / Values A date/time representation that is unambiguous in conveying universal coordinated time (UTC) Rationale This ties an event to a specific date and time. Security audits typically require a consistent time base, e.g., UTC, to eliminate time-zone issues arising from geographical distribution. Notes In a distributed system, some sort of common time base, e.g., an NTP[7]server, is a good implementation tactic. 5.1.4 Event Outcome Indicator Description Required Indicates whether the event succeeded or failed. Format / Values Enumeration: Value Meaning ---- ---------------------------------------------------- 0 Success 4 Minor failure; action restarted, e.g., invalid password with first retry 8 Serious failure; action terminated, e.g., invalid password with excess retries 12 Major failure; action made unavailable, e.g., user account disabled due to excessive invalid logon attempts Rationale Some audit events may be qualified by success or failure indicator. For example, a Logon might have this flag set to a non-zero value to indicate why a logon attempt failed. Marshall Expires - June 2003 [Page 13]
Security Audit and Access Accountability Message December 2002 5.2 Active Participant Identification The following data identify a user for the purpose of documenting personal accountability for the audited event. Optionally, the userÆs network access location may be specified. There may be more than one user per event, e.g., in cases of actions initiated by one user for other users, however only one user may be the initiator/requestor for the event. 5.2.1 User ID Description Required Unique identifier for the user performing the event Format / Values Key from authentication system. For a common message, this identifier should be one known to a common authentication system (e.g., single sign-on), if available. Otherwise, it is a unique value within the Audit Source ID. Rationale This field ties an audit event to a specific user. Notes For cross-system audits, especially with long retention, this user identifier should permanently tie an audit event to a specific user via a perpetually unique key. 5.2.2 UserIsRequestor Description Optional Indicator that the user is or is not the requestor-actor for the audit event. Format / Values Boolean, default/assumed value is "true" Marshall Expires - June 2003 [Page 14]
Security Audit and Access Accountability Message December 2002 Rationale This value is used to distinguish between requestor-users and recipient-users. For example, one person may request a report- output to be sent to a another user. 5.2.3 Role ID Code Description Optional Specification of the role the user plays when performing the event, as assigned in role-based access control security Format / Values Coded value, with attribute "code" valued with the role code or text from authorization system. This may reference a standard enumeration. For such cases the XML schema defines these optional attribute values: Attribute Value -------------- -------------------------------------------- CodeSystem OID reference CodeSystemName Name of the coding system DisplayName The value to be used in displays and reports OriginalText Input value that was translated to the code Rationale This value ties an audited event to a userÆs role. It is an optional value that might be used to group events for analysis by user functional role categories. Notes Many security systems are unable to produce this data, hence it is optional. For the common message, this identifier should be the one known to a common authorization system, if available. Otherwise, it is a unique value within the Audit Source ID. Consider using a globally unique identifier associated with the role to avoid ambiguity in auditing heterogeneous systems. Role ID is not a substitute for personal accountability. Marshall Expires - June 2003 [Page 15]
Security Audit and Access Accountability Message December 2002 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 5.3.1 Network Access Point Type Code Description Optional An identifier for the type of network access point that originated the audit event. Format / Values Enumeration: Value Meaning ----- ---------------- 1 Machine Name 2 IP Address 3 Telephone Number Rationale This datum identifies the type of network access point identifier of the user device for the audit event. It is an optional value that may be used to group events recorded on separate servers for analysis of access according to a network access pointÆs type. 5.3.2 Network Access Point ID Description Optional An identifier for the network access point of the user device for the audit event. This could be a device id, IP address, or some other identifier associated with a device. Format / Values Text may be constrained to only valid values for the given Network Access Point Type, if specified. Recommendation is to be as specific as possible where multiple options are available. Marshall Expires - June 2003 [Page 16]
Security Audit and Access Accountability Message December 2002 Rationale This datum identifies the userÆs network access point, distinct from the server that performed the action. It is an optional value that may be used to group events recorded on separate servers for analysis of a specific network access pointÆs access across all servers. Note Network Access Point ID is not a substitute for personal accountability. Internet IP addresses, in particular, are highly volatile and may be assigned to more than one person in a short time period. Examples Network Access Point ID: SMH4WC02 Network Access Point Type: 1 = Machine Name Network Access Point ID: 10.10.203.42 Network Access Point Type: 2 = IP address Network Access Point ID: 610-555-1212 Network Access Point Type: 3 = Phone Number 5.4 Audit Source Identification The following data are required primarily for application server systems and processes. Since multi-tier, distributed, or composite applications make source identification ambiguous, this collection of fields may repeat for each server or process actively involved in the event. For example, multiple value-sets can identify participating web servers, application processes, and database server threads in an n-tier distributed application. Passive event participants, e.g., low-level network transports, need not be identified. 5.4.1 Audit Enterprise Site ID Description Optional Logical server location within the healthcare enterprise network, e.g., a hospital or other provider location within a multi-entity provider group. This is configurable and defined by the application that generates the audit record. It contains a unique code that identifies a business organization (owner of data) that is known to the Marshall Expires - June 2003 [Page 17]
Security Audit and Access Accountability Message December 2002 enterprise. The value further qualifies [disambiguates] the Audit Source ID. Values may vary depending on type of business. There may be levels of differentiation within the organization. Format / Values Unique identifier within the healthcare enterprise. Null value when the system is uniquely identified by Audit Source ID. Rationale This value differentiates among the sites in a multi-site enterprise health information system. 5.4.2 Audit Source ID Description Required Identifier of the server where event originated. Format / Values Unique identifier, at least within the Audit Enterprise Site ID Rationale This field ties the event to a specific server system. It may be used to group events for analysis according to where the event occurred. Notes In some server 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 identifier for the group of servers rather than a specific hardware system. 5.4.3 Audit Source Type Code Description Optional Code specifying the server type where event originated. Marshall Expires - June 2003 [Page 18]
Security Audit and Access Accountability Message December 2002 Format / Values Enumeration: Value Meaning ----- ------------------------------------------ 1 End-user device 2 Web server process 3 Application server process 4 Database server process 5 Security server, e.g., a domain controller 6 ISO level 1-3 network component 7 ISO level 4-6 operating software 8 External source, unknown type Rationale This field indicates which type of system 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 server where the event occurred. 5.5 Participant Object Identification The following data assist the auditing process by indicating specific instances of data or objects that have been accessed. These data are optional if the values for Event Identification, Active Participant Identification, and Audit Source Identification are sufficient to documents the entire auditable event. In addition, the production audit records containing these data may be enabled or not, as determined by healthcare organization policy and regulatory requirements. Because events may have more than one participant, this group should be considered a repeating set of values. For example, depending on institutional policies and implementation choices: - Two participant object value-sets can be used to identify access to patient data by medical record number plus the specific health care encounter or episode for the patient. - A patient participant and his authorized representative may be identified concurrently. - An attending physician and consulting referrals may be identified concurrently. - All patients identified on a worklist may be identified. Marshall Expires - June 2003 [Page 19]
Security Audit and Access Accountability Message December 2002 5.5.1 Participant Object Type Code Description Optional Code for the participant object type being audited. This value is distinct from the userÆs role or any user relationship to the participant object. Format / Values Enumeration: Value Meaning ----- ------------- 1 Person 2 System Object 3 Organization Rationale To describe the object being acted upon. In addition to queries on the subject of the action in an auditable event, it is also important to be able to query on the object of that action. 5.5.2 Participant Object Type Code Role Description Optional Code representing the functional application role of Participant Object being audited Format / Values Enumeration, specific to Participant Object Type Code: Value Meaning Participant Object Type Codes ----- -------------------- ----------------------------- 1 Patient 1 û Person 2 Location 3 û Organization 3 Report 2 û System Object 4 Resource 1 û Person 3 û Organization 5 Master file 2 - System Object 6 User 1 û Person 7 List 2 - System Object Marshall Expires - June 2003 [Page 20]
Security Audit and Access Accountability Message December 2002 8 Doctor 1 û Person 9 Subscriber 3 û Organization 10 Guarantor 1 û Person 3 û Organization 11 Security User Group 2 û System Object 12 Security Resource 2 û System Object 13 Security Granularity 2 û System Object Definition 14 Provider 1 û Person 3 û Organization 15 Report Destination 2 û System Object 16 Report Library 2 û System Object 17 Schedule 2 û System Object 18 Customer 3 û Organization 19 Job 2 - System Object 20 Job Stream 2 - System Object 21 Table 2 - System Object 22 Routing Criteria 2 - System Object 23 Query 2 û System Object A "Security Resource" an abstract securable object, e.g., a screen, interface, document, program, etc. Rationale For some audit analysis it may be necessary to indicate a more granular type of participant, based on the application role it serves. 5.5.3 Participant Object Data Life Cycle Description Optional Identifier for the data life-cycle stage for the participant object. This can be used to provide an audit trail for data, over time, as it passes through the system Format/Values Enumeration: Value Meaning ----- -------------------------------------- 1 Origination 2 Amendment 3 Verification 4 Translation Marshall Expires - June 2003 [Page 21]
Security Audit and Access Accountability Message December 2002 5 Access / use 6 De-identification 7 Aggregation, summarization, derivation 8 Report 9 Disclosure 10 Receipt 11 Archiving 12 Destruction Rationale Institutional policies for privacy and security may optionally fall under different accountability rules based on data life cycle. This provides a differentiating value for those cases. 5.5.4 Participant Object ID Type Code Description Required Describes the identifier that is contained in Participant Object ID. Format / Values Coded-value enumeration, specific to Participant Object Type Code, using attribute-name "code": code Meaning Participant Object Type Codes ---- ---------------------- ----------------------------- 1 Medical record number 1 û Person 2 Patient number 1 û Person 3 Enrollee number 1 û Person 4 Social Security Number 1 û Person 5 Account number 1 û Person 3 û Organization 6 Guarantor ID 1 û Person 3 û Organization 7 Report Name 2 - System Object 8 Report Number 2 - System Object 9 Search Criteria 2 - System Object This enumeration may be replaced by a coded-value reference to a standard enumeration, e.g., HL7 version 2 table 207. For such cases the XML schema defines these optional attribute values: Attribute Value -------------- -------------------------------------------- CodeSystem OID reference Marshall Expires - June 2003 [Page 22]
Security Audit and Access Accountability Message December 2002 CodeSystemName Name of the coding system DisplayName The value to be used in displays and reports OriginalText Input value that was translated to the code Rationale Required to distinguish among various identifiers that may synonymously identify a participant object. 5.5.5 Participant Object ID Sensitivity Description Optional Denotes policy-defined sensitivities for the Participant Object ID such as VIP, HIV status, mental health status, or similar topics. Format / Values Values are institution and implementation defined text-strings. 5.5.6 Participant Object ID Description Required Identifies a specific instance of the participant object Format / Values 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 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 Expires - June 2003 [Page 23]
Security Audit and Access Accountability Message December 2002 5.5.7 Participant Object Name Description Optional An instance-specific descriptor of the Participant Object ID audited, such as a personÆs name Format / Values Free text Rationale This field may be used in a query/report to identify audit events for a specific person, especially if multiple synonymous Participant Object IDs have been used for that person. 5.5.8 Participant Object Query String Description Optional The actual query string for a query-type participant object. Format / Values Base 64 encoded data Rationale For query events it may be necessary to capture the actual query string input the query process in order to identify the specific event. It is a data blob, relative to auditing, that may be decoded and interpreted by downstream audit analysis processing 6. XML Schema Definition <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="AuditMessage"> <xs:complexType> <xs:sequence> <xs:element name="EventIdentification" type="EventIdentificationType"/> <xs:element name="AuditSourceIdentification" Marshall Expires - June 2003 [Page 24]
Security Audit and Access Accountability Message December 2002 type="AuditSourceIdentificationType" maxOccurs="unbounded"/> <xs:element name="ActiveParticipant" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="ActiveParticipantType"/> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="ParticipantObjectIdentification" type="ParticipantObjectIdentificationType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="EventIdentificationType"> <xs:attribute name="EventID" type="xs:string" use="required"/> <xs:attribute name="EventActionCode" use="optional" default="E"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="C"> <xs:annotation> <xs:appinfo>Create</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="R"> <xs:annotation> <xs:appinfo>Read</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="U"> <xs:annotation> <xs:appinfo>Update</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="D"> <xs:annotation> <xs:appinfo>Delete</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="E"> <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"> Marshall Expires - June 2003 [Page 25]
Security Audit and Access Accountability Message December 2002 <xs:simpleType> <xs:restriction base="xs:integer"> <xs:enumeration value="0"> <xs:annotation> <xs:appinfo>Success</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Minor failure</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>Serious failure</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>Major failure; action made unavailable </xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="AuditSourceIdentificationType"> <xs:attribute name="AuditEnterpriseSiteID" type="xs:string" use="optional"/> <xs:attribute name="AuditSourceID" type="xs:string" use="required"/> <xs:attribute name="AuditSourceTypeCode" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>End-user device</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>Web server process</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Application server process</xs:appinfo> </xs:annotation> </xs:enumeration> Marshall Expires - June 2003 [Page 26]
Security Audit and Access Accountability Message December 2002 <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Database server process</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> <xs:appinfo>Security server, e.g., a domain controller </xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:documentation>ISO level 1-3 network component </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:appinfo>ISO level 4-6 operating software</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>External source, unknown type</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ActiveParticipantType"> <xs:sequence minOccurs="0"> <xs:element name="RoleIDCode" minOccurs="0"> <xs:complexType> <xs:complexContent> <xs:restriction base="CodedValueType"> <xs:attribute name="code" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="UserID" type="xs:string" use="required"/> <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> Marshall Expires - June 2003 [Page 27]
Security Audit and Access Accountability Message December 2002 <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Machine Name</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>IP Address</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Telephone Number</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ParticipantObjectIdentificationType"> <xs:sequence> <xs:element name="ParticpantObjectIDTypeCode" type="CodedValueType"/> <xs:choice minOccurs="0"> <xs:element name="ParticipantObjectName" type="CodedValueType" minOccurs="0"/> <xs:element name="ParticipantObjectQueryString" type="CodedBase64ValueType" minOccurs="0"/> </xs:choice> </xs:sequence> <xs:attribute name="ParticipantObjectID" type="xs:string" use="required"/> <xs:attribute name="ParticipantObjectTypeCode" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <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> Marshall Expires - June 2003 [Page 28]
Security Audit and Access Accountability Message December 2002 </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ParticipantObjectTypeCodeRole" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Patient</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>Location</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo> Report</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Resource</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> <xs:appinfo>Master file</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:appinfo>User</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:appinfo>List</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>Doctor</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="9"> <xs:annotation> <xs:appinfo>Subscriber</xs:appinfo> Marshall Expires - June 2003 [Page 29]
Security Audit and Access Accountability Message December 2002 </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 Group</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>Security Resource</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="13"> <xs:annotation> <xs:appinfo>Security Granualarity Definition</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="14"> <xs:annotation> <xs:appinfo>Provider</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="15"> <xs:annotation> <xs:appinfo>Report Destination</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="16"> <xs:annotation> <xs:appinfo>Report Library</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="17"> <xs:annotation> <xs:appinfo>Schedule</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="18"> <xs:annotation> <xs:appinfo>Customer</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="19"> <xs:annotation> <xs:appinfo>Job</xs:appinfo> Marshall Expires - June 2003 [Page 30]
Security Audit and Access Accountability Message December 2002 </xs:annotation> </xs:enumeration> <xs:enumeration value="20"> <xs:annotation> <xs:appinfo>Job Stream</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="21"> <xs:annotation> <xs:appinfo>Table</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="22"> <xs:annotation> <xs:appinfo>Routing Criteria</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="23"> <xs:annotation> <xs:appinfo>Query</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ParticipantObjectDataLifeCycle" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Origination</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>Amendment</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Verification</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Translation</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> Marshall Expires - June 2003 [Page 31]
Security Audit and Access Accountability Message December 2002 <xs:appinfo>Access / Use</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:appinfo>De-identification</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:appinfo>Aggregation, summarization, derivation </xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>Report</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="9"> <xs:annotation> <xs:appinfo>Disclosure</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="10"> <xs:annotation> <xs:appinfo>Receipt</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="11"> <xs:annotation> <xs:appinfo>Archiving</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>Destruction</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ParticipantObjectIDSensitivity" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="CodedValueType"> <xs:attribute name="code" type="xs:string" use="optional"/> <xs:attributeGroup ref="CodeSystem"/> <xs:attribute name="displayName" type="xs:string" use="optional"/> <xs:attribute name="originalText" type="xs:string" use="optional"/> Marshall Expires - June 2003 [Page 32]
Security Audit and Access Accountability Message December 2002 </xs:complexType> <xs:complexType name="CodedBase64ValueType"> <xs:complexContent> <xs:restriction base="CodedValueType"> <xs:attribute name="code" type="xs:base64Binary" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:attributeGroup name="CodeSystem"> <xs:attribute name="codeSystem" type="OID" use="optional"/> <xs:attribute name="codeSystemName" type="xs:string" use="optional"/> </xs:attributeGroup> <xs:simpleType name="OID"> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> </xs:restriction> </xs:simpleType> </xs:schema> 7. Security Considerations Audit data must be secured at least to the same extent as the underlying data and activities being audited. This includes access controls as well as data integrity and recovery functions. This document acknowledges the need for, but does not specify, the policies and technical methods to accomplish this. It is conceivable that audit data might have unintended uses, e.g., tracking the frequency and nature of system use for productivity measures. ASTM standard E2147-01[5] states, in paragraph 5.3.10, "Prohibit use for other reasons than to enforce security and to detect security breaches in record health information systems, for example, the audits are not to be used to explore activity profiles or movement profiles of employees.ö Marshall Expires - June 2003 [Page 33]
Security Audit and Access Accountability Message December 2002 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Marshall, G., and Dickinson, G., "Common Audit Message", HL7 Security and Accountability Special Interest Group, November 2001 4 "IHE Technical Framework", Volume III, HIMMS/RSNA, April 2002 5 "E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems", ASTM International, June 2002 6 "ISO/IEC 15408:1999 Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements", ISO, August 1999 7 Mills, D., Network Time Protocol (Version 3) Specification, Implementation, March 1992. Acknowledgments The author gratefully acknowledges the advice and assistance of the following people during the preparation of this document: Carmela Couderc, Siemens Medical Solutions Health Services Michael Davis, SAIC Gary Dickinson, Per-Se Technologies, Inc. Robert Horn, Agfa James McAvoy, Siemens Medical Solutions Health Services Jennifer Puyenbroek, McKesson Information Solutions Angela Ray, McKesson Information Solutions Author's Addresses Glen Marshall Siemens Medical Solutions Health Services 51 Valley Stream Parkway Malvern, PA 19312 USA Phone: (610) 219-3938 Email: glen.f.marshall@siemens.com Marshall Expires - June 2003 [Page 34]