idnits 2.17.1 draft-marshall-security-audit-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 333 has weird spacing: '...list of trigg...' == Line 463 has weird spacing: '...of data from/...' == Line 2188 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HL7ASSIG' is mentioned on line 91, but not defined == Missing Reference: 'ISO15408-2' is mentioned on line 337, but not defined == Unused Reference: 'RFC1305' is defined on line 2054, but no explicit reference was found in the text == Unused Reference: 'HL7SASIG' is defined on line 2068, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E2147' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'W3CXML-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'W3CXML-2' Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft G. Marshall 3 Document: draft-marshall-security-audit-12.doc Siemens 4 Expires: November 2004 May 2004 6 Security Audit and Access Accountability Message 7 XML Data Definitions for Healthcare Applications 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026 except that the right to produce derivative 13 works is not granted. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document defines the format of data to be collected, and minimum 34 set of attributes that need to be captured, for security auditing in 35 healthcare application systems. The format is defined as an XML 36 schema, which is intended as a reference for healthcare standards 37 developers and application designers. It consolidates several 38 previous documents on security auditing of healthcare data. 40 Table of Contents 42 1. Purpose.......................................................2 43 2. Scope.........................................................4 44 2.1 Data Collection...........................................4 45 2.2 Anticipated Data End-uses.................................5 46 2.3 Conformance...............................................6 47 3. Goals.........................................................6 48 3.1 Effective Data Gathering..................................6 49 3.2 Efficiency................................................6 50 4. Trigger Events................................................8 51 4.1 Security Administration...................................8 52 4.2 Audit Administration and Data Access......................9 53 4.3 User Access...............................................9 54 5. Data Definitions.............................................12 55 5.1 Event Identification.....................................12 56 5.2 Active Participant Identification........................16 57 5.3 Network Access Point Identification......................19 58 5.4 Audit Source Identification..............................21 59 5.5 Participant Object Identification........................23 60 6. XML Schema...................................................29 61 6.1 XML Schema Definition....................................30 62 6.2 XML Schema Localization..................................41 63 7. Security Considerations......................................42 64 8. References...................................................42 65 8.1 Normative References.....................................42 66 8.2 Informative References...................................43 67 Draft Change History............................................43 68 Acknowledgments.................................................44 69 Author's Address................................................45 70 Copyright Statement.............................................45 72 1. Purpose 74 To help assure healthcare privacy and security in automated systems, 75 usage data need to be collected. These data will be reviewed by 76 administrative staff to verify that healthcare data is being used in 77 accordance with the healthcare provider's data security requirements 78 and to establish accountability for data use. This data collection 79 and review process is called security auditing. 81 This document defines the format of the data to be collected and 82 minimum set of attributes that need to be captured by healthcare 83 application systems for subsequent use by an automation-assisted 84 review application. The data includes records of who accessed 85 healthcare data, when, for what action, from where, and which 86 patients' records were involved. The data definition is an XML 87 schema to be used as a reference by healthcare standards developers 88 and application designers. 90 This document consolidates previously disjoint viewpoints of security 91 auditing from Health Level 7 (HL7)[HL7ASSIG], Digital Imaging and 92 Communications in Medicine (DICOM) Working Group 14, Integrating the 93 Healthcare Enterprise (IHE)[IHETF-3], the ASTM International 94 Healthcare Informatics Technical Committee (ASTM E31)[E2147], and the 95 Joint NEMA/COCIR/JIRA Security and Privacy Committee[NEMASPC]. It is 96 intended as a reference for these groups and other healthcare 97 standards developers. 99 The purposes the document fulfills are to: 101 1) Define data to be communicated for evidence of compliance with, or 102 violations of, a healthcare enterprise's security and privacy 103 policies and objectives. 105 This document defines the audit message format and content for 106 healthcare application systems. The focus of auditing is to 107 retrospectively detect and report security/privacy breaches. This 108 includes capturing data that supports individual accountability 109 for patient record creation, access, updates, and deletions. 111 This document does not define healthcare security and privacy 112 policies or objectives. It also does not include real-time access 113 alarm actions since there is a perception in the healthcare 114 community that security measures that inhibit access may also 115 inhibit effective patient care, under some circumstances. 117 2) Depict the data that would potentially reside in a common audit 118 engine or database. 120 Privacy and security audit data is to be collected on each 121 hardware system, and there are likely to be separate local data 122 stores for system-level and application-level audits. Collating 123 these records and providing a common view - transcending hardware 124 system boundaries - is seen as necessary for cost-effective 125 security and privacy policy administration. 127 The data definitions in this document support such a collation, 128 but the technical implementation alternatives are not covered in 129 this document. 131 3) Depict data that allows useful queries against audited events. 133 Audit data, in its raw form, reflects a sequential view of system 134 activity. Useful inquiries for security and privacy 135 administration need workflow, business process, organizational, 136 role, and person-oriented views. Data definitions in this 137 document anticipate and support creating those views and queries, 138 but do not define them. 140 4) Provide a common reference standard for healthcare IT standards 141 development organizations. 143 By specifying an XML schema, this document anticipates extensions 144 to the base schema to meet requirements of healthcare standards 145 bodies and application developers. 147 2. Scope 149 2.1 Data Collection 151 This document specifies audit data to be collected and communicated 152 from automated systems. It does not include non-automated processes. 154 Data for events in the above categories may be selectively collected, 155 based on healthcare organization policy. This document does not 156 specify any baseline or minimal policies. 158 For each audited event, this document specifies the minimal data 159 requirements plus optional data for the following event categories: 161 1) Security administrative events - establishing and maintaining 162 security policy definitions, secured object definitions, role 163 definitions, user definitions, and the relationships among them. 164 In general, these events are specific to the administrative 165 applications. 167 2) Audit access events - reflecting special protections implemented 168 for the audit trail itself. 170 3) Security-mediated events - recording entity identification and 171 authentication, data access, function access, nonrepudiation, 172 cryptographic operations, and data import/export for messages and 173 reports. In general, these events are generic to all protected 174 resources, without regard to the application data content. 176 4) Patient care data events - documenting what was done, by whom, 177 using which resources, from what access points, and to whose 178 medical data. In general, these audits are application-specific 179 since they require knowledge of the application data content. 181 Security subsystems found in most system infrastructures include a 182 capability to capture system-level security relevant events like 183 logon and security object accesses. This document does not preclude 184 such functions being enabled to record and supply the data defined in 185 this document, but transformation of the collected data to the common 186 XML schema definition may be necessary to support requirements 187 consolidated auditing views. 189 Application-level events, such as patient record access, are not 190 captured by system-level security audits. The defined data support 191 applications' record access auditing for healthcare institutional 192 security and privacy assurance plus related policy administration 193 functions. 195 System-local data definitions for collection and storage of audit 196 data, prior to transformation to a common schema and transmission to 197 a common repository, are not included in this document. 199 2.2 Anticipated Data End-uses 201 This document anticipates, but does not define, end-uses for the data 202 collected. 204 The typical healthcare IT environment contains many systems from 205 various vendors and developers who have not implemented common or 206 interoperable security administrative functions. This document 207 anticipates a requirement to transmit data from several unrelated 208 systems to a common repository. It also anticipates the aggregated 209 data may then be queried and viewed an a variety of ways. 211 There are distinctions of detail granularity, specificity, and 212 frequency between audit data required for surveillance versus 213 forensic purposes. While some surveillance data may be useful for 214 forensics, the scope of this document is limited to surveillance. 216 This document does not address access real-time policy violation 217 alarm actions. There is a perception in the healthcare community 218 that security measures that inhibit access may also inhibit effective 219 patient care, under some circumstances. 221 This document does not define any data for patient care consents or 222 patients' permissions for data disclosure. It is conceivable that 223 the proposed audit data could be input to such applications, however, 224 assuming strict access controls for audit data have been established. 226 This document does not define system-specific or application-specific 227 data that may be collected and reported in addition to the defined 228 elements. For example, it is conceivable that audit mechanisms may 229 be useful for tracking financial or payroll transactions. At the 230 same time, this document does not preclude extending the XML schema 231 to incorporate additional data. 233 There is a potential requirement for a set of administrative messages 234 to be sent from a central source to each participating system to 235 uniformly specify, control, enable, or disable audit data collection. 236 Such messages are not included in this document. 238 2.3 Conformance 240 This document does not include any definitions of conformance 241 practices. Instead, it anticipates that standards development 242 organizations that reference this document may specify their own 243 conformance requirements. 245 3. Goals 247 3.1 Effective Data Gathering 249 The process of assuring that security policies are implemented 250 correctly is essential to information security administration. It is 251 a set of interrelated tasks all aimed at maintaining an acceptable 252 level of confidence that security protections are, in fact, working 253 as intended. These tasks are assisted by data from automated 254 instrumentation of system and application functions. 256 Data gathered from a secured environment is used to accumulate 257 evidence that security systems are working as intended and to detect 258 incidents and patterns of misuse for further actions. Once messages 259 have been collected, various reports may be created in support of 260 security assurance and administration information requirements. 262 When a site runs multiple heterogeneous applications, each 263 application system may have its own security mechanisms - user logon, 264 roles, access right permissions and restrictions, etc. Each 265 application system also has its own security log file that records 266 security relevant events, e.g., login, data access, and updates to 267 the security policy databases. A system administrator or security 268 auditor must examine each of these log files to find security 269 relevant incidents. Not only is it difficult to examine each of 270 these files separately, the format and contents of each file may be 271 confusingly different. 273 Resolving these issues requires a framework to: 275 - Maximize interoperability and the meaningfulness of data across 276 applications and sites 277 - Minimize ambiguity among heterogeneous systems 278 - Simplify and limit the costs of administrative audit tasks. 280 3.2 Efficiency 282 One of the leading concerns about auditing is the potential volume of 283 data gathering and its impact on application system performance. 284 Although this document does not prescribe specific implementations or 285 strategies, the following are meant as informative guidance for 286 development. 288 1) Audits should be created for transactions or record-level data 289 access, not for individual attribute-level changes to data. 291 2) This document does not discourage locally optimized gathering of 292 audit data on each application system. Instead, it anticipates 293 implementation-defined periodic gathering and transmission of data 294 to a common repository. This common repository would be optimized 295 for after-the-fact audit queries and reporting, thus unburdening 296 each application system of those responsibilities. It is also 297 important to keep the message size compact so that audit data will 298 not penalize normal network operation. 300 3) On each application system, a variety of policy-based methods 301 could be employed to optimize data gathering and storage, e.g., 302 selective auditing of only events defined as important plus 303 workload buffering and balancing. Data gathering itself should be 304 stateless to avoid the overhead of transactional semantics. In 305 addition, prior to transmission, some filtering, aggregation, and 306 summarization of repeated events would reduce the number of 307 messages. Audit data storage and integrity on each application 308 system need only be scaled for relatively low-volume and short- 309 duration requirements, yet be consistent with implementation- 310 defined minimums for holding the data for subsequent collection. 312 4) Leveraging existing data collection should be considered. For 313 example, most commercial security subsystems record events in a 314 local common log file, so the log file data can be extracted for 315 communication to a common repository. Also, it is common in some 316 systems' designs to have a transaction log for data reconstruction 317 in event of database loss, so collecting data-update audit data 318 within this subsystem could reduce impact on application system 319 performance. 321 5) A security audit repository would gather all audit message data 322 from the different applications in one database with one standard 323 structure. This would allow easier evaluation and querying. Once 324 a suspicious pattern has been found in the audit log repository, 325 investigation might proceed with more detail in the application 326 specific audit log. The presence of a common repository also 327 simplifies and streamlines the implementation of policies for 328 audit data storage, integrity, retention, and destruction. 330 4. Trigger Events 332 The following identifies representative trigger events for generating 333 audit messages. This is not a complete list of trigger events. 335 For those events arising in the security infrastructure the "minimal" 336 and "basic" level of auditing as outlined in the Common 337 Criteria[ISO15408-2] should be used as a reference standard. 339 4.1 Security Administration 341 This group includes all actions that create, maintain, query, and 342 display definitions for securing data, functions, and the associated 343 access policies. For each trigger type, the creation, update or 344 amendment, deletion, and activation or deactivation are auditable. 346 4.1.1 Data Definition 348 This includes creation, modification, deletion, query, and display of 349 security attributes for data sets, data groups, or classes plus their 350 atomic data elements or attributes. 352 4.1.2 Function Definition 354 This includes, for example, creation, modification, deletion, query, 355 or display of security attributes and auditable events for the 356 application functions used for patient management, clinical 357 processes, registry of business objects and methods, program creation 358 and maintenance, etc. 360 4.1.3 Domain Definition 362 This includes all activities to create, modify, delete, query, or 363 display security domains according to various organizational 364 categories such as entity-wide, institutional, departmental, etc.: 366 4.1.4 Classification Definition 368 This includes all activities that create, modify, delete, query or 369 display security categories or groupings for functions and data such 370 as patient management, nursing, clinical, etc. 372 4.1.5 Permission Definition 374 This includes all activities that create, modify, delete, query or 375 display the allowable access permissions associated with functions 376 and data, such as create, read, update, delete, and execution of 377 specific functional units or object access or manipulation methods. 379 4.1.6 Role Definition 381 This includes all activities that create, modify, delete, query or 382 display security roles according to various task-grouping categories 383 such as security administration, admissions desk, nurses, physicians, 384 clinical specialists, etc. It also includes the association of 385 permissions with roles for role-based access control. 387 4.1.7 User Definition 389 This includes all activities that create, modify, delete, query, or 390 display user accounts. It includes password or other authentication 391 data. It also includes the association of roles with users for role- 392 based access control, or permissions with users for user-based access 393 control. 395 4.2 Audit Administration and Data Access 397 This category includes all actions that determine the collection and 398 availability of audit data. 400 4.2.1 Auditable Event Enable or Disable 402 This reflects a basic policy decision that an event should or should 403 not be audited. Some, but not necessarily all, triggers or use cases 404 must create an audit record. The selection of what to audit depends 405 on administrative policy decisions. Note that, for integrity, this 406 event should always be audited. 408 4.2.2 Audit Data Access 410 This includes instances where audit data is viewed or reported for 411 any purpose. Since the audit data itself may include data protected 412 by institutional privacy policies and expose the implementation of 413 those policies, access to the data is highly sensitive. This event 414 should therefore always be audited. 416 4.2.3 Audit Data Modify or Delete 418 This includes instances where audit data is modified or deleted. 419 While such operations are sometimes permitted by systems policies, 420 modification or destruction of audit data may well be the result of 421 unauthorized hostile systems access. Therefore, this type of event 422 should always be audited. 424 4.3 User Access 426 This category includes events of access to secured data and functions 427 for which audit data might be collected. 429 4.3.1 Sign-On 431 This includes successful and unsuccessful attempts from human users 432 and automated system. It also includes re-authentication actions and 433 re-issuing time-sensitive credentials such as Kerberos tickets. 435 4.3.2 Sign-Off 437 This includes explicit sign-off events and session abandonment 438 timeouts from human users and automated systems. 440 4.3.3 Function Access 442 This includes user invocation of application or system functions that 443 have permission definitions associated with them. Note that in a 444 Discretionary Access Control environment not all functions require 445 permissions, especially if their impact is benign in relation to 446 security policies. 448 The following are examples of trigger events relevant to healthcare 449 privacy. The actual triggers for institutional data access, policies 450 for non-care functions, and support regulatory requirements need to 451 be identified by application-domain standards developers and system 452 implementers. 454 4.3.3.1 Subject of Care Record Access 456 This includes all functions which manipulate basic patient data: 458 - Create, e.g., demographics or patient profile 459 - Assign identifier, e.g., medical record number 460 - Update, amend 461 - Merge/unmerge, e.g., combine multiple medical records for one 462 patient 463 - Import/export of data from/to an external source, including 464 printing and creation of portable media copies. 465 - Delete, e.g., invalid creation of care record 467 4.3.3.2 Encounter or Visit 469 This includes all functions which associate a subject of care with an 470 instance of care: 472 - Create, e.g., demographics or patient profile 473 - Assign encounter identifier 474 - Per-admit 475 - Admit 476 - Update, amend 477 - Delete, e.g., invalid creation of encounter record, breakdown of 478 equipment, patient did not arrive as expected 480 4.3.3.3 Care Protocols 482 This includes all functions which associate care plans or similar 483 protocols with an instance or subject of care: 485 - Schedule, initiate 486 - Update, amend 487 - Complete 488 - Cancel 490 4.3.3.4 Episodes or Problems 492 This includes specific clinical episodes within an instance of care. 493 Initiate 495 - Update, amend 496 - Resolve, complete 497 - Cancel 499 4.3.3.5 Orders and Order Sets 501 This includes clinical or supplies orders within an instance or 502 episode of care. 504 - Initiate 505 - Update, amend 506 - Check for contraindications 507 - Verify 508 - Deliver/complete - including instructions 509 - Cancel 511 4.3.3.6 Health Service Event or Act 513 This includes various health services scheduled and performed within 514 an instance or episode of care 516 - Schedule, initiate 517 - Update, amend 518 - Check for contraindications 519 - Verify 520 - Perform/complete - including instructions 521 - Cancel 523 4.3.3.7 Medications 525 This includes all medication orders and administration within an 526 instance or episode of care. 528 - Order 529 - Check 530 - Check for interactions 531 - Verify 532 - Dispense/deliver - including administration instructions 533 - Administer 534 - Cancel 536 4.3.3.8 Staff/Participant Assignment 538 This includes staffing or participant assignment actions relevant to 539 an instance or episode of care. 541 - Assignment of healthcare professionals, caregivers attending 542 physician, residents, medical students, consultants, etc. 543 - Change in assigned role or authorization, e.g., relative to 544 healthcare status change. 545 - De-assignment 547 5. Data Definitions 549 This section defines and describes the data in the XML schema. The 550 actual XML schema definition is in section 6. 552 The proposed data elements are grouped into these categories: 554 1) Event Identification - what was done 555 2) Active Participant Identification - by whom 556 3) Network Access Point Identification - initiated from where 557 4) Audit Source Identification - using which server 558 5) Participant Object Identification - to what record 560 5.1 Event Identification 562 The following data identify the name, action type, time, and 563 disposition of the audited event. There is only one set of event 564 identification data per audited event. 566 5.1.1 Event ID 568 Description 570 Identifier for a specific audited event, e.g., a menu item, 571 program, rule, policy, function code, or application name, or URL. 572 It identifies the performed function. 574 Optionality: Required 575 Format / Values 577 Coded value, either defined by the system implementers or as a 578 reference to a standard vocabulary. The "code" attribute must be 579 unambiguous and unique, at least within Audit Source ID (see 580 section 5.4). Examples of Event IDs are program name, method 581 name, or function name. 583 For implementation defined coded values or references to 584 standards, the XML schema defines these optional attributes: 586 Attribute Value 587 -------------- -------------------------------------------- 588 CodeSystem OID reference 589 CodeSystemName Name of the coding system; strongly recommended 590 to be valued for locally-defined code-sets. 591 DisplayName The value to be used in displays and reports 592 OriginalText Input value that was translated to the code 594 To support the requirement for unambiguous event identification, 595 multiple values may not be specified. 597 Rationale 599 This identifies the audited function. For "Execute" Event Action 600 Code audit records, this identifies the application function 601 performed. 603 5.1.2 Event Action Code 605 Description 607 Indicator for type of action performed during the event that 608 generated the audit. 610 Optionality: Optional 612 Format / Values 614 Enumeration: 616 Value Meaning Examples 617 ----- --------------------- ---------------------------------- 618 C Create Create a new database object, such 619 as Placing an Order. 620 R Read/View/Print/Query Display or print data, such as a 621 Doctor Census 622 U Update Update data, such as Revise 623 Patient Information 625 D Delete Delete items, such as a doctor 626 master file record 627 E Execute Perform a system or application 628 function such as logon, program 629 execution, or use of an object's 630 method 632 Rationale 634 This broadly indicates what kind of action was done on the 635 Participant Object. 637 Notes 639 Actions that are not enumerated above are considered an Execute of 640 a specific function or object interface method or treated two or 641 more distinct events. An application action, such as an 642 authorization, is a function Execute, and the Event ID would 643 identify the function. 645 For some applications, such as radiological imaging, a Query 646 action may only determine the presence of data but not access the 647 data itself. Auditing need not make as fine a distinction. 649 Compound actions, such as "Move," would be audited by creating 650 audit data for each operation - read, create, delete - or as an 651 Execute of a function or method. 653 5.1.3 Event Date/Time 655 Description 657 Universal coordinated time (UTC), i.e. a date/time specification 658 that is unambiguous as to local time zones. 660 Optionality: Required 662 Format / Values 664 A date/time representation that is unambiguous in conveying 665 universal coordinated time (UTC), formatted according to the ISO 666 8601 standard[ISO8601] 668 Rationale 670 This ties an event to a specific date and time. Security audits 671 typically require a consistent time base, e.g., UTC, to eliminate 672 time-zone issues arising from geographical distribution. 674 Notes 676 In a distributed system, some sort of common time base, e.g., an 677 NTP[RFC1305]server, is a good implementation tactic. 679 5.1.4 Event Outcome Indicator 681 Description 683 Indicates whether the event succeeded or failed. 685 Optionality: Required 687 Format / Values 689 Enumeration: 691 Value Meaning 692 ---- ---------------------------------------------------- 693 0 Success 694 4 Minor failure; action restarted, e.g., invalid password 695 with first retry 696 8 Serious failure; action terminated, e.g., invalid 697 password with excess retries 698 12 Major failure; action made unavailable, e.g., user 699 account disabled due to excessive invalid logon attempts 701 Rationale 703 Some audit events may be qualified by success or failure 704 indicator. For example, a Logon might have this flag set to a 705 non-zero value to indicate why a logon attempt failed. 707 Notes 709 In some cases a "success" may be partial, for example, an 710 incomplete or interrupted transfer of a radiological study. For 711 the purpose of establishing accountability, these distinctions are 712 not relevant. 714 5.1.5 Event Type Code 716 Description 718 Identifier for the category of event. 720 Optionality: Optional 721 Format / Values 723 Coded value enumeration, either defined by the system implementers 724 or as a reference to a standard vocabulary. For implementation 725 defined codes or references to standards, the XML schema defines 726 these optional attributes: 728 Attribute Value 729 -------------- -------------------------------------------- 730 CodeSystem OID reference 731 CodeSystemName Name of the coding system; strongly recommended 732 to be valued for locally-defined code-sets. 733 DisplayName The value to be used in displays and reports 734 OriginalText Input value that was translated to the code 736 Since events may be categorized in more than one way, there may be 737 multiple values specified. 739 Rationale 741 This field enables queries of messages by implementation-defined 742 event categories. 744 5.2 Active Participant Identification 746 The following data identify a user for the purpose of documenting 747 accountability for the audited event. A user may be a person, or a 748 hardware device or software process for events that are not initiated 749 by a person. 751 Optionally, the user's network access location may be specified. 753 There may be more than one user per event, for example, in cases of 754 actions initiated by one user for other users, or in events that 755 involve more than one user, hardware device, or system process. 756 However, only one user may be the initiator/requestor for the event. 758 5.2.1 User ID 760 Description 762 Unique identifier for the user actively participating in the event 764 Optionality: Required 766 Format / Values 768 User identifier text string from the authentication system. It is 769 a unique value within the Audit Source ID (see section 5.4). 771 Rationale 773 This field ties an audit event to a specific user. 775 Notes 777 For cross-system audits, especially with long retention, this user 778 identifier will permanently tie an audit event to a specific user 779 via a perpetually unique key. 781 For node-based authentication -- where only the system hardware or 782 process, but not a human user, is identified -- User ID would be 783 the node name. 785 5.2.2 Alternative User ID 787 Description 789 Alternative unique identifier for the user 791 Optionality: Optional 793 Format / Values 795 User identifier text string from authentication system. This 796 identifier would be one known to a common authentication system 797 (e.g., single sign-on), if available. 799 Rationale 801 In some situations a user may authenticate with one identity but, 802 to access a specific application system, may use a synonymous 803 identify. For example, some "single sign on" implementations will 804 do this. The alternative identifier would then be the original 805 identify used for authentication, and the User ID is the one known 806 to and used by the application. 808 5.2.3 User Name 810 Description 812 The human-meaningful name for the user 814 Optionality: Optional 816 Format / Values 818 Text string 820 Rationale 822 The User ID and Alternative User ID may be internal or otherwise 823 obscure values. This field assists the auditor in identifying the 824 actual user. 826 5.2.4 User Is Requestor 828 Description 830 Indicator that the user is or is not the requestor, or initiator, 831 for the event being audited. 833 Optionality: Optional 835 Format / Values 837 Boolean, default/assumed value is "true" 839 Rationale 841 This value is used to distinguish between requestor-users and 842 recipient-users. For example, one person may initiate a report- 843 output to be sent to a another user. 845 5.2.5 Role ID Code 847 Description 849 Specification of the role(s) the user plays when performing the 850 event, as assigned in role-based access control security 852 Optionality: Optional; multi-valued 854 Format / Values 856 Coded value, with attribute "code" valued with the role code or 857 text from authorization system. More than one value may be 858 specified. 860 The codes may be implementation-defined or reference a standard 861 vocabulary enumeration. For implementation defined codes or 862 references to standards, the XML schema defines these optional 863 attributes: 865 Attribute Value description 866 -------------- -------------------------------------------- 867 CodeSystem OID reference 868 CodeSystemName Name of the coding system; strongly recommended 869 to be valued for locally-defined code-sets. 871 Display Name The value to be used in displays and reports 872 OriginalText Input value that was translated to the code 874 Rationale 876 This value ties an audited event to a user's role(s). It is an 877 optional value that might be used to group events for analysis by 878 user functional role categories. 880 Notes 882 Many security systems are unable to produce this data, hence it is 883 optional. 885 For the common message, this identifier would be the one known to 886 a common authorization system, if available. Otherwise, it is a 887 unique value within the Audit Source ID (see section 5.4). 888 Consider using a globally unique identifier associated with the 889 role to avoid ambiguity in auditing data collected from multiple 890 systems. 892 Role ID is not a substitute for personal accountability. 894 Ambiguities arise from composite roles and users with multiple 895 roles, i.e., which role within a composite is being used or what 896 privilege was a user employing? 898 5.3 Network Access Point Identification 900 The network access point identifies the logical network location for 901 application activity. These data are paired 1:1 with the Active 902 Participant Identification data. 904 5.3.1 Network Access Point Type Code 906 Description 908 An identifier for the type of network access point that originated 909 the audit event. 911 Optionality: Optional 913 Format / Values 915 Enumeration: 917 Value Meaning 918 ----- -------------------------------- 919 1 Machine Name, including DNS name 920 2 IP Address 921 3 Telephone Number 923 Rationale 925 This datum identifies the type of network access point identifier 926 of the user device for the audit event. It is an optional value 927 that may be used to group events recorded on separate servers for 928 analysis of access according to a network access point's type. 930 5.3.2 Network Access Point ID 932 Description 934 An identifier for the network access point of the user device for 935 the audit event. This could be a device id, IP address, or some 936 other identifier associated with a device. 938 Optionality: Optional 940 Format / Values 942 Text may be constrained to only valid values for the given Network 943 Access Point Type, if specified. Recommendation is to be as 944 specific as possible where multiple options are available. 946 Rationale 948 This datum identifies the user's network access point, which may 949 be distinct from the server that performed the action. It is an 950 optional value that may be used to group events recorded on 951 separate servers for analysis of a specific network access point's 952 data access across all servers. 954 Note 956 Network Access Point ID is not a substitute for personal 957 accountability. Internet IP addresses, in particular, are highly 958 volatile and may be assigned to more than one person in a short 959 time period. 961 Examples 963 Network Access Point ID: SMH4WC02 964 Network Access Point Type: 1 = Machine Name 966 Network Access Point ID: 192.0.2.2 967 Network Access Point Type: 2 = IP address 969 Network Access Point ID: 610-555-1212 970 Network Access Point Type: 3 = Phone Number 972 5.4 Audit Source Identification 974 The following data are required primarily for application systems and 975 processes. Since multi-tier, distributed, or composite applications 976 make source identification ambiguous, this collection of fields may 977 repeat for each application or process actively involved in the 978 event. For example, multiple value-sets can identify participating 979 web servers, application processes, and database server threads in an 980 n-tier distributed application. Passive event participants, e.g., 981 low-level network transports, need not be identified. 983 Depending on implementation strategies, it is possible that the 984 components in a multi-tier, distributed, or composite applications 985 may generate more than one audit message for a single application 986 event. Various data in the audit message may be used to identify 987 such cases, supporting subsequent data reduction. This document 988 anticipates that the repository and reporting mechanisms will perform 989 data reduction when required, but does not specify those mechanism. 991 5.4.1 Audit Enterprise Site ID 993 Description 995 Logical source location within the healthcare enterprise network, 996 e.g., a hospital or other provider location within a multi-entity 997 provider group. 999 Optionality: Optional 1001 Format / Values 1003 Unique identifier text string within the healthcare enterprise. 1004 May be unvalued when the audit-generating application is uniquely 1005 identified by Audit Source ID. 1007 Rationale 1009 This value differentiates among the sites in a multi-site 1010 enterprise health information system. 1012 Notes 1014 This is defined by the application that generates the audit 1015 record. It contains a unique code that identifies a business 1016 organization (owner of data) that is known to the enterprise. The 1017 value further qualifies and disambiguates the Audit Source ID. 1018 Values may vary depending on type of business. There may be 1019 levels of differentiation within the organization. 1021 5.4.2 Audit Source ID 1023 Description 1025 Identifier of the source where the event originated. 1027 Optionality: Required 1029 Format / Values 1031 Unique identifier text string, at least within the Audit 1032 Enterprise Site ID 1034 Rationale 1036 This field ties the event to a specific source system. It may be 1037 used to group events for analysis according to where the event 1038 occurred. 1040 Notes 1042 In some configurations, a load-balancing function distributes work 1043 among two or more duplicate servers. The values defined for this 1044 field thus may be considered as an source identifier for a group 1045 of servers rather than a specific source system. 1047 5.4.3 Audit Source Type Code 1049 Description 1051 Code specifying the type of source where event originated. 1053 Optionality: Optional 1055 Format / Values 1057 Coded-value enumeration, optionally defined by system implementers 1058 or a as a reference to a standard vocabulary. Unless defined or 1059 referenced, the default values for the "code" attribute are: 1061 Value Meaning 1062 ----- ------------------------------------------------------ 1063 1 End-user interface 1064 2 Data acquisition device or instrument 1065 3 Web server process tier in a multi-tier system 1066 4 Application server process tier in a multi-tier system 1067 5 Database server process tier in a multi-tier system 1068 6 Security server, e.g., a domain controller 1069 7 ISO level 1-3 network component 1070 8 ISO level 4-6 operating software 1071 9 External source, other or unknown type 1073 For implementation defined codes or references to standards, the 1074 XML schema defines these optional attributes: 1076 Attribute Value 1077 -------------- -------------------------------------------- 1078 CodeSystem OID reference 1079 CodeSystemName Name of the coding system; strongly recommended 1080 to be valued for locally-defined code-sets. 1081 DisplayName The value to be used in displays and reports 1082 OriginalText Input value that was translated to the code 1084 Since audit sources may be categorized in more than one way, there 1085 may be multiple values specified. 1087 Rationale 1089 This field indicates which type of source is identified by the 1090 Audit Source ID. It is an optional value that may be used to 1091 group events for analysis according to the type of source where 1092 the event occurred. 1094 5.5 Participant Object Identification 1096 The following data assist the auditing process by indicating specific 1097 instances of data or objects that have been accessed. 1099 These data are required unless the values for Event Identification, 1100 Active Participant Identification, and Audit Source Identification 1101 are sufficient to document the entire auditable event. Production of 1102 audit records containing these data may be enabled or suppressed, as 1103 determined by healthcare organization policy and regulatory 1104 requirements. 1106 Because events may have more than one participant object, this group 1107 can be a repeating set of values. For example, depending on 1108 institutional policies and implementation choices: 1110 - Two participant object value-sets can be used to identify access 1111 to patient data by medical record number plus the specific health 1112 care encounter or episode for the patient. 1113 - A patient participant and his authorized representative may be 1114 identified concurrently. 1115 - An attending physician and consulting referrals may be identified 1116 concurrently. 1117 - All patients identified on a worklist may be identified. 1118 - For radiological studies, a set of related participant objects 1119 identified by accession number or study number, may be identified. 1121 Note, though, that each audit message documents only a single usage 1122 instance of such participant object relationships and does not serve 1123 to document all relationships that may be present or possible. 1125 5.5.1 Participant Object Type Code 1127 Description 1129 Code for the participant object type being audited. This value is 1130 distinct from the user's role or any user relationship to the 1131 participant object. 1133 Optionality: Optional 1135 Format / Values 1137 Enumeration: 1139 Value Meaning 1140 ----- ------------- 1141 1 Person 1142 2 System Object 1143 3 Organization 1144 4 Other 1146 Rationale 1148 To describe the object being acted upon. In addition to queries on 1149 the subject of the action in an auditable event, it is also 1150 important to be able to query on the object type for the action. 1152 5.5.2 Participant Object Type Code Role 1154 Description 1156 Code representing the functional application role of Participant 1157 Object being audited 1159 Optionality: Optional 1161 Format / Values 1163 Enumeration, specific to Participant Object Type Code: 1165 Value Meaning Participant Object Type Codes 1166 ----- -------------------- ---------------------------------- 1167 1 Patient 1 - Person 1168 2 Location 3 - Organization 1169 3 Report 2 - System Object 1170 4 Resource 1 - Person 1171 3 - Organization 1172 5 Master file 2 - System Object 1173 6 User 1 - Person 1174 2 - System Object (non-human user) 1175 7 List 2 - System Object 1176 8 Doctor 1 - Person 1177 9 Subscriber 3 - Organization 1178 10 Guarantor 1 - Person 1179 3 - Organization 1180 11 Security User Entity 1 - Person 1181 2 - System Object 1182 12 Security User Group 2 - System Object 1183 13 Security Resource 2 - System Object 1184 14 Security Granularity 2 - System Object 1185 Definition 1186 15 Provider 1 - Person 1187 3 - Organization 1188 16 Data Destination 2 - System Object 1189 17 Data Repository 2 - System Object 1190 18 Schedule 2 - System Object 1191 19 Customer 3 - Organization 1192 20 Job 2 - System Object 1193 21 Job Stream 2 - System Object 1194 22 Table 2 - System Object 1195 23 Routing Criteria 2 - System Object 1196 24 Query 2 - System Object 1198 A "Security Resource" is an abstract securable object, e.g., a 1199 screen, interface, document, program, etc. -- or even an audit 1200 data set or repository. 1202 Rationale 1204 For some detailed audit analysis it may be necessary to indicate a 1205 more granular type of participant, based on the application role 1206 it serves. 1208 5.5.3 Participant Object Data Life Cycle 1210 Description 1212 Identifier for the data life-cycle stage for the participant 1213 object. This can be used to provide an audit trail for data, over 1214 time, as it passes through the system 1216 Optionality: Optional 1217 Format/Values 1219 Enumeration: 1221 Value Meaning 1222 ----- -------------------------------------- 1223 1 Origination / Creation 1224 2 Import / Copy from original 1225 3 Amendment 1226 4 Verification 1227 5 Translation 1228 6 Access / Use 1229 7 De-identification 1230 8 Aggregation, summarization, derivation 1231 9 Report 1232 10 Export / Copy to target 1233 11 Disclosure 1234 12 Receipt of disclosure 1235 13 Archiving 1236 14 Logical deletion 1237 15 Permanent erasure / Physical destruction 1239 Rationale 1241 Institutional policies for privacy and security may optionally 1242 fall under different accountability rules based on data life 1243 cycle. This provides a differentiating value for those cases. 1245 5.5.4 Participant Object ID Type Code 1247 Description 1249 Describes the identifier that is contained in Participant Object 1250 ID. 1252 Optionality: Required 1254 Format / Values 1256 Coded-value enumeration, specific to Participant Object Type Code, 1257 using attribute-name "code". The codes below are the default set. 1259 Value Meaning Participant Object Type Codes 1260 ----- ---------------------- ----------------------------- 1261 1 Medical Record Number 1 - Person 1262 2 Patient Number 1 - Person 1263 3 Encounter Number 1 - Person 1264 4 Enrollee Number 1 - Person 1265 5 Social Security Number 1 - Person 1266 6 Account Number 1 - Person 1267 3 - Organization 1268 7 Guarantor Number 1 - Person 1269 3 - Organization 1270 8 Report Name 2 - System Object 1271 9 Report Number 2 - System Object 1272 10 Search Criteria 2 - System Object 1273 11 User Identifier 1 - Person 1274 2 - System Object 1275 12 URI 2 - System Object 1277 User Identifier and URI[RFC2396] text strings are intended to be 1278 used for security administration trigger events to identify the 1279 objects being acted-upon. 1281 The codes may be the default set stated above, implementation- 1282 defined, or reference a standard vocabulary enumeration, such as 1283 HL7 version 2.4 table 207 or DICOM defined media types. For 1284 implementation defined codes or references to standards, the XML 1285 schema defines these optional attributes: 1287 Attribute Value 1288 -------------- -------------------------------------------- 1289 CodeSystem OID reference 1290 CodeSystemName Name of the coding system; strongly recommended 1291 to be valued for locally-defined code-sets. 1292 DisplayName The value to be used in displays and reports 1293 OriginalText Input value that was translated to the code 1295 Rationale 1297 Required to distinguish among various identifiers that may 1298 synonymously identify a participant object. 1300 5.5.5 Participant Object Sensitivity 1302 Description 1304 Denotes policy-defined sensitivity for the Participant Object ID 1305 such as VIP, HIV status, mental health status, or similar topics. 1307 Optionality: Optional 1309 Format / Values 1311 Values are institution- and implementation-defined text strings. 1313 5.5.6 Participant Object ID 1315 Description 1317 Identifies a specific instance of the participant object 1319 Optionality: Required 1321 Format / Values 1323 Text string. Value format depends on Participant Object Type Code 1324 and the Participant Object ID Type Code. 1326 Rationale 1328 This field identifies a specific instance of an object, such as a 1329 patient, to detect/track privacy and security issues. 1331 Notes 1333 Consider this to be the primary unique identifier key for the 1334 object, so it may be a composite data field as implemented. 1336 5.5.7 Participant Object Name 1338 Description 1340 An instance-specific descriptor of the Participant Object ID 1341 audited, such as a person's name 1343 Optionality: Optional 1345 Format / Values 1347 Text string 1349 Rationale 1351 This field may be used in a query/report to identify audit events 1352 for a specific person, e.g., where multiple synonymous Participant 1353 Object IDs (patient number, medical record number, encounter 1354 number, etc.) have been used. 1356 5.5.8 Participant Object Query 1358 Description 1360 The actual query for a query-type participant object. 1362 Optionality: Optional 1363 Format / Values 1365 Base 64 encoded data 1367 Rationale 1369 For query events it may be necessary to capture the actual query 1370 input to the query process in order to identify the specific 1371 event. Because of differences among query implementations and 1372 data encoding for them, this is a base 64 encoded data blob. It 1373 may be subsequently decoded or interpreted by downstream audit 1374 analysis processing. 1376 5.5.9 Participant Object Detail 1378 Description 1380 Implementation-defined data about specific details of the object 1381 accessed or used 1383 Optionality: Optional 1385 Format 1387 Type-value pair. The "type" attribute is an implementation- 1388 defined text string. The "value" attribute is a base 64 encoded 1389 data. 1391 Rationale 1393 Specific details or values from the object accessed may be desired 1394 in specific auditing implementations. The type-value pair enables 1395 the use of implementation-defined and locally-extensible object 1396 type identifiers and values. For example, a clinical diagnostic 1397 object may contain multiple test results, and this element could 1398 document the type and number and type of results. 1400 Many possible data encodings are possible for this elements, so 1401 the value is a base 64 encoded data blob. It may be subsequently 1402 decoded or interpreted by downstream audit analysis processing. 1404 6. XML Schema 1406 This section contains the actual XML schema definition for the data 1407 defined in section 5. It also provides brief guidance for specifying 1408 schema localizations for implementation purposes. 1410 The XML schema specified in section 6.1 conforms with the W3C 1411 Recommendations for XML Schema structure[W3CXML-1] and data 1412 types[W3CXML-2]. 1414 6.1 XML Schema Definition 1416 1418 1419 1420 1421 1423 1424 1425 1426 1427 1428 1429 1430 1432 1435 1436 1437 1438 1439 1440 1441 1443 1444 1445 1446 1447 1448 1449 Create 1450 1451 1452 1453 1454 Read 1455 1456 1457 1458 1459 Update 1461 1462 1463 1464 1465 Delete 1466 1467 1468 1469 1470 Execute 1471 1472 1473 1474 1475 1476 1478 1479 1480 1481 1482 1483 Success 1484 1485 1486 1487 1488 Minor failure 1489 1490 1491 1492 1493 Serious failure 1494 1495 1496 1497 1498 Major failure; action made unavailable 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1510 1511 1512 1513 1514 1515 1516 1517 1518 End-user display device, diagnostic 1519 display 1520 1521 1522 1523 1524 Data acquisition device or 1525 instrument 1526 1527 1528 1529 1530 Web server process 1531 1532 1533 1534 1535 Application server process 1536 1537 1538 1539 1540 Database server process 1541 1542 1543 1544 1545 Security server, e.g., a domain 1546 controller 1547 1548 1549 1550 1551 ISO level 1-3 network 1552 component 1553 1554 1555 1556 1557 ISO level 4-6 operating software 1558 1559 1560 1561 1562 External source, other or unknown 1563 type 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1576 1578 1579 1580 1581 1583 1584 1585 1587 1588 1590 1592 1593 1594 1595 1596 1597 Machine Name, including DNS name 1598 1599 1600 1601 1602 IP Address 1603 1604 1605 1606 1607 Telephone Number 1608 1609 1610 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 Medical Record Number 1627 1628 1629 1630 1631 Patient Number 1632 1633 1634 1635 1636 Encounter Number 1637 1638 1639 1640 1641 Enrollee Number 1642 1643 1644 1645 1646 Social Security Number 1647 1648 1649 1650 1651 Account Number 1652 1653 1654 1655 1656 Guarantor Number 1657 1658 1659 1660 1661 Report Name 1663 1664 1665 1666 1667 Report Number 1668 1669 1670 1671 1672 Search Criteria 1673 1674 1675 1676 1677 User Identifier 1678 1679 1680 1681 1682 URI 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1696 1698 1699 1701 1702 1704 1705 1706 1707 1708 1709 Person 1710 1711 1712 1713 1714 System object 1715 1716 1717 1718 1719 Organization 1720 1721 1722 1723 1724 Other 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 Patient 1736 1737 1738 1739 1740 Location 1741 1742 1743 1744 1745 Report 1746 1747 1748 1749 1750 Resource 1751 1752 1753 1754 1755 Master file 1756 1757 1758 1759 1760 User 1761 1762 1763 1764 1765 List 1766 1767 1768 1769 1770 Doctor 1771 1772 1773 1774 1775 Subscriber 1776 1777 1778 1779 1780 Guarantor 1781 1782 1783 1784 1785 Security User Entity 1786 1787 1788 1789 1790 Security User Group 1791 1792 1793 1794 1795 Security Resource 1796 1797 1798 1799 1800 Security Granualarity Definition 1801 1802 1803 1804 1805 Provider 1806 1807 1808 1809 1810 Report Destination 1811 1812 1813 1814 1815 Report Library 1816 1817 1818 1819 1820 Schedule 1821 1822 1823 1824 1825 Customer 1826 1827 1828 1829 1830 Job 1831 1832 1833 1834 1835 Job Stream 1836 1837 1838 1839 1840 Table 1841 1842 1843 1844 1845 Routing Criteria 1846 1847 1848 1849 1850 Query 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 Origination / Creation 1862 1864 1865 1866 1867 Import / Copy from original 1868 1869 1870 1871 1872 Amendment 1873 1874 1875 1876 1877 Verification 1878 1879 1880 1881 1882 Translation 1883 1884 1885 1886 1887 Access / Use 1888 1889 1890 1891 1892 De-identification 1893 1894 1895 1896 1897 Aggregation, summarization, 1898 derivation 1899 1900 1901 1902 1903 Report 1904 1905 1906 1907 1908 Export / Copy to target 1909 1910 1911 1912 1913 Disclosure 1915 1916 1917 1918 1919 Receipt of disclosure 1920 1921 1922 1923 1924 Archiving 1925 1926 1927 1928 1929 Logical deletion 1930 1931 1932 1933 1934 Permanent erasure / Physical destruction 1935 1936 1937 1938 1939 1940 1941 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1958 1959 1960 1961 1962 1963 1964 1966 6.2 XML Schema Localization 1968 The schema specified in section 6.1 may be extended and restricted to 1969 meet local implementation-specific requirements. W3C Recommendation 1970 for XML Schema structure[W3CXML-1], section 4, is the governing 1971 standard for accomplishing this. 1973 As of the current version of this document, a public reference URI 1974 for the base schema has not been established. 1976 Local definitions reference the common audit message base schema. For 1977 example, here is a schema with a local vocabulary restriction for 1978 "Audit Enterprise Site ID" plus an extension adding a new "Audit 1979 Source Asset Number" element. 1981 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2008 2009 2010 2011 2012 2014 7. Security Considerations 2016 Audit data must be secured at least to the same extent as the 2017 underlying data and activities being audited. This includes access 2018 controls as well as data integrity and recovery functions. This 2019 document acknowledges the need for, but does not specify, the 2020 policies and technical methods to accomplish this. 2022 It is conceivable that audit data might have unintended uses, e.g., 2023 tracking the frequency and nature of system use for productivity 2024 measures. ASTM standard E2147-01[E2147] states, in paragraph 5.3.10, 2025 "Prohibit use for other reasons than to enforce security and to 2026 detect security breaches in record health information systems, for 2027 example, the audits are not to be used to explore activity profiles 2028 or movement profiles of employees." 2030 Some audit data arise from security-relevant processes other than 2031 data access. These are the trigger events listed in section 4.1 and 2032 4.2 of this document. Audit data defined in this document can record 2033 the accountabilities for and results of these processes, as part of a 2034 complete security implementation. A discussion of the associated 2035 authorities, reference standards, and implementation technology 2036 choices for the processes is outside the scope of this document. 2038 8. References 2040 8.1 Normative References 2042 [E2147] "E2147-01 Standard Specification for Audit and Disclosure 2043 Logs for Use in Health Information Systems," ASTM 2044 International, June 2002 2046 [ISO15408-2]"ISO/IEC 15408:1999 Common Criteria for Information 2047 Technology Security Evaluation, Part 2: Security 2048 Functional Requirements," ISO, August 1999 2050 [ISO8601] "ISO 8601:2000 Data elements and interchange formats -- 2051 Information interchange -- Representation of dates and 2052 times," ISO, December, 2000 2054 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2055 Specification, Implementation," RFC 1305, March 1992. 2057 [RFC2396] Berners-Lee, et. al., "Uniform Resource Identifiers 2058 (URI): Generic Syntax," RFC 2396, August 1998 2060 [W3CXML-1] W3C Recommendation "XML Schema Part 1: Structures," 2061 version 1.0, May 2001 2063 [W3CXML-2] W3C Recommendation "XML Schema Part 2: Datatypes," 2064 version 1.0, May 2001 2066 8.2 Informative References 2068 [HL7SASIG] Marshall, G., and Dickinson, G., "Common Audit Message," 2069 HL7 Security and Accountability Special Interest Group, 2070 November 2001 2072 [IHETF-3] "IHE Technical Framework," Volume III, HIMMS/RSNA, April 2073 2002 2075 [NEMASPC] "Security and Privacy Auditing in Health Care Information 2076 Technology," Joint NEMA/COCIR/JIRA Security and Privacy 2077 Committee, 26 June 2001 2079 Draft Change History 2081 Version Date Description 2082 00 12/02 Original draft publication 2083 01 02/03 1) Reword the Abstract to be more understandable to a 2084 wider audience. 2085 2) Revise Purpose and Scope and Data definition 2086 sections for clarity, in accordance with comments 2087 from several reviewers. 2088 3) Document default value for Event Action Code. 2089 4) Add Alternate User ID and User Name fields. 2090 5) Include participant object identifier support for 2091 objects of security administration trigger events. 2092 6) Update XML schema to agree with data definitions. 2093 02 03/03 1) Updated schema to make the "code" attribute in 2094 CodedValueType a required value. 2095 2) Minor wording changes to the Abstract for clarity. 2096 3) Added reference to "Security and Privacy Auditing 2097 in Health Care Information Technology", by the 2098 Joint NEMA/COCIR/JIRA Security and Privacy 2099 Committee. 2100 03 04/03 1) Clarified that function access detail definitions 2101 in section 4.3.3 are non-normative examples 2102 2) Specified optionalities of data items separately 2103 from descriptions 2104 3) Added normative reference to ISO 8601:2000 standard 2105 for date and time data format 2106 4) Added Participant Object Detail element 2107 5) Minor editorial changes for clarity 2108 04 09/03 1) Added import, export, and logical deletion to the 2109 Participant Object Data Life Cycle enumeration. 2110 2) Renamed "Participant Object ID Sensitivity" to 2111 "Participant Object Sensitivity" 2113 3) Added "TypeValuePair" complex type to schema and 2114 changed Participant Object Detail to TypeValuePair 2115 type 2116 5) Added "Encounter Number" to Participant Object ID 2117 Type Code enumeration 2118 6) Added Event Type Code to Event Identification as a 2119 optional repeating Coded Value 2120 7) Added standards references, discussion, and an 2121 example of schema localization for implementation 2122 purposes 2123 8) Added a note that the User ID is the system or 2124 process name for node-based identification. 2125 9) Changed Event ID to a mandatory non-repeating Coded 2126 Value 2127 10)Changed Audit Source Type Code to an optional 2128 repeating Coded Value, added data acquisition 2129 device to the default value set, and clarified that 2130 end-user devices include diagnostic displays 2131 11)Minor editorial changes to fix typographical errors 2132 and improve clarity. 2133 05 10/03 1) Minor editorial changes to fix typographical errors 2134 and improve clarity. 2135 06 11/03 1) Minor editorial changes for clarity. 2136 2) Changes to introduction, suggested by RFC Editor. 2137 07 11/03 1) Minor editorial changes suggested by RFC Editor. 2138 08 12/03 1) Insertion of required RFC boilerplate and copyright, 2139 per RFC Editor. 2140 09 04/04 1) Correct problems found by IBM Schema Quality Check, 2141 per RFC Editor. 2142 10 04/04 1) Correct a problem and incorporate a suggestion, per 2143 RFC Editor 2144 11 05/04 1) Split References into Normative and Informative 2145 Sections 2146 12 05/04 1) Revised Security Considerations and made minor edits 2147 as requested by RFC Editor 2149 Acknowledgments 2151 The author gratefully acknowledges the advice and assistance of the 2152 following people during the preparation of this document: 2154 Carmela Couderc, Siemens Medical Solutions 2155 Michael Davis, SAIC 2156 Gary Dickinson 2157 Christoph Dickmann, Siemens Medical Solutions 2158 Daniel Hannum, Siemens Medical Solutions 2159 Robert Horn, Agfa 2160 James McAvoy, Siemens Medical Solutions 2161 John Moehrke, General Electric Medical Systems 2162 Jennifer Puyenbroek, McKesson Information Solutions 2163 Angela Ray, McKesson Information Solutions 2164 Lawrence Tarbox, Siemens Corporate Research 2166 Author's Address 2168 Glen Marshall 2169 Siemens Medical Solutions Health Services 2170 51 Valley Stream Parkway 2171 Malvern, PA 19312 2172 USA 2173 Phone: (610) 219-3938 2174 Email: glen.f.marshall@siemens.com 2176 Copyright Statement 2178 Copyright (C) The Internet Society 2003. All Rights Reserved. 2180 This document and translations of it may be copied and furnished to 2181 others, and derivative works that comment on or otherwise explain it 2182 or assist in its implementation may be prepared, copied, published 2183 and distributed, in whole or in part, without restriction of any 2184 kind, provided that the above copyright notice and this paragraph are 2185 included on all such copies and derivative works. However, this 2186 document itself may not be modified in any way, such as by removing 2187 the copyright notice or references to the Internet Society or other 2188 Internet organizations, except as needed for the purpose of 2189 developing Internet standards in which case the procedures for 2190 copyrights defined in the Internet Standards process must be 2191 followed, or as required to translate it into languages other than 2192 English. 2194 The limited permissions granted above are perpetual and will not be 2195 revoked by the Internet Society or its successors or assigns. 2197 This document and the information contained herein is provided on an 2198 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2199 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2200 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2201 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2202 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."