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."