5 ihe it infrastructure technical framework supplement … · · 2005-03-30ihe it infrastructure...

Copyright © 2004: ACC/HIMSS/RSNA

Integrating the Healthcare Enterprise

5

IHE IT Infrastructure Technical Framework Supplement 2004-2005

Audit Trail and Node Authentication Profile 10

(ATNA)

15

Trial Implementation Version

Publication Date: August 15, 2004

IHE IT Infrastructure Technical Framework –ATNA Supplement ______________________________________________________________________________

__________________________________________________________________________

Trial Implementation Version Copyright © 2004: ACC/HIMSS/RSNA 2004-08-15

1

Contents 20 Foreword ......................................................................................................................................... 2 Profile Abstract ............................................................................................................................... 4 Volume I – Integration Profiles ...................................................................................................... 6 9. Audit Trail and Node Authentication (ATNA).......................................................................... 7

Key Features of ATNA .............................................................................................................. 7 25 ATNA Security Assumptions .................................................................................................... 8

9.1 Connection Authentication ................................................................................................. 9 9.2 Audit Trails ......................................................................................................................... 9

9.2.2 Backwards Compatibility .............................................................................................. 11 9.3 Audit Trail Transport...................................................................................................... 12 30

9.4 Actors/Transactions .......................................................................................................... 12 9.5 Encryption Option............................................................................................................. 14 9.6 Audit Trail and Node Authentication Process Flow......................................................... 15

9.6.1 Normal Node Process Flow............................................................................................ 15 9.6.2 Unauthorized Node Process Flow .................................................................................. 17 35 9.6.3 Unauthorized User Process Flow ................................................................................... 18

Volume 2 - Transactions............................................................................................................... 20 3.19 Authenticate Node ............................................................................................................ 20

3.19.1 Scope......................................................................................................................... 20 3.19.2 Use Case Roles ......................................................................................................... 20 40 3.19.3 Referenced Standards................................................................................................ 21 3.19.4 Interaction Diagram .................................................................................................. 21 3.19.5 Trigger Events........................................................................................................... 21 3.19.6 Message Semantics ................................................................................................... 22 3.19.7 Local User Authentication ........................................................................................ 23 45

3.20 Record Audit Event.......................................................................................................... 25 3.20.1 Scope......................................................................................................................... 25 3.20.2 Use Case Roles ......................................................................................................... 25 3.20.3 Referenced Standards................................................................................................ 25 3.20.4 Interaction Diagram .................................................................................................. 26 50 3.20.5 Record Audit Event................................................................................................... 26 3.20.6 Trigger Events and Message semantics .................................................................... 26 3.20.6.3 Audit Message Transports .................................................................................... 29 3.20.7 Audit Message Formats ............................................................................................ 30

G.1 Message Transformation................................................................................................... 65 55


__________________________________________________________________________


2

Foreword Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration of the information systems that support modern healthcare institutions. Its fundamental objective 60 is to ensure that in the care of patients all required information for medical decisions is both correct and available to healthcare professionals. The IHE initiative is both a process and a forum for encouraging integration efforts. It defines a technical framework for the implementation of established messaging standards to achieve specific clinical goals. It includes a rigorous testing process for the implementation of this framework. And it organizes educational sessions and 65 exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users.

The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in their respective domains in an integrated manner, defining configuration choices when necessary. 70 When clarifications or extensions to existing standards are necessary, IHE refers recommendations to the relevant standards bodies.

This initiative has numerous sponsors and supporting organizations in different medical specialty domains and geographical regions. In North America the primary sponsors are the American College of Cardiology (ACC), the Healthcare Information and Management Systems Society 75 (HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including the European Association of Radiology (EAR) and European Congress of Radiologists (ECR), the Coordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation du 80 Système d'Information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), and Società Italiana di Radiologia Medica (SIRM). In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDIS-DC; cooperating organizations include the Japan Industries Association of Radiological Systems (JIRA), the Japan Association of Healthcare Information Systems Industry (JAHIS), Japan 85 Radiological Society (JRS), Japan Society of Radiological Technology (JSRT), and the Japan Association of Medical Informatics (JAMI). Other organizations representing healthcare professionals are invited to join in the expansion of the IHE process across disciplinary and geographic boundaries.

The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology, 90 Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. It is expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The current version for these Technical Frameworks, may be found at www.rsna.org/IHE or www.himss.org/IHE.. 95

The IHE Technical Framework identifies a subset of the functional components of the healthcare enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,


__________________________________________________________________________


3

standards-based transactions. It describes this body of transactions in progressively greater depth. The volume I provides a high-level view of IHE functionality, showing the transactions organized into functional units called Integration Profiles that highlight their capacity to address 100 specific clinical needs. The subsequent volumes provide detailed technical descriptions of each IHE transaction.

This IHE IT Infrastructure Technical Framework Supplement is issued for Trial Implementation through March 2005, per the schedule announced in February 2004. 105

Comments and change proposals arising from Trial Implementation may be submitted to http://forums.rsna.org under the forum:

“Integrating the Healthcare Enterprise” Select the sub-forum: 110

“IHE IT Infrastructure 2004-2005 Supplement for Trial Implementation” The IHE IT Infrastructure Technical Committee will address these comments resulting from implementation, connect-a-thon testing, and demonstrations such as HIMSS 2005. Final text is expected to be published in May 2005.115


__________________________________________________________________________


4

Profile Abstract The ITI Audit Trail and Node Authentication (ATNA) Profile establishes the characteristics of a Secure Node:

1. It describes the security environment (user identification, authentication, authorization, 120 access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments.

2. It defines basic security requirements for the communications of the node using TLS or equivalent functionality.

3. It defines basic auditing requirements for the node 125

The profile also establishes the characteristics of the communication of audit messages between the Secure Nodes and Audit Repository nodes that collect audit information.

This profile is based upon the Basic Security Profile written by the IHE Radiology committee, and has been extended to incorporate options that are needed by other disciplines. It incorporates a transition strategy so that implementations based on the existing IHE Radiology Technical 130 Framework will operate properly in this new profile.


__________________________________________________________________________


5

Add the following bullet to the volume 1 Glossary

secure domain A network, hardware systems, secure nodes, and physical environment for

which a single set of security policies is defined and enforced for access to 135 its addressable objects.

secure node A network-addressable system that conforms to a secure domain’s access policies and management. A secure node often supports IHE actors.

local authentication In the ATNA profile the term “local authentication” means that the user identification, authentication, and authorization method is chosen by the 140 local system administration and does not necessarily comply with any IHE profile. It may be a local username password system, a secure token system, or any other system that is considered acceptable by the local security administration.

Patient (When used in the context of ATNA) RFC-XXXX defines the means of 145 identifying the person who is a patient. The patient information in audit event records corresponds to the information available to identify a patient at the time the audit record was generated, and does not reflect later updates (e.g. patient reconciliation).

PatientID (When used in the context of ATNA) A free text that holds the system-150 internal patient identifier being unique within that system domain. The patient identifier domain is that assigned to the system that generated the audit event record. The patient information in audit event records corresponds to the information available to identify a patient at the time the audit record was generated, and does not reflect later updates (e.g. 155 patient reconciliation).

SUID The Study Instance UID from a DICOM SOP instance, or collection of SOP instances.

160


__________________________________________________________________________


6

Volume 1 – Integration Profiles Add the following bullet to the end of the bullet list in section 1.7

The ITI Audit Trail and Node Authentication (ATNA) Profile establishes the characteristics of a Basic Secure Node:

1. It describes the security environment (user identification, authentication, authorization, 165 access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments.

2. It defines basic auditing requirements for the node

3. It defines basic security requirements for the communications of the node using TLS or equivalent functionality. 170

4. It establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information.

This profile is based upon the Basic Security Profile written by the IHE Radiology committee, and has been extended to incorporate options that are needed by other disciplines. It incorporates a transition strategy so that implementations based on the older IHE Technical Framework will 175 operate properly in this new profile.


__________________________________________________________________________


7

Add Section 9 to Volume 1

9. Audit Trail and Node Authentication (ATNA) The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security 180 measures which, together with the Security Policy and Procedures of the enterprise, provide patient information confidentiality, data integrity and user accountability. The goals of the Audit Trail and Node Authentication Integration Profile are: • User Accountability (Audit Trail).

To allow a security officer in an institution to audit activities, to assess compliance with a 185 secure domain’s policies, to detect instances of non-compliant behavior, and to facilitate detection of improper creation, access, modification and deletion of Protected Health Information (PHI). PHI is considered to be the patient-identifiable information records (e.g. Registration, Order, Study/Procedure, Reports, Images, and Presentation States). It may be accessed by users or exchanged between the systems. This includes information exported to 190 and imported from every secured node in the secure domain. The audit trail contains information so that questions can be answered such as:

• For some user: which patients’ PHI was accessed? • For some patient PHI: which users accessed it? • What user authentication failures were reported? 195 • What node authentication failures were reported?

• Access Control ATNA contributes to access control by limiting network access between nodes and limiting access to each node to authorized users. Network communications between secure nodes in a secure domain are restricted to only other secure nodes in that domain. Secure nodes limit 200 access to authorized users as specified by the local authentication and access control policy.

• Centralized Audit Record Repository Provides a central Audit Record repository as the simplest means to implement security requirements. An immediate transfer of Audit Records from all the IHE actors to the Audit Record Repository is required when possible, reducing the opportunities for tampering and 205 making it easier to audit the department, but disconnected nodes may store audit data for transfer to the Audit Repository upon reconnection to the secure domain network.

• PHI Data Integrity To allow tracking of the life of PHI information (creation, modification, deletion and location) and its data integrity during this process. 210

Key Features of ATNA

The key features of the Audit Trail and Node Authentication Integration Profile are the following:


__________________________________________________________________________


8

• Authentication of the user. For this profile the user authentication may utilize any technology. IHE does not restrict or describe the user authentication technology to be used 215 for the ATNA profile.

• Audit record generation. This profile requires that events concerning PHI use are recorded and transmitted to a repository where they can be monitored to detect indications of inappropriate activity.

• Authentication of the node during communications. This profile requires that the nodes are 220 authorized and authenticated nodes for all data communications transferring PHI. It does not convey user identification. By using the user authentication and access control selected for each node, user accountability can be assured.

ATNA Security Assumptions

The underlying assumptions are: 225 • All systems that are members of the secure domain implement a Secure Node Actor for the

ATNA profile. The ATNA profile defines transactions between the secure nodes to create a secure domain that is under the management of a domain security officer.

• All applications on a secure node will comply with ATNA requirements, regardless of whether they are IHE Actors or not. They apply to all IT assisted activities that directly 230 create, access, update, and delete PHI, not only those specified by IHE and performed by IHE actors.

• IHE addresses only those security requirements related to systems within the scope of IHE healthcare applications. It does not address other security requirements such as defending against network attacks, virus infection, etc. The principal objective of the Audit Trail 235 mechanism is to track data access to PHI, not IHE transactions.

• IHE does not mandate the use of encryption during transmission. Most hospital networks provide adequate security through physical and procedural mechanisms. The additional performance penalty for encryption is generally not justified for these networks. This profile mandates the use of the TLS security negotiation mechanism for all communications 240 between secure nodes as a means of ensuring that they only communicate with other authorized secure nodes. It permits the negotiation of encryption if both nodes are configured to request and support encryption. This allows installation of IHE secure nodes into environments where the network is not otherwise secured.

• The Audit Trail and Node Authentication Integration Profile requires only local user 245 authentication. The profile allows each secure node to use the access control technology of its choice to authenticate users. The use of Enterprise User Authentication is one such choice, but it is not necessary to use this profile.

• Mobile equipment can participate in the Audit Trail and Node Authentication Integration Profile, but special issues related to mobile equipment are not explicitly addressed in this 250 profile.


__________________________________________________________________________


9

• The Audit Trail and Node Authentication Profile provides tools that are useful for enterprises attempting to become compliant with privacy and security regulations (HIPAA, European, Japanese, etc.), but the profile does not itself make the enterprise compliant.

• ATNA assumes that physical access control, personnel policies and other organizational 255 security considerations necessary to make an enterprise compliant with security and privacy regulations are in place.

9.1 Connection Authentication The Audit Trail and Node Authentication Integration Profile requires the use of bi-directional certificate-based node authentication for connections to and from each node. The DICOM, HL7, 260 and HTML protocols all have certificate-based authentication mechanisms defined. These authenticate the nodes, rather than the user. Connections to these machines that are not bi-directionally node-authenticated shall either be prohibited, or be designed and verified to prevent access to PHI.

Note: Communications protocols that are not specified by IHE profiles, e.g. SQL Server, must be bi-directionally 265 authenticated if they will be used for PHI. This profiles does not specify how that authentication is to be performed.

This requirement can also be met by ensuring complete physical network security with strict configuration management. This means that no untrusted machine can obtain physical access to any portion of the network. Making the connection authentication configurable enhances 270 performance in physically secured networks. A Secure Node Actor shall be configurable to support both connection authentication and physically secured networks.

9.2 Audit Trails 9.2.1 Audit Messages

The use of auditing as part of a security and privacy process is appropriate for situations where 275 the people involved are generally trustworthy and need a wide range of flexibility to respond rapidly to changing situations. This is the typical healthcare provider environment. Auditing tracks what takes place, and the people involved know that their actions are being audited. This means that the audit records must capture event descriptions for the entire process, not just for individual components that correspond to individual IHE actors. 280

The IHE audit trail is the first of several profiles that correspond to different forms of access control and authentication. Auditing is always needed independent of the access control and authentication method chosen.

The IHE-specified audit flow is illustrated in Figure 9.2-1.

1. Real world activities take place, and some of these activities involve the applications 285 processing of a device that includes support for some IHE profiles. This product has components that may correspond to specific IHE Actors. The product may also have other capabilities that are independent of IHE recommendations.


__________________________________________________________________________


10

2. A wide variety of events take place during this process. Some of these events are directly related to IHE Actor activities. Others may be indirectly related, and still others are not 290 related to any IHE specification. The events are both extremely detailed minor events, such as keystrokes, and high level events such as analyzing a diagnostic study. Very few of these events are relevant to security and privacy auditing. Most are too low level to be useful or are otherwise irrelevant.

3. The “Security Audit and Access Accountability Message XML Data Definitions for 295 Healthcare Applications” (RFC-xxxx)1 defines an XML schema for reporting events that are relevant to security and privacy auditing. It was defined in cooperation with the ASTM, HL7, and DICOM standards organizations and the NEMA/COCIR/JIRA Security and Privacy Committee. The IHE recommends the use of the RFC-XXX format, and recommends reporting only events that it can describe. 300

a) DICOM has standardized some of the audit message vocabulary. The DICOM Audit Message Vocabulary extends the basic vocabulary provided with RFC-XXX, and also further specifies some optional elements in RFC-XXX. An example of vocabulary extension is the addition of a coded value to indicate that a field contains a DICOM Study Instance UID. An example of optional element specification is the requirement 305 that the UserID field in RFC-XXX messages shall be the user ID used by the local device operating system, and that the AlternateID shall be the user ID used by the enterprise authentication system (if it is different).

b) This profile defines other events that do not correspond to events defined in the DICOM vocabulary. These events are describable by RFC-XXX, and this profile 310 includes requirements for such descriptions.

IHE auditing specifies that when using the RFC-XXX, events that can be described using the DICOM vocabulary they shall be reported using the DICOM vocabulary, even if the device is not otherwise a DICOM compliant device. Events that do not match the DICOM vocabulary shall be reported using RFC-XXX vocabulary or other extensions. 315 Events that cannot be reported using RFC-XXX are not candidates for reporting.

4. The local site will then apply its own reporting policies. The IHE profile specifies the capabilities that should be present for audit reporting, and also that there should be controls present to allow the local site security administration to control reporting detail. The IHE profile does not specify any audit reporting functions or formats. 320

5. IHE specifies events that must be reported in the audit trail. There are other events related to security, which may be reported in the audit trail or by other means. This profile does not describe them and does not require that they use this reporting format or mechanism. Examples of such events are network routing and firewall logs. 325

1 This RFC does not yet have a number assigned. The latest draft can be found at http://www.ietf.org/internet-drafts/draft-marshall-security-audit-12.txt.


__________________________________________________________________________


11

Figure 9.2-1 Flow of Events into Audit Messages

ApplicationActivities

ProductCapabilities

Application

System

IETF CAM

Standard AuditVocabularies (e.g.DICOM)

IHE AuditVocabularyExtensions

Product AuditCapabilities

Site Policies

Audit Repository

Reported Events

Reportable Events

DescribableEvents

All Events

Items in Bold outlineare defined by the

ATNA profile

330

9.2.2 Backwards Compatibility

This profile also defines the continued use of messages that are formatted in accordance with the IHE Provisional Audit Message format from the Basic Security Profile. This older format describes events that are suitable for reporting in Radiology and other diagnostic and treatment activities. These events are a subset of the kind of events that can be described using RFC-XXX 335 and the DICOM vocabulary.

The IHE ATNA Profile also allows for the reporting of these events using the Provisional format over either of the IHE specified transport mechanisms. The intention is that products will gradually transition from the Provisional message format to RFC-XXX format, but it is recognized that this transition will take time and that there is a significant installed base. 340


__________________________________________________________________________


12

The Provisional format is unlikely to be of interest to other healthcare applications, which should use the RFC-XXX format and DICOM Vocabulary where appropriate.

9.3 Audit Trail Transport

The Audit Trail and Node Authentication Integration Profile specifies the use of Reliable Syslog Cooked Profile (RFC-3195, Section 4) as the mechanism for logging audit record messages to 345 the central audit record repository. It also permits the use of BSD Syslog (RFC-3164). There are, however, several known limitations of BSD Syslog: • There is no confirmation to the sender that the audit record message was received at the

destination • There is no option to encrypt the audit record messages 350 • Authentication by means of certificates of the sending nodes and the central audit repository

is not possible • Messages may be truncated or lost.

The specification of Reliable Syslog Cooked Profile messages corrects these deficiencies. 355

9.4 Actors/Transactions Table 10.1-1 lists the transactions for each actor directly involved in the Audit Trail and Node Authentication Integration Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile that implementations 360 may choose to support is listed in ITI-TF 1: 9.4. Their relationship is shown in Figure 9.4-1.


__________________________________________________________________________


13

ITI-20: Record Audit Event ↓

ITI-1: Maintain Time

Secure Node grouped with

PHI Application

Time Server Secure Node grouped with

Any IHE Actor

Audit Repository

Secure Node grouped with

Any IHE Actor

ITI-20: Record Audit Event↑

↔ ITI-20: Record Audit Event

ITI-19: Node Authentication

ITI-1: Maintain Time

Figure 9.4-1. Audit Trail and Node Authentication Diagram

When an implementation chooses to support this Integration Profile for an actor, that actor shall 365 be grouped with the Secure Node actor. It is required that all IHE actors and any other activities in this implementation support the Audit Trail and Node Authentication Integration Profile.

A means must be provided to upload the required certificates to the implementation, e.g. via floppy disk or file transfer via network.

Non-IHE applications that process PHI shall detect and report auditable events, and protect 370 access.

Table 9.4-1. Audit Trail and Node Authentication Integration Profile - Actors and

Transactions Actor Transactions Optionality Vol II / III Section

<any PHI application grouped with a Secure Node Actor> Record Audit Event R IHE ITI-2: 3.20 <any IHE actor grouped with a Secure Node actor> Record Audit Event R IHE ITI-2: 3.20 Audit Record Repository Record Audit Event R IHE ITI-2: 3.20

Authenticate Node R IHE ITI-2: 3.19 Secure Node

Maintain Time R IHE ITI-2: 3.7

375

The Secure Node Actor shall include:


__________________________________________________________________________


14

1. The Authenticate Node transaction for all network connections that may expose private information. These transactions are defined for:

a) DICOM, using TLS

b) HL7, using TLS 380

c) HTTP, using TLS

2. All local user activity (login, logout, etc.) protected to ensure only authorized users.

3. An audit transport mechanism, either:

a) Reliable Syslog Cooked Profile format (RFC-3195, Section 4)

b) BSD Syslog (RFC-3164), the baseline syslog mechanism. 385

4. Generation of audit messages for recommended events utilizing one of the defined alternatives for audit message formats. The audit messages formatted are:

a) The IETF common audit message format, using the DICOM and IHE vocabularies.

b) The Provisional IHE Audit Message format,

390

The Audit Repository shall support:

1. Both audit transport mechanisms.

2. Any IHE-specified2 audit message format, when sent over one of those transport mechanisms. Note that new applications domains may have their own extended vocabularies in addition to the DICOM and IHE vocabularies. This also means that an 395 ATNA Audit Repository is also automatically a Radiology Basic Security profile Audit Repository because it must support the IHE Provisional Message format and it must support the BSD syslog protocol.

3. Self protections and user access controls.

This profile does not specify other functions for the Audit Repository, but it is expected that 400 most repositories will perform screening, reporting, archival, etc.

9.5 Encryption Option Secure Nodes may implement the ATNA Encryption Option. This option specifies the support of encryption to protect confidentiality.

405

2 Other audit formats outside of IHE specifications are also possible, but such auditing would be a product-specific feature outside of IHE’s scope.


__________________________________________________________________________


15

9.6 Audit Trail and Node Authentication Process Flow The security measures in the Audit Trail and Node Authentication Integration Profile are user authentication, node authentication, and generation of audit records. Node authentication and user authentication define a number of transactions that establish the concept of a Secure Node and a collection of connected Secure Nodes in a secure domain (see Volume ITI-III: Appendix 410 A).

Generation of audit records requires a set of audit trigger events and a definition of the content of the audit records. This profile specifies two acceptable message formats:

1. Messages formatted in accordance with the IHE Audit Message format. This is a combination of the DICOM Audit Messages format and IHE extensions. The IHE 415 extensions to RFC-XXXX add event codes and information needed for uses that are not within the domain of the DICOM Standard.

2. The predecessor IHE Provisional Audit Message format. This format was defined as an interim format while the standards work to define the Common Audit Message format and vocabularies progressed through the standards organizations. 420

Based on the work done in ASTM (E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems) and HL7 (Framework for Audit Messages), IHE defined a detailed set of audit trigger events, a set of general audit messages with the content for the audit record, and a mapping for each event to a general audit message. The content of the audit record has been specified by means of an XML Schema (see Volume ITI-II: Appendix F). 425

In the following paragraphs three typical process flows are described for situations in which authorized users, unauthorized users, and unauthorized nodes attempt to gain access to protected health information (PHI).

9.6.1 Normal Node Process Flow

The following scenario shows how the IHE security measures operate for authorized access to 430 PHI from an authorized node in the network:

1. Time synchronization occurs independently. These transactions may take place at any time. Correct time is needed to generate Audit Records with a correct timestamp.

2. A user logs on to Image Display/Secure Node actor. The user enters valid credentials and is authorized to access the node. 435

3. The node generates audit records.

4. The user wants to query/retrieve and view some images. Before image transactions can take place, an authentication process between the Image Display/Secure Node actor and the Image Manager/Image Archive/Secure Node actor takes place. 440

5. Following node authentication, the node initiates the query/retrieve transactions.

6. The node generates audit records.


__________________________________________________________________________


16

Image Manager/

Image Archive/ Secure Node

Image Display/ Secure Node

Audit Record Repository/ Secure Node

Time Server

Record Audit Event [ITI-20](User Authenticated)

Maintain Time [ITI-1]

Query Images


Retrieve Images

Record Audit Event [ITI-20] (Query Images)

View Images

AuthenticateNode [ITI-19]

Record Audit Event [ITI-20] (Retrieve Images)


Record Audit Event [ITI-20] (Retrieve Images)

Record Audit Event [ITI-20] (Instances Used)

Figure 9.6-1. Authorized Node Process Flow 445


__________________________________________________________________________


17

9.6.2 Unauthorized Node Process Flow

The following scenario shows how the IHE security measures help to prevent unauthorized access to PHI from an unauthorized node in the network:

1. An unauthorized node tries to query the Lab Automation Manager/Secure Node actor for 450 information. This fails because no authentication has taken place, and an audit record is generated.

2. The unauthorized node tries an authentication process with the Lab Automation Manager/Secure Node. This fails because the Lab Automation Manager/Secure Node will not trust the certificate presented by the Malicious Node, and an audit record is generated. 455

Note that the sequencing of the transactions is just one example; transactions from an unauthorized node are totally unpredictable and may happen in any order.

Authentication failure

Authentication failure

Lab Automation Manager/

Secure Node

Audit Record Repository/ Secure Node

Unauthorized Node

Query Images

Record Audit Event [ITI-20](Node Authentication Failure)

Record Audit Event [ITI-20](Node Authentication Failure)

Authenticate Node [ITI-19]

Figure 9.6-2. Unauthorized Node Process Flow 460


__________________________________________________________________________


18

9.6.3 Unauthorized User Process Flow

The following scenario shows how the IHE security measures help to prevent unauthorized 465 access to PHI from an unauthorized user in the healthcare enterprise:

1. An unauthorized user tries an authentication process with the ECG Display/Secure Node actor. This fails because the ECG Display/Secure Node actor detects that the user name and credentials presented are not valid at this secure node, and an audit record is generated. 470

ECG Display/

Secure Node Audit Record Repository/ Secure Node

Time Server


Record Audit Event [ITI-20] (User Authenticated)


Local User Authentication (unauthorized user)

Figure 9.6-3. Unauthorized User Process Flow 475

Add the following definitions to Appendix A Actor Summary Definitions

Secure Node The presence of this actor on a system means that all of the other actors and other non-IHE software complies with the IHE rules for user authentication, communications authentication, and security policies. 480


__________________________________________________________________________


19

Audit Repository This actor provides a repository for audit events. IHE does not specify what analysis and reporting features should be implemented for an audit repository.

Add the following definitions to Appendix B Transaction Summary Definitions

Node Authentication This transaction is embedded within all network communications activity. 485 All DICOM, HL7, and HTML connections shall comply with the IHE specification for bi-directional authentication and authorization of communications of Protected Healthcare Information (PHI). IHE does not specify how other protocols that transfer PHI shall perform bi-directional authentication and authorization, but requires that other protocols perform 490 such authentication and authorization.

Record Audit Event The delivery of an audit event description from any secure node to the Audit Repository.


__________________________________________________________________________


20

Volume 2 - Transactions Add sections 3.19 and 3.20 to Volume 2 495

3.19 Authenticate Node This section corresponds to Transaction 19 of the IHE ITI Technical Framework. Transaction 19 is used by the Secure Node actors

3.19.1 Scope

In the Authenticate Node transaction, the local Secure Node presents its identity to a remote 500 Secure Node, and authenticates the identity of the remote node. After this mutual authentication other secure transactions may take place through this secure pipe between the two nodes.

In addition, the Secure Node authenticates the identity of the user who requests access to the node. This user authentication is a local operation that does not involve communication with a remote node. 505

3.19.2 Use Case Roles

Actor: Secure Node

Role: Establish a protocol specific trust relationship between two nodes in a network. Establishes the identity of a user, and authorizes access to the patient data and applications at the node. 510

Actor: User

Role: Someone who wants to have access to the data and applications available at the node.

A uthenticate N ode

Secure N ode

Secure N ode U ser


__________________________________________________________________________


21

3.19.3 Referenced Standards

DICOM 2003 PS 3.15: 515 Security Profiles. Annex B1: The Basic TLS Secure Transport Connection profile.

IETF: Transport Layer Security (TLS) 1.0 (RFC 2246)

ITU-T: Recommendation X.509 (03/00). “Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks"

3.19.4 Interaction Diagram 520

Note: This diagram does not imply sequencing of Authentication Node and Local User Authentication.

Local Secure Node

Authenticate Node

Remote Secure Node

Authenticate Node

Local User Authentication

3.19.5 Trigger Events

The Local Secure Node starts the authentication process with the Remote Secure Node when 525 information exchange between the two nodes is requested. The first transaction shall be the Authenticate Node transaction, and all other PHI transactions performed by IHE actors shall be secure transactions. This authentication process is needed when a secure connection is established.

The Basic Secure Node shall always apply the Authenticate Node process to every DICOM, 530 HTTP, or HL7 connection.


__________________________________________________________________________


22

3.19.6 Message Semantics

3.19.6.1 DICOM and HL7 Connections

The Local Secure Node uses the TLS protocol to establish a trust relationship with the Remote Secure Node. The configuration settings for the TLS protocol depends upon the messaging 535 standard that are used for the connection. HL7 and DICOM transactions are required to adhere to the specifications in this section. All Secure Nodes shall be configurable for use on a physically secured network or not on a physically secured network.

When configured for use on a physically secured network, the normal DICOM and HL7 connection mechanisms shall be used. 540

When configured for use not on a physically secured network implementations shall use the TLS protocol, and the following cyphersuite shall be supported:

TLS_RSA_WITH_NULL_SHA

If the ATNA Encryption Option is implemented, the following cyphersuite shall also be 545 supported:

TLS_RSA_WITH_AES_128_CBC_SHA.

The recommended "well-known port 2762" as specified by DICOM shall be used when the Secure node is configured for use not on a physically secured network. When the secure node is 550 configured for use on a physically secured network, a different port number shall be used, preferably the standard port 104. HL7 does not specify port numbers, but the port number used when configured for use on a physically secured network shall be different than the port number used when configured for use not on a physically secured network.

The Authenticate node transaction involves the exchange of certificates representing the 555 identities of the trusted nodes. Certificates shall use the X.509 standard.

The healthcare enterprise should define the maximum expiration time for certificates in its security policy. The IHE Technical Framework recommends a maximum expiration time of 2 years.

The Secure node shall provide means for installing of the required certificates, for example, via 560 removable media or network interchange. Implementation must support the configuration of a list of authorized nodes (see ITI TF-2: Appendix A). Connections shall only be accepted from the authorized nodes on the list and connections only attempted to nodes on the list.

If Secure Node is configured for physical security, then it shall use the non-TLS DICOM port and protocol. 565


__________________________________________________________________________


23

3.19.6.2 HTTP Connections

3.19.6.2.1 Expected Actions

A trusted association will be established between the two nodes. This association will be used for all further secure transactions between the IHE actors in two nodes.

The HTTP connection shall be made using a TLS connection in the same manner as HL7 and 570 DICOM TLS connections described above, although the port number shall be configurable.

Note: Most web browsers do not support the mutual authentication of both nodes by means of TLS. They usually only support authentication of the server node by means of TLS, leaving the client node un-authenticated. SSL connections are similar in only authenticating the server node. This is not suitable for use in the transfer of PHI. Secured HTTP communications will require the use of either browser extensions like applets, modified browsers, 575 or application software that uses mutually authenticating TLS connections.

If Secure Node is configured for physical security, then it shall use the normal HTTP protocol.

3.19.7 Local User Authentication

The Secure Node starts the authentication process with a User when the User wants to log on to the node. The secure node shall not allow access to PHI to an operator who has not successfully 580 completed the local user authentication. Local user authentication is not an IHE specified network transaction, although it may utilize a network system for user authentication.

This is a local invocation of functions at the Secure Node. The identity of the User will be established by the Secure Node actor based on methods such as: • Username with Password 585 • Biometrics • Smart card • Magnetic Card

The User shall log in using his or her own unique individually assigned identity. Identities must be unique across the secure domain. A user may have more than one identity. The Secure Node 590 shall be configurable to maintain a list of authorized users for the Secure Node.

The rules for assignment of unique individual identities to users is part of the Security Policy of the healthcare enterprise. Development of these rules is outside the scope of the IHE Technical Framework. The following examples list a few special cases related to user identification that may occur in practice. 595

3.19.7.1 Example: Team approach

When the operator is part of a team performing a procedure, the other members of the team involved in creating and accessing the data should be manually identified and recorded in the procedure log (which may be paper or electronic), and it is assumed that all have accessed the data even though they were not (and cannot be in most cases) actually logged on to the piece of 600 equipment.


__________________________________________________________________________


24

During some procedures, it may be necessary for one operator to relieve the operator who has already been authenticated by the system. It is recommended that the first operator log off and that the system authenticate the new operator.

3.19.7.2 Example: Access to locked exam room, no user logon on modality. 605

There may be situations where the acquisition modality has no user logon features, and access to the equipment is controlled by controlling access to the examination room. In these situations an equipment-specific user ID will be used, and access to the room should be recorded in the procedure log (which may be paper or electronic).

3.19.7.3 Example: Enterprise User Authentication 610

The healthcare enterprise may implement local user authentication using the Enterprise User Authentication Profile (EUA). This implementation may be mixed with other non-EUA access to the secure domain, based upon each node’s internal use an EUA availability.


__________________________________________________________________________


25

3.20 Record Audit Event 615

This section corresponds to Transaction 20 of the IHE ITI Technical Framework. Transaction 20 is used by the all IHE actors that support the Audit Trail and Node Authentication Integration Profile to communicate with the Audit Record Repository actors.

3.20.1 Scope

In the Record Audit Event transaction, the IHE actor creates an entry in the Audit Log at the 620 Audit Record Repository.

3.20.2 Use Case Roles

Record Audit Event

Any Application

or Actor

Audit Record Repository

Application or Actor: Any actor or any other application that is grouped with the Secure Node Actor. 625

Role: Create an audit record and transmit this record to the Audit Record Repository.

Actor: Audit Record Repository

Role: Receive an audit record from the Audit Record Creator and store this for audit purposes.

3.20.3 Referenced Standards

IETF: The BSD Syslog Protocol. (RFC 3164); 630

Reliable Delivery for Syslog (RFC 3195);

Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC <tbd>).

DICOM: Supplement 95

ASTM: E2147-01 Standard Specification for Audit and Disclosure Logs for Use in 635 Health Information Systems.


__________________________________________________________________________


26

W3C: Recommendation: Extensible Markup Language (XML) 1.0

3.20.4 Interaction Diagram

Any IHEActor or any PHI

application

Record Audit Event

Audit Record Repository

3.20.5 Record Audit Event 640

The Audit Record Repository shall accept the Audit Record message. The usage of the result by the Audit Record Repository is beyond the scope of the IHE Technical Framework.

3.20.6 Trigger Events and Message semantics

An Audit Log is a record of actions performed on data by users. Actions are queries, views, additions, deletions and changes. The IHE actor creates an Audit Record when an IHE 645 transaction-related event occurs or when a non-transaction event occurs.

IHE specifies that events defined in Table 3.20.6-1 shall be reportable by means of the IHE Audit Trail. Radiology devices may also find that their subset of events is reportable by means of the IHE Provisional Audit Message Format. This is not recommended other than as a strategy for managing the upgrade of products and systems to the DICOM Audit Message Standard with 650 IHE Extensions.

Table 3.20.6-1. Audit Record trigger events

Trigger Event Description Source Vocabulary Actor-start-stop Startup and shutdown of any actor. Applies to all actors. Is

distinct from hardware powerup and shutdown. DICOM (Sup 95)

Audit-Log-Used The audit trail repository has been accessed or modified by something other than the arrival of audit trail messages.

DICOM (Sup 95)

Begin-storing-instances Begin storing SOP Instances for a study. This may be a mix of instances. Involved actors: Acquisition Modality, Image Manager/Image Archive, Image Creator.

DICOM (Sup 95)

Health-service-event Health services scheduled and performed within an instance IHE Extension (section


__________________________________________________________________________


27

Trigger Event Description Source Vocabulary or episode of care. This includes scheduling, initiation, updates or amendments, performing or completing the act, and cancellation. See note below.

3.20.7.3)

Images Availability Query Images availability query is received. DICOM (Sup 95)

Instances-deleted SOP Instances are deleted from a specific study. One event covers all instances deleted for the particular study.

DICOM (Sup 95)

Instances-Stored Instances for a particular study have been stored on this system. One event covers all instances stored for the particular study.

DICOM (Sup 95)

Medication Medication orders and administration within an instance or episode of care. This includes initial order,dispensing, delivery, and cancellation. See note below.

IHE Extension (section 3.20.7.3)

Mobile-machine-event Mobile machine joins or leaves secure domain. DICOM (Sup 95)

Node-Authentication-failure A secure node authentication failure has occurred during TLS negotiation, e.g. invalid certificate.

DICOM (Sup 95)

Order-record-event Order record created, accessed, modified or deleted. Involved actors: Order Placer. This includes initial order, updates or amendments, delivery, completion, and cancellation. See note below.

DICOM (Sup 95)

Patient-care-assignment Staffing or participant assignment actions relevant to the assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. to a patient It also includes change in assigned role or authorization, e.g., relative to healthcare status change, and de-assignment


Patient-care-episode Specific patient care episodes or problems that occur within an instance of care. This includes initial assignment, updates or amendments, resolution, completion, and cancellation. See note below.


Patient-care-protocol Patient association with a care protocol. This includes initial assignment, scheduling, updates or amendments, completion, and cancellation. See note below.


Patient-record-event Patient record created, modified, or accessed. DICOM (Sup 95)

PHI-export Any export of PHI on media, either removable physical media such as CD-ROM or electronic transfer of files such as email. Any printing activity, paper or film, local or remote, that prints PHI.

DICOM (Sup 95)

PHI-import Any import of PHI on media, either removable physical media such as CD-ROM or electronic transfers of files such as email.

DICOM (Sup 95)

Procedure-record-event Procedure record created, modified, accessed or deleted. DICOM (Sup 95)

Query Information A query has been received, either as part of an IHE transaction, or as part other products functions. For example: 1. Modality Worklist Query 2. Instance or Image Availability Query

DICOM (Sup 95)


__________________________________________________________________________


28

Trigger Event Description Source Vocabulary Security Administration Administrative actions create, modify, delete, query, and

display the following: 1. Security attributes for data sets, data groups, or classes

plus their atomic data elements or attributes. 2. Security attributes and auditable events for the

application functions used for patient management, clinical processes, registry of business objects and methods, program creation and maintenance, etc.

3. Security domains according to various organizational categories such as entity-wide, institutional, departmental, etc.

4. Security categories or groupings for functions and data such as patient management, nursing, clinical, etc.

5. The allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods.

6. Security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control.

7. User accounts. This includes assigning or changing password or other authentication data. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control.

8. Unauthorized user attempt to use security administration functions.

9. Audit enabling and disabling. 10. User authenticaton, authentication failure,

authentication revocation, or signoff. Security administration events should always be audited.

DICOM (Sup 95)

Study-Object-Event Study is created, modified, accessed, or deleted. This reports on addition of new instances to existing studies as well as creation of new studies.

DICOM (Sup 95)

Study-used SOP Instances from a specific study are created, modified or accessed. One event covers all instances used for the particular study.

DICOM (Sup 95)

Note: The IHE extension has reduced the scope of many of the IETF events to remove phrases like “checking for clinical contra-indications”. This is done to highlight that the events should be reported are those that are related 655 to the access, use, creation, and distribution of PHI. This audit log is not intended to be a general purpose monitoring system to track all kinds of medical activity. As a result, many clinically significant events will not be separately reported.

3.20.6.1 Audit Record Transportation

This profile defines two transport mechanisms for the audit messages: 660


__________________________________________________________________________


29

1. Transport utilizing the Reliable Syslog protocol in “cooked” mode as defined in RFC-3195.

2. Transport utilizing the BSD Syslog protocol defined in RFC-3164.

The Audit repository shall support both transport mechanisms for the receipt of messages. Individual IHE Actors may choose to utilize either of the two transport mechanisms, unless they 665 also comply with another Profile that further restricts the use. IHE recommends the use of reliable syslog because it deals with issues such as delivery confirmation, message loss prevention, and message truncation prevention.

The Reliable Syslog protocol specifies the use of local cache and storage. Messages are preserved locally until they are confirmed to have been successfully stored at the recipient. After 670 delivery they may be removed at the convenience of the local machine and local functions.

3.20.6.2 Audit Record format

The IHE defines several audit record formats, and future profiles may define more message formats. An IHE actor shall utilize one or more of these audit record formats. All audit record formats utilize XML encoding and are defined by XML schema. 675

The present list of audit record schema are:

1. The IHE Audit Trail format. This is a schema based on the standards developed and issued by the IETF, HL7, and DICOM organizations to meet the medical auditing needs as specified by ASTM.

2. IHE Provisional Audit Record format, defined below. This was previously defined as 680 part of the IHE Radiology technical framework. Its use is deprecated, this implies that no extensions will be made and new applications should use the new IHE Audit Trail format.

3.20.6.3 Audit Message Transports

The IHE actor will create the Audit Record and transmit this to the Audit Record Repository as 685 soon as possible. When for some reason the Audit Record repository is not available, the IHE actor shall store the Audit Record in a local buffer until the Audit Record Repository is available again. The local Audit Record at the IHE actor may be deleted when this record has been transmitted to the Audit Record Repository.

Note: The Reliable Syslog protocol has explicit support for management of occasionally 690 connected and mobile devices.

3.20.6.3.1 Reliable Syslog

The Reliable Syslog “cooked” mode defined in RFC-3195 shall be used to transport the audit messages. The schema used for the messages shall be identified as part of the “cooked” connection establishment. 695


__________________________________________________________________________


30

3.20.6.3.2 BSD Syslog

The BSD syslog is appropriate in some situations, it was defined in the IHE Rad Technical Framework, and it is widely used legacy protocol. The XML messages are permitted to violate the BSD limitations in the following ways: • The syslog port number shall be configurable, with the BSD port number (514) as the 700

default. • Messages are limited in length to 32768 bytes. Note that the underlying transport might not

accept messages longer than 1024. They may be truncated. The Audit Repository must be prepared for arbitrary truncation of messages. The IHE Provisional schema uses shortened names to reduce the size of messages, but some may exceed 1024 bytes. When these are 705 truncated the resulting XML will be incorrect and will need to be corrected by the Audit Repository to close the truncated portions of the message.

• The XML may contain Unicode characters that are encoded using the UTF-8 encoding rules. UTF-8 avoids utilizing the control characters that are mandated by the syslog protocol, but it may appear to be gibberish to a system that is not prepared for UTF-8. Audit repositories 710 must accept UTF-8 encodings and store them without damage, e.g. preserve all 8 bits.

3.20.7 Audit Message Formats

3.20.7.1 RFC-XXX format A common XML schema was defined based upon joint work by IHE, HL7, DICOM, ASTM E31, and the Joint NEMA/COCIR/JIRA Security and Privacy Committee. The IHE IT 715 Infrastructure technical framework prefers use of this schema for audit records generated by all IHE actors. The schema can be found at: www.xml.org/xml/schema/7f0d86bd/healthcare-security-audit.xsd The DICOM Standard, Supplement 95 Audit Trail Messages provides vocabulary and further 720 specification of the use of these schema elements for events that may occur in the context of DICOM equipment. IHE has evaluated this and determined that it is more broadly applicable, and extended it for more general healthcare use. For reference, the schema elements are diagrammed below. The diagrams are read from left to 725 right: elements to the right are part of the lefthandside element.

Required single element. A NetworkEntry element consists of exactly one MachineAction element.

Optional single element. A NetworkEntry element consists of zero or one MachineAction element. 730


__________________________________________________________________________


31

Optional multiple elements. A NetworkEntry element consists of zero or any number of MachineAction elements.

Selections of one out of several elements. A user consists either of a LocalUser element or of a RemoteNode element.

Compound element: The “+” in an element box means that the element 735 consists of further elements. If these expansion elements have not occurred up to this point in the document, can be expected to follow below in the document.

element AuditMessage 740

diagram

element AuditMessage/EventIdentification

diagram

element AuditMessage/ActiveParticipant

diagram


__________________________________________________________________________


32

745 element AuditMessage/AuditSourceIdentification

diagram

element AuditMessage/ParticipantObjectIdentification

diagram

3.20.7.2 DICOM Audit Trail 750

A Secure Node actor shall be able to detect events that are defined by the DICOM standard in Supplement 95, and generate Record Audit Event transactions that conform to the DICOM standard when these events take place.

The DICOM Standard provides a schema for the basic messages and states that extensions are valid. This profile does not restrict private extensions that comply with the W3C XML encoding 755 rules for the use of schemas, namespaces, etc.

3.20.7.3 IHE Audit Trail

The DICOM standard does not address all the kinds of security and privacy events that can take place in the healthcare environment. The following additional events are defined by IHE for use in healthcare. Secure nodes shall use these events when the DICOM standard events do not 760 apply.

The notation used in these tables is that used in the DICOM standard. The messages shall be encoded as instances based on the RFC-XXX schema. This profile does not restrict private extensions to the RFC-XXXX schema that comply with the W3C XML encoding rules for the use of schemas, namespaces, etc. 765


__________________________________________________________________________


33

3.20.7.3.1 Health Services Provision Event

This message may be generated whenever health services are scheduled and performed within an instance or episode of care. These include scheduling, initiation, updates or amendments, performing or completing an act, and cancellation.

Field Name Opt. Value Constraints

Event ID M EV (IHE0001, IHE, “Health Services Provision Event”)

Event Action Code M

EV: “C” (create) “R” (read) “U” (update) “D” (delete)

EventDateTime M not specialized

EventOutcomeIndicator M not specialized

Event

EventTypeCode U not specialized

Participant Object Type Code M EV 1 (person)

Participant Object Type Code Role M EV 1 (patient)

Participant Object ID Type Code M EV 2 (patient ID)

Participant Object ID M The patient ID

Participant Object Name U The patient name

Patients (1)

Participant Object Detail U Description of the event

770

In cases where there is an event that applies to more than one patient, there shall be a separate audit message for each patient.

3.20.7.3.2 Medication Event

This message may be generated whenever there are medication orders or administration within an instance or episode of care. These include initial order, dispensing, delivery, and cancellation. 775

User ID M The identity of the persons or processes manipulating the data. All that are known shall be included.

UserName U not specialized

UserIsRequestor U not specialized

User (1..n)

RoleIDCode U not specialized


__________________________________________________________________________


34


Event ID M EV (IHE0002, IHE, “Medication Event”)

Event Action Code M




Event


Participant Object Type Code M EV 1 (person) Participant Object Type Code Role M EV 1 (patient)




Patients (1)



3.20.7.3.2 Patient Care Resource Assignment Event 780

This message may be generated whenever there are staffing or participant assignment actions relevant to the assignment of healthcare professionals, caregivers, attending physician, residents, medical students, consultants, etc. to a patient. It is also generated as a result of a change in assigned role or authorization, e.g., relative to healthcare status change, and de-assignment.




User (1..n)



__________________________________________________________________________


35

785


Event ID M EV (IHE0003, IHE, “Patient Care Resource Assignment”)

Event Action Code M




Event






Patients (1)



3.20.7.3.2 Patient Care Episode Event 790

This message may be generated whenever there are specific patient care episodes or problems that occur within an instance of care. These include initial assignment, updates or amendments, resolution, completion, and cancellation.




User (1..n)



__________________________________________________________________________


36


Event ID M EV (IHE0004, IHE, “Patient Care Episode”)

Event Action Code M




Event






Patients (1)


795


3.20.7.3.2 Patient Care Protocol Event

This message may be generated whenever there is a patient association with a care protocol. These include initial assignment, scheduling, updates or amendments, completion, and 800 cancellation.




User (1..n)



__________________________________________________________________________


37


Event ID M EV (IHE0005, IHE, “Patient Care Protocol”)

Event Action Code M




Event






Patients (1)


In cases where there is an event that applies to more than one patient, there shall be a separate audit message for each patient. 805

3.20.7.4 Other event reports

Events that do not correspond to DICOM events or IHE Extension events can be reported. They shall comply with RFC-XXX. 810

3.20.7.5 Controlled Terminology for IHE Extensions

This profile defines the following controlled terminology for use in the IHE extensions. Context ID ccc1 Audit Event ID

Type: Extensible Version: 2004xxxx 815




User (1..n)



__________________________________________________________________________


38

Coding Scheme

Designator

Coding Scheme Version

Code Value {xe

““(0008,0100)””}

Code Meaning {xe ““(0008,0104)””}

IHE IHE0001 Health Services Provision Event

IHE IHE0002 Medication Event

IHE IHE0003 Patient Care ResourceAssignment

IHE IHE0004 Patient Care Episode

IHE IHE0005 Patient Care Protocol

IHE Code Definitions (Coding Scheme Designator “IHE” Coding Scheme Version “2004”)

Code Value

{xe "(0008,01

00)"}

Code Meaning{xe "(0008,0104)"}

Definition Notes

IHE0001 Health Services Provision Event

Health services scheduled and performed within an instance or episode of care. This includes scheduling, initiation, updates or amendments, performing or completing the act, and cancellation.

IHE0002 Medication Event Medication orders and administration within an instance or episode of care. This includes initial order,dispensing, delivery, and cancellation.

IHE0003 Patient Care Resource Assignment

Staffing or participant assignment actions relevant to the assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. to a patient It also includes change in assigned role or authorization, e.g., relative to healthcare status change, and de-assignment

IHE0004 Patient Care Episode Specific patient care episodes or problems that occur within an instance of care. This includes initial assignment, updates or amendments, resolution, completion, and cancellation.

IHE0005 Patient Care Protocol Patient association with a care protocol. This includes initial assignment, scheduling, updates or amendments, completion, and cancellation.

3.20.7.4 IHE Provisional Audit Message Form 820

An provisional XML Schema was defined for the contents of the audit records generated by the IHE actors in the Basic Security Integration Profile as part of the IHE Radiology effort. The


__________________________________________________________________________


39

ATNA profile includes this schema as an alternative format for audit messages. It is less flexible than the IHE Audit Trail format, and is no longer the recommended format for IHE use. The preferred format is the IHE Audit Trail format with extensions that is described above. 825

However, the IHE Provisional Audit Message format is suitable for many diagnostic equipment settings and can be transformed into an equivalent IHE Audit Trail format. It is also installed and in use at many locations. So the IHE Provisional Audit Message format is part of the IHE IT profile. The transition from its format to the IHE Audit Trail format is encouraged to reduce the burden on Audit Repositories which may result from processing this alternative format. 830

A provisional XML Schema has been defined for the contents of the audit records generated by the IHE actors in the Basic Security Integration Profile from the radiology technical framework. The audit records are used to generate an audit record log for activities related to protected health information.

The IHE Provisional Audit Message Schema is described in ITI TF-2: Appendix F. 835

Add Appendix F and Appendix G to ITI volume II

Appendix F Provisional XML Schema definition of the IHE Basic Security Integration Profile Audit Records A provisional XML Schema has been defined for the contents of the audit records generated by 840 the IHE actors in the Basic Security Integration Profile. The audit records are used to generate an audit record log for activities related to protected health information.

The complete XML Schema is as follows:


__________________________________________________________________________


40

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 845 attributeFormDefault="unqualified">

<xs:element name="IHEYr4">

<xs:complexType>

<xs:sequence>

<xs:choice> 850 <xs:element name="ActorConfig">

<xs:complexType>

<xs:sequence>

<xs:element name="Description" type="xs:string">

<xs:annotation> 855 <xs:documentation>Vendor specific free text description of the configuration change</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element ref="User"/> 860 <xs:element name="ConfigType" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ActorStartStop"> 865 <xs:complexType>

<xs:sequence>

<xs:element name="ActorName" type="xs:string"/>

<xs:element name="ApplicationAction">

<xs:simpleType> 870 <xs:restriction base="xs:string">

<xs:enumeration value="Start"/>

<xs:enumeration value="Stop"/>

</xs:restriction>

</xs:simpleType> 875 </xs:element>

<xs:element ref="User"/>

</xs:sequence>

</xs:complexType>

</xs:element> 880 <xs:element name="AuditLogUsed">

<xs:complexType>

<xs:sequence>

<xs:element name="Usage" type="xs:string"/>

<xs:element ref="User"/> 885 </xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="BeginStoringInstances">

<xs:complexType> 890 <xs:complexContent>

<xs:extension base="BeginStoringInstancesType">

<xs:sequence>


__________________________________________________________________________


41

<xs:element name="RNode" type="RemoteNodeType"/> <xs:element ref="InstanceActionDescription"/> 895 </xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element> 900 <xs:element name="DICOMInstancesDeleted" type="InstancesAction"/>

<xs:element name="DICOMInstancesUsed" type="InstancesAction"/>

<xs:element name="DicomQuery">

<xs:complexType>

<xs:sequence> 905 <xs:element name="Keys" type="xs:base64Binary"/>

<xs:element name="Requestor" type="RemoteNodeType"/>

<xs:element name="CUID" type="xs:string"/>

<xs:element name="SyntaxUID" type="xs:string"/>

</xs:sequence> 910 </xs:complexType>

</xs:element>

<xs:element name="Export">

<xs:complexType>

<xs:complexContent> 915 <xs:extension base="MediaDescriptionType">

<xs:sequence>


</xs:sequence>

</xs:extension> 920 </xs:complexContent>

</xs:complexType>

</xs:element>

<xs:element name="Import">

<xs:complexType> 925 <xs:complexContent>

<xs:extension base="MediaDescriptionType">

<xs:sequence>


</xs:sequence> 930 </xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<xs:element name="InstancesSent"> 935 <xs:complexType>

<xs:complexContent>

<xs:extension base="RetrieveInstancesType">

<xs:sequence>

<xs:element name="RNode" type="RemoteNodeType"/> 940 <xs:element ref="InstanceActionDescription"/>

</xs:sequence>

</xs:extension>


__________________________________________________________________________


42

</xs:complexContent> </xs:complexType> 945 </xs:element>

<xs:element name="InstancesStored">

<xs:complexType>

<xs:sequence>

<xs:element name="RemoteNode" type="RemoteNodeType"/> 950 <xs:element ref="InstanceActionDescription"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="NetworkEntry"> 955 <xs:complexType>

<xs:sequence>

<xs:element name="MachineAction">

<xs:simpleType>

<xs:restriction base="xs:string"> 960 <xs:enumeration value="Attach"/>

<xs:enumeration value="Detach"/>

</xs:restriction>

</xs:simpleType>

</xs:element> 965 </xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="OrderRecord">

<xs:complexType> 970 <xs:sequence>

<xs:element name="ObjectAction">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Create"/> 975 <xs:enumeration value="Modify"/>

<xs:enumeration value="Access"/>

<xs:enumeration value="Delete"/>

</xs:restriction>

</xs:simpleType> 980 </xs:element>

<xs:element name="Patient" type="PatientType"/>


</xs:sequence>

</xs:complexType> 985 </xs:element>

<xs:element name="PatientRecord">

<xs:complexType>

<xs:sequence>

<xs:element name="ObjectAction"> 990 <xs:simpleType>


<xs:enumeration value="Create"/>


__________________________________________________________________________


43

<xs:enumeration value="Modify"/> <xs:enumeration value="Access"/> 995 <xs:enumeration value="Delete"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="Patient" type="PatientType"/> 1000 <xs:element ref="User"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ProcedureRecord"> 1005 <xs:complexType>

<xs:sequence>


<xs:simpleType>

<xs:restriction base="xs:string"> 1010 <xs:enumeration value="Create"/>

<xs:enumeration value="Modify"/>


<xs:enumeration value="Delete"/>

</xs:restriction> 1015 </xs:simpleType>

</xs:element>

<xs:element name="PlacerOrderNumber" type="xs:string"/>

<xs:element name="FillerOrderNumber" type="xs:string"/>

<xs:element name="SUID" type="xs:string"/> 1020 <xs:element name="AccessionNumber" type="xs:string" minOccurs="0"/>

<xs:element name="Patient" type="PatientType"/>

<xs:element name="User" type="UserType"/>

</xs:sequence>

</xs:complexType> 1025 </xs:element>

<xs:element name="SecurityAlert">

<xs:complexType>

<xs:sequence>

<xs:element name="AlertType" type="xs:string"/> 1030 <xs:element ref="User" minOccurs="0"/>

<xs:element name="Description" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element> 1035 <xs:element name="StudyDeleted" type="InstancesAction"/>

<xs:element name="UserAuthenticated">

<xs:complexType>

<xs:sequence>

<xs:element name="LocalUsername" type="xs:string"/> 1040 <xs:element name="Action">

<xs:simpleType>



__________________________________________________________________________


44

<xs:enumeration value="Login"/> <xs:enumeration value="Logout"/> 1045 <xs:enumeration value="Failure"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence> 1050 </xs:complexType>

</xs:element>

</xs:choice>

<xs:element name="Host" type="xs:string"/>

<xs:element name="TimeStamp" type="xs:dateTime"/> 1055 </xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="RemoteNodeType">

<xs:sequence> 1060 <xs:element name="IP" type="xs:string"/>

<xs:element name="Hname" type="xs:string" minOccurs="0"/>

<xs:element name="AET" type="xs:string" minOccurs="0"/>

</xs:sequence>

</xs:complexType> 1065 <xs:complexType name="MediaDescriptionType">

<xs:sequence>

<xs:element name="MediaID" type="xs:string" minOccurs="0"/>

<xs:element name="MediaType" minOccurs="0">

<xs:simpleType> 1070 <xs:restriction base="xs:string"/>

</xs:simpleType>

</xs:element>

<xs:element name="Patient" maxOccurs="unbounded">

<xs:annotation> 1075 <xs:documentation>Patients recorded onto media.</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:complexContent>

<xs:extension base="PatientType"> 1080 <xs:sequence>

<xs:element name="SUID" type="xs:string" minOccurs="0" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation>Mandatory if known</xs:documentation> 1085 </xs:annotation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent> 1090 </xs:complexType>

</xs:element>

<xs:element name="Destination" type="PrinterType" minOccurs="0"/>


__________________________________________________________________________


45

</xs:sequence> </xs:complexType> 1095 <xs:complexType name="UserType">

<xs:choice>

<xs:element name="LocalUser" type="xs:string"/>

<xs:element name="RemoteNode" type="RemoteNodeType"/>

</xs:choice> 1100 </xs:complexType>

<xs:complexType name="PrinterType">

<xs:choice>

<xs:element name="LocalPrinter" type="xs:string"/>

<xs:element name="Node" type="RemoteNodeType"/> 1105 </xs:choice>

</xs:complexType>

<xs:complexType name="UsageType"/>

<xs:complexType name="PatientType">

<xs:sequence> 1110 <xs:element name="PatientID" type="xs:string"/>

<xs:element name="PatientName" type="xs:string"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="RetrieveInstancesType"/> 1115 <xs:complexType name="BeginStoringInstancesType"/>

<xs:complexType name="InstancesAction">

<xs:sequence>


<xs:simpleType> 1120 <xs:restriction base="xs:string">

<xs:enumeration value="Create"/>

<xs:enumeration value="Modify"/>


<xs:enumeration value="Delete"/> 1125 </xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="AccessionNumber" type="xs:string" minOccurs="0"/>

<xs:element name="SUID" type="xs:string" maxOccurs="unbounded"/> 1130 <xs:element name="Patient" type="PatientType"/>

<xs:element ref="User" minOccurs="0"/>

<xs:element name="CUID" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="NumberOfInstances" type="xs:integer" minOccurs="0"/>

<xs:element name="MPPSUID" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> 1135 </xs:sequence>

</xs:complexType>

<xs:element name="User" type="UserType"/>

<xs:element name="InstanceActionDescription" type="InstancesAction"/>

</xs:schema> 1140

The commentary, explanation, and additional requirements beyond those enforced by the XML schema requirements, are provided below.


__________________________________________________________________________


46

The audit record schema is documented “top-down”, distinguishing the following structural elements:

• Auditable events: these compound audit record schema elements represent trigger events 1145 for generating an audit record. They consist of attributes.

• Audit record elements (re-usable schema elements) that are either

o Complex, describing a data object in the audit record that consists of several simple attributes or

o Simple, holding one single value. 1150

How to read the diagrams below:

Diagrams are read from left to right: elements to the right are part of the lefthandside element.

Required single element. A NetworkEntry element consists of exactly one MachineAction element. 1155

Optional single element. A NetworkEntry element consists of zero or one MachineAction element.

Optional multiple elements. A NetworkEntry element consists of zero or any number of MachineAction elements.

Selections of one out of several elements. A user consists 1160 either of a LocalUser element or of a RemoteNode element.

Compound element: The “+” in an element box means that the element consists of further elements. If these expansion elements have not occurred up to this point in the document, can be expected to follow below in the document.

1165

B.1 Auditable Events: schema elements representing trigger events IHEYr4

This element describes a complete audit record payload as defined by the IHE Technical Framework. Each audit record contains the following information: originating host, time stamp of occurrence and the 1170


__________________________________________________________________________


47

event-related details (e.g. ActorConfig, Export). (Note: The element name IHEYr4 has no correlation to any specific version of the Technical Framework).

diagram

ActorConfig

This audit record is generated by any actor on a Secure Node whenever the configuration for the actor is 1175 changed. The description of the configuration change is free text defined by the vendor and not specified by the IHE Technical Framework.


__________________________________________________________________________


48

This event is significant to security because inappropriate activity is often detected as inappropriate modifications to configuration information. The goal is not reconstruction of configuration changes. It is detection of inappropriate activity. 1180 The values for ConfigType can be:

1. “Networking” – for changes related to networking parameters

2. “Security” – for changes related to security parameters

3. Other vendor specific types can be used for changes that are not related to networking parameters or security parameters. 1185

diagram

ActorStartStop

This audit record is generated for any actor that is on a Secure Node.

Legal values for ApplicationAction are “Start” and “Stop”. 1190 The ActorName is an arbitrary name assigned by the vendor. It need only be unique on this host. The combination of host and ActorName may be used to identify specific hardware, software, or usage. Therefore it is permissible for this name to be the same for on different hosts. But if the same application can be started multiple times on one machine and acting as different actors, the name shall enable the different actors to be separated. 1195

diagram


__________________________________________________________________________


49

AuditLogUsed

This audit record may be generated by the Audit Repository actor.

It is generated when there is audit log activity other than arrival and storage of audit records. The usage information is a free text description. 1200

diagram

BeginStoringInstances

This audit record is generated whenever any of the following Actors begins sending a new study, or sending additional instances for an existing study. Since this audit record is generated when the study 1205 transmission begins, the instance count may be unknown. This audit record is generated by the Actor that is sending the instances.

Actors that may generate this audit record:

Acquisition Modality

Image Archive 1210 Evidence Creator

Report Creator

Report Repository

Report Manager

External Report Repository Access. 1215 The RNode element indicates the remote node to which the instances are being stored.

The InstanceActionDescription element includes a User. The User is probably a local user. In situations where remote users are permitted to control storage, the remote user description may also include a remote node. The XML structure resolves any ambiguity in the meaning of common subcomponents.

1220 diagram

DICOMInstancesDeleted

This audit record is generated by:


Evidence Creator 1225 Report Creator.


__________________________________________________________________________


50

The deletion audit records are important for these actors because this denotes the end of potential exposure of this patient information. It is common on these devices for the operator to have access to all of the locally stored patient information. The deleted objects are always identified by its Study UID (SUID). SOP Class UIDs (CUID) and Modality Performed Procedure Step UIDs (MPPSUID) can be 1230 recorded optionally.

(See also: StudyDeleted). diagram

DICOMInstancesUsed

This audit record is sent whenever locally stored information is created, modified, or accessed. It shall 1235 summarize all accesses for a single patient into a single audit record. It may be sent by:


Evidence Creator

Image Display

Report Creator 1240 Report Manager.

The generating Actor shall attempt to summarize the instance usage activity and limit the number of these records generated. Given the immense variety of use patterns that a radiologist may have in viewing studies it may be difficult to summarize perfectly, so occasional extra audit records are acceptable. One heuristic is to accumulate information regarding images examined until the acquisition or analysis is 1245 complete, and then send the summary at completion of acquisition or image analysis.

The used objects are always identified by its Study UIDs (SUID). SOP Class UIDs (CUID) and Modality Performed Procedure Step UIDs (MPPSUID) can be recorded optionally.


__________________________________________________________________________


51

diagram

1250 DicomQuery

This audit record may be generated by any actor that is capable of receiving a C-FIND query and is on a secure node.

The generation of this audit record shall be controllable based on the SOP Class UID (CUID) that is used for the query. For example, an actor that can respond to both Modality Worklist queries and Image 1255 Availability queries may be configured to generate audit records only for the Modality Worklist queries. The Technical Framework specifies only certain CUIDs on certain Actors as mandatory.

The CUID in this audit record is the SOP Class UID for the query, e.g. Modality Worklist – FIND. This audit record describes the query, not the response.

The Keys are captured as the Base64 encoding of the DICOM query dataset. This enables capture of 1260 matching keys, optional keys, etc. The SyntaxUID contains the DICOM transfer syntax UID for the data that has been captured. The Requestor is the remote node that issued the query.

diagram


__________________________________________________________________________


52

Export 1265 This audit record is generated by any Actor that is capable of exporting data to media and is on a Secure Node.

Note that print, fax, voice playout, etc. are also forms of export. This is why the MediaID, MediaType, and Destination are all optional. The appropriate entry or entries shall be selected to describe the output.

The Patient data consists of patient identification and imported objects’ identifications. 1270

diagram

Import

This audit record may be generated by any actor on a Secure Node that is capable of performing a media import. The Patient data consists of Patient identification and imported objects’ identifications. 1275


__________________________________________________________________________


53

diagram

InstancesSent

This audit record is sent upon completion of the transmission of a study. It is sent by the actor that is transmitting the study, which may be an Image Archive. 1280

diagram

InstancesStored This audit record is generated by an Image Archive, after it has completely received the images for a study. DICOM lacks an “end of study” indicator, so this may entail some guessing by the Image Archive. 1285 It is permitted to have multiple InstancesStored audit records sent during the transmission of a study. The Image Archive may attempt to limit the number of InstancesStored audit records generated by means of reasonable heuristics. Most archives already employ such heuristics to optimize storage performance.

diagram

1290 NetworkEntry

This audit record is generated by any secure node that is capable of mobile operations or that is on a deliberately interruptible connection.


__________________________________________________________________________


54

The event is needed for machines that can detach and reconnect to the secure domain as a normal and expected situation. It is not intended to report network problems, loose cables, or other un-intentional 1295 detach and reconnect situations.

The machine shall send this message prior to detaching. In the event that this is not possible, it shall retain the message in a local buffer so that it can be sent later. The mobile machine then captures audit messages in a local buffer while it is outside the secure domain. When it is reconnected to the secure domain, it sends the detach message (if buffered), followed by the buffered messages, followed by a 1300 mobile machine message for rejoining the secure domain. The timestamps on these messages shall be the time that the event occurred, not the time that the message is sent.

MachineAction describes a connection or disconnection as values “Attach” or “Detach”, respectively.

diagram

1305 OrderRecord

This audit record is generated by an Order Placer or DSS/Order Filler actor whenever an order record is created, accessed, modified, or deleted.

diagram

1310 PatientRecord

This audit record is generated by an ADT Patient Registration, DSS/Order Filler or Order Placer actor, whenever a patient record is created, modified, or accessed.

diagram

1315 ProcedureRecord

This audit record is generated by:

DSS/Order Filler whenever a patient procedure record is created, modified, accessed, or deleted.


__________________________________________________________________________


55

diagram

1320 SecurityAlert

This audit record is generated by any Actor on a secure node whenever a node needs to report a security alert. The IHE Technical Framework specifically requires reporting a SecurityAlert for TLS authentication failures. Secure nodes may choose to report alerts for other security related situations that are not described by IHE audit events. 1325 The failure that caused the alert shall be described as code in the AlertType as follows:

1. “NodeAuthenticationFailure” if there has been an authentication failure during TLS setup. (Successful TLS connections do not generate SecurityAlert.)

2. Other vendor specific codes for other kinds of security alerts.

Description allows additional free text details on reasons or circumstances for the security alert. 1330 If the security alert can be related to a specific user, the User attribute shall be present.

diagram

StudyDeleted

This audit record is generated by an Image Manager/Image Archive or Report Repository actor whenever 1335 a study, or a portion of a study, is deleted from the archive.

The deleted objects are always identified by its Study UIDs (SUID). SOP Class UIDs (CUID) and Modality Performed Procedure Step UIDs (MPPSUID) can be recorded optionally.

(See also: DICOMInstancesDeleted).


__________________________________________________________________________


56

1340 diagram

UserAuthenticated

This audit record may be generated by any Secure Node.

The legal values for Action are: “Login”, “Logout”, and “Failure”. In the case of authentication failure, the LocalUsername shall be the name given during the attempt. 1345

diagram

B.2 Audit record elements: schema elements representing audit record objects

AccessionNumber The DICOM Accession Number represented as a string. 1350

Action

Action describes what happens during a user authentication event (UserAuthenticated). The legal values for Action are: “Login”, “Logout”, and “Failure”.


__________________________________________________________________________


57

1355

ActorName The ActorName is an arbitrary name assigned by the vendor. It need only be unique on this host. The combination of host and ActorName may be used to identify specific hardware, software, or usage. Therefore it is permissible for this name to be the same for on different hosts. But if the same application can be started multiple times on one machine and acting as different actors, the 1360 name shall enable the different actors to be separated.

AET AET holds a free text value for the DICOM Application Entity Title to identify a machine user running on a network node (a remote node). 1365

AlertType A string that conveys a description of the kind of event that raised the security alert. This can either be a specific code or a free text value. If there has been an authentication failure during TLS setup then the value shall be:“NodeAuthenticationFailure” otherwise the value is 1370 application defined.

ApplicationAction A controlled text describing the running status of an application or actor for the event ActorStartStop. Legal values are “Start” and “Stop”. 1375

ConfigType ConfigType describes which kind of configuration activity took place for an actor. The values for ConfigType can be:

• “Networking” – for changes related to networking parameters 1380

• “Security” – for changes related to security parameters

• Other vendor specific types can be used for changes that are not related to networking parameters or security parameters.

CUID 1385 The SOP Class UID describes what type of DICOM objects were used by an actor and may influence the generation or interpretation of an audit record, e.g. in DICOMQuery.


__________________________________________________________________________


58

Description A free text description that allows additional details to be given in certain event records, e.g. 1390 ActorConfig, SecurityAlert.

Destination The Destination value holds the import target of a media import activity, e.g. a printer or a network node. 1395

diagram

FillerOrderNumber The identifier for an order issued by the Order Filler.

Hname (used in RemoteNode) 1400

The name (hostname) that identifies a remote node in a network domain.

Host (used in the audit record root element IHEYr4)

The hostname element duplicates the hostname from the syslog message. It is provided to simplify the processing of the XML content by making the XML body complete and independent 1405 of the syslog framing.

InstanceActionDescription, InstancesAction The InstanceActionDescription element and the InstancesAction element type describe actions on patient data, e.g. delete or transfer image objects. The type of action performed is specified by 1410 controlled text in ObjectAction (e.g. create, read).

The Patient element identifies the patient to which the data belongs to. The patient data objects used are identified by the Study UID (SUID). It is not necessary in every case to identify all objects worked on, so that a summary audit record may state the number of data objects worked on (NumberOfInstances, e.g. for specifying that 523 images were transferred). 1415

Optionally, the usage context can be further specified by identifying the performing user (User), the DICOM object’s SOP Class UIDs (CUID) or related MPPS UIDs (MPPSUID).


__________________________________________________________________________


59

diagram

IP The IP address that identifies a remote node in a network.

1420

Keys This value holds a representation of a DICOM query. Its binary format (base64Binary) allows any query keys (e.g. matching keys, optional keys) to be captured. The SyntaxUID of the DICOMQuery audit record is necessary to interpret this binary value.

1425

LocalPrinter This element from the PrinterType audit record object holds data to describe a local printer in contrast to a printer connected to a remote node.

LocalUser 1430 The LocalUser specifies a human or machine user by a name assigned to a person or to an automatic process. This name is unqiue in a circumscribed environment only, in contrast to remote users that are defined by a RemoteNodeType.

LocalUsername 1435


__________________________________________________________________________


60

The LocalUsername is a free text that identifies a user in a certain domain, e.g. during a username/ password logon.

MachineAction MachineAction describes a network connectivity event (NetworkEntry) of a machine, which is 1440 connection to or disconnection from the network. The legal values are “Attach” and “Detach”, respectively.

MediaDescriptionType The MediaDescriptionType contains the data to describe a removable medium and patient 1445 imaging data stored on it. This data is used for describing media import and export events.

The medium identification (MediaID), type of medium (MediaType) or data transfer target (Destination) cannot always be stated. This may relate to print, fax, voice playout, or other multimedia im-/export.

The identification of the one or more patients whose data is stored on the medium, must always 1450 be present. If available, the Study UIDs (SUID) of DICOM objects shall be present in the patient data so that they are clearly associated.

diagram

MediaID This string holds an identifier of the removable media used for data import or export. This 1455 identifier can be a removable media volume ID, a DICOM FilesetID, an e-mail address, a filename, a telephone number, or any other ID as appropriate.


__________________________________________________________________________


61

MediaType This string describes the media type imported or exported, which may be a hardcopy type (e.g. 1460 “paper”, “film”), or a digital medium type (e.g. “CD-R”, “fax”, “file”).

MPPSUID A Modality Performed Procedure Step UID can be conveyed in this audit record attribute for events that describe actions on a patient’s DICOM objects. 1465

Node This audit record element describes the identification of a remote node in the network (see RemoteNode) for a printer (PrinterType).

diagram

1470

NumberOfInstances This attribute holds the number of data objects used as a summary in one single audit record instead of generating an own audit record for each instance action (see InstancesAction).

ObjectAction 1475

This attribute describes the type of action performed on an imaging object. Legal values are “Create”, “Modify”, “Access”, “Delete”.

Patient This element always describes a patient by basic identification data: a free text system identifier 1480 and patient name.

The events InstancesAction, PatientRecord, ProcedureRecord, OrderRecord use it in the following way:


__________________________________________________________________________


62

diagram

The media-related events Import and Export use the Patient element by adding identifiers of this patient’s imaging objects that are stored on the medium (see MediaDescriptionType). 1485

diagram

PatientID A free text that holds a system-internal patient identifier being unique within that system domain.

PatientName 1490 The free text name of the patient to whom the imaging objects used belong to.

PlacerOrderNumber The identifier for a requested imaging procedure issued by the Order Placer.

1495

PrinterType This element identifies a printer as a destination of data export. The printer is either connected locally and is identified by a free text name (LocalPrinter) or is connected to a remote node which is identified as defined in RemoteNode (Node).

diagram

1500


__________________________________________________________________________


63

RemoteNode, RNode, Node These elements, describing a node in the network, have the same structure (of type RemoteNodeType). The network node is viewed “remote” when it is connected to a network and is not the node where current activity takes places (local node). A remote node is identified by

• IP Address (IP), either IPv4 dotted-decimal notation, or IPv6 hexadecimal notation 1505

• Hostname (Hname), if known

• Application Entity Title (AET), if applicable. diagram

Requestor In the context of a DicomQuery event, the Requestor is the remote node that issued the query. 1510

diagram

SUID The Study UID identifying a DICOM object that was used.

SyntaxUID 1515 The SyntaxUID contains the DICOM transfer syntax UID that allows interpreting the query key data that has been captured in an audit record for a DICOMQuery event.

TimeStamp (used in the audit record root element IHEYr4)

This is the time when the event occurred or was detected. Note that the XML dateTime datatype 1520 requires either UTC or an offset to UTC. This may duplicate fields in the Syslog message. It is


__________________________________________________________________________


64

provided to simplify the processing of the XML content by making the XML body complete and independent of the syslog framing.

Usage 1525 A free text to describe how audit records from the audit repository were used in cases other than receiving or storage (e.g. a privacy officer reviewing a selection of audit records stored).

User This element identifies a user that performs activities generating audit records. The user 1530 identification is either a username defined in a circumscribed domain (LocalUser) or, if a remote machine acts as a user, is a remote node identification (RemoteNode).

diagram


__________________________________________________________________________


65

Appendix G – Transition from Radiology Basic Security to ATNA

G.1 Message Transformation 1535

The IHE Provisional messages can be transformed into equivalent Audit Trail messages by various means. One such is the use of an XSLT. The following XSLT is an illustrative example of such a transformation. It has not been tested or verified on the full range of real world messages, nor does it include much error processing, but it does transform properly formed IHE Provisional audit trail messages into the RFC-XXXX format. It is provided for educational 1540 purposes only.

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:msxsl="urn:schemas-microsoft-1545 com:xslt" xmlns:js="javascript:code"> <xsl:output method="xml" encoding="UTF-8"/> <msxsl:script language="JScript" implements-prefix="js"><![CDATA[ function encode64(i) // base 64 encoding { 1550 var k = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="; var o = ""; var c1, c2, c3, e1, e2, e3, e4 = ""; var l = 0; do 1555 { c1 = i.charCodeAt(l++); c2 = i.charCodeAt(l++); c3 = i.charCodeAt(l++); e1 = c1 >> 2; 1560 e2 = ((c1 & 3) << 4) | (c2 >> 4); e3 = ((c2 & 15) << 2) | (c3 >> 6); e4 = c3 & 63; if (isNaN(c2)) e3 = e4 = 64; 1565 else if (isNaN(c3)) e4 = 64; o = o + k.charAt(e1) + k.charAt(e2) + k.charAt(e3) + k.charAt(e4); c1 = c2 = c3 = e1 = e2 = e3 = e4 = ""; } 1570 while (l < i.length); return o; } ]]></msxsl:script> <xsl:template match="/IHEYr4"> 1575 <AuditMessage> <xsl:attribute name="xsi:noNamespaceSchemaLocation">http://www.xml.org/xml/schema/7f0d86bd/healthcare-security-audit.xsd</xsl:attribute> <EventIdentification> 1580 <xsl:attribute name="EventDateTime"><xsl:value-of select="TimeStamp"/></xsl:attribute> <xsl:apply-templates mode="EventIdentification"/> </EventIdentification> <xsl:apply-templates mode="ActiveParticipant"/> 1585 <xsl:apply-templates mode="AuditSourceIdentification"/> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </AuditMessage> </xsl:template>

__________________________________________________________________________


66

 1590   <xsl:template mode="EventIdentification" match="ActorConfig"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'E'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> 1595 <EventID> <xsl:attribute name="code"><xsl:value-of select="'ActorConfig'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> 1600 <xsl:template mode="EventIdentification" match="ActorStartStop"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'E'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'ActorStartStop'"/></xsl:attribute> 1605 </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="AuditLogUsed"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'R'"/></xsl:attribute> 1610 <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'AuditLogUsed'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> 1615 </xsl:template> <xsl:template mode="EventIdentification" match="BeginStoringInstances"> <xsl:apply-templates mode="EventIdentification" select="InstanceActionDescription"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> 1620 <xsl:attribute name="code"><xsl:value-of select="'BeginStoringInstances'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> 1625 <xsl:template mode="EventIdentification" match="DICOMInstancesDeleted"> <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of 1630 select="'DICOMInstancesDeleted'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="DICOMInstancesUsed"> 1635 <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'DICOMInstancesUsed'"/></xsl:attribute> </EventID> 1640 <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="DicomQuery"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'E'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> 1645 <EventID> <xsl:attribute name="code"><xsl:value-of select="'DICOMQuery'"/></xsl:attribute> </EventID> </xsl:template> <xsl:template mode="EventIdentification" match="Export"> 1650 <xsl:attribute name="EventActionCode"><xsl:value-of select="'R'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'Export'"/></xsl:attribute> </EventID> 1655


__________________________________________________________________________


67

</xsl:template> <xsl:template mode="EventIdentification" match="Import"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'C'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> 1660 <xsl:attribute name="code"><xsl:value-of select="'Import'"/></xsl:attribute> </EventID> </xsl:template> <xsl:template mode="EventIdentification" match="InstanceActionDescription"> <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> 1665 </xsl:template> <xsl:template mode="EventIdentification" match="InstancesSent"> <xsl:apply-templates mode="EventIdentification" select="InstanceActionDescription"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> 1670 <xsl:attribute name="code"><xsl:value-of select="'InstancesSent'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="InstancesStored"> 1675 <xsl:apply-templates mode="EventIdentification" select="InstanceActionDescription"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'InstancesStored'"/></xsl:attribute> </EventID> 1680 <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="NetworkEntry"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'E'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> 1685 <EventID> <xsl:attribute name="code"><xsl:value-of select="'NetworkEntry'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> 1690 <xsl:template mode="EventIdentification" match="ObjectAction"> <xsl:attribute name="EventActionCode"><xsl:choose><xsl:when test=". = 'Create'"><xsl:value-of select="'C'"/></xsl:when><xsl:when test=". = 'Access'"><xsl:value-of select="'R'"/></xsl:when><xsl:when test=". = 'Modify'"><xsl:value-of select="'U'"/></xsl:when><xsl:when test=". = 'Delete'"><xsl:value-of 1695 select="'D'"/></xsl:when><xsl:otherwise><xsl:value-of select="'E'"/></xsl:otherwise></xsl:choose></xsl:attribute> </xsl:template> <xsl:template mode="EventIdentification" match="OrderRecord"> <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> 1700 <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'OrderRecord'"/></xsl:attribute> </EventID> </xsl:template> 1705 <xsl:template mode="EventIdentification" match="PatientRecord"> <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'PatientRecord'"/></xsl:attribute> 1710 </EventID> </xsl:template> <xsl:template mode="EventIdentification" match="ProcedureRecord"> <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> 1715 <EventID> <xsl:attribute name="code"><xsl:value-of select="'ProcerdureRecord'"/></xsl:attribute> </EventID> </xsl:template> <xsl:template mode="EventIdentification" match="SecurityAlert"> 1720 <xsl:attribute name="EventActionCode"><xsl:value-of select="'E'"/></xsl:attribute>

__________________________________________________________________________


68

<xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'SecurityAlert'"/></xsl:attribute> </EventID> 1725 <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="StudyDeleted"> <xsl:apply-templates mode="EventIdentification" select="ObjectAction"/> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> 1730 <EventID> <xsl:attribute name="code"><xsl:value-of select="'StudyDeleted'"/></xsl:attribute> </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> 1735 <xsl:template mode="EventIdentification" match="UserAuthenticated"> <xsl:attribute name="EventActionCode"><xsl:value-of select="'E'"/></xsl:attribute> <xsl:attribute name="EventOutcomeIndicator"><xsl:value-of select="0"/></xsl:attribute> <EventID> <xsl:attribute name="code"><xsl:value-of select="'UserAuthenticated'"/></xsl:attribute> 1740 </EventID> <xsl:apply-templates mode="EventTypeCode"/> </xsl:template> <xsl:template mode="EventIdentification" match="*"/>  1745   <xsl:template mode="EventTypeCode" match="Action"> <EventTypeCode> <xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute> 1750 </EventTypeCode> </xsl:template> <xsl:template mode="EventTypeCode" match="AlertType"> <EventTypeCode> <xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute> 1755 </EventTypeCode> </xsl:template> <xsl:template mode="EventTypeCode" match="ApplicationAction"> <EventTypeCode> <xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute> 1760 </EventTypeCode> </xsl:template> <xsl:template mode="EventTypeCode" match="ConfigType"> <EventTypeCode> <xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute> 1765 </EventTypeCode> </xsl:template> <xsl:template mode="EventTypeCode" match="MachineAction"> <EventTypeCode> <xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute> 1770 </EventTypeCode> </xsl:template> <xsl:template mode="EventTypeCode" match="*"/>   1775  <xsl:template mode="ActiveParticipant" match="ActorConfig"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="ActorName"> 1780 <ActiveParticipant> <xsl:attribute name="UserID"><xsl:value-of select="."/></xsl:attribute> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> </ActiveParticipant> </xsl:template> 1785 <xsl:template mode="ActiveParticipant" match="ActorStartStop"> <xsl:apply-templates mode="ActiveParticipant"/>


__________________________________________________________________________


69

</xsl:template> <xsl:template mode="ActiveParticipant" match="AET"> <xsl:attribute name="AlternativeUserID"><xsl:value-of select="."/></xsl:attribute> 1790 </xsl:template> <xsl:template mode="ActiveParticipant" match="AuditLogUsed"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="BeginStoringInstances"> 1795 <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="Destination"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> 1800 <xsl:template mode="ActiveParticipant" match="DICOMInstancesDeleted"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="DICOMInstancesUsed"> <xsl:apply-templates mode="ActiveParticipant"/> 1805 </xsl:template> <xsl:template mode="ActiveParticipant" match="DicomQuery"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="Export"> 1810 <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="Hname"> <xsl:attribute name="UserName"><xsl:value-of select="."/></xsl:attribute> </xsl:template> 1815 <xsl:template mode="ActiveParticipant" match="Import"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="InstanceActionDescription"> <xsl:apply-templates mode="ActiveParticipant"/> 1820 </xsl:template> <xsl:template mode="ActiveParticipant" match="InstancesSent"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="InstancesStored"> 1825 <ActiveParticipant> <xsl:apply-templates mode="ActiveParticipant" select="RemoteNode"/> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="true()"/></xsl:attribute> </ActiveParticipant> </xsl:template> 1830 <xsl:template mode="ActiveParticipant" match="IP"> <xsl:attribute name="UserID"><xsl:value-of select="'node'"/></xsl:attribute> <xsl:attribute name="NetworkAccessPointID"><xsl:value-of select="."/></xsl:attribute> <xsl:attribute name="NetworkAccessPointTypeCode"><xsl:value-of select="2"/></xsl:attribute> </xsl:template> 1835 <xsl:template mode="ActiveParticipant" match="LocalPrinter"> <ActiveParticipant> <xsl:attribute name="UserID"><xsl:value-of select="."/></xsl:attribute> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> <RoleIDCode> 1840 <xsl:attribute name="code"><xsl:value-of select="'Printer'"/></xsl:attribute> </RoleIDCode> </ActiveParticipant> </xsl:template> <xsl:template mode="ActiveParticipant" match="LocalUser"> 1845 <xsl:attribute name="UserID"><xsl:value-of select="."/></xsl:attribute> </xsl:template> <xsl:template mode="ActiveParticipant" match="LocalUsername"> <ActiveParticipant> <xsl:attribute name="UserID"><xsl:value-of select="."/></xsl:attribute> 1850 <xsl:attribute name="UserIsRequestor"><xsl:value-of select="true()"/></xsl:attribute> </ActiveParticipant> </xsl:template>

__________________________________________________________________________


70

<xsl:template mode="ActiveParticipant" match="MediaID"> <ActiveParticipant> 1855 <xsl:attribute name="UserID"><xsl:value-of select="."/></xsl:attribute> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> <xsl:apply-templates mode="ActiveParticipantRoleIDCode" select="../MediaType"/> </ActiveParticipant> </xsl:template> 1860 <xsl:template mode="ActiveParticipant" match="NetworkEntry"> <ActiveParticipant> <xsl:attribute name="UserID"><xsl:value-of select="../Host"/></xsl:attribute> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> </ActiveParticipant> 1865 </xsl:template> <xsl:template mode="ActiveParticipant" match="Node"> <ActiveParticipant> <xsl:apply-templates mode="ActiveParticipant"/> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> 1870 </ActiveParticipant> </xsl:template> <xsl:template mode="ActiveParticipant" match="OrderRecord"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> 1875 <xsl:template mode="ActiveParticipant" match="PatientRecord"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="ProcedureRecord"> <xsl:apply-templates mode="ActiveParticipant"/> 1880 </xsl:template> <xsl:template mode="ActiveParticipant" match="RemoteNode"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> <xsl:template mode="ActiveParticipant" match="Requestor"> 1885 <ActiveParticipant> <xsl:apply-templates mode="ActiveParticipant"/> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="true()"/></xsl:attribute> </ActiveParticipant> </xsl:template> 1890 <xsl:template mode="ActiveParticipant" match="RNode"> <ActiveParticipant> <xsl:apply-templates mode="ActiveParticipant"/> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> </ActiveParticipant> 1895 </xsl:template> <xsl:template mode="ActiveParticipant" match="SecurityAlert"> <xsl:apply-templates mode="ActiveParticipant"/> <ActiveParticipant> <xsl:attribute name="UserID"><xsl:value-of select="../Host"/></xsl:attribute> 1900 <xsl:attribute name="UserIsRequestor"><xsl:value-of select="false()"/></xsl:attribute> </ActiveParticipant> </xsl:template> <xsl:template mode="ActiveParticipant" match="StudyDeleted"> <xsl:apply-templates mode="ActiveParticipant"/> 1905 </xsl:template> <xsl:template mode="ActiveParticipant" match="User"> <ActiveParticipant> <xsl:apply-templates mode="ActiveParticipant"/> <xsl:attribute name="UserIsRequestor"><xsl:value-of select="true()"/></xsl:attribute> 1910 </ActiveParticipant> </xsl:template> <xsl:template mode="ActiveParticipant" match="UserAuthenticated"> <xsl:apply-templates mode="ActiveParticipant"/> </xsl:template> 1915 <xsl:template mode="ActiveParticipant" match="*"/>

__________________________________________________________________________


71

<xsl:template mode="ActiveParticipantRoleIDCode" match="MediaType"> 1920 <RoleIDCode> <xsl:attribute name="code"><xsl:value-of select="."/></xsl:attribute> </RoleIDCode> </xsl:template> <xsl:template mode="ActiveParticipantRoleIDCode" match="*"/> 1925    <xsl:template mode="AuditSourceIdentification" match="Host"> <AuditSourceIdentification> 1930 <xsl:attribute name="AuditSourceID"><xsl:value-of select="."/></xsl:attribute> </AuditSourceIdentification> </xsl:template> <xsl:template mode="AuditSourceIdentification" match="*"/>  1935   <xsl:template mode="ParticipantObjectIdentification" match="BeginStoringInstances"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> 1940 <xsl:template mode="ParticipantObjectIdentification" match="DICOMInstancesDeleted"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="DICOMInstancesUsed"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> 1945 </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="DicomQuery"> <ParticipantObjectIdentification> <xsl:attribute name="ParticipantObjectTypeCode"><xsl:value-of select="2"/></xsl:attribute> 1950 <xsl:attribute name="ParticipantObjectTypeCodeRole"><xsl:value-of select="3"/></xsl:attribute> <xsl:attribute name="ParticipantObjectID"><xsl:value-of select="CUID"/></xsl:attribute> <ParticipantObjectIDTypeCode> <xsl:attribute name="code"><xsl:value-of select="'2'"/></xsl:attribute> 1955 </ParticipantObjectIDTypeCode> <xsl:apply-templates mode="ParticipantObjectQuery" select="Keys"/> <xsl:apply-templates mode="ParticipantObjectDetail" select="SyntaxUID"/> </ParticipantObjectIdentification> </xsl:template> 1960 <xsl:template mode="ParticipantObjectIdentification" match="Export"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="Import"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> 1965 </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="InstanceActionDescription"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="InstancesSent"> 1970 <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="InstancesStored"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> 1975 <xsl:template mode="ParticipantObjectIdentification" match="OrderRecord"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="Patient"> <ParticipantObjectIdentification> 1980 <xsl:apply-templates mode="ParticipantObjectIdentification" select="PatientID"/> <xsl:attribute name="ParticipantObjectTypeCode"><xsl:value-of select="1"/></xsl:attribute> <xsl:attribute name="ParticipantObjectTypeCodeRole"><xsl:value-of select="1"/></xsl:attribute> 1985

__________________________________________________________________________


72

<ParticipantObjectIDTypeCode> <xsl:attribute name="code"><xsl:value-of select="'2'"/></xsl:attribute> </ParticipantObjectIDTypeCode> <xsl:apply-templates mode="ParticipantObjectIdentification" select="PatientName"/> <xsl:apply-templates mode="ParticipantObjectDetail" select="../SUID"/> 1990 </ParticipantObjectIdentification> <xsl:apply-templates mode="ParticipantObjectIdentification" select="SUID"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="PatientID"> <xsl:attribute name="ParticipantObjectID"><xsl:value-of select="."/></xsl:attribute> 1995 </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="PatientName"> <ParticipantObjectName> <xsl:value-of select="."/> </ParticipantObjectName> 2000 </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="PatientRecord"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="ProcedureRecord"> 2005 <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="SecurityAlert"> <ParticipantObjectIdentification> <xsl:attribute name="ParticipantObjectID"><xsl:value-of 2010 select="../Host"/></xsl:attribute> <xsl:attribute name="ParticipantObjectTypeCode"><xsl:value-of select="2"/></xsl:attribute> <xsl:attribute name="ParticipantObjectTypeCodeRole"><xsl:value-of select="13"/></xsl:attribute> 2015 <ParticipantObjectIDTypeCode> <xsl:attribute name="code"><xsl:value-of select="12"/></xsl:attribute> </ParticipantObjectIDTypeCode> <xsl:apply-templates mode="ParticipantObjectDetail" select="Description"/> </ParticipantObjectIdentification> 2020 </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="StudyDeleted"> <xsl:apply-templates mode="ParticipantObjectIdentification"/> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="SUID"> 2025 <ParticipantObjectIdentification> <xsl:attribute name="ParticipantObjectID"><xsl:value-of select="."/></xsl:attribute> <xsl:attribute name="ParticipantObjectTypeCode"><xsl:value-of select="2"/></xsl:attribute> <xsl:attribute name="ParticipantObjectTypeCodeRole"><xsl:value-of 2030 select="3"/></xsl:attribute> <ParticipantObjectIDTypeCode> <xsl:attribute name="code"><xsl:value-of select="'9'"/></xsl:attribute> </ParticipantObjectIDTypeCode> <xsl:apply-templates mode="ParticipantObjectDetail" select="../AccessionNumber"/> 2035 <xsl:apply-templates mode="ParticipantObjectDetail" select="../CUID"/> <xsl:apply-templates mode="ParticipantObjectDetail" select="../FillerOrderNumber"/> <xsl:apply-templates mode="ParticipantObjectDetail" select="../NumberOfInstances"/> <xsl:apply-templates mode="ParticipantObjectDetail" select="../MPPSUID"/> <xsl:apply-templates mode="ParticipantObjectDetail" select="../PlacerOrderNumber"/> 2040 </ParticipantObjectIdentification> </xsl:template> <xsl:template mode="ParticipantObjectIdentification" match="*"/>   2045  <xsl:template mode="ParticipantObjectDetail" match="AccessionNumber"> <ParticipantObjectDetail> <xsl:attribute name="type"><xsl:value-of select="'AccessionNumber'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of 2050 select="js:encode64(string(.))"/></xsl:attribute>

__________________________________________________________________________


73

</ParticipantObjectDetail> </xsl:template> <xsl:template mode="ParticipantObjectDetail" match="CUID"> <ParticipantObjectDetail> 2055 <xsl:attribute name="type"><xsl:value-of select="'ContainsSOPClass'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> </xsl:template> 2060 <xsl:template mode="ParticipantObjectDetail" match="Description"> <ParticipantObjectDetail> <xsl:attribute name="type"><xsl:value-of select="'Description'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of select="js:encode64(string(.))"/></xsl:attribute> 2065 </ParticipantObjectDetail> </xsl:template> <xsl:template mode="ParticipantObjectDetail" match="FillerOrderNumber"> <ParticipantObjectDetail> <xsl:attribute name="type"><xsl:value-of select="'FillerOrderNumber'"/></xsl:attribute> 2070 <xsl:attribute name="value"><xsl:value-of select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> </xsl:template> <xsl:template mode="ParticipantObjectDetail" match="MPPSUID"> 2075 <ParticipantObjectDetail> <xsl:attribute name="type"><xsl:value-of select="'ContainsMPPS'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> 2080 </xsl:template> <xsl:template mode="ParticipantObjectDetail" match="NumberOfInstances"> <ParticipantObjectDetail> <xsl:attribute name="type"><xsl:value-of select="'NumberOfInstances'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of 2085 select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> </xsl:template> <xsl:template mode="ParticipantObjectDetail" match="PlacerOrderNumber"> <ParticipantObjectDetail> 2090 <xsl:attribute name="type"><xsl:value-of select="'PlacerOrderNumber'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> </xsl:template> 2095 <xsl:template mode="ParticipantObjectDetail" match="SUID"> <ParticipantObjectDetail> <xsl:attribute name="type"><xsl:value-of select="'ContainsSOPInstances'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of 2100 select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> </xsl:template> <xsl:template mode="ParticipantObjectDetail" match="SyntaxUID"> <ParticipantObjectDetail> 2105 <xsl:attribute name="type"><xsl:value-of select="'TransferSyntax'"/></xsl:attribute> <xsl:attribute name="value"><xsl:value-of select="js:encode64(string(.))"/></xsl:attribute> </ParticipantObjectDetail> </xsl:template> 2110 <xsl:template mode="ParticipantObjectDetail" match="*"/>    <xsl:template mode="ParticipantObjectQuery" match="Keys"> 2115 <ParticipantObjectQuery> <xsl:value-of select="."/>

__________________________________________________________________________


74

</ParticipantObjectQuery> </xsl:template> <xsl:template mode="ParticipantObjectQuery" match="*"/> 2120    <xsl:template match="*"/> </xsl:stylesheet> 2125

5 ihe it infrastructure technical framework supplement … · · 2005-03-30ihe it infrastructure...

Documents